JBNZ

This sounds unlikely to be possible unless the target host has some type of service listening while locked which accepts files or you have some sweet 0day for the target OS. The key vector for USB attacks while locked is that the locked machine will typically recognise an ethernet interface allowing network-based attacks.

Has the OP been updated since it was posted more than ten years ago?

I also went for the faster shipping option and had 7 days between approval of order and confirmation of order being shipped. As digip noted, it's a small team churning these things out. Hopefully it helps with your doubts that others experienced similar waits before receiving the bunny successfully.

I use LastPass. My understanding regarding the Citrix involvement is that LogMeIn, who own LastPass, have also acquired a Citrix property (GoTo), rather than LastPass being acquired by Citrix. That said, the acquisition by LogMeIn did raise some concerns when that occurred, because many users didn't feel that LogMeIn had the credibility to be trusted with a vault of all of their secrets. There were also issues with LogMeIn dropping support for the freemium model on their other products historically, leaving users in the lurch. I've stayed with it because it fits my use case well and I haven't had any issues. Often, discussion of LastPass leads to mention of Tavis Ormandy, who has had a lot of success finding significant vulnerabilities in LastPass, including those which disclose passwords and those which lead to code execution if you had the binary component installed. If my threat model included people dropping 0day to read my emails, or a rogue Tavis Ormandy, I wouldn't be using a cloud password manager at all and would likely use a KeePass-based system. I'm doubtful that LastPass is unique in having critical vulnerabilities in their codebase, and what Tavis's testing has illustrated is that LastPass's vulnerability resolution timeline is very acceptable, even with very complex cases. I don't have any insight into the vuln resolution practices of other vendors, so it's hard to quantify whether I'd gain anything by moving to an alternative provider of the same kind of system.

Converting that exact thing is probably not helpful, as that is managing keypresses much more manually. That code seems to just enter every pin from 0000 to 9999, which the ducky may not be suited for unless there's enough space to hardcode every pin entry. I'd expect the bunny to do this trivially, however. Optionally keeping the original delays between entry, something like this should do for starters: LED B SLOW ATTACKMODE HID #UNCOMMENT FOR ENTRY INTO MACOS #ATTACKMODE HID PID_0x024f VID_0x05ac for x in {0..9}{0..9}{0..9}{0..9}; do #QUACK DELAY 8000; #LED G SLOW; #QUACK DELAY 5500; #LED G; QUACK STRING $x; QUACK ENTER; done

Just tested this out to confirm. Haven't dug into the 'why' as far as @s00500 but can confirm that where captiveportal used to work, it no longer does. The only changes @Sebkinne made in that commit were to align the payload with the new extension and LED format, so if breaking changes were made to the framework, this won't have addressed those.

You can force recovery by pulling the bunny out of the USB port as soon as the LED goes green, three times in a row. On the fourth time, it should turn green, then turn off, then flash red for three minutes or so while recovering. EDIT: This is what I get for answering questions instead of sleeping. Don't pull it when it turns green, it should turn green when plugged in, then turn off briefly. Pulling it while turned off had the greatest success for me.

It does seem like you could be running into the issues described in the thread you linked. When I test your example payload on Win 10, with RNDIS_ETHERNET and HID, Windows reports "driver unavailable" and no new ethernet interface is presented. It seems like this is a limitation of the platform at present. RNDIS and HID are a valid combination, from the perspective of the bunny, but it looks like Win10 isn't playing ball.

After an embarrassing number of times breaking the insertion of the kernel module, resulting in losing serial access and having to force reset... I'm setting the manufacturer name with a line similar to the following in ATTACKMODE. I was getting thrown by nested quotes, but it seems like all of these are required to successfully pass an argument containing spaces to the module: mod_params="$mod_params iManufacturer='\"Test Words\"'" I think in future, I will surround any experimental code with a check for arming mode to ensure I don't break arming behaviour again.

What state is your BB in at present? I'm occasionally making changes that cause it to fail to register as USB gadget, which put it in a state where in arming mode the LED will turn green, then turn off for a second before turning green quickly, then flashing blue indefinitely. In that state, I find that letting it turn green the first time, then pulling it when it turns off and repeating that three times results in the next time I plug it in, it turns green then flashes red and restores itself. EDIT: I managed to misunderstand both of your posts! You're asking in preparation for experimenting. Yeah, in my experience, the steps above allow a reset to be forced. EDIT TO EDIT: Given that you're asking in preparation before action, I'll admit I'm confused about the title saying that the factory reset won't work.

I expect that if you want a gadget to work on a real engagement, you do the 'tweaking in one way or another' on a test system which emulates the target system first. Similarly, you ensure that you're emulating devices which you know to work in the target environment, to reduce the friction. You don't necessarily just stroll in, slap a gadget into the nearest port and watch it rain shells, although I guess sometimes you get lucky, too.

The BB won't have direct access to your filesystem over serial. There are a number of ways to transfer files over serial, which Google can provide more information on. For your current case, I'd recommend from serial mounting the filesystem which is exposed during arming mode and putting the files there: udisk_folder=/root/udisk mkdir -p $udisk_folder mount /dev/nandf $udisk_folder cp file /root/udisk/ umount /root/udisk Then unplug the Bunny, plug it back in and use Windows Explorer to grab your files.

You seem to be mixing up some instructions. You ask how to serial into the bash bunny, but the instructions in your second post are the wiki instructions for "Sharing an Internet Connection with the Bash Bunny from Windows". These are different tasks. Instead, follow these steps: http://wiki.bashbunny.com/#!./index.md#Connecting_to_to_the_Bash_Bunny_Serial_Console_from_Windows

How comfortable are you with git and subversion? There are steps here on how to do this. Alternatively, if you're okay with the content being routed via a third party, check out http://kinolien.github.io/gitzip/ and https://minhaskamal.github.io/DownGit/#/home which are referenced in that answer.

Yeah it will, it's a pretty standard webserver. If you serve a directory, it'll look for an index.html and serve that first. Alternatively, you can select any HTML file and serve that explicitly. More detail at https://docs.python.org/2/library/simplehttpserver.html Where are you running PowerShell? Have you installed it on the bunny or are you trying to run a web server on the target host?

In the script bash_bunny.sh, /dev/nandf is mounted onto /root/udisk in the do_mount() function. udisk_folder=/root/udisk mkdir -p $udisk_folder mount /dev/nandf $udisk_folder

A simple and terrible example would be a payload which contained simply: ATTACKMODE ECM_ETHERNET python -m SimpleHTTPServer Once this executes, the full bunny filesystem is exposed to the target on on http://172.16.64.1:8000/, which is the bunny's default IP and SimpleHTTPServer's default port. Options to SimpleHTTPServer would let you better specify a directory to serve from and an alternative port.

Presumably you'd want to expose the file to the target either as a USB storage device and address it that way, or by running a server on the BB and accessing the file over the network.

Basically, as Dav-ee and hkyq said, the bunny has significantly greater capability than a ducky. The main downside is the slightly longer boot time. Whether this impacts your purchasing decision depends entirely on your use case. They're tools for different jobs. For me the key selling point of the bunny is the potential for responding to feedback from the target host. While executing an attack, I can profile the target host across the network interface to determine which execution paths the attack should follow. If your script establishes a comms channel between the target and the bunny, you could run a script on the target, send the result to the bunny, parse the result and use it to inform the escalating attack. The ducky is great, but you don't have the same control over the context that keystrokes are being blasted into, while the bunny lets you add a much greater level of intelligence into your attack.

If anyone was wanting to experiment with this, just had a quick look and early indications are that this is fairly trivially achievable by modifying ATTACKMODE. I used the same format used for idProduct and idVendor to modify iSerialNumber and added SN_*) into the case statement which parses arguments. Now giving argument SN_DEADBEEF as argument to ATTACKMODE changes my device's serialnumber to that. Will report back if I run into failure cases on this.

I note from reading ATTACKMODE that the serialnumber the device presents is defined there, with a comment noting that changing the serialnumber requires reinstalling the RNDIS driver on Windows. Beyond this note, are there any technical limitations preventing a scripted approach to configuring the serialnumber? This would be useful as some USB whitelisting frameworks, such as USBGuard use a combination of name, serial, VID and PID to whitelist devices. It would be handy to preempt this method of blocking the Bash Bunny by having programatic access to these parameters. I'm keen to dig into it myself, but wanted to put feelers out as to whether anyone was aware of technical hurdles I may hit in the process

I've submitted a PR. Is the source for the captiveportal binary available? It would be nice for accountability to be able to attest to exactly how the payload is functioning.

I haven't submitted a PR because I'm still getting things up and running and am not sure what the standardised fix to this will be, but I've found that adding "source bunny_helpers.sh" to the payloads.txt, after the ATTACKMODE line, allows the helper \$SWITCH_POSITION to be used. With this modification, the payload works for me.