Zero-Knowledge Relay: An Exfiltration Channel We Cannot Read

Every drop box needs a way to phone home. The standard approach is an SSH reverse tunnel to a VPS you rent from a cloud provider, and it works -- until you think about what you're actually doing. You're sending captured credentials, network maps, and client data through a server that stores everything in plaintext on disk, that can be subpoenaed, that can be compromised by anyone who pops the VPS, and that you're trusting entirely because you set it up yourself. The Blacksight Relay at relay.blacksight.io was built to eliminate that trust requirement entirely.

Why Are VPS-Based Tunnels a Liability?

The typical drop box exfiltration setup looks like this: the device establishes an SSH reverse tunnel to a VPS (usually a $5/month Linode or DigitalOcean instance), the operator SSH-es into the VPS and through the tunnel to the device, and loot is either pulled through the tunnel or uploaded to the VPS for later retrieval. Some operators use Wireguard or OpenVPN instead of SSH, but the architecture is the same: a rented server in the middle that sees everything.

The problems with this approach are structural, not incidental:

• Plaintext on disk. Captured hashes, credentials, PCAPs, and network maps sit on the VPS filesystem in cleartext. If the VPS is compromised (and cloud instances are targeted constantly), everything from the engagement is exposed. Full disk encryption helps but doesn't protect against a compromised running system.
• Subpoena risk. Cloud providers comply with law enforcement requests. If your VPS is in a US datacenter, a subpoena can compel the provider to image the disk, capture network traffic, or provide access credentials. You may not even be notified, depending on the jurisdiction and whether a gag order is attached.
• Shared infrastructure. Your VPS runs on shared hardware. Hypervisor vulnerabilities, side-channel attacks, and provider-side access are all in the threat model. You're trusting the cloud provider's security posture with your client's data.
• Credential management. SSH keys or VPN credentials for the VPS need to be on the drop box. If the device is discovered and seized, those credentials give the finder access to the VPS and everything on it -- current engagement, past engagements if you reuse the instance, and any other infrastructure connected to it.
• Attribution. The VPS is rented with your payment method. It has a static IP that points back to your account. If the engagement goes sideways or there's a dispute about scope, the VPS creates a clear attribution chain.

How Does the Blacksight Relay Work?

The relay at relay.blacksight.io is a WebSocket broker. It accepts connections from Phantom and Scout devices on one side and from operator clients (the dashboard or CLI) on the other. Its only job is to forward messages between matched pairs. It does not decrypt, inspect, store, or log the contents of those messages.

The relay runs as an Elixir/Phoenix application. Device and operator connections are authenticated using short-lived tokens derived from the device's identity key and the operator's account credentials. The relay verifies that the device and operator belong to the same account and establishes a forwarding channel between them. From that point on, every message from the device is forwarded to the operator, and every message from the operator is forwarded to the device. The relay treats the message payload as an opaque binary blob.

The Three Properties

The relay's security model rests on three properties: end-to-end encryption, no persistent storage, and metadata minimization.

End-to-End Encryption: AES-256-GCM

All data between the device and the operator is encrypted with AES-256-GCM before it leaves the device. The encryption key is derived during device provisioning using ECDH (Elliptic Curve Diffie-Hellman) key agreement between the device's identity key and the operator's key pair. The resulting shared secret is passed through HKDF (HMAC-based Key Derivation Function) to produce the AES-256 encryption key and a separate authentication key.

GCM (Galois/Counter Mode) provides both confidentiality and authenticity. Each message includes a 96-bit nonce (incremented per message to prevent reuse) and a 128-bit authentication tag. The authentication tag ensures that any modification to the ciphertext -- including by the relay itself -- is detected and rejected by the recipient. The relay cannot tamper with messages in transit without the operator's client detecting it.

The critical point: the encryption keys exist only on the device and in the operator's client. They are never sent to the relay, never derived from relay-held material, and never stored anywhere the relay can access. The relay forwards ciphertext. That's it.

No Persistent Storage: ETS In-Memory Only

The relay stores connection state and message routing information in ETS (Erlang Term Storage), which is an in-memory data structure native to the BEAM virtual machine. ETS tables are not persisted to disk. When the relay process restarts, crashes, or is redeployed, all state is lost.

There is no database. There are no log files containing message content. There is no message queue that buffers data to disk when the operator is offline. If the operator is not connected when the device sends data, the message is held in an ETS-backed buffer with a configurable TTL (default: 5 minutes) and then discarded. If the operator connects within that window, buffered messages are delivered and immediately removed from the buffer. If not, they're gone.

This is a deliberate trade-off. A relay that buffers indefinitely would be more convenient (the operator could disconnect for hours and catch up later), but it would also accumulate encrypted data on the relay server -- data that, while encrypted, could be stored and potentially attacked later if a key is compromised. The short TTL ensures the relay never accumulates meaningful data.

Metadata Minimization

The relay logs connection events (device connected, operator connected, channel established) for availability monitoring but does not log message content, message sizes, message timing at sub-second granularity, or source IP addresses. Connection events are logged with the account identifier (a UUID) and a timestamp, retained for 24 hours for debugging, then deleted.

The relay does not know the Phantom's deployment location, the target network, the type of data being exfiltrated, or the commands being sent. It knows that account X has a device connected and an operator connected, and that messages are flowing between them. That's the minimum metadata required to perform message routing.

What Happens If the Relay Is Compromised?

Assume the worst: an attacker gains root access to the relay server. What do they get?

• Current message traffic: Encrypted blobs in transit. AES-256-GCM ciphertext with no key material on the server. Decryption requires the operator's private key, which is not on the relay.
• Buffered messages: Encrypted blobs in ETS, at most 5 minutes old. Same encryption, same lack of key material.
• Historical data: Nothing. ETS is in-memory only, no database, no persistent logs of message content.
• Connection metadata: Account UUIDs and timestamps from the last 24 hours. No IP addresses, no device locations, no target information.
• Authentication tokens: Short-lived (15-minute expiry), specific to the WebSocket session, and useless for decrypting message content.

An attacker who compromises the relay can see that encrypted traffic is flowing and between which account identifiers. They cannot decrypt that traffic, inject commands that the device or operator would accept (because injected messages would fail GCM authentication), or access historical engagement data. The damage is limited to traffic analysis of connection timing and volume.

Compare this to a compromised VPS: the attacker gets plaintext credentials, PCAPs, network maps, SSH keys to the drop box, and potentially data from previous engagements. The relay's zero-knowledge architecture makes compromise a metadata exposure event rather than a total engagement compromise.

How Does Data Flow Between Device and Operator?

The complete data path for a loot exfiltration (device to operator):

• The Phantom captures data (credentials, handshakes, PCAP excerpts, scan results) and serializes it into a structured message.
• The message is encrypted with AES-256-GCM using the shared key derived during provisioning. The nonce is incremented. The resulting ciphertext and authentication tag are packed into a binary frame.
• The encrypted frame is sent over the WebSocket connection to relay.blacksight.io. The WebSocket connection itself uses TLS 1.3, adding a transport-layer encryption envelope.
• The relay receives the frame, identifies the destination (the operator's WebSocket connection for this account), and forwards the frame without modification.
• The operator's client receives the frame, verifies the GCM authentication tag (rejecting the message if it has been tampered with), decrypts it with the shared key, and deserializes the original message.

The command path (operator to device) is identical in reverse. The operator's client encrypts the command, the relay forwards it, and the device decrypts and executes it. Every message in both directions is encrypted end-to-end with keys the relay never possesses.

Is the Relay Required for Every Engagement?

The relay is not mandatory. The Phantom stores all captured data on its encrypted local partition. An operator who prefers to avoid any third-party infrastructure (including ours) can deploy the Phantom, let it capture data locally, and retrieve the device physically at the end of the engagement. The encrypted partition is unlocked with the operator's key, and the data is extracted directly.

This is the right choice for engagements with extremely strict data handling requirements (certain government or defense contracts, for example) where no engagement data should traverse any external network, even encrypted. The trade-off is losing real-time visibility: without the relay, the operator cannot monitor the engagement, adjust modes, or trigger the kill switch remotely.

A middle ground is using the relay for command and control (mode switching, status checks, kill switch) but keeping captured data local. Scope, Venom, Siren, and Fang can be configured to store loot locally rather than exfiltrating it. Commands and status messages are small and contain no client data, so the metadata exposure from relay usage is minimal.

How Does the Relay Compare to a VPS?

The fundamental difference is trust. A VPS requires you to trust the server -- trust that it won't be compromised, trust that it won't be subpoenaed, trust that the provider won't access your data, trust that you configured it correctly, trust that you'll remember to wipe it after the engagement. The relay requires no trust. Even if we are hostile -- even if we actively try to compromise your engagement -- the end-to-end encryption prevents us from reading your data, and the GCM authentication prevents us from injecting commands.

This isn't a theoretical distinction. The relay was designed so that its security properties hold even against the operator of the relay itself. We built a system we cannot abuse, because the alternative was asking customers to trust us, and trust is not an engineering control.