Beaconing Behind a CDN Front
Your hunt team is reviewing proxy and NetFlow data for a 1,200-host enclave. One workstation, used by a contracting officer, connects to a large CDN IP every 300 seconds with about 4 seconds of jitter, sends roughly 1.2 KB, receives about 4 KB, and holds each TLS session 40–60 seconds. The pattern runs around the clock but pauses for 90 minutes at 03:00. DNS logs show random-looking subdomains queried against one authoritative server about every 10 minutes. Proxy logs show a JA3 fingerprint that matches both a known malware family and a widely used software updater. Seventeen other hosts contact the same CDN, but with no fixed interval. Blocking the CDN range would disrupt patching for 300 systems. The contracting officer is traveling and cannot be reached for 8 hours. The threat-intel team rates the malware match as 'possible.' You must decide whether to isolate, block, or continue monitoring, and what evidence to collect.
1. Assess the likelihood that this is C2. State your confidence and the alternative hypotheses.
Read the worked answer
Fixed 300-second intervals with plus-or-minus 4 seconds of jitter, asymmetric small-out/large-in traffic, and a 24-hour cadence strongly resemble tasking beaconing; malware often uses jitter to defeat periodicity detection. The random-looking DNS subdomains to one authoritative server are more suspicious than the TLS, because they suggest DNS tunneling or domain generation. The JA3 match is weak: JA3 fingerprints libraries, not intent, and a common updater can share it. The 17 other hosts contacting the CDN without a fixed interval support a benign CDN or updater explanation for the IP, but not for the one host's cadence. The 90-minute pause at 03:00 could be a maintenance window, an operator pause, or a beacon schedule; it does not resolve the question. Confidence is moderate, roughly 60–70%, that the host is compromised. Alternatives include a telemetry agent with a randomized check-in, a backup or patch client, or a proxy health check. Cadence plus DNS anomaly justifies host collection, not a network-wide block.
2. Recommend next collection and the isolation decision.
Read the worked answer
Do not block the CDN range; that breaks patching for 300 systems and telegraphs the hunt. Isolate the single workstation at the EDR layer while preserving a network capture; if EDR isolation is unavailable, use a switch ACL that permits only the incident-response VLAN. Collect memory, autoruns, scheduled tasks, browser extensions, recent documents, and full TLS metadata; pull the host's DNS cache and proxy logs for the random subdomains. Query passive DNS for the authoritative server and the subdomains; check whether the subdomains resolve to the same IP or use TXT records. Hunt the 17 other hosts for the same subdomain pattern, not just the CDN IP. Because the user is traveling, coordinate remote isolation with the user's chain of command and preserve the laptop for forensics. If the host is off-network, use the EDR cloud console.
3. How does the 03:00 pause affect your confidence, and what would you check?
Read the worked answer
The pause is consistent with a scheduled task or a beacon that sleeps outside an operator's working hours; it is also consistent with a backup or patch window. If the pause aligns with the enterprise patch window, it supports the benign update hypothesis. If it aligns with the adversary's regional working hours, it supports C2. Check the host's scheduled tasks and the proxy logs at 03:00, and determine whether the pause is exactly 90 minutes every day or variable. A fixed 90-minute pause is more artificial; a variable pause is less diagnostic. The pause should not drive isolation by itself, but it is a useful discriminator. If the pause disappears when the host is isolated, that suggests the beacon is host-based rather than network-based.