hidendseek Posted January 2, 2022 Posted January 2, 2022 Hello world. I am pretty new to the scene and having some issues with my Bash Bunny MKII (I think its MK2). First I am using a laptop running debian(64bit). I would like to know how to unmount (if necessary) and eject the BB when it is in an attackmode. For example following the guide on docs.hak5 getting bash bunny online requires to have the Bash Bunny in attack mode with payload.txt containing "ATTACKMODE ECM_ETHERNET" +run bb.sh+ connect + screen into BB+ run apt update && apt upgrade How do I eject after I finish? I have noticed while BB is in arming mode and I eject the mounted BB the blue led continues to blink. Obviously I do not want to umount -a I mostly have access to linux machines. As i said i am new to Hak5 products. I cannot find many linux attacks that i can get my feet wet and hopefully learn how to make my own linux and or windows attacks. So I have been trying to get "linuxinfograbber" to work. the Readme.md states this attack is to be used on debian. So i tested it on a kali box. The attack fails after a few seconds of the attack. I have tweaked the payload.txt enough so the attack works almost to the end. It seems that the attack fails because kali doesn't automount the BB and cannot complete the bash ./recon.sh . If anyone has gotten the "linuxinfograbber" attack to work I'd appreciate some guidance.
dark_pyrro Posted January 2, 2022 Posted January 2, 2022 If you're not using ATTACKMODE STORAGE there's nothing to eject really. In that case (using ATTACKMODE ECM_ETHERNET) I most often connect to the Bunny using ssh and just issue the poweroff command. I just use screen or minicom to serial into the Bunny when it's in arming mode, but any way to access the Bunny is OK. Doing a correct poweroff is most often not an option if on an engagement. In such a situation, it's just to pull the Bunny. Not ideal, but sometimes the alternatives are limited. When possible, I always poweroff/shutdown the Bunny in a controlled way. The blue blinking LED won't stop just by ejecting the Bunny. Ejecting just unmounts the Bunny storage from the target computer, but the Bunny keeps on running as the standalone computer that it actually is for as long as it has power. Therefore it will continue to do the things that it is told to do, such as blinking the LED even after ejecting it. Ejecting isn't equal to powering the Bunny off. BTW, you know it''s a Mk2 if it has an SD card slot. Regarding the payload, where exactly do you experience problems and what tweaks have you made?
hidendseek Posted January 3, 2022 Author Posted January 3, 2022 thank you for the reply.It's nice to know that indeed have the MK2. for some reason i am having trouble connecting via ssh. i am able to ssh into other devices. in regards to "linuxinfograbber" the attack would fail at line 31 (Q STRING mkdir -p \$lootdir) and at line 35 (Q STRING bash \$exepos/recon.sh \$lootfile) i was able to get line 35 to work only when the BB was mounted.
dark_pyrro Posted January 3, 2022 Posted January 3, 2022 It should be mounted since ATTACKMODE STORAGE is set in the payload. The payload isn't really as "universal" as it says to be either. Just using something Debian based isn't enough. For example, if using Ubuntu, the payload will not work since ifconfig and xterm isn't a part of later versions of the distro. However, the payload is more than 4 years old so not that strange. Things happen over time. What troubles do you experience when it comes to ssh? It's pretty straight forward if the Bunny is in the correct ETHERNET mode.
hidendseek Posted January 5, 2022 Author Posted January 5, 2022 Hm that is kind of unfortunate. I have tried a few different "debian"s and they do not mount the bash bunny. Maybe I'm missing something. I got ssh to work. I guess i need to figure out how to get my hands on something with Windows. Thanks for help.
dark_pyrro Posted January 5, 2022 Posted January 5, 2022 It should mount on Linux based systems without any problem, I use that kind of environment all the time along with the Bunny when developing payloads or interacting with it. I more or less only use Windows when I need a target to test things on. There is something else other than the OS that is the source of your mounting issues. Check your switch position. If not in arming mode, check what the payload in the specific switch position does. Makes sure it uses an attackmode that includes being a storage device.
hidendseek Posted January 6, 2022 Author Posted January 6, 2022 I would appreciate if you could share a payload or part of a payload that can preform a bash command. When i plug in the BB in CLI I run "sudo find / -type d -name "BashBunny" -ls" The BB directory cannot be found. If i mount the BB run same command the directory shows up in the results. No matter if the BB is in arming or attack mode. Payload1 attackmode is Storage + red led + open terminal and try to run recon.sh that is located in the root folder of BashBunny(/media/$USER/BashBunny/), Terminal opens but cannot access the root of the BB . running sudo fdisk -l and (lsblk) indicates BB is /dev/sdc Payload2 Storage + HID + yellow led do the same thing as payload1. exact same results. terminal opens and fails to access BB via /dev/sdc or /dev/sdc1.
dark_pyrro Posted January 6, 2022 Posted January 6, 2022 I'm not really sure I understand what you're talking about. If I insert the Bunny in arming mode (Switch position 3 closest to the USB connector of the Bunny), it is mounted automatically (using Ubuntu). When executing the command you specified ( sudo find / -type d -name "BashBunny" -ls ) on the Ubuntu box, it finds the Bunny mounted under /media/<username>/BashBunny so I encounter no problems accessing the Bunny in arming mode. If I do the same but using attack mode and a payload containing ATTACKMODE STORAGE (using for example switch 1), the same thing happens. The Bunny mounts as intended. You say "If I mount the BB"; isn't the Bunny being mounted automatically on your Debian machine (not sure if it's plain Debian or some distro based on Debian)? You have to focus on getting basic things to work first, then move on to try specific payloads (such as the LinuxInfoGrabber). Don't mix the troubleshooting scenarios. It just makes it all complex and difficult to follow. Also, don't access Linux devices directly using their device name when it comes to storage. Always mount them first. In other words, don't use device names like /dev/sdc to access the Bunny, make sure it's mounted somewhere first. That's your first issue to solve. To be able to help troubleshooting further, I need to know exactly what Debian variant you are using and from where it can be downloaded, just to make sure that I can get the full picture of the environment in which you are trying to get the Bunny working. Because of the fact that I can't reproduce some vital steps of where you are failing, I can't give any advise at this point on how to try to get it all working.
hidendseek Posted January 8, 2022 Author Posted January 8, 2022 did some digging and found out that a lot of the distros i have indeed have auto mount turned off. Seems to be a KDE/Plasma setting.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.