Beaconing Explained for CySA+, Security+, and PenTest+

Beaconing Explained: Detecting Command-and-

Control Traffic for CySA+, Security+, PenTest+,

 and SecAI+

Sep 27, 2026 · @Ken

What Beaconing Is

Once malware lands on a host, it has a problem: it needs instructions and can't accept inbound connections through a firewall. So it calls out instead. At intervals, it contacts the attacker's command-and-control server, asks whether there is anything to do, and goes quiet again.

That repeated callback is beaconing, and it is the heartbeat of a compromise. It begins after initial access and persists through every later stage — privilege escalation, lateral movement, exfiltration. If an intrusion is ongoing, something is almost certainly beaconing.

Here is the idea the whole topic turns on:

Beaconing is detected by the rhythm of the traffic, not its content.

Modern C2 is encrypted. You cannot read the payload, and you generally cannot tell a beacon from ordinary web traffic by inspecting any single connection — it looks like a browser fetching a page over HTTPS. What gives it away is the pattern: one host contacting one destination every sixty seconds, for three days, with a consistency no human browsing session ever produces.

That is why beacon hunting is flow analysis rather than payload inspection, and why it works even against traffic you cannot decrypt.

What a Beacon Looks Like on the Wire

When an implant lands on a host, it needs to find out what its operator wants it to do. It does that by reaching out to the command-and-control server on a schedule and asking what to do. Four properties of that outreach define the beacon, and each one is a knob the attacker can turn.

Interval (sleep time). The gap between check-ins. A noisy tool might beacon every 10 seconds; a patient operator will set it to 4 hours, or once a day. Short intervals give the attacker responsive control but leave an obvious pattern. Long intervals hide well but make interactive work painful — which is why many operators run a long sleep for persistence and drop it to seconds only when they are actively working the host.

Jitter. A randomization percentage applied to the interval so check-ins aren't perfectly regular. At 0% jitter, a 60-second beacon fires at 60, 120, 180, 240 seconds. At 30% jitter, it fires somewhere between 42 and 78 seconds each time. Jitter is specifically an anti-detection feature: it exists to defeat tools that look for exact periodicity. What it cannot do is remove the central tendency — over enough samples, a jittered beacon still clusters around its base interval, and that is what good detection keys on.

Payload size. A check-in with nothing to report is small and, critically, consistent. Hundreds of outbound requests within a few bytes of each other are a signature, even when the content is unreadable. Sudden large responses are the operator tasking the implant; sudden large outbound transfers are exfiltration.

Channel. Where the traffic goes and what protocol it wears:

• HTTPS over 443 is the default for most frameworks. It blends into the overwhelming majority of enterprise egress, and the payload is encrypted.
• DNS tunnels data through query and response records, often TXT or NULL. It is slow and noisy in volume, but it works in environments that block everything else, because DNS is rarely blocked outright.
• Trusted cloud and SaaS services — a Slack workspace, a Google Drive folder, a Discord webhook, a GitHub Gist, a Microsoft Graph endpoint. This is the hardest variant to handle, because the destination is a service the organization legitimately uses, has already allowlisted, and may not be able to block. Reputation-based blocking fails here by design.
• ICMP and other unusual protocols, mostly in tightly restricted environments where the obvious paths are closed.

The frameworks that show up on exams and in real incidents — Cobalt Strike, Sliver, Mythic, Havoc, Brute Ratel, Empire — all expose these same knobs. Cobalt Strike calls its implant a Beacon outright, and its malleable C2 profiles let an operator reshape headers, URIs, and user-agent strings so the traffic mimics a legitimate application. That is worth internalizing: an attacker can control almost everything about how the traffic looks. What they cannot fully control is how it behaves over time.

Why Beaconing Is Hard to See

Every instinct a newer analyst brings to network traffic works against them here.

It is outbound, and outbound is trusted. Firewalls are usually configured tightly for inbound connections and loosely for outbound ones. A workstation reaching out to port 443 is the single most ordinary event on an enterprise network. Nothing about the connection direction raises a flag.

It is encrypted, and the payload is the part you cannot read. TLS inspection is not universally deployed, and where it is, certificate pinning, privacy exceptions, and sheer volume leave gaps. Signature-based inspection has nothing to match against.

It is low and slow. Volume-based alerting — thresholds, rate limits, data-loss triggers — assumes the bad thing is big. A beacon moves a few hundred bytes at a time. Over a month, that adds up to real data, but no single moment of it crosses a threshold.

The destination can be legitimate. When the C2 channel rides a Slack webhook or a Google Drive API endpoint, domain reputation is good, the certificate is valid, and blocking the domain would break the business. Threat intelligence feeds full of known-bad IPs do nothing for you.

Real software beacons too. Software update checkers, telemetry agents, EDR sensors, monitoring clients, mail clients polling for new messages, NTP — all of it is periodic outbound traffic. A detection rule that fires on "regular outbound connections" fires constantly. This is the practical problem: beaconing detection generates false positives at a rate that will bury a small SOC, and tuning it means building an inventory of what legitimately beacons in your environment.

That last point is the one exam writers like, because it separates the answer that sounds right from the answer that works. Blocking the pattern is not an option. Understanding the baseline is.

How to Detect It

Detection works by looking at the shape of a conversation over time, not any single packet. Five approaches, roughly in the order you would apply them.

1. Time-delta analysis. Pull every connection between one internal host and one external destination, sort by timestamp, and compute the gaps between them. Plot those gaps. Human-driven browsing produces a scattered mess. A beacon produces a tight cluster around one value — tighter with low jitter, looser with high, but still a cluster. Tools like RITA (Real Intelligence Threat Analytics) score exactly this and are worth knowing by name.

2. Connection count and duration. A host that opens 2,880 connections to the same destination in 24 hours, each lasting under a second, is not a person browsing. Long-tail counting — rank internal/external pairs by connection count — surfaces this quickly.

3. Payload-size consistency. Compute the standard deviation of request sizes for each host-destination pair. Legitimate traffic varies widely. A beacon's idle check-ins do not. Low variance across a high connection count is one of the strongest single indicators available.

4. JA3/JA3S and JA4 TLS fingerprinting. Even when you cannot decrypt the session, the TLS client hello reveals a fingerprint of the library and configuration that produced it. Malware written in Go or using a custom TLS stack often fingerprints differently from the browsers and system libraries on the same host. A JA3 hash seen on exactly one workstation and nowhere else is worth a look.

5. Baseline and rarity. Newly observed domain, newly observed for this host, only one host in the organization talks to this destination — these are cheap to compute and cut the candidate set dramatically. A beacon to a legitimate cloud service will pass the reputation check, but the specific workspace or endpoint is often still unique to the compromised host.

Where the data comes from matters as much as the analysis. Zeek connection logs (conn.log, ssl.log, dns.log), NetFlow or IPFIX records, firewall and proxy logs, and DNS query logs are the network side. EDR telemetry adds the piece the network cannot see: which process opened the connection. svchost.exe Reaching a Discord webhook every four minutes is a conclusion, not a lead. Correlating the network pattern with the responsible process is how an analyst turns a suspicion into an incident.

DNS-specific beaconing has its own tells: very long subdomain labels, high query volume to a single second-level domain, unusual record types (TXT, NULL, CNAME chains), high entropy in the query names, and NXDOMAIN patterns from domain-generation algorithms.

What to Do When You Find One

Confirmed beaconing means an active adversary has a live channel into your environment. The response sequence matters, and exams test the order as much as the actions.

Do not tip them off first. The instinct to immediately block the destination at the firewall is understandable and usually wrong as a first move. The operator will notice the channel go dark, and if they have a second implant or a dormant backdoor—which competent operators do—they will switch to it. You will lose visibility while keeping the intrusion. Scope first, then act decisively across everything at once.

Scope it. The beacon you found is one host. Search network telemetry for every other host talking to that destination, related infrastructure (same certificate, same JA3 hash, same hosting range, same DGA family), and the same timing signature to other destinations. Pull the responsible process from EDR and hunt for that binary, hash, service name, scheduled task, and run key everywhere.

Contain. Network-isolate the affected hosts rather than powering them off — you keep memory and you keep the ability to investigate. Modern EDR platforms do host isolation in one click while leaving the analyst's own connection open.

Collect before you clean. Memory capture, the implant binary, process and network artifacts, relevant logs. Once you reimage, it is gone.

Eradicate and recover. Remove the persistence mechanism, not just the running process. Rotate credentials for every account that touched the host, because assume-breach means assume-credential-theft. Reimage where the foothold is uncertain.

Block and detect. Now block the infrastructure, and turn the indicators — domains, IPs, JA3 hashes, file hashes, the timing profile — into standing detections. Feed the destination into your threat-intel platform.

Report and improve. Document dwell time, the initial access vector, and the detection gap. If the beacon ran for 60 days before anyone noticed, the finding is not "malware on a laptop" — it is "we do not have egress visibility," and that is what goes in the report to management.

On the prevention side, the controls that actually reduce beaconing risk are egress filtering with a default-deny posture, forcing all web traffic through an authenticated proxy, DNS filtering with logging, TLS inspection where it is feasible, network segmentation so a beaconing workstation cannot reach the crown jewels, and an allowlist of the cloud services the business genuinely uses.

CySA+ (CS0-004) Exam Tips

This exam puts the most weight on beaconing, and it shows up across three of the four domains: Security Operations (34%), Vulnerability Management (26%), Incident Response and Management (24%), and Reporting and Communication (16%).

CySA+ asks you to behave like an analyst, which means most beaconing questions are scenario questions with log excerpts or traffic summaries. Expect to see a table of timestamps or connection counts and be asked what it indicates, or to be given four candidate explanations and asked which one is consistent with the evidence.

What to know cold:

• Read a timestamp column and spot periodicity. If the gaps between entries hover near a constant value, that is a beacon, jitter included. Practice doing the subtraction quickly.
• Consistent small payload sizes across many connections is the second signature to recognize on sight.
• Know your log sources and what each one can and cannot tell you. Firewall and flow logs give you the pattern; DNS logs give you tunneling and DGA evidence; proxy logs give you URIs and user agents; EDR gives you the process. A question that asks, "Which data source would best confirm X?" is asking whether you know the boundaries.
• Correlate network and endpoint. The highest-scoring answer in a CySA+ scenario usually pairs the traffic pattern with the process or parent process that produced it.
• Incident response order. Preparation, detection and analysis, containment, eradication, recovery, and lessons learned — and within that, scope before you block.
• Trend and behavioral analysis over signature matching. CySA+ leans heavily on the idea that modern threats are found by deviation from baseline, not by matching a known pattern.
• Reporting. Be ready for questions about what to communicate and to whom. Send dwell time, scope, business impact, and the control gap to management; send indicators to the detection team.

One scheduling note: CS0-003 retires on Dec 22, 2026 for the English exam, with translated versions following in March 2027. If you are studying now, study CS0-004.

Security+ (SY0-701) Exam Tips

Security+ treats beaconing at the vocabulary and concept level rather than through log analysis. You will not be asked to compute time deltas. You will be asked what a term means and which indicator points to which activity.

What to know:

• Command and control is a stage of an attack, and beaconing is how the implant stays in touch. Be able to place C2 in a kill-chain sequence: reconnaissance, delivery, exploitation, installation, command and control, actions on objectives.
• The indicator-of-compromise vocabulary. Beaconing sits alongside unusual outbound traffic, connections at odd hours, traffic to unfamiliar geographic regions, and data volume anomalies. Security+ likes questions of the form "a security analyst notices X — which of the following best describes this?"
• The distinguishing detail is regularity. If a question describes traffic that is periodic, small, and outbound to the same external host, the answer is beaconing or C2 — not a DDoS, not a port scan, not data exfiltration on its own.
• DNS tunneling as a covert channel. Know that DNS can carry C2 data and why it often succeeds.
• Mitigations Security+ expects: firewall egress rules, DNS filtering, network segmentation, IDS/IPS, SIEM correlation, and EDR.
• Botnets. Bots beacon to their C2 for instructions; this is a classic Security+ framing of the same concept.

SY0-701 is the current version. A successor is expected in the late-2026 to early-2027 window, so check CompTIA's exam page before you book if you are reading this well after publication.

PenTest+ (PT0-003) Exam Tips

PenTest+ flips the perspective. Here, you configure the beacon, and the exam cares whether you can run a post-exploitation channel that stays up and stays quiet.

What to know:

• You configure sleep and jitter, and you should know why. Longer sleep with meaningful jitter is the evasive configuration; short sleep with no jitter is the one that gets caught. Expect a question that hands you a defender's detection capability and asks which C2 setting best avoids it.
• Framework fluency. Cobalt Strike Beacon, Sliver, Mythic, Havoc, Empire, Metasploit's Meterpreter. Know what a malleable C2 profile is and that it lets you shape traffic to look like a known application.
• Channel selection based on the target environment. If egress is filtered to a proxy, you use HTTPS through it. If only DNS resolves outbound, you use DNS. If the target already lives in Microsoft 365 or Slack, you use that.
• Redirectors and infrastructure design. Fronting your team server behind a redirector, using a domain with aged reputation and appropriate categorization, and separating short-haul from long-haul C2 are standard practice and fair game.
• Detection evasion has a scope boundary. Evasion testing is only in scope when the rules of engagement say so, and PenTest+ is consistent that the rules of engagement are the governing document.
• Reporting is the deliverable. If your beacon ran for the whole engagement undetected, the finding is not "I had C2" — it is that the client lacks egress monitoring. Recommend egress filtering, TLS inspection, and beacon-pattern detection. Write the finding from the defender's point of view.

SecAI+ (CY0-001) Exam Tips

SecAI+ approaches beaconing from the angle of how machine learning changes the problem on both sides. The AI-Assisted Security domain carries 24% of the exam, and beacon detection is one of the cleanest examples of why analytics beat signatures.

What to know:

• Beaconing is an anomaly-detection problem, not a signature problem. There is no string to match. Models cluster host-destination pairs by timing variance, payload-size variance, and connection count, then flag the outliers. Unsupervised approaches work here because you do not need labeled malware samples to notice that one host behaves unlike every other host.
• Baselining is the whole game. A model trained on your network learns what normal periodic traffic looks like in your environment — which update services, which telemetry agents, which SaaS clients. Transplanting a model between organizations without retraining produces noise.
• False positives are the operational constraint. Expect questions about precision versus recall in a SOC context. A detector that catches every beacon but buries analysts in alerts is a failed control.
• Explainability matters for response. An analyst needs to know why a connection was flagged — which feature drove the score — before they will isolate an executive's laptop. Black-box scoring slows response.
• Adversarial pressure runs the other way too. Attackers tune jitter, vary payload padding, and randomize destinations specifically to move their traffic inside the model's normal region. AI-generated or AI-assisted malware can adapt its beacon profile in response to what gets blocked and what doesn't.
• The data pipeline is part of the control. Flow logs, DNS logs, and EDR telemetry feed the model; gaps in collection create gaps in detection, no matter how good the model is.

Key Takeaways

• Beaconing is the periodic outbound check-in an implant makes to its command-and-control server. It is the heartbeat of an active intrusion.
• Detection keys on rhythm, not content. Interval, jitter, payload-size consistency, and connection count are visible even when the traffic is fully encrypted.
• Jitter hides the exact pattern but not the central tendency. Over enough samples, a jittered beacon still clusters.
• The channel can be entirely legitimate. HTTPS to an allowlisted SaaS service defeats reputation-based blocking by design.
• Legitimate software beacons constantly. Baselining what normally beacons in your environment is what makes the detection usable.
• Scope before you block. Blocking one channel warns the operator and pushes them to a backup you haven't found yet.
• Correlate network with endpoint. The traffic pattern is the lead; the responsible process is the confirmation.
• Each exam tests a different face of it: CySA+ wants analysis of logs, Security+ wants the vocabulary and the indicator, PenTest+ wants the operator's configuration choices, and SecAI+ wants the anomaly-detection model and its limits.