Web Server Beacon During a Change Freeze
At 03:12 on a Saturday, an EDR alert fires on IIS-PROD-07, one of 60 internet-facing web servers. The alert shows w3wp.exe spawning powershell.exe with a Base64-encoded command; the PowerShell process then makes an outbound TLS connection to 45.77.12.9:443 every 60 seconds. The server hosts a customer portal with about 2,000 active sessions, and the application owner is unreachable for the next two hours. EDR blocked the PowerShell process but did not isolate the host. The SIEM shows the same destination IP appeared in proxy logs from two other web servers in the past week, but no EDR alert fired there. The SOC has one analyst on shift, a 30-minute containment SLA for confirmed critical servers, and a change freeze on the customer portal until 08:00. The web root is on a separate volume, and the server has 32 GB RAM.
1. What is your first containment decision, and what evidence do you collect before making any change? Explain the trade-offs.
Read the worked answer
Treat this as a likely web-shell-to-C2 incident, not as a blocked PowerShell event. The EDR blocked one process, but w3wp.exe remains the parent and the beacon pattern suggests persistence through the web application.
Containment: apply EDR network containment to IIS-PROD-07 and block 45.77.12.9:443 at the edge firewall. This respects the 30-minute SLA and stops further command-and-control without rebooting or deleting the web root. The trade-off is that containment may interrupt some customer sessions, but leaving an actively beaconing internet-facing host connected risks data theft and lateral movement. Notify the on-call application owner and incident lead, but do not wait indefinitely for approval.
Before or immediately after isolation, capture volatile evidence: a memory image, the full process tree and command lines for w3wp.exe and powershell.exe, current network connections, loaded modules, and the EDR telemetry for the alert. Preserve the web root with timestamps and hashes, plus IIS access logs and proxy logs for the destination IP. Do not reboot, reimage, or clear logs. Sequence matters: stop the network channel first, then capture memory while the process is still running.
2. How do you hunt for additional compromised servers using the available telemetry?
Read the worked answer
Build hunts around behaviors, not just the IP. In proxy and Zeek logs, search for 45.77.12.9, the TLS SNI and certificate, JA3/JA3S values, and 60-second periodic connections from server subnets. In IIS logs, look for POST requests to unusual .aspx, .ashx, or upload paths, requests with long or encoded parameters, and access from the same source ranges. In EDR, search for w3wp.exe spawning powershell.exe, cmd.exe, certutil.exe, or unsigned binaries, and for encoded PowerShell command lines. Compare web-root file hashes and recent creation times across the other 59 web servers. In the SIEM, correlate the same destination IP with proxy events from the two servers already seen, then check whether those hosts have EDR gaps or older agents. Prioritize internet-facing servers with the same application stack, but do not exclude internal servers that proxy through the edge. Document each hit with host, timestamp, evidence source, and confidence so the IR lead can scope containment.
3. What should the 08:00 handover contain for the application owner and IR lead?
Read the worked answer
The handover should be decision-oriented. Include a concise timeline from the first EDR alert through containment, the affected asset and business service, the containment actions taken, and what remains active. State the evidence collected and its location, including memory image hash, web-root snapshot, IIS and proxy logs, and EDR process tree. List the hunt results: which servers are confirmed, suspected, or cleared, and the criteria used. State the current risk to the customer portal, including possible session interruption and data exposure. Recommend next steps: forensic review of the web shell, credential rotation for the application pool and any accounts used on the host, rebuild from trusted media after evidence preservation, and edge blocking of the C2 infrastructure. Identify gaps, such as the two servers with proxy hits but no EDR alert, and who owns each follow-up. Avoid claiming the server is clean just because EDR blocked PowerShell.