The Lab – Gear Check – Hak5 Bash Bunny – Storage

Sorry for the late edition.  I got my days mixed up, yesterday.  This week had two Mondays in it, as far as my brain could tell.  I got the short end of the stick on that.

This week, we’re going very quickly look at the “STORAGE” Attack Mode on the Bash Bunny.

This is what it looks like when I plug my Bash Bunny into a Linux Mint 17 laptop:

[ 4966.425800] usb 3-1: new high-speed USB device number 2 using xhci_hcd
[ 4966.444695] usb 3-1: New USB device found, idVendor=f000, idProduct=fff0
[ 4966.444707] usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=7
[ 4966.444713] usb 3-1: Product: RNDIS/Ethernet Gadget
[ 4966.444718] usb 3-1: Manufacturer: Linux 3.4.39 with sunxi_usb_udc
[ 4966.444722] usb 3-1: SerialNumber: ch000001
[ 4966.615123] cdc_acm 3-1:2.0: This device cannot do calls on its own. It is not a modem.
[ 4966.615169] cdc_acm 3-1:2.0: ttyACM0: USB ACM device
[ 4966.615800] usbcore: registered new interface driver cdc_acm
[ 4966.615802] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 4966.618621] usb-storage 3-1:2.2: USB Mass Storage device detected
[ 4966.618795] scsi6 : usb-storage 3-1:2.2
[ 4966.618891] usbcore: registered new interface driver usb-storage
[ 4971.629404] scsi 6:0:0:0: Direct-Access                               0000 PQ: 0 ANSI: 2
[ 4971.629670] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 4971.630115] sd 6:0:0:0: [sdb] 4194304 512-byte logical blocks: (2.14 GB/2.00 GiB)
[ 4971.630264] sd 6:0:0:0: [sdb] Write Protect is off
[ 4971.630266] sd 6:0:0:0: [sdb] Mode Sense: 0f 00 00 00
[ 4971.630405] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA
[ 4971.631847]  sdb:
[ 4971.632512] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[ 4973.119396] FAT-fs (sdb): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

When we put a payload into Attack Mode STORAGE, the drive presents a 2G drive to the system.  This looks just like the drive that gets presented when plugging the Bash Bunny in via Arming Mode.

This is useful for some attacks, such as what the TwinDuck firmware the USB Rubber Ducky provides, where we use both STORAGE and HID Attack Modes, then use Ducky commands to bring up a command prompt of some sort, type some commands to figure out where our drive is at, and drop files to that location.  This kind of attack is becoming less useful with corporate policies that prevent the use of USB thumb drives, these days, but the Bunny has another way to do this same kind of thing.  We’ll look at that next week when we introduce the networked attack modes.

The Lab – Gearcheck – Hak5 Bash Bunny

Anyone who has hung around this blog for a while should know by now that I’m a fan of the Hak5 gear.  The newest gadget gizmo of “gosh, did I do that” to be released is the Bash Bunny.  This is a USB device that offers more sophisticated attacks than the hard coded USB Rubber Ducky, but also acts as storage like the TwinDuck firmware, as well as behaving as a network device like the LAN Turtle.  You can choose multiple “attack modes” to define your payload, and bring home the loot.


The Bunny is slightly larger (wider) than a typical USB thumb drive, and doesn’t look like a generic drive.  It also runs a full blown Debian Linux installation under the hood, so it takes a few seconds to boot.  And at twice the price of a USB rubber ducky (and then some,) it definitely doesn’t wedge the Ducky out completely.  The Ducky still works much faster upon plugin, and has that “I’m just a drive, you can TRUST me” look to it that the Bunny may never have.

The Bunny’s network capabilities are also are just a facade to allow for a few network type attacks against the victim computer.  In order for the Bunny to reach the internet, it has to trick the victim computer into letting it piggy back.  The LAN Turtle doesn’t rely on the “victim” host in order to do stuff on the rest of the network, so it also is not squeezed out of its niche.

Where the Bunny shines, though, is being able to coordinate multiple “attack modes” to gain trust as a HID or as a New Network, and then use combined “bunny script” and full blown Bash logic to determine what steps to take.  It suddenly provides flexibility in how to react to an initial command.

For example, you could have it do an “nmap” against the victim computer, then process the results to do multiple other attempts at gaining information/drop a shell/whatever based on the results.

How does this work?  There is a switch on the side that has three positions.  The one closest to the USB plug is switch 3 (“arming” mode,) which loads the Bunny as a storage device, so you can upload files to the payloads directories as needed.  The other two are “switch 1” and “switch 2” so that you can have more than one payload option at hand without having to re-arm between payload attempts.  If you built a “Windows” payload on “switch 1” and a “Linux” payload on “switch 2” you just set it to the appropriate switch before plugging in and exfiltrating … I mean “running an involuntary backup” on the data.

The LED is also multi-color, and you can program it to display the color as well as hold solid or blink based on where you’re at in your payload.  This gives you immediate visual feedback, and that makes it easy to tell what step you’re at when you suddenly find you need to snatch the device and leave because unexpected visitors just showed up while you were “helping their data along.”

In all seriousness, though, as a legitimate admin tool, this ranks above the Ducky as far as being able to drop customized long HID scripts onto a virtual machine console that doesn’t take “copy/paste.”  With the Ducky, you would have to code in pauses like little “sleep” statements, and just trust that the next step is going to be what you expect it to be.  With this, you have Bash to let you do some logic before deciding on what to do next.  It’s not the same as an old fashioned Expect script, but it gives some of the same power.

At least, in my head it does.  I haven’t really had any opportunity to play with it more than to make sure it works since I got it.  My dream is that I can code in some input detection so that something like the “hit caps lock 4 times” on my TwinDuck firmware could be used to trigger “the next step” of the payload without it just moving on on its own.  I’m going to do some payload testing and post the examples here in later Gearcheck posts.