C2 and Beaconing Detection

Purpose and Scope

Command and control (C2) communication allows attackers to maintain control over compromised systems. Most malware and implants communicate with C2 servers in regular patterns called beaconing. This playbook covers techniques to detect beaconing behavior using network and endpoint telemetry.

Prerequisites

• Network flow data: NetFlow, IPFIX, or Zeek connection logs with timing information
• Proxy or firewall logs: HTTP/HTTPS metadata including URLs and timing
• DNS query logs: For DNS based C2 detection
• Endpoint network telemetry: Process to network connection mapping
• Statistical analysis capabilities: Tools for interval and jitter calculation

Detection Goals

Identify C2 activity by detecting:

• Regular interval communication (beaconing)
• Connections to rarely accessed destinations
• Long duration connections (long-polling or persistent C2)
• DNS beaconing and tunneling
• HTTP based C2 with distinctive patterns
• Encrypted C2 over standard ports

Understanding Beaconing

What Is Beaconing?

Beaconing is periodic communication from a compromised host to attacker infrastructure. The implant checks in at regular intervals to:

• Report status and exfiltrate data
• Receive new commands
• Download additional payloads
• Maintain persistence even if commands are not issued

Beacon Characteristics

• Interval: Time between check ins (seconds to hours)
• Jitter: Random variation added to avoid detection (usually 0-50%)
• Sleep time: Longer intervals during off hours
• Payload size: Small check in requests, larger responses with commands

Common C2 Frameworks

Well known frameworks have characteristic patterns:

• Cobalt Strike: Configurable intervals with jitter, malleable C2 profiles
• Metasploit Meterpreter: HTTPS with characteristic certificate patterns
• Empire/Covenant: HTTP based with configurable sleep times
• Sliver: Multiple protocols including DNS and HTTP

Detection Approaches

Statistical Interval Analysis

Calculate the time between connections from each source to each destination:

1. Group connections by source IP and destination
2. Calculate intervals between consecutive connections
3. Compute standard deviation of intervals
4. Low standard deviation relative to mean indicates regular beaconing

Formula for regularity score: standard_deviation / mean_interval. Values below 0.5 are suspicious.

Frequency Domain Analysis

Apply Fast Fourier Transform (FFT) to connection timestamps to identify periodic signals. Strong peaks at specific frequencies indicate beaconing.

Long Connection Analysis

Some C2 uses long lived connections or frequent reconnection patterns:

• Connections lasting hours to known external IPs
• Rapid reconnection after disconnection
• WebSocket or HTTP long-polling patterns

Hunting Queries

Beacon Detection by Interval Regularity

Splunk:

index=firewall action=allow direction=outbound
| sort 0 src_ip, dest_ip, _time
| streamstats current=f last(_time) as prev_time by src_ip, dest_ip
| eval interval = _time - prev_time
| where interval > 0
| stats count, avg(interval) as avg_interval, stdev(interval) as stdev_interval by src_ip, dest_ip
| where count > 20 AND stdev_interval < avg_interval * 0.5
| eval regularity_score = stdev_interval / avg_interval
| sort regularity_score
| table src_ip, dest_ip, count, avg_interval, regularity_score

Zeek Connection Log Analysis

index=zeek sourcetype=zeek:conn
| where id_resp_p IN (80, 443) AND local_orig=true AND NOT local_resp=true
| sort 0 id_orig_h, id_resp_h, ts
| streamstats current=f last(ts) as prev_ts by id_orig_h, id_resp_h
| eval interval = ts - prev_ts
| where interval > 0 AND interval < 3600
| stats count, avg(interval) as avg_int, stdev(interval) as std_int by id_orig_h, id_resp_h
| where count > 10
| eval beacon_score = std_int / avg_int
| where beacon_score < 0.5
| sort beacon_score

DNS Beaconing Detection

C2 over DNS exhibits regular query patterns to specific domains:

index=dns query_type=A
| rex field=query "(?[^.]+).(?[^.]+.[^.]+)$"
| sort 0 src_ip, domain, _time
| streamstats current=f last(_time) as prev_time by src_ip, domain
| eval interval = _time - prev_time
| where interval > 0
| stats count, avg(interval) as avg_int, stdev(interval) as std_int, dc(subdomain) as unique_subdomains by src_ip, domain
| where count > 50 AND std_int / avg_int < 0.3 AND unique_subdomains > 10
| table src_ip, domain, count, avg_int, unique_subdomains

Low Frequency Destinations

Beacons often connect to destinations contacted by few hosts:

index=proxy
| stats dc(src_ip) as unique_sources, sum(bytes) as total_bytes by dest_host
| where unique_sources < 3 AND total_bytes > 10000
| sort unique_sources
| table dest_host, unique_sources, total_bytes

HTTP C2 Indicators

HTTP based C2 may exhibit:

• Regular POST requests with small payloads
• Unusual URI patterns or paths
• Missing or unusual User-Agent strings
• Response sizes larger than request sizes
• JA3/JA3S fingerprints matching known C2
• Certificates with unusual subjects or issuers

DNS C2 Indicators

• High volume of queries to single domain
• Long subdomain strings (encoded data)
• TXT record queries for data exfiltration
• High entropy in subdomain portion
• Queries at regular intervals
• NXDOMAIN responses followed by successful queries

Correlation with Endpoint

When beaconing is detected, correlate with endpoint data:

• Identify the process making network connections
• Check process ancestry (parent process)
• Review process file hash against threat intelligence
• Look for persistence mechanisms associated with the process
• Check for other suspicious behaviors from the same host

Validation and False Positives

• Update services: Software updates, antivirus signature checks
• Monitoring agents: Endpoint agents checking in to management servers
• Heartbeat mechanisms: Legitimate applications with keepalive patterns
• Cloud sync: OneDrive, Dropbox, and similar services
• Chat applications: Slack, Teams with persistent connections

Build allowlists for known legitimate beaconing behavior. Focus analysis on destinations not in allowlists.

Escalation Guidance

Escalate when:

• Beaconing to destination not matching known legitimate services
• Process associated with beaconing is unsigned or suspicious
• Destination domain is newly registered or has poor reputation
• Multiple hosts beaconing to same destination
• Correlation with other malicious indicators on the host

References

• MITRE ATT&CK: Command and Control (TA0011)
• MITRE ATT&CK: Application Layer Protocol (T1071)
• MITRE ATT&CK: DNS (T1071.004)
• SANS: Finding Beacons in the Dark
• Mandiant: Detecting Cobalt Strike with Analytics
• RITA: Real Intelligence Threat Analytics