IDS Beacon Alert Mixes Red-Team and User Hosts
Your IDS sensors cover a 1 Gbps internet edge and generate about 8,000 alerts per day. A new signature, 'Possible Cobalt Strike Beacon', fires 400 times in 24 hours from 20 internal hosts to three external IPs on TCP 443. The traffic is TLS, about 2 KB per session, and sessions from most hosts recur at roughly 60-second intervals with small jitter. Five of the source hosts belong to the red team, which is authorized to test only 10.0.50.0/24 this week; the other 15 are ordinary user laptops. The edge firewall logs show the connections are allowed, and NetFlow shows no large uploads. EDR is deployed on all hosts but has no detections for these connections. The red-team lead is available by chat, and the SOC manager wants to block all 20 hosts at the firewall immediately to protect the network.
1. How do you validate the alert before blocking all 20 hosts?
Read the worked answer
Start by separating authorized red-team activity from possible malware. Confirm the five red-team host IPs and their authorized scope with the red-team lead in writing. The stated scope is 10.0.50.0/24, so traffic from those hosts to external IPs may be in scope or may be out of scope; do not assume either. For the 15 user laptops, extract TLS metadata: SNI, certificate issuer and subject, JA3/JA3S, packet sizes, and beacon interval. Compare the three external IPs and certificates across all 20 hosts. Check EDR process trees on the laptops for the process making the connection, parent process, and command line. Review proxy logs and DNS for the same destinations and for repeated failed lookups. If the 15 laptops share the same JA3 and beacon pattern but different user activity, that strongly suggests a common malware campaign. The absence of EDR detections lowers confidence but does not clear the hosts; EDR may miss fileless or signed malware.
2. What containment and evidence-preservation sequence do you recommend?
Read the worked answer
Do not block all 20 hosts blindly. First, block the three external IPs at the edge for all internal hosts except the authorized red-team range, or block them globally if the red-team lead confirms the infrastructure is not part of the test. Isolate the 15 user laptops through EDR network containment, preserving memory and process evidence before any reboot. For the five red-team hosts, ask the lead to pause or confirm the activity; if it is authorized, document it and avoid destroying their test evidence. If it is not authorized, treat them like the others.
Before containment, capture volatile data on at least a sample of the 15 laptops: memory, network connections, process tree, and the binary path. Export IDS packet captures for the beacon sessions and save Zeek conn, ssl, and x509 logs. Blocking at the firewall alone may stop C2 but leaves the implant resident; isolation plus memory capture supports both containment and later analysis.
3. How do you communicate the disagreement with the SOC manager and document the decision?
Read the worked answer
Acknowledge the manager's goal: stop beaconing quickly. Explain that immediate blocking of all 20 hosts would also disrupt an authorized red-team test and could tip off or destroy evidence on the 15 potentially infected laptops. Present a split plan: block the external infrastructure now, isolate the 15 user laptops for investigation, and confirm the five red-team hosts with the red-team lead before acting. Give a time bound, for example 15 minutes for confirmation, and state what happens if confirmation is not received.
Document the decision in the incident ticket: the IDS signature, source and destination counts, red-team scope, validation evidence, containment actions, and who approved them. Record the residual risk of leaving red-team hosts connected and the risk of disrupting the test. This creates an audit trail and prevents later confusion about why not all 20 hosts were blocked at once.