Zero-Knowledge Relay: Why Your Red Team Data Should Never Touch a VPS

MAY 2, 2026 - Written by Yves SoeteBlacksight LLC — architecture details atred.blacksight.io/connect

Most red team drop boxes phone home via SSH reverse tunnels to a VPS — meaning every captured credential, hash, and PCAP sits on a cloud server that can be compromised, subpoenaed, or seized. We built a zero-knowledge relay that forwards encrypted blobs without being able to decrypt them. Here is how the architecture works and why it matters for OPSEC.

The standard red team exfiltration path looks like this: device at target connects to operator's VPS via SSH reverse tunnel, operator SSHs into VPS, data sits on VPS disk. This works until it does not.

The VPS problem

A VPS running in AWS, DigitalOcean, or Linode is a server you do not control. The hosting provider has physical access to the hardware. Law enforcement can serve the provider with a warrant. The VPS itself is a target — it runs an SSH server on the public internet, and if your key management is sloppy (and during a multi-day engagement at 2 AM, it often is), it becomes an attack surface.

More importantly, the VPS decrypts everything. The SSH tunnel terminates there. Captured NTLMv2 hashes, WPA handshakes, credential pairs from captive portals, full PCAPs — all of it sits in plaintext on a server you rented with your credit card. If that server is compromised by a third party during the engagement, your client's data is exposed. If the hosting provider receives a legal order, they can image the disk.

For a penetration testing firm handling sensitive engagements — financial institutions, defense contractors, healthcare organizations — this is an unacceptable risk that most firms accept simply because no better option existed.

How the Blacksight Relay works

The Blacksight Relay at relay.blacksight.io is a WebSocket message broker. It has three properties that make it fundamentally different from a VPS tunnel:

1. End-to-end encryption. All data is encrypted on the device before it leaves. The encryption keys exist only on the device and on the operator's client (the Blacksight Connect app or web dashboard). The relay never has the keys. It receives ciphertext from the device and forwards ciphertext to the operator. It cannot decrypt, modify, or inspect any payload.

2. No persistent storage. The relay has no database. It writes nothing to disk. Connection state (which device code is connected to which operator session) is tracked in memory using ETS and is lost on restart. There are no logs of payload content. There is no command history. A forensic image of the relay server yields nothing useful about any engagement.

3. Metadata minimization. The relay knows two things: a device code is connected, and an operator session is requesting access to that device code. It does not know what kind of device it is, what mode it is running, what data it is capturing, or what commands the operator is sending. All of that is inside the encrypted blob.

What happens if the relay is compromised

If an attacker gains root on the relay server, they can observe encrypted WebSocket connections in real time. They can see that device code ABC123 is connected and that an operator session is matched to it. They can see encrypted binary blobs flowing in both directions.

They cannot decrypt any of it. They cannot inject commands (commands are encrypted and authenticated — the device rejects anything it cannot decrypt with its key). They cannot modify data in transit without breaking decryption on the other end. They cannot recover historical data because none exists on disk.

Compare this to a compromised VPS: attacker gets plaintext access to every credential, hash, PCAP, and command log from every engagement that ever used that server.

The data flow in detail

Device to operator (loot exfiltration): The device captures data (credentials, hashes, PCAPs, scan results). It encrypts the payload locally. It sends the ciphertext over 4G cellular to the relay via a persistent WebSocket connection. The relay looks up the matched operator session for that device code and forwards the ciphertext. The operator's client decrypts it locally.

Operator to device (commands): The operator sends a command (kill switch, mode toggle, config change, self-destruct). The command is encrypted on the operator's client. The ciphertext is sent to the relay. The relay forwards it to the device. The device decrypts and executes it. The relay never knows what command was sent.

Device connectivity: The device uses its own 4G cellular connection, completely independent of the target network. It never touches the target's internet uplink. This provides an independent OPSEC channel that cannot be monitored by the target's network security team.

Optional relay usage

The relay is not mandatory. Operators can choose to keep all data on the device and retrieve it physically at the end of the engagement. The relay is there for operators who need real-time access to engagement data without returning to the target site — but the choice is yours.

Full architecture diagrams and technical details at red.blacksight.io/connect.