Five-Minute Beacon from a Branch VLAN
You are the tier-2 analyst in a 2,400-employee logistics company's SOC. Zeek and NetFlow feed the SIEM, and full packet capture is retained for only 72 hours. A 14-day hunt query returns 14 internal hosts that each open an HTTPS session roughly every 300 seconds with ±12 seconds of jitter to three IP addresses inside a single cloud-hosting /24. The TLS SNI is a well-known CDN name, but the certificate subject is an unrelated domain. JA3 fingerprint 72a589da586844d7f0818ce684948eea appears on these 14 hosts and nowhere else in the estate. Sessions are small and near-symmetric: about 1.1 KB outbound, 900 bytes inbound. All 14 hosts are in one branch VLAN of 180 workstations; two of them are domain controllers. EDR has raised nothing, the proxy allows the traffic because the CDN category is permitted, and no user has reported a problem.
1. How do you decide whether this is command-and-control or a legitimate agent before escalating? What do you check, and in what order?
Read the worked answer
Order matters because the 72-hour capture window is the only evidence that expires.
- Bind flows to processes first (cheap, fast, decisive). Use EDR network-connection history to map each 5-minute session to a PID, image path, command line and signer. If all 14 bind to the same signed patch or monitoring agent, this is a baseline discovery: document it and stop.
- If the process is unsigned, lives in a user-writable path, or is a LOLBin (rundll32, regsvr32, powershell), start a rolling capture filtered to that /24 immediately. That clock is already running.
- Test the beacon statistics. A 300-second interval with ±12 seconds of jitter is machine-generated; no human returns to a host 288 times over 14 days with 4% variance. Compare against the other 166 branch hosts: legitimate agents are usually estate-wide, implants usually are not.
- The SNI/certificate mismatch is the strongest single tell. CDN-fronted C2 routinely presents a certificate for a different name; a legitimate CDN-served SaaS application does not. Pull the certificate out of a capture and check CN/SAN and issuer.
- Read the traffic volume. 1.1 KB out and 900 bytes in is tasking-and-check-in, not file transfer or browsing.
Escalate when 1 through 4 converge. Do not wait for EDR, which is blind to fileless beaconing.
2. Two domain controllers are in scope. Do you block at egress now, and what are the operational consequences of each option?
Read the worked answer
Do not block the /24 at egress as a first action, and do not block only the two DCs.
Blocking by IP is weak here: the destination is a cloud-hosting /24, so the actor rotates addresses within days and the block goes stale. If that provider also serves legitimate traffic to the branch, a /24 deny creates a self-inflicted outage you will have to explain.
Order of operations:
- Scope before containing. Get process-level attribution on all 14 hosts. If 12 turn out to be a known agent and 2 do not, your action set shrinks dramatically and safely.
- Use an application-layer control. A JA3-based block, or a proxy/DNS denial for the destination, survives IP rotation and does not affect unrelated tenants of the same provider.
- For the DCs specifically, prefer EDR network containment or a host-firewall rule for that specific flow over taking the server off the network. DC isolation breaks replication, Kerberos and possibly DNS/DHCP for the whole branch - a much larger incident than the beacon.
- Keep capturing for one full beacon cycle after the block, so you observe retry and failover behaviour; that tells you whether the implant has a fallback channel.
Whatever you decide, write down the residual risk you accepted. That note is what you will be asked about in the post-incident review.
3. Write the detection you would deploy after this hunt, and name the false positive it will generate.
Read the worked answer
Detection: over a 6-hour window, flag any internal host whose outbound 443 sessions toward a single /24 meet all of: (a) 8 or more sessions, (b) standard deviation of inter-arrival time under 15% of the mean, (c) median bytes out below 3 KB, plus a rarity term - the JA3 fingerprint appears on fewer than 5 hosts estate-wide - and a TLS metadata mismatch where the certificate SAN does not contain the SNI string.
Why those thresholds: the jitter test separates scheduled beaconing from human browsing. The rarity term is what stops every workstation running the corporate agent from matching. The byte-volume term excludes streaming and large downloads.
The false positive it will produce: any legitimate vendor agent that is licensed per host and runs on only a handful of machines - a niche backup product, an out-of-band management poller, a SCADA health check - will satisfy all three conditions, because low prevalence is exactly what the rule rewards. Expect the first week to be noisy.
Mitigate by allowlisting the JA3 plus certificate pair, never the IP, so the exception does not rot when the provider changes addresses. Review the exception list with the endpoint team before suppressing anything, and re-test the rule monthly with a synthetic beacon to confirm the suppression has not swallowed the detection.