What is Tunna and how does it work?

Share this…

Tunna is a union of tools that will wrap any TCP communication over HTTP. It can be used to bypass network restrictions in environments completely protected by firewalls.



In a completely closed firewall, restricted incoming and outgoing connections, except the port of the web server, explains an expert in data security. The webshell can be used to connect to any service on the remote host. This would be a local connection on a local port on the remote host and should be allowed by the firewall.

The webshell will read the service port data and wrap them over HTTP and send them as an HTTP response to the local proxy.

The local proxy will develop and write the data in its local port where the client program will connect. When the local proxy receives data in the local port, it will send it to the webshell as an HTTP POST request. Webshell will read the HTTP POST request  data and place it in the service port and repeat.

Only the web server port must be open (normally 80/443). All communication (external) is made through the HTTP protocol.

tunna 1 bien

tunna 2 bien

tunna 3 bien

tunna 4 bien

tunna 5 bien

Initiation phase

The first package starts a session with webshell: retrieves a cookie, for example: https: //webserver/conn.ext?proxy

The second packet sends the connection configuration options to the webshell, for example: https: //webserver/conn.ext?proxy & port = 4444 & ip =

IP and port for the webshell to connect to this is a threaded request: In php this request will enter an infinite loop to keep the webshell socket connection alive. Also, the professional in cyber security tells us; in other webshells [OK] it is received again.

TUNNA client

A local socket to which the client program will connect will be created. Once the client is connected, the ping thread starts and execution begins. All data in the client socket is read and sent as an HTTP Post request. All data in the webshell socket is sent in response to the POST request.

Pinging thread

Since HTTP responses cannot be asynchronous. This thread will make HTTP get requests in the webshell based on an interval. If the webshell has data to send, it will also send it in response to this request. Otherwise, it will send an empty response.

The local proxy data is sent with HTTP POST request. There are Get requests every 0.5 seconds to query the webshell data if there is data on the webshell side sent in response to one of these requests


Webshell connects to a socket on the local or remote host. Any information written in the socket is sent back to the proxy in response to a request (POST / GET) any information received with a POST request is written to the socket.


All requests must have the URL parameter “proxy” configured to be managed by the webshell (https: //webserver/conn.ext?proxy)

At exit / at error

Remove all threads and close the local socket. Send the proxy and close it to webshell: remove the remote threads and close the socket


The SOCKS support is a complement module for Tunna. Locally there is a separate thread that handles connection requests and traffic adds a header that specifies the port and the size of the packet and forwards it to Tunna. According to the cyber securityexpert, Tunna sends it to the remote web server removes the HTTP headers and forwards the packet to the remote SOCKS proxy. The SOCKS remote proxy initiates the connection and assigns the received port to the local port. If the remote SOCKS proxy receives service data, looks at the allocation table, and finds the port it needs to respond to, it adds the port as a header so that the local SOCKS proxy knows where to forward the data. Any traffic from the received port will be sent to the local port and vice versa.