Beacon Hunting — Interval Analysis, Jitter, and Byte Signatures

Beacon hunting is statistical pattern recognition. The adversary’s implant fires on a timer — and timers produce patterns that human behavior does not. The hunter’s job is to separate programmatic from human in a sea of connections.

The Multi-Factor Beacon Score

No single metric reliably identifies beacons without flooding results with benign programmatic traffic (software updates, telemetry, NTP). The RITA model uses four factors:

Factor 1: Connection Rate to Destination

// Connections per hour from single host to single external destination
Zeek_conn_CL
| where TimeGenerated > ago(24h)
| where local_orig_b == true and local_resp_b == false
| summarize conn_count = count(), 
            unique_hours = dcount(bin(TimeGenerated, 1h))
  by id_orig_h_s, id_resp_h_s, id_resp_p_i
| extend conn_rate_per_hour = toreal(conn_count) / toreal(unique_hours)
| where conn_rate_per_hour > 20   // >20 connections/hour = programmatic

Factor 2: Interval Regularity (CV)

Computing true interval statistics requires time-series ordered data. In Sentinel/KQL:

// Simplified: compute interval from sorted timestamps per dst
let src = "10.1.2.3";
let dst = "91.213.50.5";
Zeek_conn_CL
| where id_orig_h_s == src and id_resp_h_s == dst
| order by TimeGenerated asc
| extend prev_time = prev(TimeGenerated)
| extend interval_sec = datetime_diff('second', TimeGenerated, prev_time)
| where isnotnull(interval_sec) and interval_sec > 0
| summarize 
    mean_interval = avg(interval_sec),
    std_interval = stdev(interval_sec),
    conn_count = count()
| extend cv = std_interval / mean_interval
| where conn_count > 20  // enough samples

CV interpretation:

CV < 0.05: extremely regular (clock-precise)
CV 0.05–0.30: low jitter (automated with ≤10-20% jitter)
CV 0.30–0.60: moderate jitter (aggressive jitter profile, hard to detect statistically)
CV > 0.60: high variance (human-like or very high jitter)

Threshold for flagging: CV < 0.30 is the standard beacon threshold. CV < 0.60 is worth investigation when combined with other factors.

Factor 3: Byte-Size Consistency

Zeek_conn_CL
| where id_orig_h_s == src and id_resp_h_s == dst
| summarize 
    mean_orig = avg(orig_bytes_l),
    std_orig = stdev(orig_bytes_l),
    mean_resp = avg(resp_bytes_l),
    std_resp = stdev(resp_bytes_l),
    conn_count = count()
| extend cv_bytes = std_orig / (mean_orig + 1)  // +1 avoids div/0

Fixed check-in packets produce CV_bytes < 0.10. Variable-size traffic (HTTP responses) produces CV_bytes > 0.50.

Factor 4: Peer Cohort Filter

// How many internal hosts talk to this destination?
Zeek_conn_CL
| where TimeGenerated > ago(30d)
| where local_orig_b == true and local_resp_b == false
| summarize host_count = dcount(id_orig_h_s) by id_resp_h_s
// Beacon candidates: host_count == 1 (only this host) or <=5

Safe Harboring — The FP Killer

Without exclusions, beacon hunts return thousands of results dominated by:

Windows Update servers (regular, byte-consistent)
Antivirus telemetry (regular heartbeats)
Domain controller traffic (NetLogon, DNS, LDAP)
Browser autoupdate checks
NTP servers

Build your safe harbor list:

let safe_harbor_ips = dynamic(["13.107.0.0/14", "52.96.0.0/14",  // Microsoft
                                "8.8.8.8", "1.1.1.1",             // DNS resolvers
                                "17.0.0.0/8",                     // Apple
                                "216.58.0.0/16"]);                 // Google
// Exclude in beacon hunt:
| where not(ipv4_is_in_range(id_resp_h_s, "13.107.0.0/14"))
// Or use: ASN-based exclusion for Microsoft/Akamai/Cloudflare

ASN-based exclusion is more robust than IP-based because CDN IPs change frequently:

# ASNs to always safe-harbor in beacon hunts:
AS8075  Microsoft (update.microsoft.com, office365.com)
AS16509 Amazon AWS (may include legitimate SaaS)
AS13335 Cloudflare (may be C2 — use with caution, exclude only for >=100-host destinations)
AS15169 Google
AS20940 Akamai

The Long-Connection Alternative

When beacon interval math is unreliable (sampled data, high jitter), hunt for long connections instead. C2 sessions that maintain persistent connections appear as single conn.log entries with very long duration.

Zeek_conn_CL
| where TimeGenerated > ago(7d)
| where local_orig_b == true and local_resp_b == false
| where duration_d > 3600           // > 1 hour
| where service_s !in ("ssl", "http") or isempty(service_s)  // prefer unusual services
| summarize 
    session_count = count(),
    total_duration = sum(duration_d),
    max_resp_bytes = max(resp_bytes_l)
  by id_orig_h_s, id_resp_h_s, id_resp_p_i
| where session_count > 5           // recurring long sessions
| order by total_duration desc

Long connections + non-standard service + non-CDN destination = high-priority investigation.

Worked Example

Full beacon hunt: PEAK format

PEAK Phase: Hypothesize

Hypothesis (Hypothesis-Driven type): An adversary operating in our network is using a Cobalt Strike beacon with a 60-second callback interval and 10% jitter, targeting port 443 on an external VPS. The beacon will appear in conn.log as a series of TLS connections (service=ssl or service=-) to a rare destination with interval CV < 0.15 and consistent orig_bytes.

Data required: Zeek conn.log + ssl.log, 30 days, full-fidelity (not sampled). SIEM: Microsoft Sentinel.

Success criteria: Identify ≥1 (src IP, dst IP, port) tuple where: conn_count > 100, CV < 0.30, peer_cohort ≤ 3, not in safe harbor list.

PEAK Phase: Hunt

Query 1 — Rate filter:

let safe_harbor_asns = dynamic(["8075", "16509", "15169", "20940"]);
Zeek_conn_CL
| where TimeGenerated > ago(30d)
| where local_orig_b == true and local_resp_b == false
| summarize conn_count = count() by id_orig_h_s, id_resp_h_s, id_resp_p_i
| where conn_count > 100
// → 2,847 results after 30 days

Query 2 — Add peer cohort:

// Join with host count per destination
| join kind=inner (
    Zeek_conn_CL | summarize host_count = dcount(id_orig_h_s) by id_resp_h_s
  ) on id_resp_h_s
| where host_count <= 3
// → 43 results (eliminated ~99% of noise)

Query 3 — Manual CV calculation on top candidates:

Manually pull timestamps for top 10 candidates and compute CV in Python:

import pandas as pd
intervals = pd.Series([61, 58, 62, 59, 60, 61, 57, 63, 60, 59])
cv = intervals.std() / intervals.mean()
print(f"CV: {cv:.3f}")  # → CV: 0.029

Result: 1 candidate passes all filters:

Src: 10.2.1.44, Dst: 91.213.50.22:443
conn_count: 1,440 (30 days × 48/hour = ~1,440 @ 60s interval)
peer_cohort: 1 (only this host)
CV: 0.031 (very regular)
service: ssl (TLS confirmed)
avg_orig_bytes: 512, std_dev: 14 (CV_bytes = 0.027 — fixed-size check-in)

PEAK Phase: Act

Pivot to ssl.log for JA3 and cert:

JA3: 72a7c4de… (matches Cobalt Strike default profile — Threat Intel lookup)
SNI: update-cdn-proxy.net (registered 14 days ago — WHOIS)
Cert validation: ok (Let’s Encrypt, 7 days old)

Pivot to endpoint (Sysmon Event 3):

Process: svchost.exe from path C:\Users\jsmith\AppData\Roaming\ (not System32)
Parent: explorer.exe (abnormal — legitimate svchost spawns from services.exe)

Verdict: Confirmed Cobalt Strike beacon. ATT&CK: T1071.001, T1036.005.

Hunt converted to detection (Sigma):

title: Cobalt Strike Default JA3 on Non-Standard svchost Path
status: experimental
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    ja3hash: '72a7c4de...'
    Image|endswith: 'svchost.exe'
  filter_legitimate:
    Image|startswith: 'C:\Windows\System32\'
  condition: selection and not filter_legitimate
falsepositives:
  - Unknown legitimate software with same JA3
level: high

Retrieval Practice

You have a beacon candidate: CV=0.52, conn_count=180 over 30 days. Your threshold was CV < 0.30. Should you close the lead, and what does the CV value tell you about the attacker's profile?

Reveal answer

Do not close it — a CV of 0.52 may indicate a C2 with aggressive jitter configuration (30-50% jitter), which intentionally pushes CV above the statistical detection threshold. CV=0.52 with conn_count=180 (6 connections/day average) still warrants investigation if it passes the peer cohort and safe harbor filters. The jitter level suggests a more sophisticated operator — default Cobalt Strike profiles have near-zero jitter; operators who configure 50% jitter are actively evading beacon detection. Escalate to a follow-up pivot: check ssl.log for cert metadata (age, self-signed), check the destination domain WHOIS age, and check endpoint Sysmon for the process making the connections. Jitter defeats interval analysis; behavioral analysis fills the gap.