Search the Community

I've had two BashBunny payloads fail on me (USB_File_Exfiltration and SmartFileExtract_Exfiltration) when I ran them in the morning, after working on them for a full day trying to get them to work (the night before). Debugging the scripts on Windows, I found out that the date/time stamp formatting for the filename was causing the issue. The hour is left-padded with a space in the AM. I found the following hint for creating Windows Batch Script variables that are properly formatted with the date/time. My modified code to match the format in the payload scripts is below: @echo off for /f "tokens=2 delims==" %%a in ('wmic OS Get localdatetime /value') do set "dt=%%a" set "YY=%dt:~2,2%" & set "YYYY=%dt:~0,4%" & set "MM=%dt:~4,2%" & set "DD=%dt:~6,2%" set "HH=%dt:~8,2%" & set "Min=%dt:~10,2%" & set "Sec=%dt:~12,2%" set "datestamp=%YYYY%%MM%%DD%" & set "timestamp=%HH%%Min%%Sec%" & set "fullstamp=%YYYY%%MM%%DD%_%HH%%Min%%Sec%" echo datestamp: "%datestamp%" echo timestamp: "%timestamp%" echo fullstamp: "%fullstamp%" pause Here is the output: datestamp: "20190809" timestamp: "084546" fullstamp: "20190809_084546" Press any key to continue . . . And here is the link that helped me figure it out: How do I get current datetime on the Windows command line, in a suitable format for using in a filename? I hope this helps someone avoid the struggle I've been having the last two days.

I did a search for a hex editor but surprisingly, didn't find anything listed...I think it is operator error4 and I apologize if I f'd up. I want to be able to read the files on a disk, thumb drive, etc. I'd like to be able to massage the MBR in Windows....way back in the dark ages some guys writing security software for PCs for the government where I was at gave me a debug routine to fix the MBR that they had massaged. I was doing computer repair back in those days....but a lot of beer washed away all those brain cells. Once DOS 5.0 came out with fdisk /mbr, the software was obsolete. but, I would like to be able to see those first bits that are read...I have hexedit for windows...but, haven't gotten in to it. Will check to see if there is one for Ubuntu...thought I would ask for those more intelligent than I (every user on here)

tl;dr- Add logic to the RD to monitor key lock values. Use this for functions like file transfer. Because I wanted to see if I could, I wrote a VBScript to transmit a file using the Scroll lock, Caps lock, and Num lock keys. As it turns out, if you record the data with a fast enough camera you can decode the bits and reproduce the transmitted file. Unfortunately, to make it feasible for a camera to pickup the LED fluctuations and and then for a human to interpret the blinks, the transfer rate is very slow. In fact, if you have the time and ability to use a camera to record the computer, you should really just take a picture of the screen. If only there was a technical means of monitoring these LED statuses that could increase the rate at which this could operate... (Note: In the above video, you have to view at 60fps and set the playback speed to 25% to even have a chance of decoding it manually) Fast forward a couple days and I saw another demonstration of the Rubber Ducky on Hak5. As I understand it, the RD interprets a compiled script and primarily acts as an output only HID. Because of this, payloads from the RD have only two ways of currently gathering information. One is to exfiltrate the data over a network connection (bad because it may be logged by a firewall or proxy), and the other is to switch to USB storage mode (bad because systems may monitor or block USB Mass Storage Devices). However, by utilizing Caps/Num/Scroll lock, payloads could potentially communicate any type of data back to the Rubber Ducky (without tripping any host system security/monitoring). I'm suggesting that some logic be added to the RD to monitor the Key Locks and use them as a way of receiving data. In the video demonstration demonstration, I used sendkeys to flip the status on the three LEDs. Every-other-bit is sent to Num Lock and Caps Lock with Num Lock being bit one, Caps Lock being bit two, and Scroll Lock always being the timing. For efficiency's sake, every transmission of two bits is indicate by alternating Scroll Lock. This means that with SL turns on, two bits were sent and when SL turns off, 2 more bits were sent. This timing is necessary to indicate to the interpreter (be it human or RD) that the other two bits are current (even if they haven't changed in value). The script currently lacks any intelligence- it just blindly sends the contents of a file. But, if the script were to know it was talking to the RD, it could wait for acknowledgements from the RD before sending a file. Furthermore, since this technique would allow two-way communications with the RD, we could incorporate useful file transfer features like CRCs and the inclusion of the file name. As I mentioned in the beginning, using this technique to visually send information via the LEDs is too slow to really be of any value. But, this same technique may have value when the thing observing the LED value changes is a Rubber Ducky. I estimate that this technique would allow binary data to be sent to the RD at around 1.5 kB/s. Granted, this is a far cry from USB Mass Storage Device speeds and network transfer speeds, but this method doesn't require a system to be on-line and wouldn't leave any trail on the host system*. Of course, in addition to file transfers, two-way communications with the RD can open up more possibilities. For instance, the RD could run a script on the host system to see what version of the OS is running and then send the OS version back to the RD. From there, the RD could send a different script based on the version. Granted, you could just put this logic in one payload file that is executed on the host, but there may be cases where you want to keep some secret sauce on the RD and never written to a host machine. The Duck Whisper *- Okay, some key-loggers might record the key presses. But if the system has a key-logger, it would have recorded the entire RD session anyway.

In Hak5's blog post about stealing files with the USB Rubber Ducky, they only targeted the documents folder on the C: drive. I'm looking to steal all .PDFs/Excel spreadsheet, regardless of their directory/drive. Can anyone show me how this is done? I have been trying all day now, but can't get a satisfactory result. Thanks in advance! Any help would be greatly appreciated.

Hello Do not bother the I have a question I am looking for extension of them does not like the KGB that File Commnad You can just about 10 of these cases suggest me Of course I could not find by searching ... thank you

Hello, I just got my rubber ducky a couple days ago and I wanted to encode my file but I got an 'corrupt file' error. Does somebody have ideas or tips what I could try doing? The following error; Thomass-Air:Desktop thomas$ sudo java -jar ~/Desktop duckencode.jar -i disableWinDefender.txt -o ~/Desktop Error: Invalid or corrupt jarfile /Users/thomas/Desktop Thanks, Thomas