How to Detect Beaconing Malware in Network Traffic
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Command-and-control beaconing is statistically distinguishable from legitimate user network traffic. Humans browse the web irregularly: clicks, reads, waits: generating bursty, variable-interval connections. Malware implants phone home on a timer: every 60 seconds, every 5 minutes, every 15 minutes. Even with jitter (random variation added to sleep intervals to evade detection), the statistical regularity of C2 beaconing stands out against baseline traffic. This guide covers building beaconing detection capability from network logs through prioritized alert queues.
Understand the Beaconing Statistical Profile
C2 frameworks implement beaconing with configurable sleep intervals and jitter percentages. Cobalt Strike's default beacon: 60-second sleep with 0% jitter by default (operators often add jitter but frequently forget). Metasploit Meterpreter: 1-second check-in by default, more aggressive than typical C2. Empire/Havoc: configurable, typically 5-15 second defaults. The key statistical properties of beaconing traffic: (1) Low standard deviation of inter-connection intervals: beacons at 60-second intervals with 10% jitter have intervals between 54 and 66 seconds; the standard deviation is ~3-4 seconds; (2) High connection count to the same destination within a 24-hour period: a 60-second beacon generates ~1,440 connections per day to the same IP/domain; (3) Consistent payload size: many C2 frameworks send check-in payloads of consistent size (e.g., 200-400 bytes) even when no tasks are queued; (4) Low data volume per connection: beaconing connections typically transfer under 1KB when idle. Combine these: a destination with 1,000+ connections per day, average interval of 60 seconds, standard deviation under 10 seconds, and average bytes under 500 is almost certainly C2.
Collect Connection Data with Zeek
Zeek's conn.log is the primary beaconing detection data source. Key fields: ts (timestamp), id.orig_h (source IP), id.resp_h (destination IP), id.resp_p (destination port), proto (TCP/UDP), duration (connection duration in seconds), orig_bytes (bytes sent), resp_bytes (bytes received), conn_state. To extract beaconing candidates:
# From Zeek conn.log, extract connections per source-destination pair
cat conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p duration orig_bytes resp_bytes |
awk '{print $2, $3, $4, $1}' |
sort |
awk 'prev==$1" "$2" "$3 {print prev, $4-prevts} {prev=$1" "$2" "$3; prevts=$4}' |
# Each line: src dst port interval_seconds
awk '{count[$1" "$2]; sum[$1" "$2]+=$3; sq[$1" "$2]+=$3*$3} END {
for (key in count) {
mean=sum[key]/count[key];
var=sq[key]/count[key]-mean*mean;
print key, count[key], mean, sqrt(var)
}
}' |
awk '$3 > 20 && $4 < 30 && $5 < 10' # 20+ connections, 30s mean interval, 10s stdev
This pipeline identifies source-destination pairs with 20+ connections at regular intervals (under 30-second mean) with low variance (under 10-second standard deviation). Tune thresholds to your environment: high-frequency polling applications (monitoring agents, heartbeat services) will need exclusion.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Build SIEM Beaconing Detection Queries
KQL in Microsoft Sentinel for beaconing detection over Zeek logs:
zeek_conn_CL
| where TimeGenerated > ago(24h)
| where id_resp_p_d in (80, 443, 8080, 8443) // HTTP/HTTPS ports
| summarize
ConnectionCount = count(),
IntervalList = make_list(TimeGenerated),
AvgBytes = avg(orig_bytes_d + resp_bytes_d)
by SourceIP = id_orig_h_s, DestIP = id_resp_h_s, DestPort = id_resp_p_d
| where ConnectionCount > 50
| extend
Intervals = array_sort_asc(IntervalList),
AvgBytes = round(AvgBytes)
| mv-expand with_itemindex=idx Intervals
| extend Interval = iff(idx > 0, datetime_diff('second', todatetime(Intervals), prev(todatetime(Intervals))), 0)
| where Interval > 0
| summarize MeanInterval = avg(Interval), StdDevInterval = stdev(Interval), Count = count() by SourceIP, DestIP, DestPort, AvgBytes
| where StdDevInterval < 30 and MeanInterval < 600 and MeanInterval > 10
| extend JitterPct = round(StdDevInterval/MeanInterval*100, 1)
| where JitterPct < 20
| order by Count desc
This query finds connections with regular intervals (10-600 seconds mean, under 20% jitter): the hallmarks of automated beaconing versus human browsing.
Detect Long-Poll C2 Sessions
Some C2 frameworks use HTTP long-polling instead of periodic short connections: the implant holds an HTTP connection open for minutes or hours waiting for commands. This avoids the regular-interval signature but leaves a different pattern: long-duration low-data connections. Zeek conn.log query for long-poll detection:
index=zeek sourcetype=conn
| eval duration_min=duration/60
| where duration_min > 10 AND (orig_bytes + resp_bytes) < 10000
| where dest_port IN (80, 443, 8080, 8443)
| stats count as connection_count, avg(duration_min) as avg_duration_min, sum(orig_bytes + resp_bytes) as total_bytes
by src_ip, dest_ip, dest_port
| where connection_count > 5 and avg_duration_min > 15
| eval suspicious_score=if(avg_duration_min > 30 AND total_bytes < 50000, "HIGH", "MEDIUM")
| sort - avg_duration_min
A connection lasting 30+ minutes that transfers under 10KB of data is not streaming video or downloading a file: it is either a legitimate long-poll application (identify and whitelist) or a C2 session. Review by destination IP and compare against threat intelligence.
Correlate with Threat Intelligence
Beaconing analysis produces destination IPs and domains with high connection regularity. Enrich with threat intelligence to prioritize investigation. Automated enrichment pipeline: (1) Extract unique destination IPs from beaconing detections; (2) Query threat intelligence APIs: VirusTotal, Shodan, Greynoise, and Cisco Umbrella Investigate for each IP; (3) Flag IPs that appear in commercial C2 feeds: Proofpoint ET Intelligence, Recorded Future, Mandiant Advantage; (4) Check IP age and hosting: newly registered domains and IPs in cloud provider ranges (AWS, Azure, GCP) hosting C2 is common: Shodan's org: filter identifies cloud-hosted destinations. Correlation KQL in Sentinel:
beaconing_results
| join kind=leftouter ThreatIntelligenceIndicator on $left.DestIP == $right.NetworkIP
| where IsActive == true
| project SourceIP, DestIP, ConnectionCount, MeanInterval, ConfidenceScore, ThreatType
| order by ConfidenceScore desc
High-interval-regularity connections to IPs in threat intelligence feeds are confirmed C2: escalate to incident response immediately.
Build a Beacon Score and Prioritize Alerts
A composite beacon score reduces analyst alert fatigue by ranking endpoints by C2 probability. Score formula (0-100):
def beacon_score(connection_count, std_dev, mean_interval, avg_bytes, ti_match):
score = 0
# Regularity component (0-40 points)
jitter_pct = std_dev / mean_interval if mean_interval > 0 else 1
score += max(0, 40 - int(jitter_pct * 200)) # Perfect regularity = 40 pts
# Volume component (0-20 points)
if connection_count > 1000: score += 20
elif connection_count > 100: score += 10
elif connection_count > 20: score += 5
# Bytes component (0-20 points - small payloads more suspicious)
if avg_bytes < 500: score += 20
elif avg_bytes < 2000: score += 10
# Threat intel (0-20 bonus)
if ti_match: score += 20
return min(100, score)
Implement as a Splunk saved search or Sentinel workbook. Score above 70: send to analyst queue (investigate within 24 hours). Score above 90: page on-call (investigate within 1 hour). Score below 70: log to threat hunting backlog for weekly review. Exclude known monitoring and management IPs (SCCM, backup agents, monitoring systems) before scoring: these generate legitimate high-regularity connections.
The bottom line
Beaconing detection uses two complementary methods: interval regularity analysis (standard deviation of inter-connection intervals below 10-30 seconds over 50+ connections indicates automated C2) and long-connection detection (connections over 10 minutes with under 10KB transferred indicate long-poll C2). Build SIEM queries against Zeek conn.log, enrich results with threat intelligence, and implement a composite beacon score to prioritize analyst investigation. Exclude known legitimate high-frequency services before applying detection thresholds.
Frequently asked questions
How do I detect Cobalt Strike beaconing in network logs?
Cobalt Strike beaconing appears in network logs as regular HTTP or HTTPS connections to the same destination at fixed intervals (default 60 seconds) with small payload sizes (typically under 500 bytes for idle check-ins). Detect by calculating the standard deviation of inter-connection intervals for each source-destination pair: Cobalt Strike with 0% jitter has standard deviation under 1 second; with 20% jitter the standard deviation is around 12 seconds. Also look for HTTP/S connections lasting more than 10 minutes with minimal data transfer, which indicate Cobalt Strike's long-poll HTTPS listener mode.
What is a good jitter threshold for beaconing detection?
A jitter threshold of under 20% of the mean interval (standard deviation less than 20% of mean connection interval) effectively identifies most C2 beaconing while producing manageable false positive rates. For a 60-second beacon interval, this means flagging connections where the standard deviation is under 12 seconds. Legitimate applications with regular polling (monitoring agents, heartbeat services) will trigger this threshold: build an exclusion list for known management tool source IPs and management server destinations before applying the threshold to production traffic.
How do attackers use domain fronting to hide C2 beaconing?
Domain fronting routes C2 traffic through a legitimate CDN (Cloudflare, AWS CloudFront, Azure CDN) so that network defenders see connections to a reputable CDN hostname, not the attacker's C2 server. The HTTP Host header inside the TLS connection specifies the attacker's actual C2 domain, invisible to network inspection without TLS decryption. Detection: deploy TLS inspection at the network perimeter and alert when the SNI (Server Name Indication) in the TLS handshake does not match the HTTP Host header in the decrypted request — this is the defining characteristic of domain fronting. Many CDN providers have implemented controls to prevent domain fronting (AWS CloudFront explicitly blocks it since 2018), but fronting via other CDNs remains a viable attacker technique.
What is fast-flux and how does it complicate C2 infrastructure detection?
Fast-flux is a technique where a C2 domain's DNS A records rotate through a large pool of IP addresses with very short TTLs (30-300 seconds). Each DNS query returns a different IP, making IP-based blocking ineffective: by the time a security team adds an IP to a blocklist, the C2 has rotated to a different IP. Double-flux also rotates the DNS nameserver records themselves. Detection: monitor for domains with TTL values under 300 seconds and A record changes across consecutive queries; alert on domains in your environment where a single FQDN resolves to more than 5 distinct IPs within one hour. Behavioral analytics on the domain rather than the IP is the correct detection approach: block the C2 domain at your DNS resolver rather than individual IPs.
How do I build a beaconing detection query in Microsoft Sentinel?
Sentinel beaconing detection using CommonSecurityLog or network flow data: calculate the standard deviation of inter-connection intervals using the KQL series_stats() function. Example KQL: summarize ConnectionTimes=make_list(TimeGenerated) by SourceIP, DestinationIP, DestinationPort | extend intervals=series_diff(ConnectionTimes) | extend stats=series_stats(intervals) | where stats.stdev < stats.avg * 0.2 and array_length(intervals) > 20 | order by stats.stdev asc. This flags source-destination pairs where connections occurred 20+ times with standard deviation under 20% of the mean interval — the statistical signature of automated beaconing. Tune by adding exclusions for known management tool IPs in the SourceIP filter.
How do I distinguish beaconing from legitimate application polling in network traffic where both use regular intervals?
Legitimate polling applications (monitoring agents, heartbeat services, cloud metadata checks) and C2 beaconing both create regular-interval connection patterns. Differentiate them using four signals beyond interval regularity alone. First, payload consistency: C2 beacons typically transmit identical or near-identical byte counts on each check-in when no tasks are queued; legitimate polling applications vary payload size based on data returned. Calculate the coefficient of variation for bytes-per-connection on each source-destination pair -- values below 10% with consistent small payloads are more characteristic of C2. Second, destination registration age: query the registrar creation date for the destination domain; C2 infrastructure frequently uses domains registered within the past 30-90 days while legitimate monitoring services use established domains. Third, TLS certificate age and issuer: C2 HTTPS often uses Let's Encrypt certificates issued within weeks of the communication starting; established SaaS monitoring services use long-lived certificates from commercial CAs. Fourth, process-to-connection correlation using endpoint telemetry: in Microsoft Defender or CrowdStrike, identify which process is making the network call -- legitimate monitoring agents have known process names and installation paths while C2 implants often masquerade as system processes from unexpected directories like AppData or Temp. Build your exclusion list from known management tools with documented process names and destination domains, and apply beaconing scoring only to traffic that does not match the exclusion list.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.