The framework

Introduction

This project is an open-source Python based tunnelling framework that helps you to create a tunnel between two (or more) computers on different channels/protocols. Although the name of the project correlates with the word "exfiltrate", the framework is more about tunnelling than exfiltration. The main use-case for it is to create a full Internet Protocol v4 (IPv4) based tunnel between the end points, that can be used as a communication channel to send IP packets back and forth.

The tool is built on the client-server architecture, so at least two computers are needed to set up the environment. The server side can offer different protocols that can be used for tunnelling. The client chooses a protocol that is offered by the server and available on the client network (for example: allowed on the firewall or not restricted by an active network device), and attempts to create a communication channel or tunnel with the server. If the process succeeds, the specified protocol will be used to tunnel data over the network.

What's new about this

There is nothing new about tunnelling, there are and were loads of tools on the Internet that can be used, but exactly this was the problem. Each and every tool was designed to do only one thing: to do tunnelling over a specific protocol and that it is. In majority of the cases there were some issues like:

• No Portability
• No Modularity
• No Automation
• No Support or it was End of Life product
• No Documentation
• Hard to configure

This project aims to change the landscape of tunnelling, by developing a framework that fixes these issues.

Framework

By aiming to change this, XFLTReaT works as a framework. It supports multiple protocols (not just only one) and unifies the interface for all tunnelling modules. It is possible to create new tunnel modules for protocols with ease.
Also the framework makes tunnelling easier for everybody, because:

• It is easy to install and configure (still a basic understanding is needed)
• The dependencies are kept low
• Unified tunnelling interface is developed for creating modules
• Uses only one interface for all traffic
• Handles multiple clients
• Modular authentication support
• Modular encryption support
• Python based and OOP
• Check functionality to map out the network (see below)

Modes of operation

Server

By not specifying any (or specifying the --server) arguments when running the framework, it will start in server mode. The server mode runs all the modules that were enabled in the configuration, so it binds on a port or on a socket and waits for incoming connections. When the client connects, the received IP packets will be rewritten and forwarded to the original destination.

Check

If the --check argument is specified the framework does the following things on all enabled modules:

• generates a challenge (not a mathematical hard one)
• sends it to the server (encapsulated in the selected protocol)
• waits for the server response on the same protocol

If the server responded and the challenge's solution is right, it means that the protocol could be used for exchanging data (green line), so it might be capable to do tunnelling. In case there was no answer or the solution was wrong, the protocol is filtered or altered (red line).

This feature comes handy when the client connects to a new network and needs to find a way to tunnel data. It makes the process a lot easier than crafting ICMP/TCP/DNS/etc packets by hand.

Client

When --client argument is specified, only one module MUST be enabled in the configuration. That enabled module will be used to create a tunnel over the protocol. If connection was made, all data will be routed over that channel instead of using the default route.

In case if the --split argument is specified along the --client then the split tunnel mode will be used. In this mode NOT all traffic will be sent over the tunnel, only those packets that are sent to IPs that are explicitly listed in the scope.txt (or in the file that was specified in the configuration under the [Global] section's scope option).

Command line arguments

The tool comes with a number of arguments that can modify behaviour of the tool. Three of these are already listed above (server, client and check).

Help

Argument: -h or --help

Prints out the help menu that lists and explains all the arguments.

Config

Argument: --config=config.file

By default the framework uses the xfltreat.conf file, but an alternate configuration can be set with this.

Split tunnelling

Argument: --split

This option enables the split tunnelling functionality. If this was enabled then the framework does not change the default gateway, but adds specific routes for IPs/IP ranges that can be found in the scope file, which is by default the misc/scope.txt, but can be modified in the configuration.

Ignoring missing dependencies

Argument: --ignore-dependencies

In certain cases it is not possible or hard to install Python modules, and we still want to use the basic functionality of the framework. If no encryption needed or the SCTP module will not be in use, then by running the framework with this option will ignore the warnings and run. This could introduce some unwanted effects, like raised exceptions. Only those should use this option who are capable handling the issues caused by this.

Verbose mode

Argument: --verbose=2

There are three verbosity levels (0, 1, 2). The default is 0, which suppresses all the output and only prints that is really necessary. The level 1 is the verbose mode, where slightly more information is printed and the level 2 is the debug mode where all packet related information is printed.

Server

Argument: NONE or -s or --server

Default mode, see above.

Client

Argument: -c or --client

See above.

Check

Argument: --check

See above.

Unified modul interface

Reading the Development section on the Wiki helps to understand this topic in depth. In a nutshell the framework requires a module format that needs to be used when a new module is developed. This format consists of predefined methods and attributes that must be in the module. These methods will be called and the attributes will be interpreted by the framework.
The format should cover the differences between tunnelling types like stateless and stateful, or when a different channel is used to send and receive, etc.

One interface to rule them all

Installing different tunnelling tools would mean multiple network interfaces. These interfaces have to be set up, routing and firewalls need to be adjusted according to these. XFLTReaT changes this, even if multiple different tunnels are in use in the same time, it uses only one. It reduces the administration overhead, only one firewall rule needs to be added.