I deployed a Sigma rule designed to detect base64 encoded PowerShell commands in Windows command line logs. Encoded PowerShell is a common technique used by attackers to obscure payloads, which makes it a valuable detection signal in many environments.
The rule worked immediately, but not in the way I expected. Within a week it produced hundreds of alerts. Almost all originated from a CI pipeline executing a legitimate encoded script.
Encoded PowerShell is frequently used in automation because it simplifies quoting and avoids command line parsing issues. As a result, a rule that flags encoded execution can produce significant noise in environments with heavy automation.
The simplest solution would have been to exclude the CI service account or script path. That would have removed the alerts but also created a blind spot. If that same account were abused later, the detection would not fire.
Instead I examined what consistently characterized the legitimate events.
- The parent process was always the CI runner.
- The command line structure was predictable.
- The encoded payload length stayed within a narrow range.
Using those characteristics I refined the rule so alerts are suppressed only when the parent process matches the CI runner and the command line matches the known deployment pattern.
This kept the rule effective while dramatically reducing noise. It also maintained visibility if encoded PowerShell appears outside that expected execution chain.
Tuning detections is rarely about disabling a rule. It is about understanding the environment well enough to narrow the conditions under which legitimate activity occurs.