Data Exfiltration with ease

As someone who has to regularly diagnose issues on a plethora of operational systems and under various failure scenarios, just as a pen tester or adversary I need to think of alternative ways to do things. Some turn out to be incredibly straightforward ways to exfiltrate data from a system.

From a data loss prevention point-of-view it is clearly of critical importance that you understand any potential exfiltration mechanism so you can put in appropriate controls.

All you need are three things:
1. A transport mechanism to use/abuse. This doesn't have to be technological; a human with a USB stick for example is just as good. But you must understand the nuances of the transport.
2. A method to encode and transmit the data you are after onto the transport mechanism
3. A method to decode and receive the data over the transport mechanism

From a defenders point-of-view you need to detect and prevent potential abuses. E.g. gluing USB ports, vetting people. So there is a possible fourth item (a method for items 1 thru 3 to be done covertly or below-the-radar).

However, my example is technological.

Take a Citrix environment that is locked down so you cannot attach drives and can only access an SSH shell. However, to allow "sys admin" tasks, text-based cut-and-paste is allowed between the client and the server via Citrix.

What we want to do is get "large" text files and some binary files off the system quickly.

It turns out this is trivial. Not only that but you don't need to install anything, just use the tools that are available to you. This is ideal for an adversary, it reduces the IoC landscape.

So, the transport mechanism in this case is the cut-and-paste feature.

The encoding; well that depends on your system.

Typically, most Unix/Linux will have openssl installed. So let's use that.

The general encoding steps are simple in this case.
1. Compress the life out of the file(s) so we have the smallest possible amount of data to transmit over the transport. We want the cut-and-paste to work and there can be limits that become annoying.
2. Encode using base64.
3. Cut-and-paste the output.

As an example, let's get a copy of /bin/bash

First, we count the number of lines. Typically a buffer will only allow so many lines:

target$ gzip -9c /bin/bash | openssl enc -a | wc -l
9742

Excellent, something like PuTTY can usually work with a 10000 line buffer over the network. If it is too big, cut it into pieces.

So, in the case of PuTTY, we can go to the menu by clicking the icon at the top left of the window, go to Change Settings, then Window. We set the Lines of scrollback to cover the number of lines needed and click Apply.

Then clear the screen and via the PuTTY menu click Clear Scrollback.

Type in the command to get the data:

target$ gzip -9c /bin/bash | openssl enc -a

Go back to the PuTTY window and click Copy All to Clipboard.

Save to your client via your favourite editor and strip out the header and footer (the bits that aren't part of the output from the command).

Finally, convert it back to the original by reversing the process, this time on the client:

client$ openssl enc -a -d -in bash.puttycopy | gunzip > myBash

For that added confidence you could run a sha256 hash or similar on both copies to prove success.

Of course, you don't have to use gzip and openssl; you can use whatever is there.

On old Solaris systems you probably have uuencode and uudecode. However, a text cut-and-paste has a common side-effect; trailing spaces are removed. Yet, for uuencode/uudecode trailing spaces are important.

Well, there are a 1001 ways to get round that. A simple one is to add a non-space before transmit and remove before decode. E.g.

To encode:

target$ gzip -9c /bin/bash | uuencode - | sed -e 's;$;x;'

And to decode:

client$ sed -e 's;x$;;' bash.puttycopy | uudecode | gunzip > myBash

And not even a hint of new software on the target - we have used available transports to receive data and only used tools already on the target.

A simple solution from a defenders point-of-view would be to disable cut-and-paste, after making the appropriate business impact assessments.

From a forensics point of view, you would be looking at bash history, traffic patterns, audit logs, etc. In theory, an adversary only needs to succeed once to get your data, but a defender likewise (should) only need the adversary to slip up once to get detected. Whether that is in time is another matter.