# Beaconing Detection > Use when hunting for command-and-control beaconing in network telemetry — the regular-interval callbacks that reveal C2 even when the destination and payload are unknown. - Skill: `jihedbfr-art/beaconing-detection` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/beaconing-detection` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/beaconing-detection/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/beaconing-detection --- ## Prerequisites - Target system, dependencies and environment configured. ## Usage ### Purpose Compromised hosts phone home, and most C2 does it by *beaconing* — connecting to the controller at regular intervals to check for commands. That regularity is a behavioural signature you can hunt even without knowing the destination or decoding the traffic, which makes beaconing detection one of the highest-value network hunts. This skill covers finding beaconing in network logs, catching C2 that IP/domain blocklists miss. ### When to use it Hunting network telemetry (proxy, firewall, DNS, netflow) for C2 you don't already have indicators for. It's especially valuable because it targets *behaviour* (durable) rather than infrastructure (which rotates), so it catches C2 using new, unknown domains and IPs. ### Procedure 1. **Get the network connection data.** Beaconing hunts run on connection logs with timestamps and destinations — proxy logs, firewall logs, netflow, or DNS logs. You need enough history to see the pattern (the interval) repeat. 2. **Hunt for regularity, not destination.** The core signal: a host connecting to the same external destination at *consistent intervals* over time. Group connections by source-destination pair and look at the time-between-connections — a tight, repeating interval (every 60s, every hour) is the beacon signature. 3. **Account for jitter.** Modern C2 adds randomisation (jitter) to the interval to evade simple detection, so the interval won't be perfectly constant — hunt for *approximate* regularity (a clustered distribution of intervals) rather than exact. Beaconing analysis tools handle jitter statistically. 4. **Filter out legitimate beaconing — the main challenge.** Lots of benign software beacons: software update checks, telemetry, monitoring agents, synced apps. These produce the same regular-interval pattern. Baseline and allowlist the known-good beacons (a specific update service to a vendor domain) so the malicious ones surface — this filtering is most of the work. 5. **Prioritise the suspicious survivors.** After filtering known-good, focus on beacons to newly-seen/rare destinations, to uncategorised domains, with unusual user-agents, or from hosts that shouldn't be beaconing anywhere. Combine the timing signal with destination reputation and context. 6. **Investigate hits** as a hunt (the hypothesis-driven method) — confirm whether the beaconing host and destination are malicious, pivot to endpoint data, and escalate to IR if confirmed. 7. **Operationalise** — a confirmed beaconing pattern (and the analytic that found it) becomes a detection; the C2 destination becomes an IoC (feeds detection and threat-intel). ### Cheatsheet ``` C2 beacons = connects to controller at REGULAR INTERVALS -> behavioural signature hunt the BEHAVIOUR (durable) not the destination (rotates) -> catches unknown C2 data: connection logs with timestamps + destination (proxy/fw/netflow/DNS), enough HISTORY signal: same src->dst pair at CONSISTENT intervals over time group by src-dst -> time-between-connections -> tight repeating interval = beacon jitter: modern C2 randomises interval -> hunt APPROXIMATE regularity (clustered dist), not exact ; beaconing tools handle it statistically FILTER legit beacons (the main work): updates, telemetry, monitoring, synced apps baseline + allowlist known-good -> malicious surface prioritise survivors: new/rare dest | uncategorised domain | odd user-agent | host that shouldn't beacon investigate -> pivot to endpoint -> escalate ; operationalise (detection + IoC) ``` ### Reading the hunt - **A host beaconing to a rare/new/uncategorised destination at a regular (jittered) interval** = a strong C2 lead; the timing signature plus a suspicious destination is exactly what this hunt targets, and it catches C2 with no known indicators. The highest-value find. - **Regular beaconing to a known vendor/update service** = benign; these dominate the results and are the noise to filter. Baselining known-good is most of the work — without it, the hunt drowns in legitimate beacons. - **Beaconing with jitter** (approximately-regular, not exact intervals) = deliberate evasion; don't require perfect regularity or you'll miss modern C2. Hunt the clustered interval distribution. - **A host beaconing that has no business talking to the internet** (a server that shouldn't, an internal-only system) = suspicious regardless of destination reputation; context sharpens the timing signal. - **A confirmed beacon** = escalate to IR (active C2), extract the destination as an IoC, and turn the pattern into a detection so you catch it automatically next time. - **Timing signal + destination reputation + host context combined** = the reliable way to separate malicious beacons from the benign majority. ### Pitfalls - **Requiring perfect regularity.** Jitter breaks exact-interval detection; modern C2 randomises deliberately. Hunt approximate/clustered regularity, not a constant. - **Not filtering legitimate beacons.** Benign software beacons constantly (updates, telemetry, monitoring); without baselining known-good, the malicious signal drowns. This filtering is the core effort. - **Hunting destination instead of behaviour.** Chasing known-bad IPs/domains misses C2 on new infrastructure; the timing behaviour is what's durable and catches unknown C2. - **Insufficient history.** You need enough time span to see the interval repeat; a short window can't reveal a slow (hourly/daily) beacon. - **Timing alone.** A regular interval to a benign destination is benign; combine timing with destination reputation and host context to prioritise. ### References - The malware c2-and-network-analysis, network packet-capture-analysis, and dns-and-proxy-hunting skills - Beaconing analysis tooling (RITA and similar) and netflow analysis - MITRE ATT&CK — TA0011 (Command and Control), T1071 - The hypothesis-driven-hunting and operationalising-a-hunt skills ## Inputs - Relevant source code, logs, network traces, or system specifications. ## Outputs - Analysis findings, security audit report, or generated code artifacts.