Jump to content

Details about HWID spoofing needed

Bernhard Diener

Recommended Posts


[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.

Link to comment
Share on other sites

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:


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!

Link to comment
Share on other sites


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).

Link to comment
Share on other sites

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


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

"Install" Nirsoft USBDeview

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

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!!!)

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 6 months later...


This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

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