Wireshark: identifying C2 beaconing by timing patterns

I have strong material from more than eight independent sources plus three verified images. Writing the post now.

A sixty-second heartbeat

Somewhere on a corporate network right now, a laptop is sending a small HTTPS request to a server it has never spoken to before today, receiving a few hundred bytes back, and going quiet. Then, close to a minute later, it does it again. And again. The payloads are encrypted, the destination looks like a content-delivery node, and nothing in any single packet is obviously wrong. What gives the machine away is not what it says but when it says it: the metronomic regularity of a compromised host phoning home to whoever now controls it. That rhythm is called beaconing, and learning to see it in a packet capture is one of the most durable skills in network defense. Encryption has blinded the content-inspection tools that dominated the 2010s, but it cannot hide timing. A beacon has to check in to be useful, and checking in leaves a pattern in the one dimension attackers find hardest to disguise: the clock.

What a beacon is, and why malware needs one

When an attacker compromises a machine, the implant they leave behind is rarely autonomous. It needs to receive commands, exfiltrate data, and take new instructions, all from a command-and-control server (usually written C2 or C&C). But an implant that holds an open connection to a suspicious server is trivial to spot, so modern malware inverts the relationship. It stays dormant, waking on a timer to ask the C2 server a single question: do you have anything for me? Most of the time the answer is no, and it goes back to sleep. This poll-and-sleep loop is the beacon. The interval between check-ins is the sleep time or beacon interval. Short intervals give an operator near-real-time control but generate more traffic; long intervals are stealthier but make interactive work sluggish. Commodity tooling exposes this as a simple knob. In Cobalt Strike, the commercial adversary-simulation platform that has become the most abused C2 framework in the world, the operator sets the cadence with a sleep command and can layer on randomness with a jitter percentage. The sample Malleable C2 profile that Palo Alto's Unit 42 dissected in March 2022 used a 30-second sleep with 20% jitter, though real operators tune this constantly, and other reversed defaults land nearer a minute. Here is the crucial point that the marketing around "encrypted C2" tends to bury: none of that hides the beacon's existence. A human browsing the web produces bursty, irregular, purpose-driven traffic. A machine on a sleep timer produces something no person ever would, which is a connection to the same destination at a suspiciously even tempo, hour after hour, including at 3 a.m. when nobody is at the keyboard. That is the signal.

Reading the rhythm in Wireshark

Wireshark is a packet analyzer: it captures every frame on a network interface and lets you dissect it field by field. It is the wrong tool for scanning a terabyte of traffic, but it is the right tool for the confirming, forensic close-read once you have a suspect. Suppose you have a source host and a destination IP you distrust. The workflow is short. First, narrow the capture to just that conversation with a display filter such as ip.addr == 192.0.2.10 && ip.addr == 198.51.100.5. Now you are looking only at packets between the two machines. The trick is then to make Wireshark show you the gaps rather than the packets. Wireshark tracks several timestamps per frame, and the one that matters here is the time delta from the previous packet, exposed as the field frame.time_delta. Add it as a column, or better, filter to just the connection-initiating packets (for TCP, the SYN packets: tcp.flags.syn == 1 && tcp.flags.ack == 0) so that each row represents one fresh check-in rather than the chatter within a session. Scroll that list and the pattern becomes visible to the naked eye. If the deltas read 60.01, 59.98, 60.02, 60.00 seconds, connection after connection, you are almost certainly looking at an automated process, and if that process is talking to an unfamiliar external host, you are looking at a likely beacon. For something more persuasive than a column of numbers, Wireshark's Statistics → I/O Graph plots traffic over time. Set the interval to match your suspected cadence and a beacon renders as a picket fence: a spike, a flat gap, another spike, evenly spaced across the whole capture. The I/O Graph can plot frame.time_delta directly, turning the timing distribution into a shape your eye can judge in a second. Statistics → Conversations is the other workhorse: it collapses the whole capture into a table of who-talked-to-whom with packet counts, byte counts, and durations, so a low-volume conversation that persists for the entire capture window jumps out as exactly the kind of long, thin, patient connection a beacon produces.

Jitter, and the myth that it defeats you

Attackers know all of this, which is why the jitter knob exists. Jitter randomizes each sleep by a percentage. A 60-second sleep with 30% jitter means each interval is drawn somewhere between roughly 42 and 60 seconds (Cobalt Strike subtracts a random slice), so the deltas read 54, 48, 59, 44, 57, and the clean picket fence smears into noise. The common belief that follows is seductive and wrong: add enough jitter and the beacon disappears. It does not, and understanding why is the intellectual core of beacon hunting. Jitter is produced by a random number generator drawing from a uniform distribution around a central value. That is still a distribution with a stable mean and a bounded, symmetric spread, and statistics is very good at spotting exactly that. Instead of asking "are the intervals identical?", the defender asks "are the intervals tightly clustered around a single value in a way human behavior never is?" A host connecting every 60 seconds plus or minus 10 is abnormal no matter how the individual gaps scatter, as Hunt.io puts it, because the statistical regularity survives the randomization. The open-source framework RITA (Real Intelligence Threat Analytics), built by Active Countermeasures and now catalogued by CISA, operationalizes this. Rather than looking for identical gaps, RITA scores the shape of the timing distribution. It measures the skew (how lopsided the distribution is) and the dispersion (how tightly it clusters). A jittered beacon, because its randomness is symmetric, produces a skew close to zero and a modest, even dispersion, which is precisely the fingerprint of a machine drawing sleeps from a uniform generator. Jitter, in other words, does not erase the pattern; it is the pattern. RITA rolls these factors into a single score from 0 to 1, and in the activecm threat-hunting labs a beacon making 108,858 connections at one-second intervals scored a perfect 1.0. When the DFIR Report ran a live Cobalt Strike beacon for an hour in 2022, RITA flagged it with the highest score regardless of jitter, concluding that an hour of data was enough.

When Wireshark stops scaling

This is where the honest limitation of Wireshark surfaces. Loading an enterprise's full traffic into a GUI and eyeballing I/O graphs does not scale past a single suspect. Beacon hunting at scale means summarizing packets into flow records first, and the standard tool for that is Zeek (formerly Bro), a network-monitoring engine that watches traffic and writes structured connection logs. Zeek's conn.log records one line per connection with source, destination, ports, protocol, duration, and bytes in each direction. RITA ingests those logs and runs its statistical analysis across the entire network at once, ranking every talking pair by beacon score so an analyst reviews the top of a sorted list instead of scrolling a capture. The division of labor is the right mental model. Zeek and RITA find the needle across the whole haystack; Wireshark is what you reach for once you have the needle, to prove what the connection actually is, confirm the timing by hand, and pull out indicators like the destination, the TLS fingerprint, and the request structure. You can even reproduce RITA's math manually: export the connection times with tshark (Wireshark's command-line sibling) to a CSV, then compute the mean, standard deviation, and skew of the inter-arrival times in a spreadsheet. RITA just automates the tedious part.

The false positive nobody warns you about

Here is the misconception that trips up newcomers most: that periodic traffic to an external server is a beacon. It is not. Your network is full of machines that phone home on a timer for entirely legitimate reasons, and they beacon far more cleanly than most malware does. The worst offender is NTP (Network Time Protocol), which keeps a computer's clock accurate by checking with a time server on a consistent schedule, typically every 15 to 60 minutes. Add software-update checks, antivirus definition pulls, license validation, cloud-sync clients, and telemetry heartbeats, and a naive "flag anything periodic" detector drowns in false alarms. The regularity is real; the malice is not. Just how hard this problem is was quantified by the open-source beacon-spectrum research, which applies a Rayleigh phase-coherence test, a technique borrowed from astronomy for finding periodic signals in irregularly timed events, to network connection timestamps. Its most sobering result: in a test environment, a real NTP client and a deliberately planted beacon scored identically, both returning a p-value indistinguishable from zero. Periodicity alone, the author argues, simply cannot separate the two. The real discriminators are contextual, meaning the destination port, the DNS resolution history of the domain, the symmetry of the data volumes, and how long the relationship persists. That same research draws a hard mathematical boundary that every practitioner should internalize. Because the test statistic is bounded by the number of events observed, you need roughly 57 check-ins within an analysis window to confirm a beacon with confidence. Over a three-hour capture, that puts an effective ceiling around a 189-second period: a beacon that sleeps longer than about three minutes simply does not fire often enough to be caught in that window, no matter how clever the algorithm. In the same tests, a 30-second beacon was caught 100% of the time with no jitter but dropped toward zero as jitter climbed past 50%, and a 120-second beacon was caught only 4% of the time even at a modest 20% jitter. Detection is not a solved problem; it is a race between how often the beacon speaks and how long you are willing to watch.

What SUNBURST taught everyone

The definitive real-world lesson in patient beaconing is SUNBURST, the backdoor that rode a trojanized SolarWinds Orion update into thousands of organizations, discovered in December 2020. Its designers understood beacon detection intimately and built to defeat it. SUNBURST did not beacon on install. It stayed dormant for 12 to 14 days before doing anything, long enough to slip past the observation window of any short-lived capture and to decouple the malicious traffic from the update that delivered it. When it finally woke, it began by beaconing over DNS, encoding victim information into subdomain lookups against avsvmcloud[.]com generated by a domain-generation algorithm, and only escalated to HTTP command-and-control once a victim looked worth the attention. Its HTTP C2 typically checked in around 60-second intervals but was configurable, and it could jitter its signal specifically to defeat detectors that relied on rigid clustering. The defensive footnote is that statistical hunting still had a shot. Active Countermeasures demonstrated that RITA could surface SUNBURST's beaconing because the skew-and-dispersion approach reads jitter as evidence rather than camouflage. The catch was the dwell time. A tool only finds a beacon in traffic it has retained, and SUNBURST's two-week nap meant many organizations had long since rotated away the logs that would have shown the first check-ins. The malware's real innovation was not evading the math; it was outlasting the memory of the network.

What to watch next

The timing signal endures because it is load-bearing: a beacon that stops checking in stops being controllable, so the attacker cannot simply delete the tell. But the arms race is moving toward the two levers SUNBURST already pulled. The first is longer, sparser sleeps, pushing beacon periods past the window any practical capture can hold and forcing defenders toward always-on flow logging with long retention rather than reactive packet grabs. The second is behavioral mimicry, timing check-ins to piggyback on genuinely periodic services or to fire only during business hours so the rhythm hides inside the noise of a working day. The uncomfortable open question is the one the phase-coherence research made explicit: if a beacon and an NTP client can be mathematically indistinguishable, then timing analysis alone will always need context to finish the job, and every layer of context an attacker learns to fake buys them another window of invisibility. The clock still tells on them. The unsettled part is how long we can afford to keep watching it, and how much traffic we are willing to remember to do so.

Sources

1. Fortra, Cobalt Strike: Beacon (product features), 2024.
2. Unit 42, Palo Alto Networks, How the Malleable C2 Profile Makes Cobalt Strike Difficult to Detect, 2022.
3. The DFIR Report, Cobalt Strike, a Defender's Guide, Part 2, 2022.
4. Black Hills Information Security, Detecting Malware Beacons With Zeek and RITA, 2020.
5. Active Countermeasures / activecm, Threat Hunting Labs: Beacons, 2021.
6. activecm, RITA (Real Intelligence Threat Analytics), GitHub repository, 2024.
7. blurxy, beacon-spectrum: periodic C2 detection via a Rayleigh phase-coherence test, GitHub repository, 2025.
8. Hunt.io, How to Detect & Stop C2 Beaconing, 2024.
9. Wireshark Foundation, I/O Graphs, Wireshark User's Guide, 2024.
10. Ask Wireshark, How to plot 'Time delta from previous captured frame' in statistics, 2013.
11. Cynet, SUNBURST Backdoor C2 Communication Protocol, 2021.
12. Microsoft Security, Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop, 2021.
13. FortiGuard Labs, What We Have Learned So Far about the "Sunburst"/SolarWinds Hack, 2020.
14. Active Countermeasures, Detecting Sunburst (AKA the SolarWinds Compromise) With RITA and AI-Hunter, 2020.
15. Hussain Rahim, Beacon Analysis (notes on NTP and false positives), Medium, 2022.