Jittered Beaconing, a Closing Branch, and a Severity Threshold That Does Not Fit
A 55-seat SOC at a regional bank receives an EDR alert: 14 teller workstations have begun resolving a newly registered domain every 61 seconds, with deliberate jitter. Two of those hosts also show an unsigned scheduled task created at 02:14. The IR plan defines a P1 as confirmed malware on more than 20 hosts or any impact to core banking. It is 16:40 on a Friday; the branch closes at 17:00, and the teller supervisor says the PCs will be switched off as usual. The SOC can isolate endpoints on its own authority but needs duty-manager approval to block a domain at the perimeter firewall. Analysts confirm one affected host currently holds an active RDP session originating from an internal jump server. There is no threat-hunting capability on weekends, the malware family is unknown, and no sample has been detonated.
1. The plan's P1 threshold is more than 20 hosts. Do you declare P1 or P2, and how do you justify the call?
Read the worked answer
Declare P1 under a documented duty-manager override, and say so in the ticket.
The threshold is a proxy for impact, built on the assumption that scope is known and that 20 hosts represents material spread. Neither assumption holds here. Reasoning against the P2 reading:
- Scope is unmeasured, not small. 14 is the count of EDR-covered hosts that fired. The teller subnet may contain older or unmanaged machines, and the jump server is implicated by the RDP session. The true denominator is unknown, so the 20-host line cannot be applied.
- The beacon is not opportunistic. 61-second intervals with jitter is a hallmark of an established, deliberately configured implant, which implies dwell time measured in days or weeks, not minutes.
- Persistence exists. The unsigned scheduled task at 02:14 means the adversary survives a reboot; treating this as a nuisance alert would leave that in place.
- Lateral movement is in progress. An RDP session from a jump server to an infected host is either the intrusion path or an imminent pivot into a higher-trust zone.
The correct exam answer is not "follow the number." It is "recognise when the classification rule is a poor fit, escalate on the risk it is meant to capture, and record the rationale." Also note the 17:00 deadline: at P2 the response would wait until Monday, and the evidence would be gone.
2. Lay out the actions for the first 60 minutes in order: the powered-off PCs, the RDP session, the hosts, and the domain block.
Read the worked answer
Minute 0–10: stop the destruction of evidence. Tell the teller supervisor explicitly, in writing, that the machines must stay powered on and connected. Powering off clears memory, and memory is where the injected beacon configuration, the scheduled-task creator, and possibly credentials live. Escalate to the branch manager if the supervisor insists.
Minute 10–20: handle the lateral path. Isolate the jump server as well as the teller host and identify the account and source of the RDP session. If that session is an attacker's, the jump server is now a foothold into the server VLAN; if it is an administrator's, that administrator's workstation is in scope. Do not merely kill the session - preserve it and its logs first.
Minute 20–35: contain the 14 hosts with network containment, not shutdown. EDR isolation keeps them running and reachable by the console while cutting all other traffic. Leave one host as the memory-capture candidate before any remediation touches it.
Minute 35–50: block and sinkhole the domain once the duty manager approves, in parallel with the containment rather than after it. Then use the block as a scope detector: DNS logs will show every host that ever resolved the domain, including machines with no EDR. Note that a perimeter block does not stop an implant using hardcoded IPs, so watch for follow-on traffic to other destinations.
Minute 50–60: notify incident commander, duty manager, and communications; do not discuss the incident on the branch's shared channel.
3. Which forensic artifacts must be captured before any host is reimaged, and what does each one buy you?
Read the worked answer
Order them by perishability and by the question they answer.
1. Memory image of at least one infected host. Answers: what process is beaconing, where the scheduled task payload lives, any injected modules, and whether plaintext credentials are resident. It disappears on reboot and is destroyed by "just reimage it."
2. The scheduled task itself - the XML definition, the binary or script it points to, its hash and signature status, and the creation timestamp. Answers persistence mechanism and whether the same task exists on hosts the EDR did not flag (compare via a fleet-wide task query).
3. DNS and proxy logs for the domain, going back 30+ days. Answers scope: which hosts resolved it, when the first resolution occurred, and whether anything else in the estate talks to the same infrastructure. This is the single most valuable artifact for deciding whether you are done.
4. Windows security events (4624, 4625, 4688) and jump-server RDP logs covering the session window. Answers who moved where and whether the intrusion came from inside.
5. EDR telemetry already in the console, exported and hashed, plus prefetch/amcache for execution history.
6. Registry, autoruns, and the local admin group membership to catch secondary persistence.
The purpose is threefold: scope the intrusion, support a clean rebuild (you cannot verify a rebuild if you never characterised the compromise), and preserve chain of custody for HR, legal, or law enforcement if an insider is involved.