Jump to content

Bash Bunny vs RubberDucky (Real World)?


breachr

Recommended Posts

Ive seen some topics asking this question. And the obvious answer is: Bash Bunny = Full Linux machine, Ethernet simulation and more powerful.

But what exactly does that mean from a real appliance viewpoint? Mubix Attacks are only possible with Bash Bunny, okay. But what else exactly?

For Example this "Bash Bunny" Payload https://hak5.org/blogs/payloads/microsoft-windows-10-fake-logon-screen should be possible to be executed with the Rubbery Ducky, doesnt it? I also understand that Rubbery Ducky Mass Storage Emulation is only 1.1 and Bash Bunny is 2.0 (sadly no 3.0), but does that justify a 7 second boot time?

 

Dont get me wrong, i really like the idea of the Bash Bunny. But i just dont get why anyone would use it over the Rubber Ducky for real world scenarios.

Link to comment
Share on other sites

I use my Bunnies more than the Duckies I have, simply because of the fact that I like the flexibility of the Bunny and sometimes want to process stuff on the device. I don't see why there's a "this or that". The Ducky has its pros and since I don't have to chose between the two (because I have both), I just use the one that suits my needs at every given moment.

Link to comment
Share on other sites

10 hours ago, dark_pyrro said:

I use my Bunnies more than the Duckies I have, simply because of the fact that I like the flexibility of the Bunny and sometimes want to process stuff on the device. I don't see why there's a "this or that". The Ducky has its pros and since I don't have to chose between the two (because I have both), I just use the one that suits my needs at every given moment.

That is exactly what i mean, which flexibility do you mean? What are you processing on the device? Can you tell me 1-2 use cases besides the mubix attack, in which you go for the bash bunny?

Link to comment
Share on other sites

The main reasons to grab the Bunny on an engagement (there are others of course):
- more payloads than 1 using the switch
- no need to encode payloads
- using Bash and Python in payloads and not just DuckyScript (although DuckyScript 3.0 has extended the feature set a lot with the new gen Ducky, so it's not bad in any way)
- Bluetooth features (if using the Mk2)
- networking makes it possible to enhance payload functionality (SMB and web server functionality, etc.)
- and, linked to the above, possibility to post-process and/or control the events of the payload depending on what the target sends back to the Bunny over the network
- the Bunny opens for possibilities to be used in target environments where external USB storage devices isn't allowed (which eliminates using the Ducky if in need of exfiltrating information from the target to the device, the Bunny can of course also *not* be possible to use if networking restrictions are applied, but it allows extended possibilities to succeed compared to the Ducky)
- easier to get LED status from payloads
- possible to use larger Micro SD cards, but that's seldom really a reason to select the Bunny, however, even if you don't use the max capacity of the Bunny Micro SD card, you are better off in many cases even at smaller storage sizes (still talking GB sizes) since the Ducky will get slower in relation to the size of the external storage that is used, there is a reason to why the Ducky still comes with a really small sized card (in terms of storage)

Link to comment
Share on other sites

  • 3 months later...

Archived

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

  • Recently Browsing   0 members

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