C2 Beaconing Detection via Log Interval Analysis and Temporal Correlation

Why This Matters

Defenders who identified the 2020 SolarWinds SUNBURST implant noted that the malware deliberately introduced randomised sleep periods between check-ins — yet statistical analysis of DNS beacon intervals still revealed a non-random distribution that stood out against legitimate traffic. Command-and-control beaconing is one of the most reliable post-compromise indicators available to a SOC analyst because it is hard for attackers to eliminate entirely: the implant must call home, and calling home repeatedly always leaves a pattern. Mastering interval analysis of HTTP and DNS logs is therefore a foundational SIEM skill.

Core Concept

C2 beaconing refers to periodic outbound communication from an implant to an attacker-controlled server. The implant sleeps for a fixed interval, wakes, sends a small HTTP or DNS request, processes any tasking returned, then sleeps again. The result in proxy or DNS logs is a series of requests to the same destination at near-regular intervals.

Jitter is intentional randomness added to the sleep period to evade naive regularity detectors. A beacon with ±10 % jitter on a 60-second interval will actually fire anywhere from 54 to 66 seconds after the previous request. The coefficient of variation (standard deviation ÷ mean) of inter-request deltas exposes jitter-masked beacons: legitimate browsing has very high CV, beacons have low CV (typically < 0.3 even with jitter).

User-Agent consistency is a secondary indicator. Browsers rotate User-Agent strings when they update; an implant hardcoding a UA string will maintain identical UA across dozens or hundreds of requests — a pattern easily detected by grouping log records.

Technical Deep-Dive

# Extract HTTP request timestamps and destination from Apache/nginx access log
awk '{print $4, $7, $12}' access.log | grep "evil.com" 
  | awk '{print $1}' | tr -d '[' 
  | sort > beacon_times.txt

# Calculate inter-request deltas in seconds using awk
awk 'BEGIN{prev=0}
{
  cmd = "date -d ""$1"" +%s"; cmd | getline ts; close(cmd)
  if (prev > 0) print ts - prev
  prev = ts
}' beacon_times.txt

| index=proxy sourcetype=squid
| eval _time=strptime(timestamp, "%d/%b/%Y:%H:%M:%S")
| sort _time
| streamstats window=2 current=t last(_time) AS prev_time BY dest_host
| eval delta = _time - prev_time
| where isnotnull(delta) AND delta > 0
| stats count avg(delta) AS mean_delta stdev(delta) AS sd_delta BY dest_host
| eval cv = sd_delta / mean_delta
| where count > 20 AND cv < 0.3
| sort cv

-- Splunk timechart approach: visualise request rate per candidate domain
index=proxy dest_host="suspicious.example.com"
| timechart span=1m count AS requests_per_min

# Python: statistical beacon detector over parsed log deltas
import statistics, sys

deltas = [int(l.strip()) for l in open("deltas.txt") if l.strip()]
if len(deltas) < 10:
    sys.exit("Insufficient data")

mean = statistics.mean(deltas)
sd   = statistics.stdev(deltas)
cv   = sd / mean
print(f"Mean interval : {mean:.1f}s")
print(f"Std deviation : {sd:.1f}s")
print(f"CV            : {cv:.3f}  ({'BEACON CANDIDATE' if cv < 0.3 else 'normal'})")

Analytical Methodology

1. Ingest proxy or web server access logs into your SIEM. Filter on outbound connections to external destinations — strip internal RFC-1918 addresses.
2. Group records by destination host. Rank by request count. Legitimate CDN and update traffic will dominate; sort by CV to surface anomalies.
3. For each high-count external destination, extract the time series of request timestamps. Compute inter-request deltas. Plot a histogram: beaconing produces a narrow spike near the beacon interval; browsing produces a flat distribution.
4. Apply a CV threshold of 0.3 or lower as the primary filter. Inspect all destinations meeting this criterion.
5. Examine User-Agent strings for the candidate domain. One or two distinct UAs across 50+ requests is suspicious; typical browsers produce 3–5 or more across a session.
6. Cross-reference the destination domain against threat intelligence feeds (VirusTotal, URLhaus, PassiveDNS). Newly registered domains and domains with no legitimate content are additional risk signals.
7. Pivot to DNS logs: confirm the implant is resolving the destination frequently. Short TTL responses from the candidate domain indicate DNS-based C2 infrastructure.
8. If a beacon is confirmed, calculate the beacon interval precisely (mean of deltas). Document first-seen and last-seen timestamps. Identify the source host and associated user account.
9. Escalate with: source IP, destination domain/IP, beacon interval ± jitter percentage, first beacon timestamp, total beacon count, and any payload bytes observed in request/response size fields.

Common Analytical Errors

• Confusing heartbeats with beacons: Legitimate software (Windows Update, antivirus, Dropbox) also beacons on regular schedules. Always cross-reference destination against known-good software update endpoints before escalating.
• Using too short a window: Calculating CV over five deltas produces unreliable statistics. Require at least 20 data points before drawing conclusions.
• Ignoring byte sizes: A beacon sending zero-byte POST bodies is distinct from one sending variable-length data. Examining the bytes_out field can confirm active tasking sessions hidden within regular check-ins.
• Overlooking HTTPS inspection gaps: If your proxy does not perform TLS inspection, you may see only the TCP connection timestamps and not the HTTP request details. Beacon timing is still visible at the connection level; adapt your delta calculation to TCP session open events.

NICE Framework Alignment

Further Reading

• Mandiant: "Definitive Guide to C2 Beacon Detection" (2022)
• SANS FOR572: Advanced Network Forensics — Beacon Detection module
• Splunk Security Essentials app — "Detect Beaconing with Flare, Elastic Stack, or Splunk" use case
• David Bianco, "The Pyramid of Pain" — why C2 infrastructure is a high-value detection target
• Elastic EQL documentation: sequence matching for periodic event detection