Skip to content
Reverse Engineering
Command & Controladvanced

Peer-to-Peer C2

A botnet replaces its central server with a peer-to-peer overlay, so nodes relay commands to each other with no single C2 address to seize.

Peer-to-peer C2 dissolves the central server. Instead of every implant calling one host, each infected node holds a peer list of other infected nodes and exchanges tasking, updates, and stolen data with them over a custom overlay protocol. Commands are typically signed by the operator's private key and gossiped through the mesh, so any peer can inject and propagate them while no peer needs to know the operator's address. Take one node offline and the rest re-route around it; there is no IP or domain whose seizure decapitates the botnet.

This resilience is exactly why GameOver Zeus, Sality, the Hide N Seek IoT botnet, and TrickBot's P2P-style modules adopted it, and why takedowns require either sinkholing the peer-exchange protocol at scale or cryptographically poisoning the peer lists. The trade-off for the operator is a chatty, distinctive network footprint: every node continuously probes a churning set of peers on non-standard ports to keep its list fresh, producing fan-out traffic that looks nothing like a client talking to one server.

For an analyst the prize is the peer-exchange protocol, the bootstrap peer list, and the command-signing public key — recovering them lets defenders enumerate the botnet, crawl the mesh, and validate (or forge, in a sanctioned takedown) the signed commands.

How it works

Each node periodically contacts entries from its peer list, exchanges fresh peers, and pulls any newer signed command, verifying it against an embedded public key before acting:

c
// Illustrative P2P node loop — descriptive, not deployable.
// Tasking is gossiped peer-to-peer and verified by signature.
void p2p_node_tick(peer_t *peers, size_t npeers)
{
    for (size_t i = 0; i < npeers; i++) {
        msg_t m;
        if (!peer_request(&peers[i], OP_GET_CMD, &m))    // probe a peer
            continue;
        peer_merge_list(peers, m.advertised_peers);      // peer exchange
        if (m.cmd_version > local_version &&
            verify_sig(EMBEDDED_PUBKEY, m.cmd, m.sig)) {  // operator-signed
            run_command(m.cmd);                          // propagate forward
            local_version = m.cmd_version;
        }
    }
}

Tells for a reverser: an embedded peer list or bootstrap node array, a custom binary message framing with version numbers, a verify-style routine against a hard-coded public key, and UDP/TCP traffic to many short-lived peers on a fixed non-standard port. The signing public key and the peer-exchange opcodes are the strongest static anchors.

Detection & analysis

Static analysis:

  • Recover the bootstrap peer list (often a hard-coded array of IP:port pairs) and the peer-exchange message format. These let you crawl the overlay and enumerate live nodes. Version fields in the messages reveal the command-propagation scheme.
  • Extract the embedded public key and the signature-verification routine. Commands are operator-signed so that a hijacked peer cannot subvert the botnet; recovering the key lets investigators validate captured commands and is central to any takedown that poisons or replaces tasking.
  • Identify the overlay transport and port. A custom framing on a fixed high port, with opcodes for "get peers / get command / push data", confirms a P2P design rather than client-server C2.

Dynamic analysis:

  • Detonate and observe the fan-out. A P2P node continuously connects outbound to many distinct external IPs on one non-standard port, with short, symmetric exchanges and frequent peer churn — the opposite of a beacon's single destination. This many-peers-one-port pattern is the behavioural signature.
  • Capture and replay the peer-exchange messages with the reversed protocol to crawl the mesh and map the botnet; correlate observed peers against threat-intel node lists.
  • Watch for a node that both connects out to peers and accepts inbound connections on the same port — bidirectional same-port traffic distinguishes a mesh participant from an ordinary client.

Detection rule hint:

Flag internal hosts that initiate outbound connections to a large, churning set of external IP addresses on a single non-standard port with small, symmetric request/response payloads, especially when the same host also accepts inbound connections on that port — many-peer fan-out on a fixed port, rather than steady traffic to one server, is the marker of peer-to-peer C2. Enrich with reversed peer-exchange opcodes and known-node intel to confirm.

Votes

Comments(0)