Noisy PowerShell rule, a missed shadow-copy deletion, and authorised auto-isolation
A financial services firm runs Elastic Security on Elastic Cloud Hosted. Elastic Defend is deployed to 4,200 Windows endpoints and 260 Linux servers; endpoint telemetry is about 6 TB/day. The custom rule "Suspicious PowerShell" queries process.name: "powershell.exe" and produces about 1,400 alerts per day, 96% of which come from a single signed administrative script, Invoke-InventorySync.ps1, that runs hourly under one service account. Last week an operator ran vssadmin.exe delete shadows /all /quiet on a file server, followed by wbadmin delete catalog. Nothing alerted; the incident surfaced three days later when backups failed. The SOC staffs an on-call analyst 24/5 but nobody after hours. Management has authorised automatic host isolation for confirmed high-severity ransomware behaviour, provided an analyst can reverse it quickly.
1. Tune the noisy rule and close the detection gap without disarming either. Specify the exception entries, what else you add, and how you validate before and after.
Read the worked answer
Two problems, treated separately.
Noise. Make the exception as narrow as the evidence allows while leaving the rule meaningful. Preferred entries: file.hash.sha256 of Invoke-InventorySync.ps1 AND the service account's user.name; if the hash rotates every release, fall back to process.command_line matching the script path AND process.parent.name of the scheduler. Keep the rule enabled - disabling or closing it converts a noisy signal into no signal, and the next real PowerShell intrusion goes unseen. Then add alert suppression keyed on host.name + process.command_line with a one-hour window so 1,400 alerts collapse to a handful per day.
Gap. A KQL rule on process.name was never going to see this: vssadmin.exe and wbadmin.exe are different processes, and the malicious behaviour is the sequence, not the binary. Add an EQL sequence rule matching shadow-copy deletion followed by backup-catalogue deletion on the same host.name within a 10-minute maxspan, and separately a single-event rule on process.args containing delete shadows or resize shadowstorage regardless of parent, mapped to the impact tactic. Enable the prebuilt ransomware rules that cover the same technique so you are not relying on one custom query.
Validation. Use the rule editor's test against the last 30 days to confirm the exception removes the admin script and nothing else, and confirm the new sequence rule would have fired on the file-server event. Also verify Elastic Defend is actually collecting process events on that server - if it ships only auth logs, no rule can fire, and the gap is telemetry, not detection logic.
2. Design the automatic isolation action with guardrails. What must be true for it to be safe and reversible when no analyst is on shift?
Read the worked answer
Mechanics. Attach an Endpoint response action (isolate) plus a notification connector to the detection rule. Isolation is enforced locally by Elastic Defend; the agent's connection to Fleet and Kibana is preserved, which is precisely what makes it reversible - an analyst releases the host from the response-action console and the action is audited against the initiating user.
Guardrails, in order of importance.
- Scope: workstations only (
host.os.type: windowsand not a server OS). A file server runningvssadminmay be a legitimate backup job; isolating it converts a detection into an outage. Servers get an alert-only rule with a page. - Condition on identity, not vibes: trigger the action from named high-severity rules you have reviewed, not from every rule carrying a generic ransomware tag.
- Canary: enable the automated action for one pilot group for two weeks and count isolations versus manual releases. If any isolation is unexplained, stop.
- After-hours reality: there is no analyst overnight, so pair the isolation with an immediate notification to a 24/7 channel and a written release procedure, including a break-glass path in case the isolated machine is the one an analyst needs to reach.
- Test end to end in a lab endpoint. A response action that fails silently while the SOC believes containment happened is worse than no automation at all.
Finally, define the review: 100% of automated isolations reviewed next business day, with a standing metric of false-isolation rate.
3. Thirty days later, the SOC manager asks how you will prove detection actually improved rather than just got quieter. What do you measure?
Read the worked answer
Alert volume alone proves nothing - a rule that never fires also reduces volume. Measure four things and commit to targets up front.
1. Alert quality. Alert-to-case conversion rate (alerts that an analyst escalates into a case) and a sampled true-positive rate from analyst review of closed alerts. Baseline the current ratio first: 1,400 alerts/day with a handful of real ones gives a very low conversion. Target over 20% conversion and under 100 alerts/week from the PowerShell family.
2. Detection coverage, not rule count. Count MITRE tactics that have at least one enabled rule which produced a signal in the last 30 days, and check for telemetry gaps - hosts with no process events, integrations that stopped reporting, rules failing on index patterns or timeouts in rule monitoring.
3. Speed. Mean time to detect for the scripted purple-team techniques, measured from event timestamp to alert creation, not from when someone noticed.
4. Controlled tests. Run three scripted techniques against a lab host group - shadow-copy deletion, a credential-dump attempt, and an encoded PowerShell command - and confirm each alerts, while the administrative script produces no alert. Repeat monthly. A detection programme that cannot demonstrate both directions (fires on the bad thing, quiet on the known-good thing) is just moving numbers around.