Transferring Data the Low Tech Way

If you’ve ever had a penetration test of some form of remote management application, like Citrix or Terminal Services you’ve been given the advice to restrict the flow of information through the managed application via restricting local drives and the clipboard through the ICA Policy.

But, how effective is this? Can we get data across the link? Can we get data back?

Of course we can, we just need to think more low tech. There is one device that is pretty much required for every remote management application: the keyboard. It is possible to use it to transfer custom data into files on the remote host using applications such as notepad or even Word.

It would be a boring test if we just typed in the hex values of bytes as most tools that we’d want to use to explore the internal network are around 100K which will probably produce flashbacks to typing in programs from a magazine in the 1980s!

So we need to automate it; injecting the keystrokes directly into the network traffic is feasible, but difficult to manage as the connection will usually be encrypted and have multiple different tunnels.

Thus we bring to the front Hak5’s Rubber Ducky. The Rubber Ducky is a simple device that pretends to be a USB keyboard, but instead of allowing typing, injects a pre-defined set of key strokes, as if generated by a keyboard. It is controlled by a simple scripting language that is simple to use and learn. Other alternatives are possible, such as using a Teensy or an Arduino.

As we’re transferring binary content we need to encode it into ASCII to pass safely across the keyboard link. To this end, I initially decided to encode the content as a set of broken up hex strings, this means I need a decoder at the other end. A simple Visual Basic Script was written which will take a file, and convert the hex to binary. Visual Basic Script was chosen as it is an integral part of the Windows Scripting Host which can be found on every version of Windows since Windows 2003. We can get this over to the other host by typing it in, or using the Ducky.

The next step is to translate the binary to hex, for my purposes I wanted to demonstrate a persistent remote shell, for which my only method of transport was DNS; so I chose to bring iodine across. So then we pass this through a binary to Hex convertor.

Then it is as simple as loading up notepad on my target, plug in the Ducky and wait for it to transfer across before translating it with the prepared VB script.

This solution was very hacky and worked for my requirements in the 2 days that I had to test, but it could be seriously improved, e.g. by using compression and base64 to reduce the size of the data being transferred across via the keyboard.

Another possible enhancement it to make a method of transferring data back using QR codes and screenswipes: you can store nearly 7KB of data in a type 40-L QR code. Which is 177 x 177 pixels, so you could use multiples QR codes to get a decent throughput.

There is also the GUI Transfer Toolkit which uses GUI events to transfer data, although this is a lot slower than using the keyboard.