The framework

Introduction

This project is an open-source Python based tunnelling framework that helps you 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 succeed, 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 every 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 (needs some improvements)
• Modular encryption support (will be introduced later)
• 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, then that 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.

Unified modul interface

Reading the Development section on the Wiki helps to understand this topic in depth, but in a nutshell the framework requires a module format that needs to be used when a new module is developed. This format consists predefined methods and attributs 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 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.