Jump to content

Noob Question(s)


Recommended Posts

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.

Link to comment
Share on other sites

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?

Edited by dark_pyrro
  • Upvote 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...