Listeners

Resources

TCP :
- By h3ll-ka1ser : https://h3ll-ka1ser.gitbook.io/boot2root/tools/c2-frameworks/cobalt-strike/tcp-beacon
Smb :
- By h3ll-ka1ser : https://h3ll-ka1ser.gitbook.io/boot2root/tools/c2-frameworks/sliver/lateral-movement/pivots
Dns :
- By infoblox : https://www.infoblox.com/blog/security/dns-a-small-but-effective-c2-system/
- By h3ll-ka1ser : https://h3ll-ka1ser.gitbook.io/boot2root/tools/c2-frameworks/sliver/dns-c2
Detection :
- Detect Cobalt Strike Masquerading : https://ar5iv.labs.arxiv.org/html/2506.08922
- Detecting DNS-Tunneling Malware : https://ar5iv.labs.arxiv.org/html/2505.22220

Tools

ja3 : https://github.com/salesforce/ja3

Notes

HTTP & HTTPs
The HTTP Process (Insecure / Plaintext)

In standard HTTP, all data is sent across the internet exactly as it is typed. If your beacon uses HTTP, the enterprise firewall can read the exact malware commands.

TCP Handshake: The beacon and server establish a basic connection (SYN, SYN-ACK, ACK).

The Request: The beacon sends the HTTP GET request. The URL (e.g., /get_task?id=99) and all headers are sent in visible plaintext.

The Response: The C2 server sends the command (e.g., whoami) back in plaintext.

The Flaw: The enterprise firewall inspects the packet, sees the word whoami, and instantly blocks it.
sequenceDiagram
    participant Beacon
    participant Firewall
    participant C2 Server
    
    Beacon->>C2 Server: 1. TCP Handshake
    Beacon->>Firewall: 2. GET /task (Plaintext)
    Note over Firewall: Reads: "Ah, this is a C2 check-in"
    Firewall--xC2 Server: 3. BLOCKS CONNECTION
The HTTPS Process (Secure / Ciphertext)

HTTPS uses the exact same HTTP protocol, but it adds a TLS handshake to build an encrypted tunnel before any actual HTTP data is sent.

TCP Handshake: The beacon and server establish a basic connection (Port 443).

ClientHello: The beacon says hello and lists its supported encryption ciphers.

ServerHello & Certificate: The server picks an encryption method and sends its digital certificate.

Key Exchange: Both sides mathematically agree on a temporary, secret “Session Key”.

The Encrypted Tunnel: The secure tunnel is now locked.

The Request & Response: The beacon asks for a task, and the server sends the command. Both are encrypted.

The Advantage: The firewall only sees a stream of randomized, unreadable bytes (ciphertext) and lets it pass.
sequenceDiagram
    participant Beacon
    participant Firewall
    participant C2 Server
    
    Beacon->>C2 Server: 1. TCP Handshake
    Beacon->>C2 Server: 2. TLS ClientHello & ServerHello (Keys Exchanged)
    Note over Beacon, C2 Server:  SECURE TUNNEL ESTABLISHED 
    Beacon->>Firewall: 3. Encrypted GET Request (Random Bytes)
    Note over Firewall: Firewall is blind.<br>Reads: "kj298hdsf..."
    Firewall->>C2 Server: Forwards Packet
    C2 Server->>Beacon: 4. Encrypted Response (Random Bytes)

C2 Listener Topologies and Decision Guide

Listener Categories

Listener Type Category Who Initiates Internet Required? Best For
HTTP/HTTPS Egress Implant → Teamserver Yes (direct) Standard engagements, blended web traffic
DNS Egress Implant → Teamserver Yes (direct) Strict egress filtering
mTLS Egress Implant → Teamserver Yes (direct) High-bandwidth internal ops
SMB P2P Implant ←> Upstream Beacon No (relayed) Windows internal networks, segmented subnets
TCP P2P Implant ←> Upstream Beacon No (relayed) Cross-platform internal pivoting
External C2 Hybrid Both Depends Custom protocols (DoH, Slack, etc.)

What “Egress” Means

An egress listener is one where the implant initiates a connection outbound to your teamserver (or redirector). The traffic flows from the victim’s network to the internet.

The implant “calls home.”

The teamserver listens for incoming connections.

Works through firewalls because outbound traffic is usually allowed.

Examples: HTTP, HTTPS, DNS, mTLS.

What “P2P” Means

A peer-to-peer (P2P) listener is one where the implant communicates with another beacon, not directly with the teamserver. The traffic stays inside the internal network.

The downstream beacon doesn’t have internet access.

It talks to an upstream beacon that does have internet access.

The upstream beacon relays commands and output.

Examples: SMB (named pipes), TCP pivots.

What “Both” Means

External C2 is the only listener type that can work in both modes, because it’s a specification, not a fixed implementation. You decide how the Third-Party Client communicates with the Third-Party Controller:

Implementation Choice Mode Example
Client initiates connection to Controller Egress DoH over HTTPS
Controller initiates connection to Client P2P/Bind Named pipe relay through an upstream beacon
Both directions (bidirectional) Hybrid Custom protocol with fallback

This is why External C2 is the most flexible - and also the most complex.

Quick Decision Guide

Scenario Use
Victim has internet access HTTP/HTTPS, DNS, or mTLS (egress)
Victim has no internet, but SMB is allowed internally SMB beacon (P2P)
Victim has no internet, and SMB is blocked TCP pivot (P2P)
Victim has no internet, tunnel via custom protocol External C2 (hybrid)
You need high bandwidth and low latency mTLS (egress)
You need to bypass strict egress filtering DNS (egress)
You need to blend with normal web traffic HTTPS (egress)

Summary

Category Listeners Direction
Egress HTTP/HTTPS, DNS, mTLS Implant → Teamserver (direct)
P2P SMB, TCP Implant ←> Upstream Beacon (relayed)
Both External C2 Depends on your implementation

The rule of thumb: Egress listeners cross the network boundary to the internet. P2P listeners stay inside the network and rely on another beacon to relay their traffic out. External C2 is the wildcard - you decide which mode it uses.

Listener Type	Category	Who Initiates	Internet Required?	Best For
HTTP/HTTPS	Egress	Implant → Teamserver	Yes (direct)	Standard engagements, blended web traffic
DNS	Egress	Implant → Teamserver	Yes (direct)	Strict egress filtering
mTLS	Egress	Implant → Teamserver	Yes (direct)	High-bandwidth internal ops
SMB	P2P	Implant ←> Upstream Beacon	No (relayed)	Windows internal networks, segmented subnets
TCP	P2P	Implant ←> Upstream Beacon	No (relayed)	Cross-platform internal pivoting
External C2	Hybrid	Both	Depends	Custom protocols (DoH, Slack, etc.)

Implementation Choice	Mode	Example
Client initiates connection to Controller	Egress	DoH over HTTPS
Controller initiates connection to Client	P2P/Bind	Named pipe relay through an upstream beacon
Both directions (bidirectional)	Hybrid	Custom protocol with fallback

Scenario	Use
Victim has internet access	HTTP/HTTPS, DNS, or mTLS (egress)
Victim has no internet, but SMB is allowed internally	SMB beacon (P2P)
Victim has no internet, and SMB is blocked	TCP pivot (P2P)
Victim has no internet, tunnel via custom protocol	External C2 (hybrid)
You need high bandwidth and low latency	mTLS (egress)
You need to bypass strict egress filtering	DNS (egress)
You need to blend with normal web traffic	HTTPS (egress)

Category	Listeners	Direction
Egress	HTTP/HTTPS, DNS, mTLS	Implant → Teamserver (direct)
P2P	SMB, TCP	Implant ←> Upstream Beacon (relayed)
Both	External C2	Depends on your implementation

Rotation Strategies
The Core Concept: What is Host Rotation?

When configuring an HTTP or HTTPS payload, you provide a list of multiple callback hosts (redirectors). Host Rotation is the internal logic the beacon uses to decide which host to connect to for its next check-in. The primary goal is Operational Security (OPSEC): breaking predictable patterns so network defenders cannot easily identify and block your C2 traffic using frequency analysis.

The Four Strategies Explained

1. Round Robin (Load Balancing) The beacon loops through the host list sequentially top-to-bottom. Each host is used for exactly one connection before moving to the next. When it reaches the end, it starts over.

2. Random (Evasion) The beacon selects a host completely at random for each connection attempt. This destroys predictable frequency analysis, making it exceptionally difficult for AI-driven firewalls to spot a pattern.

3. Failover (Maximum Stability) The beacon is “sticky.” It connects exclusively to the first working host. It will only switch to the next host if the current one fails consecutively for a specified number of attempts (failover-x) or a specified duration (failover-m/h/d).

4. Rotate (Scheduled Burn) The beacon connects to a host for a specific amount of time (rotate-m/h/d), then automatically switches to the next host in the list regardless of whether the first host is still working.

Visualizing the Routing Logic
graph LR
    subgraph Round Robin
        B1(Beacon) -->|1st check-in| H1(Host A)
        B1 -->|2nd check-in| H2(Host B)
        B1 -->|3rd check-in| H3(Host C)
    end

    subgraph Random
        B2(Beacon) -.->|Randomly picks| H4(Host A)
        B2 -.->|Randomly picks| H5(Host B)
        B2 -.->|Randomly picks| H6(Host C)
    end

    subgraph Failover
        B3(Beacon) ===|Continuous check-ins| H7(Host A)
        H7 -.-x|Firewall Blocks Host A| H7
        B3 -->|Fails over to| H8(Host B)
    end

    subgraph Rotate
        B4(Beacon) -->|Hours 1-2| H9(Host A)
        B4 -->|Hours 3-4| H10(Host B)
        B4 -->|Hours 5-6| H11(Host C)
    end
Strategy Comparison Table

Strategy Rotation Trigger Predictability Primary Goal
Round Robin After every connection Sequential Even traffic distribution across redirectors
Random After every connection None (Random) Evading frequency analysis by defenders
Failover After X failures or time Sticky Maximize stability of a working connection
Rotate After set time (hours/days) Time-based Scheduled infrastructure burning

N1NJ10 Notes

Table of Contents

Resources

Tools

Notes

The HTTP Process (Insecure / Plaintext)

The HTTPS Process (Secure / Ciphertext)

Listener Categories

What “Egress” Means

What “P2P” Means

What “Both” Means

Quick Decision Guide

Summary

The Core Concept: What is Host Rotation?

The Four Strategies Explained

Visualizing the Routing Logic

Strategy Comparison Table

Graph View

Table of Contents

Backlinks

Strategy	Rotation Trigger	Predictability	Primary Goal
Round Robin	After every connection	Sequential	Even traffic distribution across redirectors
Random	After every connection	None (Random)	Evading frequency analysis by defenders
Failover	After X failures or time	Sticky	Maximize stability of a working connection
Rotate	After set time (hours/days)	Time-based	Scheduled infrastructure burning