Beaconing in Proxy Logs After a CDN Change
Your team runs a 3.2-billion-event-per-day egress proxy dataset. A new hunting rule flags 47 internal hosts making an HTTPS POST every 300 seconds with about 8% jitter to /api/v2/collect on 12 domains registered within the last 40 days and fronted by the same CDN. The posts average 1.8 KB, with occasional 240 KB uploads. Three hosts are in engineering, one is a build server (10.4.8.21) that uploads crash telemetry, and the rest are sales laptops. During the same week, a sanctioned endpoint telemetry agent was updated and began using a new collector endpoint. Proxy logs show TLS SNI matching the 12 domains, but no URL path for most because of TLS 1.3. DNS logs show queries from all 47 hosts, but only the build server resolves a known vendor CNAME. Falcon shows no malicious process on 44 hosts; three sales laptops have unsigned PowerShell launched from Teams cache. The SOC has 90 minutes before shift change and wants a defensible severity call.
1. How do you triage the 47 hosts without treating them as one incident? What grouping and first queries do you use?
Read the worked answer
Break the set into behavioral clusters, not one alert. Group by host role, user, first-seen time, destination domain, POST size, process lineage, and whether the host resolves an approved CNAME. The build server and 44 hosts with no malicious process may be the sanctioned agent update; the three sales laptops with unsigned PowerShell from Teams cache are a separate, higher-risk cluster.
First queries. In proxy data, summarize by host: count of POSTs, median and max request bytes, first and last seen, distinct SNI, authenticated user, and user-agent. In DNS, compare query time to proxy POST time and check for DGA-like or newly registered domains. In Falcon, query ProcessRollup2 for the three sales laptops around the first POST, returning ParentBaseFileName, CommandLine, ImageFileName, SHA256, and UserName; pivot to NetworkConnectIP4 and DnsQueryRequest. For the build server, confirm the vendor CNAME and the agent update ticket.
Severity logic. If the three laptops show PowerShell reading browser or Teams data, writing an archive, and then POSTing, treat them as likely C2 or infostealer and isolate. If the remaining 44 show the same signed agent binary, same vendor CNAME, and same update window, close them as benign with a tuning note. Do not close all 47 because most look benign, and do not escalate all 47 because three are suspicious.
2. What endpoint and network evidence distinguishes command-and-control from the sanctioned telemetry agent?
Read the worked answer
Endpoint evidence. For the agent, Falcon should show a signed binary from the approved vendor path, a parent installer or update service, a stable hash across hosts, and no suspicious child processes. For C2, look for unsigned PowerShell, rundll32 or regsvr32 with remote payloads, browser credential access, archive creation in C:/Users/Public or C:/ProgramData, scheduled tasks, and repeated process injection alerts. The Teams cache launcher is important because it can be a living-off-the-land path.
Network evidence. Compare TLS SNI, JA3/JA4, destination IP reputation, and POST cadence. The sanctioned agent should have a vendor CNAME, consistent user-agent, and a change ticket. C2 often has jitter but may also be fixed; the key is whether the destination is approved and whether the process making the connection matches the signed agent. Check whether the 240 KB uploads align with crash dumps on the build server or with archive files on sales laptops.
Decision. If the three sales laptops show a PowerShell process making the POST and no signed agent, classify as suspected C2 even if the domain is fronted by the same CDN. If the 44 hosts show only the signed agent and vendor CNAME, classify as benign update traffic. Keep the finding open until the three laptops are contained and their payload is analyzed.
3. What detection improvement would you make after this hunt, and what would you avoid overfitting to?
Read the worked answer
Improve with correlation, not just domain reputation. Build a proxy-to-endpoint join on host and five-minute window: alert when a host makes repeated small POSTs to a newly registered domain and Falcon shows a non-browser process making the connection or an unsigned script child. Add a signed-agent allowlist keyed to hash, signer, and vendor CNAME, not just domain. Add a DNS-to-proxy mismatch rule for hosts that resolve an approved CNAME but connect to a different SNI.
Avoid overfitting. Do not hardcode the 12 domains or the 300-second interval; both will change. Do not suppress all CDN-fronted domains, because the vendor uses the same CDN. Do not treat jitter as malicious by itself; many legitimate agents jitter. Do not allowlist by user-agent alone, since it is spoofable.
Validation. Replay 30 days of proxy and DNS data against the new logic, measure false positives by host role, and require an analyst note for any allowlist. Add the three sales laptop hashes to threat intelligence and hunt for them on other endpoints. The defensible outcome is a signed-agent allowlist plus a behavioral rule that catches non-agent processes using the same infrastructure.