Hysteresis Posted March 28, 2019 Share Posted March 28, 2019 Hello everyone, I just bought my BashBunny and I'm trying to get the Quickreds and BunnyTap payloads working but I'm having trouble getting them to work. Here is the detailed description of my issues and what have been done until now. #### INITIAL CONFIG ##### I'm on a Windows 10 machine without any antivirus (and I disabled the Windows firewall too for the test). First of all, here's what I did on my BashBunny: 1) I successfully updated the firmware by downloading the update file here https://wiki.bashbunny.com/downloads.html, my version is 1.5_298. 2) I copied all the files in the Github repo to the root of my BashBunny. 3) I installed the following tools: impacket, gohhtp and responder by placing the.deb files (found here : https://forums.hak5.org/topic/40971-info-tools/ in the tools folder. I checked that the tools were installed correctly by connecting in serial mode to the BashBunny with Putty, the tools are in the /root/tools folder. 4) In addition, I completed the installation of Impacket with a "python setup.py install" in the Impacket folder (/root/tools/impacket) 5) I checked the network interfaces in /etc/network and the interfaces are well configured ### BUNNYTAP PAYLOAD TEST #### 1) I want to start the payload "BunnyTap": I place all the content of this payload in the "switch1" folder in arming mode, I uncomment the line "ATTACKMODE RNDIS_ETHERNET" in the payload and I comment the line "ATTACKMODE ECM_ETHERNET" (because I'm on a Win10 machine). 2) First of all, I want to install dnsspoof. In the switch2 folder, I place a payload containing "ATTACKMODE RNDIS_ETHERNET". I unplug and plug again my BB in switch2 mode and I follow all the steps in the Hak5 wiki to share my internet connection between the BashBunny and my WIndows 10 PC. After following all the steps, I open a Powershell and run "ssh -l root 172.16.64.1" (because it is the IP of the BashBunny). I can connect to the BashBunny, and inside I run "udisk mount". I then navigate in ~/udisk/payloads/switch1/ and execute the "Install.sh" script. I receive a"[OK]" message (followed by a message about the dhcp service) and then the ssh session closes. 3) Once this is done, I unplug my BashBunny. I open a web browser (Chrome) on HTTP pages in order to trigger the attack. When I plug my BashBunny in switch1 mode (where there is the BunnyTap payload), initially the LED does not light up, then the LED flashes blue but nothing happens on my machine (the code of the web page target_injected_xhtmljs.html that should launch does not run in my browser). After waiting 1 to 2 minutes, I unplug my BashBunny and plug it again in arming mode. I look at the contents of the switch1 folder but there is no file called "poisontap.cookies.log" as expected. 4) Another observation I was able to make while trying to launch the attack: the moment I plug the BashBunny and the LED is not yet lit, when running ncpa.cpl I see that the network card "Ethernet 2 Remote NDIS..." is activated, then the moment the LED turns blue and flashes, the network card is deactivated immediately. Do you have any method to see where my problem comes from? I really can't get the attack to work.... #### QUICKREDS PAYLOAD TEST #### For Quickcreds payload, I place the payload content in switch1 in arming mode. I unplug and plug the BashBunny in switch1 mode, here is what I observe: When plugging in the BB, the LED flashes quickly red. According to the documentation of the payload in Github, it would be the FAIL2 blink but I don't understand at all the explanation "Target did not aquire IP address" or how to solve this problem. In addition, the other FAIL1 blink means that the payload does not find the responder tool in the /tools/folder but I don't know why because I installed it previously and checked that it was there. I really don't know what to do to make this attack work either, any advice would be greatly appreciated. Thanks by advance, Hysteresis Link to comment Share on other sites More sharing options...
Bob123 Posted March 28, 2019 Share Posted March 28, 2019 Might take me a few days but let me see if I can get my setup the same as yours and see what I get with my bash bunny. Did you setup some dummy user accounts on your win10 machine with passwords to test with? I'll setup a few on mine and let you know what I get. Link to comment Share on other sites More sharing options...
Hysteresis Posted April 1, 2019 Author Share Posted April 1, 2019 Yes I put some user accounts to test but it doesn't work either. I would like to try to fix the Quickreds payload problem first because it is most likely the same problem for both payloads. Regarding the Quickreds payload, as indicated by the color of the LED (fast red) I have the impression that the BB can't get an IP address. Looking at this thread : I thought it might be a problem related to the dhcp. When I connect to the BB in serial mode with Putty while in arming mode, and execute the command "systemctl status isc-dhcp-server", this is what I get: "systemctl start isc-dhcp-server" Job for isc-dhcp-server.service failed. See 'systemctl status isc-dhcp-server.se rvice' and 'journalctl -xn' for details. "systemctl status isc-dhcp-server" ● isc-dhcp-server.service - LSB: DHCP server Loaded: loaded (/etc/init.d/isc-dhcp-server) Active: failed (Result: exit-code) since Wed 2019-03-27 10:27:04 PDT; 19s ago Process: 869 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status= 1/FAILURE) Mar 27 10:27:02 bunny dhcpd[877]: you want, please write a subnet declaration Mar 27 10:27:02 bunny dhcpd[877]: in your dhcpd.conf file for the network s...nt Mar 27 10:27:02 bunny dhcpd[877]: to which interface usb0 is attached. ** Mar 27 10:27:02 bunny dhcpd[877]: Mar 27 10:27:02 bunny dhcpd[877]: Mar 27 10:27:04 bunny isc-dhcp-server[869]: Starting ISC DHCP server: dhcpdc...! Mar 27 10:27:04 bunny isc-dhcp-server[869]: failed! Mar 27 10:27:04 bunny systemd[1]: isc-dhcp-server.service: control process ...=1 Mar 27 10:27:05 bunny systemd[1]: Failed to start LSB: DHCP server. Mar 27 10:27:05 bunny systemd[1]: Unit isc-dhcp-server.service entered fail...e. Hint: Some lines were ellipsized, use -l to show in full. Here is the result of the "journalctl -xn" command : "journalctl -xn" -- Logs begin at Wed 1969-12-31 16:00:08 PST, end at Wed 2019-03-27 10:30:19 PDT Mar 27 10:27:04 bunny isc-dhcp-server[869]: failed! Mar 27 10:27:04 bunny systemd[1]: isc-dhcp-server.service: control process exite Mar 27 10:27:05 bunny systemd[1]: Failed to start LSB: DHCP server. -- Subject: Unit isc-dhcp-server.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit isc-dhcp-server.service has failed. -- -- The result is failed. Mar 27 10:27:05 bunny systemd[1]: Unit isc-dhcp-server.service entered failed st Mar 27 10:28:24 bunny ntpd_intres[700]: host name not found: 0.debian.pool.ntp.o Mar 27 10:28:24 bunny ntpd_intres[700]: host name not found: 1.debian.pool.ntp.o Mar 27 10:28:24 bunny ntpd_intres[700]: host name not found: 2.debian.pool.ntp.o Mar 27 10:28:24 bunny ntpd_intres[700]: host name not found: 3.debian.pool.ntp.o Mar 27 10:30:19 bunny ntpd[699]: ./../lib/isc/unix/ifiter_ioctl.c:348: unexpecte Mar 27 10:30:19 bunny ntpd[699]: making interface scan socket: Permission denied So according to the thread above I tried to put "systemctl status isc-dhcp-server || systemctl start isc-dhcp-server" below the line "ATTACKMODE RNDIS_ETHERNET" in the payload.txt but it doesn't solve my issue and I have the same result by plugging the BB in switch2 mode (mode of the Quickreds payload) Also here is what I observe when connecting the BB in switch2 mode in ncpa.cpl : a network card "Ethernet 2 Remote NDIS..." appears and is activated but stays in the state "unidentified network". Any advice to troubleshoot my issue would be greatly appreciated Hysteresis Link to comment Share on other sites More sharing options...
Bob123 Posted April 2, 2019 Share Posted April 2, 2019 You know I got to be honest it does seem that you have a networking issue on your bunny. Here's what I have so far: My bunny is at firmware 1.3 I checked my installed-tools file and it shows Installed Tools: ---------------- impacket responder However I followed your first post and noticed that in the root folder the tools folder was empty. I loaded quickcreds into switch 1, plugged it into my fresh win10 box and sure enough I got a slow red blink. I again went to your post, grabbed the deb files and put them in the tools folder, rebooted the bunny, saw that they are now in the root tools folder and ran the install script. I plugged the bunny back into my win10 box and sure enough everything ran just fine. In my loot file is my user and hashed password. I'm curious why my installed tools file showed them installed even though they weren't. Maybe they were at one point? I'm curious did you mess with any networking at all on the bunny? I typed in systemctl status isc-dhcp-server and under Active I have inactive (dead) which is to be expected in arming mode. I can try it with just an RNDIS ethernet running but I'm sure it'll be fine since it loaded up on my win10 box just fine. I'm going to read through the weirdness post that you copied in but I do have one recommendation that might be worth a shot. Can you change your firmware to 1.3? I never upped mine to 1.5 and I've been hearing some talk about the latest firmware on all hak5 gadgets having some issues for some. Just my two sense. I'll keep digging and try to help where I can. Link to comment Share on other sites More sharing options...
Hysteresis Posted April 3, 2019 Author Share Posted April 3, 2019 Thanks for your time Bob123. Here is what I did today in accordance with your advices: 1) I performed a firmware recovery by removing and plugging the BB 3 times as indicated in the documentation. 2) I then updated the BB to version 1.3. and checked the version (which is now 1.3_264) 3) I installed responder (and impacket) with the .deb files, the tools do are present in the "/tools/" folder at the root of the BB. 4) I place the Quickreds payload in the switch1 mode, I unplug my BB and re-plug it in switch1 mode. However I get again a fast blinking red LED.... This is the "FAIL2" error which means that the "target did not aquire IP address". When I replug my BB back into arming mode, I do have a "quickreds" folder in the "loot" folder but with an empty "noname-1" folder inside. The payload therefore blocks on these lines; "# Check target IP address. If unset, blink RED and end. if [ -z "${TARGET_IP}" ]; then LED FAIL2 exit 1 fi" So it seems that there is a networking issue but I have no idea how to solve this problem. I thought that performing a firmware recovery would reset any network errors I may have inadvertently made, but having performed the firmware recovery + updating the system to version 1.3 did not solve anything. If someone has any idea about how to solve this problem it would be very nice... Hysteresis Link to comment Share on other sites More sharing options...
Bob123 Posted April 3, 2019 Share Posted April 3, 2019 Hopefully not too silly of a question but any chance you have another machine to test this on? Maybe something is up with Windows 10 not recognizing the network. For the test I did I simply loaded a fresh install of win10 on an older box, gave it a username and password and plugged in the BB. If that's not an option could you load up vmware or virtualbox and throw together a simple win10 test vm? As long as the BB hits the vm first it'll load and run it's payload just as if it were on a physical box. MS has a few free test VMs you can download as well. If your able to do either of the above I'd be curious on the outcome. Also what version of win10 are you using? There's so many milestones on win10 maybe a certain version is broke. I'll check what I used and let you know as well as upgrade or downgrade to whatever version your using just to check as well. Link to comment Share on other sites More sharing options...
PoSHMagiC0de Posted April 3, 2019 Share Posted April 3, 2019 Also, something to look out for is if the drivers are installed before the script begins to run. If not then it will not get an ip of victim until victim does. Tests to do. In a clean switch folder make a payload.txt that just loads the rndis_ethernet attack mode and place a 3 second delay followed by a status light letting you know it is done setting the ethernet and then check to see if you have a new interface and can ping the BB at its IP. If you do not, wait and see if things are being installed in the background for it to work. Check device manager and see if you have a broken driver in there too expecting more. If you find there is a delay with the ethernet coming up, you may have to modify the payload.txt around that part to add a delay or a loop with a counter to limit how long it goes with a delay to keep trying to get the target ip and to give up after so many times or carry on if succeeds. Any payload I modify that has a target ip getter I wrap it in a loop because of some machines running Win10 when they shouldn't will take longer to load drivers if they are not already loaded. Link to comment Share on other sites More sharing options...
Hysteresis Posted April 4, 2019 Author Share Posted April 4, 2019 @Bob123 For the sake of clarity of the previous explanations I did not specify that I had also tested running the Quickcreds and BunnyTap payloads on another Win7 machine but the result are the same as for my Win10 machine, so I’m pretty sure my problem is not linked to the Win OS. @PoSHMagiC0de When I plug the BB locally (WI-fi disabled and ethernet disconnected): Network card appears (Ethernet 2) and remains active in "Unidentified network" mode. At this point I tried to open a powershell and execute « ssh – l root 172.16.64.1 » and I got this message : " " " @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:gkVPmoSWKg+3NUmIqNOxDLXKU+Qv+ec+Ju0ndwVN0Ag. Please contact your system administrator. Add correct host key in C:\\Users\\[myName]/.ssh/known_hosts to get rid of this message. Offending ECDSA key in C:\\Users\\[myName]/.ssh/known_hosts:1 ECDSA host key for 172.16.64.1 has changed and you have requested strict checking. Host key verification failed. " " " So I went to the known_hosts file and delete its content then I retried and eventually I can ssh my BB. At this point I retried to launch the Quickcreds payload. But I usual, when plugging my BB, I can see a new network interface showing up corresponding to the BB and remaining activated, but a RED blinking LED comes up on the BB. However, the BB does have an IP adress because when blinking RED I can open a powershell and ssh my BB the same way as with the payload only containing « RNDIS_ETHERNET ». According to the documentation of the BB and the content of the Quickreds payload, it seems that it is the victim (the PC) that can't get an IP adress given by the DHCP server of the BB, as if the BB can't see the victim in the network. It is just my thoughts but I'm not sure where my problem come from... When the blinking Red LED showing up, I tried to ssh my BB and I run an ip -a : " " " 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether b6:7d:2f:1b:5b:01 brd ff:ff:ff:ff:ff:ff 3: tunl0: <NOARP> mtu 1480 qdisc noop state DOWN group default link/ipip 0.0.0.0 brd 0.0.0.0 4: gre0: <NOARP> mtu 1476 qdisc noop state DOWN group default link/gre 0.0.0.0 brd 0.0.0.0 5: sit0: <NOARP> mtu 1480 qdisc noop state DOWN group default link/sit 0.0.0.0 brd 0.0.0.0 6: ip6tnl0: <NOARP> mtu 1452 qdisc noop state DOWN group default link/tunnel6 :: brd :: 7: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 5a:00:00:5a:5a:00 brd ff:ff:ff:ff:ff:ff inet 172.16.64.1/24 brd 172.16.64.255 scope global usb0 inet6 fe80::5800:ff:fe5a:5a00/64 scope link valid_lft forever preferred_lft forever " " " Thanks by advance for your advices to solve this issue... Hysteresis Link to comment Share on other sites More sharing options...
Hysteresis Posted April 5, 2019 Author Share Posted April 5, 2019 Update: I have tried again to run the Quickreds payload on other Win10 machines different from mine (but same Windows version as mine), and the payload works correctly when the target machine is not connected to the internet and the wi-fi is disabled (otherwise the network card corresponding to the BashBunny is automatically disabled by Windows)... However, the payload doesn't work on my machine, even not connected to the internet. I tried to reset my network cards but the results were the same, it's strange. I will continue to try to see where the problem may come from on my PC and then I will give you news about the second payload Bunnytap. Thank you for your help anyway guys 🙂 Link to comment Share on other sites More sharing options...
Bob123 Posted April 5, 2019 Share Posted April 5, 2019 What version of win10 are you using? I want to test this. I will also test this with my wifi on because in all honesty I had my box isolated just because I saw no reason for it to be on a network at the time. So maybe I will then have issues as well. But I do like what PoSHMagiC0de said above. Try running the bash bunny with just an RNDIS network and see how Win10 reacts. I guess now with both wifi on and off (I will do that too). And if for some reason it takes longer to establish an IP then you'll have to delay the quickcreds program so it waits until you have an IP. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.