Ich habe eine Sigma-Regel ausgerollt, die Base64-kodierte PowerShell-Befehle in Windows-Command-Line-Logs erkennen soll. Kodierte PowerShell nutzen Angreifer oft, um Payloads zu verschleiern — deshalb ist das in vielen Umgebungen ein brauchbares Detection-Signal.
Die Regel griff sofort — aber nicht so, wie ich erwartet hatte. Innerhalb einer Woche kamen hunderte Alerts, fast alle aus einer CI-Pipeline, die ein legitimes kodiertes Skript ausführte.
Kodierte PowerShell ist in Automation üblich, weil sie Quoting vereinfacht und Parsing-Probleme auf der Kommandozeile vermeidet. Eine Regel, die kodierte Ausführung meldet, erzeugt in stark automatiserten Umgebungen schnell viel Rauschen.
Am einfachsten wäre gewesen, CI-Servicekonto oder Skriptpfad auszuschließen — die Alerts wären weg, aber auch ein blinder Fleck: Würde dasselbe Konto missbraucht, würde die Detection nicht feuern.
Stattdessen habe ich geschaut, was die legitimen Events zuverlässig charakterisierte.
- Elternprozess war immer der CI-Runner.
- Die Kommandozeilenstruktur war vorhersagbar.
- Die Länge des kodierten Payloads blieb in einem engen Bereich.
Damit habe ich die Regel verfeinert: Alerts werden nur unterdrückt, wenn der Elternprozess zum CI-Runner passt und die Kommandozeile dem bekannten Deployment-Muster entspricht.
So bleibt die Regel wirksam, das Rauschen sinkt stark, und kodierte PowerShell außerhalb dieser Kette fällt weiter auf.
Detection tunen heißt selten, eine Regel abzuschalten — sondern die Umgebung so zu verstehen, dass man legitime Aktivität eng genug eingrenzen kann.