Implementing a VPN throught text files

During our last audit, we encountered a network architecture that aroused our curiosity. The architecture was composed of two segregated networks. Those two networks completely separated but could both access a storage filesystem replicated in both networks by a central black-box, connected to the filesystem servers using a non-ip protocol.
The network is as shown in this simplified diagram:

Figure 1

Figure 1 – Network diagram

Our thought process was the following: Without trying to exploit the filesystem in any way, is it possible to take advantage of a shared folder and create a VPN to interconnect the two networks?
Short answer, yes it is possible, provided that they both have access to a shared folder, on which they have both read and write permissions.
The idea we had is to create a really simple VPN between the two networks, using the filesystem as crossing point, by writing requests into text files. Here goes the first VPN-through-text-files script.


Let’s say that a user is allowed to interact once with a machine on the network 2, or gets with some social engineering a user to run the script for him on the Network 2. He could take advantage of this one time only access to deploy the VPN-through-text-files script on the Network2 that would grant himself a permanent access from the network 1.
This network diagram (Figure 2 – VPN in action) is a high level representation of how the VPN-through-text-files script would works once executed.

Figure 2 - VPN in action (simplified)

Figure 2 – VPN in action (simplified)

The VPN would function like this (refer to Figure 2):

  • (1): Client sends a ping request to Target Server (this would normally result in “host unreachable” response because the two networks are segregated);
  • (2): The VPN-through-text-files script in “network 1” intercepts the request for Target Server and writes it in a SMB share on the filesystem in “network 1”;
  • Replication happens;
  • (3, 4): The VPN-through-text-files script in “network 2” reads the request received in the file and send it to the network;
  • (5): Target Server receives the request and proceeds to answer it;
  • (6): The VPN-through-text-files script in “network 2” intercepts the request for Client and writes it in a SMB share on the filesystem in “network 2”;
  • Replication happens;
  • (7, 8): The VPN-through-text-files script in “network 1” reads the request received in the file and send it to the network;
  • (1): Client received the request and proceeds to answer it;
  • Etc.

Having a general idea of how the script was going to work, it was time to implement a proof-of-concept of the script.


The VPN-through-text-files script was developed in Python, using the well know Python network library: Scapy.
The VPN-through-text-files script has three main components, each component is threaded:

  • Arp component: This component sniff the ARP requests on the network and answers to all requests indicating his MAC address in each response. This allows the VPN to poison ARP tables of the VPN clients and trick the clients to interact with it when sending requests to the new network;
  • Sender component: This component intercepts all requests directed at the MAC address of the machine running the VPN-through-text-files script and write to a file on a SMB share folder;
  • Receiver component: This component continuously reads a file on a SMB share folder and rebuild any request read in the file. When successfully rebuilt, the component sends them on the network.

The major problem faced during the development is with the receiver component.
In the scenario described in “Figure 2 – VPN in action (simplified)”, the user would have no control on the machines in the “Network 2”.
The problem aroused here is: How could we be sure to redirect all network responses of the machines to our VPN, without interacting with them, adding new routes, etc.?
When contacting the server on Network 2 through the VPN, if we decided to use as source IP the IP of the first network, it is unlikely that the server was going to respond. This is due to the fact that the server might not have a route to the particular address plan of Network 1, resulting in a “No route to host” error, as shown in the diagram below.

Figure 3

Figure 3 – First case scenario, no change to source IP

Secondly, we could not use the IP of the computer hosting the script on Network 2, because we would not have been able to create TCP connections across the VPN. This is due to the fact that the TCP stack of the machine hosting the script would be handling the TCP connection and would cause the TCP connection through the VPN to reset (see diagram below).

Figure 4

Figure 4 – Second case scenario, changing IP for VPN’s machine IP

Solution: Virtual IP

By creating several virtual IPs, we were able to circumvent this problem. In the “Figure 2 – VPN in action (simplified)” example, we would create a virtual IP in the range 10.200/16 and respond to any ARP request looking for our virtual IPs, indicating to all computers that we are hosting those fictive IPs.
The two problems explained in the two previous diagrams are solved by this simple solution. The server is able to route its responses to the virtual IPs, and the responses are not treated by the TCP stack of the machine, because the IP in the request does not match the IP of the machine (see diagram below for a detailed explanation).


Figure 5 – Solution, using virtual IP

The VPN script keeps track of the connections made and which virtual IP belongs to which host in the Network 1 and replaces back the virtual IP by the original IP before writing back the request to the folder, and the trick is done.


Testing the script
The VPN-through-text-files script offers a simple connection between the two networks, without any encryption or compression. Supported protocols include TCP (http, ssh, etc.) and ICMP for now.
The script was tested on a Kali Linux 4.6.0 x86_64, using Python 2.7.12+ and Scapy 2.3.2.

The screenshot below represents the test environment that was used for testing.

Figure 6

Figure 6 – Network diagram of the test environment

As we can see in the screenshot below, the client at (bottom left in the screenshot) is able to establish a SSH connection with the server at (bottom right in the screenshot) thought the VPN, even if the two networks are supposed to be segregated.

Figure 7

Figure 7 – VPN-through-text-files in action

The prerequisite in order for this script to work is that the attacker has had to have access at least once to the second network in order to implant and run the VPN-through-text-files script.


As we demonstrated with this proof of concept, it is possible using our VPN-through-text-files script to interconnect two segregated networks, using a shared file system.
The source code of this project will be available shortly.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.