Details about HWID spoofing needed

[Bernhard Diener]

Hi.

[I don't already own a BB, else I would try this out]

I wonder whether BB would be able to run on a whitelisted-devices-only system.

I see that BB's hardware ID may be set to to whatever I like. But when is this coming to effect?

Is the ID set before I connect the device, or is attackmode only starting after I connect the BB and so the BB will initially connect with a different, non-whitelisted HWID and thus become discoverable?

I found a similar thread https://forums.hak5.org/topic/51611-usb-hardware-id/ , but unfortunately Darren didn't answer the follow-up question.

[MB60893]

To my understanding, when the Bash Bunny is first plugged in, it draws power from the USB lines and boots its own Linux OS. From there, whatever options were listed in the script will be applied (such as the hardware ID), and after this point, the Bash Bunny will communicate its new settings to the USB Host device (i.e. whatever the bunny is plugged into.)

As is indicated in the documentation for VID and PID:

Quote

These 16-bit IDs are specified in hex and are used by the victim PC to find drivers (if necessary) for the specified device. 

This would make sense, as drivers need to be present before a USB device can be mounted/setup for use by the system. Therefore, the VID and PID must be set BEFORE the bunny connects.

Hope this helps!

[Bernhard Diener]

Hi.

You misunderstand what I am asking. Sure, the attackmode script with the preconfigured HWID is created before we connect the bunny.

What I am asking is: will this overcome whitelisting restrictions or not? If the stick boots while having a different ID (a generic one) and only after a few seconds (after having booted its mini linux) it changes to the new ID, then it's too late - it would already have been recognized by the whitelisting software (which is what I hope will happen).

[chrizree]

I have no enterprise environment at hand right now to verify this against, only a Windows 10 PC not joined to any domain

Method:

Check the Windows "victim" PC if it has been touched by the Bunny before, (i.e. is the "native" VID/PIDs present)

"Install" Nirsoft USBLogView
https://www.nirsoft.net/utils/usb_log_view.html

"Install" Nirsoft USBDeview
https://www.nirsoft.net/utils/usb_devices_view.html

Start Nirsoft USBLogView

Prepare the Bunny with a "spoofed" VID/PID in attack mode

Insert the Bunny into the "victim" PC

Check the Nirsoft USBLogView entries and see what gets stuck
(also check Nirsoft USBDeview after the "attack" is over)

It's possible to check the Registry as well

---

In Arming mode, check the VID/PID of the Bunny
f000:fff0

It isn't randomized between sessions/plugins, so "static" VID/PID

---

In Attack mode (ATTACKMODE HID STORAGE) the Bunny gets another VID/PID (this is without specified VID/PID in the payload!!!)
f000:ff02

It isn't randomized between sessions/plugins, so "static" VID/PID

---

When running Attack mode with a set VID and PID (for ex. ATTACKMODE HID STORAGE VID_0X0781 PID_0X5567) it never enumerates as f000:fff0 or f000:ff02, only 0781:5567
(Nicked the VID/PID from a Sandisk USB storage device)

However, running both HID and STORAGE as attack mode at the same time may look suspicious, not sure how "smart" the available tools are to spot this though when whitelistning, use one attack mode at a time.

So... the Bunny doesn't tell its true identity when being attached and enumerated, it only uses the configured/"spoofed" VID/PID (if set in the payload)

[Bernhard Diener]

Hey chrizree, thanks a lot!

That's the kind of test I was hoping for (although I didn't hope that would be the result 🙂 )

Will buy a bunny as soon as the shop lets me (only the kit is available atm) and see if I can tune my guards to detect it somehow.

Will let you know here when I succeed and also when I don't.

[Bernhard Diener]

I finally have the Bashbunny Mark II here.

chrizree, you were right. So I'll start playing with it and see what traces it leaves (if any) and let you know soon.