The Encoded PowerShell Rule That Fires on Everything
The detection engineering backlog contains a Sigma rule named 'Suspicious PowerShell EncodedCommand' that generated 4,218 alerts in the last 24 hours across 18,000 endpoints. Sampling shows 92% of hits come from three administrative service accounts running a scheduled inventory job that legitimately calls powershell.exe -EncodedCommand. Sixty-one alerts were escalated yesterday and none were true positives. The rule matches Image ending in \powershell.exe, so it misses PowerShell 7 running as pwsh.exe, and it has no CommandLine exclusions. Approximately 2,200 servers have no EDR agent and rely on this rule as their only PowerShell coverage. The CISO, citing alert fatigue, wants the rule converted into an automatic containment trigger next sprint. A red team engagement begins in three weeks and will use encoded PowerShell from a C2 framework. The SIEM retains 90 days of raw events.
1. Tune, enrich, or rewrite? What is your first change, and why not simply suppress the service accounts?
Read the worked answer
Rewriting for coverage first, precision second, suppression last.
Why not suppression: excluding the three service accounts removes the only PowerShell visibility on 2,200 servers, and it removes it precisely for accounts an attacker would target. Service accounts with logon rights are a standard escalation path. A blanket exclusion converts a noisy rule into a blind spot.
Order of work:
- Add pwsh.exe to the image match. Today the rule cannot see PowerShell 7 at all, which is a bigger risk than the false positives, and the red team will use it.
- Narrow the service-account noise by matching the known artefact rather than the account: exclude only when the parent is the scheduled task host, or the command line or script block hash matches the inventory job. Anything else from those accounts still alerts.
- Add a correlated condition: encoded command plus an outbound network connection within five minutes raises severity.
Validate each step against 90 days of raw events before shipping anything to production.
2. What is the minimum evidence bar before this rule may drive automatic containment?
Read the worked answer
Containment needs demonstrated precision, reversibility and a blast-radius check. None of the three exist yet.
- Precision: zero true positives in 61 escalations is a point estimate, not proof. Backtest the revised logic over 90 days of raw events, label every hit, and compute precision with a confidence interval. Set a threshold before enabling automation, for example a 90% lower bound.
- Split the rule: allow containment only for a high-fidelity sub-rule, such as encoded command plus a rare parent plus an outbound connection. The broad rule stays alert-only.
- Reversibility: containment must be an isolate action with a tested single-command release, a named owner, and a maximum isolation duration after which it releases automatically.
- Blast radius: exclude domain controllers, backup infrastructure and the 2,200 EDR-less servers, where isolation would cut the only management path.
Present the 61 failed escalations as cost data, and the missing pwsh coverage as the counter-argument to cutting noise for its own sake.
3. How do you prove the revised rule still detects the red team's technique?
Read the worked answer
Three layers, because historical replay alone will not catch everything.
- Unit tests: run the rule against a curated event set covering powershell.exe and pwsh.exe, encoded and plain, benign and malicious, including the exact inventory-job command line so both the suppression and the retained alert path are exercised.
- Historical replay: push 90 days of raw events through the new logic into a test index and diff alert counts per host against production. Investigate every host that drops to zero; each is either a justified suppression or a lost detection and needs a named reason.
- Adversary emulation: before the red team starts, run the encoded-PowerShell technique yourself with the same C2 framework family, confirm an alert fires at the expected severity, and document the expected artefact chain.
Verify the pipeline as well as the rule. Confirm the SIEM is actually ingesting PowerShell 7 events from those 2,200 servers. A perfect rule over uncollected logs detects nothing, and the engagement will not tell you why.