Beaconing Workstation Behind a Legacy ACL
Northwind Logistics runs a flat 10.10.0.0/16 network for 340 staff. The only full-time analyst is on leave, so a help-desk technician is watching the IDS console. At 09:12 the IDS flags workstation 10.10.4.37 for repeated TLS sessions to 203.0.113.88:443 every 300 seconds, with roughly 1.1 MB transferred each time. The user says the machine is slow but blames a video call. The EDR sensor on that host has been in degraded mode since a disk-full event two days ago, so process trees are incomplete. NetFlow is retained for 24 hours; full packet capture is not enabled. The firewall permits all outbound TCP 443 by default, and the proxy logs show the same destination with a user-agent of 'Mozilla/5.0' but no URL path because the traffic is TLS. The destination IP belongs to a regional hosting provider, not a known CDN. The technician can either block the IP at the firewall, isolate the switch port, or keep watching until the analyst returns tomorrow.
1. What should the technician do first, and what evidence should be collected before any containment?
Read the worked answer
Do not block yet. A single IP block treats the symptom and may tip off the operator or break a legitimate business service; it also leaves the host resident. Before containment:
- Pull 24 hours of NetFlow for 10.10.4.37 and for any other internal host talking to 203.0.113.88:443. A beacon with fixed 300-second intervals and near-constant byte counts is more suspicious than one matching an update schedule.
- Query DNS and proxy logs for the same destination, SNI, and user-agent; check whether the user-agent is consistent with installed software.
- Use the degraded EDR for whatever process and parent-process data exists, plus Windows event logs, scheduled tasks, services, and autoruns via remote triage.
- Ask the user whether they installed anything or clicked a link; do not rely on the video-call explanation.
- Hash and preserve the logs you collect. Do not power off the host. Then isolate the switch port if the beaconing is confirmed or if you cannot rule it out before the user's deadline. Isolation is reversible and preserves memory; a firewall block is not a containment action.
2. The user is a claims adjuster who needs the machine for a 14:00 deadline. Argue for isolation or monitoring, including business and security trade-offs.
Read the worked answer
The decision hinge is whether the host is likely compromised and what the user can do on a loaner. A claims adjuster with a 14:00 deadline does not need the same physical machine; a loaner with VPN and file access meets the business need. Isolate the port now, keep the machine powered, and collect memory before any reboot. If isolation is refused, require a written risk acceptance from the business owner, add a temporary firewall rule limiting the host to approved destinations, and set a hard stop: any new destination, elevated process, or second host contacting the IP triggers immediate isolation. Monitoring alone is weak here because EDR is degraded and packet capture is absent. The asymmetry favors isolation: a few hours of user inconvenience versus potential lateral movement and credential theft. Document the decision and the deadline so the examiner can see the trade-off was deliberate.
3. Which longer-term control would most reduce this class of risk, and what evidence supports it?
Read the worked answer
The strongest long-term control is default-deny egress through an authenticated proxy with category and destination allowlists, not another IP block. The current firewall permits all TCP 443, which is why a hosting-provider IP is reachable at all. Supporting measures:
- Enforce proxy use for workstations and block direct 443 except for approved services.
- Enable TLS inspection or at least SNI logging and JA3/JA3S fingerprinting on the proxy.
- Monitor EDR sensor health as a security control; a two-day degraded sensor should open a ticket, not persist unnoticed.
- Baseline beacon-like behavior (fixed interval, low jitter, repeated byte counts) in NetFlow. An IP block would fail against domain fronting, fast flux, or a new IP tomorrow. The evidence supporting the proxy is the 300-second cadence and the 1.1 MB sessions, which are visible in NetFlow even without packet capture.