Blocking a Malicious IP That Is Also a Shared CDN
Threat intel flags IP 203.0.113.44 as command-and-control for a malware family seen in the environment. The SOC proposes a perimeter block. Before pushing it, an analyst checks passive DNS and finds the IP is one of hundreds of front-end addresses for a large content delivery network that serves several of the company's own customer-facing assets and a payment processor's checkout page. EDR shows one endpoint, DEV-LT-07, beaconing to that IP every 300 seconds with a 2 KB payload. The endpoint is a developer laptop on the corporate VLAN with access to source repositories. The block would be applied at the egress firewall shared by all VLANs.
1. Should the team apply the IP block? Justify the decision.
Read the worked answer
Not as a blanket egress block. The IP is a shared CDN front end, so a perimeter block would break legitimate traffic to the company's own customer assets and the payment processor's checkout - an availability and revenue impact far larger than one beaconing laptop. The correct action is host-level containment: isolate DEV-LT-07 via EDR network containment so its C2 traffic stops at the endpoint, while the shared IP remains reachable for everyone else. If a network control is still wanted, scope it to the specific VLAN or host, not the shared egress. The intel indicator is real but the indicator's context (shared infrastructure) changes the right control. Blocking on indicator alone, without checking whether the indicator is exclusive to the adversary, is the error.
2. What additional detection should replace the blunt IP block?
Read the worked answer
Behavioral detection keyed to the beacon pattern rather than the address: a rule for periodic outbound connections (~300s interval, consistent small payload) to any destination, plus DNS/SNI-based detection for the malware family's known domains and JA3/JA4 fingerprints. Because the adversary can rotate CDN front ends, the durable signal is the cadence and shape of the beacon and the TLS fingerprint, not the IP. Also alert on the developer laptop's process making the connection (which process, signed or not) so the detection survives IP rotation.
3. DEV-LT-07 has repository access. What is the immediate risk beyond the beacon?
Read the worked answer
The laptop likely holds credentials, SSH keys, and cached repository tokens, and it sits on a VLAN with source access. A beaconing host with that access is a potential source-code exfiltration and a pivot into the repo. Immediate steps: contain the host, rotate credentials and tokens that were present on it, review repository access logs for unusual clones or pushes from that host or its user since first beacon, and check whether the beacon payload could carry data out (2 KB every 5 minutes is enough for staged exfiltration over time). Treat the laptop as compromised until forensics says otherwise; do not just block the IP and leave the host running.