Search the Community
Showing results for tags 'communications'.
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.