Beaconing and C2 Detection Guide

Implants that check in with their operators quietly every few minutes over HTTPS or DNS rarely trip a signature, yet that regular rhythm is one of the most reliable network traces an intrusion leaves. Beaconing detection looks for that rhythm statistically: repeated connections between the same internal host and external destination with consistent timing, consistent sizes and persistence across hours or days. This guide explains which data sources to use (proxy, DNS, Zeek and flow records, TLS fingerprints), how beacon scoring works in practice, how to cut the false positives produced by legitimate software, how to triage a hit and how to measure the programme. It is written for detection engineers, threat hunters and network security analysts. For the C2 tactic in general see the Command and Control (C2) Guide; for sensor deployment see the Zeek Network Monitoring Guide.

Key takeaways

Look for regularity, not destinations. Timing, size and duration consistency between one source and one destination over many hours finds C2 that reputation feeds have never seen.
Jitter does not hide a beacon, it widens it. Randomised sleep still produces a clustered interval distribution and persistence across the day, so score dispersion and histograms, not exact periods.
Most hits are legitimate software. Update agents, telemetry, monitoring and SaaS sync beacon too, so prevalence across the estate, allowlists with owners and enrichment are what make the output usable.
Visibility gaps decide the result. Without the original client IP behind proxies and NAT, without DNS query logs, and without decryption or TLS metadata, the analytics have nothing to work on.
DNS deserves its own analytic. High counts of unique subdomains under one parent domain indicate tunnelling or DGA-style resolution, mapped in ATT&CK as T1071.004 DNS, T1572 Protocol Tunneling and T1568.002 Domain Generation Algorithms.

What beaconing looks like and why it is detectable

Most implants are configured with a sleep interval and a jitter percentage: the implant wakes, contacts its server (often over HTTP or HTTPS, ATT&CK T1071.001 Web Protocols, inside an encrypted channel, T1573), collects any tasking and sleeps again. The operator wants low noise; the defender gets a time series. The SUNBURST backdoor shows how far operators go to blend in: MITRE ATT&CK records that it stayed dormant for up to two weeks after installation (T1497.003), used DNS for C2 designed to mimic normal SolarWinds API traffic (T1071.004), resolved randomly generated subdomains of a parent domain (T1568) and disguised HTTP traffic as the Orion Improvement Program protocol (T1001.003). Even so, the SolarWinds supply chain compromise page notes that fewer than 100 customers experienced command-and-control contact, which is the stage where network analytics had a chance to see the second phase.

Signal	What a beacon produces	What legitimate traffic usually produces
Inter-arrival time	Clustered around a sleep value, even with jitter	Bursty human browsing, or fixed schedules on well-known destinations
Payload size	Small, near-identical requests and responses when there is no tasking	Variable sizes for user activity
Persistence	Connections in most hours of the day, including nights and weekends	Working-hours pattern for user traffic
Prevalence	One or a handful of internal hosts talk to the destination	Many hosts talk to update and SaaS destinations
Destination age and reputation	Often newly registered or rarely seen domains, cheap hosting, direct-to-IP	Established domains with history
HTTP and TLS metadata	Unusual user agents, missing Host header, rare client fingerprints	Browser and known agent fingerprints

Data sources and what each one gives you

Source	Key fields	Strengths	Blind spots
Zeek conn.log	`ts`, `id.orig_h`, `id.resp_h`, `id.resp_p`, `proto`, `service`, `duration`, `orig_bytes`, `resp_bytes`, `conn_state`	Every TCP and UDP session with timing and sizes; ideal beacon input	Needs sensors placed inside NAT and before the proxy to keep the real client address
Zeek dns.log and resolver logs	Query, query type, response, client	Subdomain counts, NXDOMAIN rates, DNS tunnelling, resolution of rare domains	Encrypted DNS (DoH, DoT) to external resolvers bypasses it
Zeek ssl.log and x509 data, JA4 fingerprints	Server name, certificate fields, client and server fingerprints	Profiling encrypted sessions without decryption	Fingerprints change with libraries; collisions with legitimate software
Web proxy logs	User, client IP, URL, user agent, method, bytes, category	Authenticated user, full URL where TLS is inspected	Traffic that bypasses the proxy; pinned or excluded destinations
Firewall and NetFlow or IPFIX	5-tuple, bytes, packets, start and end	Wide coverage, cheap to retain	Sampling destroys timing; no application metadata
Full packet capture (for example Arkime)	Complete sessions, indexed	Confirms payload structure during triage	Storage cost; short retention
EDR network events	Process, command line, destination	Attributes the beacon to a binary	Not all hosts have an agent; volume limits

Two practical rules decide most outcomes. First, sampled NetFlow is not suitable for timing analysis, so collect unsampled flows or Zeek logs on the egress paths you care about. Second, if traffic goes through an internal proxy, either analyse the proxy logs (client to proxy) or make sure the analytics do not collapse every connection into "proxy to internet". RITA's default configuration warns that the IP address of an internal proxy must be listed in always_included_subnets for that reason.

How beacon scoring works

Production beacon analytics combine several sub-scores for each source and destination pair over a window, typically 24 hours. RITA, the open-source framework from Active Countermeasures that ingests Zeek logs, is a useful reference because its default configuration is published:

Minimum evidence: pairs with fewer than 4 unique connections (unique_connection_threshold) are not analysed.
Four weighted sub-scores: timestamp, data size, duration and histogram, each weighted 0.25 by default and required to sum to 1.
Timestamp score: how consistent the intervals between connections are. Robust statistics such as median absolute deviation and skew handle jitter better than a strict period match.
Data size score: how consistent the bytes per connection are. Idle check-ins look alike.
Duration score: how many hours of the window the pair is active in; RITA requires more than 6 hours seen before it scores duration and treats 12 hours as ideal consistency.
Histogram score: the shape of connection counts per time bucket, which catches flat and bimodal patterns that a single interval measure misses (histogram_mode_sensitivity defaults to 0.05).
Severity thresholds: by default a beacon score below 50 is not reported, 50 to 69 is low, 70 to 89 is medium and 90 or above is high.
Modifiers: rare destinations (prevalence at or below 2 per cent of hosts) raise the score by 15 per cent by default, very common destinations lower it, and a missing HTTP Host header raises it.

The same tool also scores long connections (base threshold one hour, high at twelve hours), which catches persistent tunnels and interactive sessions that do not beacon, and DNS C2 by counting unique subdomains under a parent domain (base 100, high 1,000). Commercial NDR and SIEM analytics use comparable ideas; whichever you run, read how its score is built before trusting it.

Building your own analytic in a SIEM

Aggregate: group connections by source, destination (domain where available, otherwise IP and port) over 24 hours.
Filter early: drop internal-to-internal traffic, destinations on a reviewed allowlist and pairs below a minimum count.
Compute features: interval median and dispersion, size dispersion, distinct hours active, total bytes out and in, and destination prevalence across hosts.
Score and rank: combine into a score and send only the top results per day to a hunting queue, not to the paging alert stream.
Enrich: domain registration age, ASN, certificate issuer and age, JA4 client fingerprint, EDR process for the source host, user and asset owner.
Promote: when a pattern proves reliable (for example a rare destination plus high score plus unsigned process), turn that combination into an alert with a documented rule. See the Detection as Code Guide.

DNS-based C2 and tunnelling

DNS is attractive to operators because it is allowed almost everywhere. Detect it with analytics designed for DNS rather than generic beaconing:

Unique subdomain count: many distinct labels under one registered domain from one client indicates data encoded in queries.
Label length and entropy: long, high-entropy labels and unusual record types (TXT, NULL) at volume.
NXDOMAIN bursts: DGA-based malware resolves many generated names before it finds a registered one (T1568.002).
Resolver bypass: clients talking DNS directly to external resolvers on port 53, or DoH to resolvers not approved for the estate. Force DNS through internal resolvers and block the rest.
Query to traffic mismatch: resolution of a rare domain followed by connections to its addresses from the same host at regular intervals.

See the DNS Security Guide.

Reducing false positives without losing detections

Common benign beacon	How to recognise it	Safe handling
OS and application update services	High prevalence, vendor-owned domains, signed processes	Allowlist by domain with an owner and review date, never by whole cloud provider range
Security agents (EDR, AV, DLP) and monitoring	Known process, consistent fingerprint, every host	Allowlist the known destinations; alert if the same fingerprint appears to a new destination
SaaS sync and collaboration clients	User-associated, high prevalence	Prevalence modifier rather than allowlist
NTP, certificate revocation checks, captive portal checks	Well-known services and ports	Filter at import
IoT and printers phoning home	Device class from asset inventory	Allowlist per device class; segment the devices

Avoid the most damaging shortcut: allowlisting whole content delivery networks or cloud provider ranges. Operators deliberately use cloud services and web services as C2 (T1102 Web Service), and redirectors in front of their servers (T1090 Proxy), precisely because defenders trust those ranges. Allowlist by domain and process, keep an owner and an expiry on every entry, and re-score allowlisted pairs periodically. See the Alert Fatigue Reduction Guide.

Triage and response for a beacon hit

Attribute the traffic: find the process with EDR network telemetry or host logs. An unsigned binary in a user profile directory, a scripting host or an unexpected service is a strong signal.
Profile the destination: registration date, hosting, certificate, other internal hosts contacting it, threat intelligence hits.
Check the content: where TLS inspection or packet capture exists, compare request structure across check-ins; implants often show near-identical requests and small responses.
Scope: search for the same destination, JA4 fingerprint, user agent or URI pattern across all hosts and the last 30 to 90 days.
Contain: isolate the host through EDR and block the destination at DNS and proxy, in that order if you want to preserve the chance to observe tasking; agree the order with the incident lead.
Preserve evidence: memory and disk from the host, PCAP or session data and the relevant logs before reimaging. See the Malware Sandbox Guide for analysing recovered binaries.

Where identity fits

Beacons are often the bridge between a foothold and credential theft. Once a host is beaconing, check what non-human identities live on it: service account credentials, cloud access keys in profiles, CI tokens and SSH keys. Treat them as exposed and rotate them as part of containment. Conversely, beacon-like regularity from a workload identity to an unfamiliar API is worth scoring too: automation behaves regularly, so a new regular destination for a service account deserves review. See the Leaked Credential Response Playbook.

Implementation, decisions and measurement

Phased rollout

Visibility first: confirm egress sensors keep real client addresses, DNS logs are collected from all resolvers, and unsampled flows or Zeek logs cover internet egress.
Baseline for two to four weeks: run scoring in hunting mode only, build the allowlist with owners and record which hits were legitimate.
Validate: run an authorised emulation of a jittered HTTPS beacon and a DNS tunnel from a test host and confirm both score highly. See the Detection Validation and Testing Guide.
Operationalise: a daily hunting queue reviewed by named analysts, with promoted high-confidence combinations as alerts.
Roll back safely: if an allowlist change or threshold change floods or silences the queue, revert the configuration from version control and re-score the affected window.

Choosing an approach

Organisation	Practical approach	Trade-off
Small, no network sensors	Proxy or secure web gateway logs plus DNS resolver logs into the SIEM with a simple scheduled analytic	Misses traffic that bypasses the proxy
Mid-size with some engineering	Zeek at egress with RITA or a SIEM analytic, JA4 fingerprints, EDR for attribution	Sensor maintenance and tuning effort
Large or high-threat	Commercial NDR or in-house analytics across data centres, cloud egress and remote users, with packet capture for triage	Cost; needs dedicated hunters to use the output

Metrics

Egress coverage: share of internet egress paths (offices, data centres, cloud VPCs, remote access) feeding the analytic.
Emulation detection rate: share of quarterly authorised beacon emulations that score above the hunting threshold.
Queue precision: share of reviewed hits that were malicious or policy-relevant, tracked monthly.
Allowlist hygiene: share of allowlist entries with owner and unexpired review date.
Time to attribution: median time from hit to identified process and owner.

Common failure patterns

Analysing after the proxy or NAT: every connection appears to come from one address and beacons disappear in aggregate traffic.
Using sampled flows: sampling destroys the interval data the analytic depends on.
Allowlisting cloud and CDN ranges: exactly where modern C2 and redirectors live.
Alerting on every score: the queue floods, analysts mute it and real beacons are missed. Rank, enrich and hunt instead.
Ignoring DNS that bypasses internal resolvers: direct port 53 and unapproved DoH remove the most useful C2 telemetry.
Short analysis windows: slow beacons and dormant implants such as SUNBURST need multi-day windows and long-connection analytics.

Framework mapping

Framework	Reference	Relevance
MITRE ATT&CK v20	TA0011 Command and Control; T1071.001, T1071.004, T1573, T1571 Non-Standard Port, T1572, T1568.002, T1102, T1090	Behaviours the analytics target
MITRE ATT&CK v20	T1041 Exfiltration Over C2 Channel; T1029 Scheduled Transfer	Size and schedule anomalies on the same channel
MITRE D3FEND	D3-NTA Network Traffic Analysis; D3-DNSTA DNS Traffic Analysis; D3-PHDURA Per Host Download-Upload Ratio Analysis; D3-CSPP Client-server Payload Profiling	Defensive techniques used
NIST CSF 2.0	DE.CM-01 networks monitored; DE.AE-03 information correlated from multiple sources	Monitoring and correlation outcomes
NIST SP 800-53 Rev. 5	SI-4 System Monitoring; SC-7 Boundary Protection; AU-6 Audit Record Review, Analysis, and Reporting	Control requirements
CIS Controls v8.1	Control 13 Network Monitoring and Defense	Network monitoring safeguards
ISO/IEC 27001:2022 Annex A	8.16 Monitoring activities	Monitoring for anomalous behaviour

Practitioner checklist

Confirm egress sensors and proxy logs keep the real internal client address.
Collect DNS logs from every resolver and block DNS and DoH to unapproved external resolvers.
Use unsampled flows or Zeek conn.log for timing analysis; reserve sampled NetFlow for volume.
Score pairs on interval, size, duration and histogram consistency over at least 24 hours, plus long-connection and subdomain analytics.
Apply prevalence and allowlists by domain and process with owners and expiry, never whole provider ranges.
Enrich hits with domain age, certificate, JA4 fingerprint and EDR process before review.
Validate quarterly with authorised jittered HTTPS and DNS beacon emulation.
Rotate credentials held on any host confirmed to be beaconing.

Beaconing and C2 Detection Guide: Finding Implants in Proxy, DNS and Flow Data