Wiki

Data Exfiltration Toolkit

DET is a modular framework to exfiltrate data. It has been designed to make it easy to develop new exfiltration methods without having to worry about the core code. This is achieved via a plugins system where each plugin represents a different exfiltration method.

This wiki is intended to give an insight into the inner workings of DET. If you'd like to change some parts of the project, or develop new exfiltration methods, please consider contributing to this repo by submitting a pull request or by opening an issue.

Exfiltration flow

This section aims at explaining the general workflow when exfiltrating a file with DET

The exfiltration process is as follows:

1. Reading the file to exfiltrate
2. Compressing the file using ZLib
3. Encrypting with AES256 (Encryption key is provided in the config file)
4. File is split into multiple hex encoded chunks
5. Each chunk is sent through a random exfiltration method (i.e plugin)

It is important to note that each plugin runs on a different thread and that it implements its own sending and receiving functions (see Plugins section)

Retrieving the file on the server-side is the same as the 5 steps above, but in reverse. Each plugin listens for incoming file chunks:

1. For each received chunk, send the chunk to the DET framework
2. DET stores each chunk an waits for the arrival of all expected chunks
3. Once all chunks have arrived, reorder the chunks and reassemble into one file
4. Decrypt using the same AES256 key, then decompress using ZLib
5. Check the file's checksum, then save the file

Data format

You may be interested in generating rules to match DET traffic in order to protect your network from data exfiltration.

Though it may be subject to future changes, this section describes how DET traffic looks like on the wire.

Each payload consists of 3 or 4 fields separated by the textual separator |!|. The content of each field varies depending on the role of the payload in the exfiltration process:

• First payload | Registration payload:

job id |!| filename |!| REGISTER |!| md5sum(file)

The first field is the job id. This is a random 7 characters alphanumeric strings (e.g 1LBUdOM) used to identify a file in the exfiltration process. It is used in order not to mess things up when multiple files are exfiltrated at once.

The filename is, well, the name of the exfilrated file

The 3rd field is the string "REGISTER". It is used to inform the server that a new file is being exfiltrated.

The last field is the MD5 sum of the file. When the file transfer is done, the MD5 sum of the received file is checked againt this value.

• Intermediate payloads | Exfiltration payloads:

job id |!| payload order |!| payload data

Payload order is a numeric value representing the order of the payload in the exfiltration process. This is used by the server to re-order the chunks before reassembling.

The 3rd field is actually the data being exfiltrated (related to a chunk)

• Final payload | 'DONE' payload:

job id |!| payload order |!| DONE

This payload is sent to signal the end of the exfiltration process

File retrieval

In order to keep track of payloads and correctly reassemble file fragments at the end of the exfiltration process, DET keeps an internal dictionary called files. Each time a new file is registered, a new entry is added to the files dict with the 'Job id' as a key. The corresponding values are:

• Checksum
• Filename
• Data: An array containing the content of the payloads by arrival order.
• Packets order: This is the order of the elements of the Data array. It is used to put the chunks in the right order before reassembling the final file.
• Packets length: As the total number of expected payloads is not known in advance, this field is updated upon receival of the 'DONE' payload (it is equal to the 'payload order' of the 'DONE' payload). Before reassembling the file, the number of received payloads (i.e len(data)) is checked against this value to determine whether or not all expected payloads have arrived.

_____________________________________
|                   | checksum      |
|                   |---------------|
|                   | filename      |
|                   |---------------|
|      jobid        | data          |
|                   |---------------|
|                   | packets_order |
|                   |---------------|
|                   | packets_len   |
|___________________|_______________|

Plugins

Plugins define exfiltration methods. They are Python modules that are imported by DET during runtime (depending on the command line options).

There are several rules to follow in order to write a new plugin for DET. Typically, a new plugin should follow this skeleton:

config = None
app_exfiltrate = None

def send(data):
    return

def listen():
    return

def proxy():
    return

class Plugin:
    def __init__(self, app, conf):
        global app_exfiltrate, config
        app_exfiltrate = app
        config = conf
        app.register_plugin('icmp', {'send': send, 'listen': listen, 'proxy': proxy})

A valid plugin should contain a Plugin class, which registers itself with DET via app.register_plugin().

You should think of a plugin as an autonomous application that can send data, listens for incoming data and proxifies data (that is listening + sending).

You can import as many modules as you need, in which case you should update the requirements.txt file.

The send function is called each time DET chooses the plugin as an exfiltration method for a particular chunk. The parameter data is actually the payload associated with that particular chunk. You can encode in whatever way you want, as long as the listen function decodes it before handing it over to DET.

The listen function should hand over the received payloads to DET through the app_exfiltrate.retrieve_data method. You can log messages on the terminal with the app_exfiltrate.log_message method by specifying the log level ('info', 'warning', 'ok', etc.)

Note that the plugin configuration should be added in the configuration file (under plugins section) and should have the same name as the Python module (by omitting the extension)