ByteRay Blog
Powershell Hunting III: Powershell Lineage
Powershell ist ein fester Bestandteil moderner Windows-Systeme und bietet durch .NET-Anbindung mächtige Möglichkeiten zur Automatisierung. Diese Eigenschaften machen es auch für Angreifer attraktiv:
- Auf jedem Windows-System vorhanden (kein zusätzlicher Code nötig)
- Direkter Zugriff auf Windows-APIs und Netzwerkressourcen
- Kann Code aus dem Speicher ausführen (fileless execution)
- Oft unzureichend überwacht oder eingeschränkt
Living off the Land-Taktiken nutzen Powershell, um Angriffe unauffällig und ohne zusätzliche Tools durchzuführen.
Der Kontext eines Powershell Prozesses kann auf einen möglichen Missbrauch von Powershell hinweisen. Nachfolgend beschreiben wir, in welchen Fällen die Prozessbeziehungen von Powershell verdächtig sind und wie wir mit CrowdStrike NextGen SIEM nach verdächtigen Prozessbeziehnugnen suchen.
* Initial Execution: Oft ist das Starten von Powershell der erste Schritt nach einer erfolgreichen Kompromittierung, um weitere Aktionen durchzuführen oder Payloads nachzuladen.
* Beispiel: Ein schadhaftes Office-Makro (`winword.exe`, `excel.exe`) startet Powershell, um die nächste Angriffsstufe herunterzuladen und auszuführen.
* Beispiel: Die Ausnutzung einer Sicherheitslücke in einem Browser (`chrome.exe`, `msedge.exe`) führt zur Ausführung von Powershell.
* Evasion: Angreifer versuchen aktiv, Erkennungsregeln zu umgehen, die auf erwarteten Prozessbeziehungen basieren.
* Beispiel: Ausführung von Powershell über WMI (Windows Management Instrumentation). Hierbei wird `wmiprvse.exe` zum Parent-Prozess anstelle des eigentlichen initiierenden Prozesses (z. B. eines Makros in Word).
* Beispiel: Anwendung von Parent Process ID (PPID) Spoofing. Dabei wird Powershell so manipuliert, dass es aussieht, als wäre es von einem harmlosen Prozess wie `explorer.exe` gestartet worden, obwohl der tatsächliche Auslöser Malware war.
* Persistence: Angreifer nutzen Mechanismen, bei denen ein Systemprozess der natürliche Elternprozess ist, die ausgeführte Aktion jedoch bösartig ist.
* Beispiel: WMI Event Subscriptions (Ereignisabonnements), die bei bestimmten Systemereignissen Powershell-Code über `wmiprvse.exe` ausführen [T1546.003].
* Beispiel: Bösartige geplante Aufgaben (Scheduled Tasks), die Powershell über die Task Scheduler-Instanz von `svchost.exe` starten [T1053.005].
* Lateral Movement: Ausführung von Powershell auf entfernten Systemen unter Nutzung eingebauter Windows-Protokolle und -Werkzeuge.
* Beispiel: Verwendung von WMI (`wmiprvse.exe` oder `wmic.exe` initiiert Remote-Ausführung), WinRM (`wsmprovhost.exe`) oder potenziell DCOM (`svchost.exe`), um Powershell auf einem Zielsystem zu starten. Auf dem Zielsystem erscheinen dann diese Dienstprozesse als Parent von Powershell.
Ein zentraler Treiber für viele dieser Szenarien ist die Evasion. Techniken wie die WMI-Ausführung oder PPID-Spoofing wurden speziell entwickelt, um die Überwachung der Prozessabstammung zu täuschen oder zu brechen. Detection-Regeln wie "Blockiere Powershell als Child-Prozess von Word" verleiten Angreifer dazu, weniger verdächtigen Parent-Prozesse wie `wmiprvse.exe` zu starten. Die Beobachtung von alternativen, ungewöhnlichen Parent-Prozessen wird somit zu einer neuen Erkennungsmöglichkeit. Darüber hinaus kann ein einzelner ungewöhnlicher Parent-Prozess auf mehrere Angriffsziele gleichzeitig hindeuten.
Beispielsweise kann `wmiprvse.exe` als Parent-Prozess von Powershell auf eine Erstausführung via WMI, auf Persistenz durch ein WMI-Ereignisabonnement oder auf Lateral Movement durch Remote-WMI-Ausführung hinweisen. WMI ist ein vielseitiges Werkzeug für Angreifer und erfordert die Beobachtung der Kette `wmiprvse.exe -> powershell.exe` für eine weitergehende Untersuchung (Analyse der Kommandozeile, WMI-Protokolle, Netzwerkverbindungen), um die spezifische Angriffsaktivität zu bestimmen.
Um Anomalien erkennen zu können, ist es wichtig, den Normalzustand zu verstehen. Powershell wird in vielen administrativen und interaktiven Szenarien legitim gestartet. Die folgenden Elternprozesse sind typischerweise unbedenklich:
* `explorer.exe` (Windows Explorer): Dies ist der häufigste Parent-Prozess für interaktive Powershell-Sitzungen. Er tritt auf, wenn ein Benutzer Powershell über das Startmenü, oder Ausführen (Win + R), die Adressleiste des Explorers oder durch Klicken auf eine `.ps1`-Skriptdatei startet.
* `cmd.exe` (Eingabeaufforderung): Wenn ein Benutzer Powershell aus einer bereits laufenden Eingabeaufforderungssitzung heraus startet, wird `cmd.exe` zum Parent- Prozess.
* `svchost.exe` (Task Scheduler Service): Powershell-Skripte, die über Scheduled Tasks ausgeführt werden, haben eine spezifische Instanz von `svchost.exe` als Parent- Prozess. Diese Instanz ist typischerweise durch `-k netsvcs -p -s Schedule` identifizierbar.
* IDEs / Konsolen: Werkzeuge wie Powershell ISE (`powershell_ise.exe`), Visual Studio Code (`Code.exe`), Windows Terminal (`wt.exe`) oder andere Entwicklerkonsolen starten legitimerweise Powershell-Prozesse, wenn Benutzer Skripte entwickeln, ausführen oder debuggen.
* Andere administrative Werkzeuge: Systemmanagementlösungen (z. B. SCCM-Agent) oder spezialisierte Drittanbieter-Administrationswerkzeuge können ebenfalls legitime Parent-Prozesse für Powershell sein.
* `powershell.exe`: Eine Powershell-Instanz kann eine weitere Powershell-Instanz starten. Dies geschieht beispielsweise bei der Verwendung unterschiedlicher Anmeldeinformationen, beim Aufbau von Remoting-Sitzungen (Enter-PSSession) oder innerhalb komplexer Skriptkonstrukte, die separate Ausführungsumgebungen erfordern.
Es ist wichtig zu betonen, dass selbst ein legitimer Parent-Prozess keine Garantie für legitime Aktivitäten ist. Die Kommandozeilenargumente, mit denen `powershell.exe` gestartet wird, sind ebenso entscheidend für die Bewertung. Stark verschleierte Befehle (z. B. mittels `-EncodedCommand` oder `-e`), der Einsatz von Download-Cradles (wie `DownloadString` oder `System.Net.WebClient`) oder das Ausführen in einem versteckten Fenster (`-WindowStyle Hidden` oder `-w Hidden`) sind unabhängig vom Parent verdächtig.
Besondere Aufmerksamkeit erfordert der Parent-Prozess `svchost.exe` (Task Scheduler). Obwohl dies ein legitimer Mechanismus ist, missbrauchen Angreifer Scheduled Tasks für Persistenz und Ausführung MITRE ATT&CK [T1053.005]. Daher erfordert die Prozesskette `svchost.exe -> powershell.exe` immer eine genauere Untersuchung: Welche Aufgabe wurde ausgeführt? Welchen Inhalt hat das Powershell-Skript oder der Befehl? Im Gegensatz dazu ist eine Kette wie `winword.exe -> powershell.exe` fast immer ein klares Anzeichen für schadhaftes Verhalten.
Im Folgenden gehen wir im Detail auf ungewöhnliche Parent-Prozesse ein.
Office-Anwendungen sollten normalerweise keine Kommandozeilen-Interpreter oder Skripting-Engines direkt starten. Dies ist ein klassischer Indikator für die Ausführung bösartiger Makros (bsp. [T1566.001] Spearphishing Attachment).
**Mechanismus:** Bösartige VBA-Makros verwenden Funktionen wie `Shell()` oder WMI-Objekte , um `powershell.exe` zu starten.
Browser sollten Powershell normalerweise nicht direkt starten. Dies deutet oft auf die Ausnutzung einer Browser-Schwachstelle, Aktivitäten einer bösartigen Erweiterung oder die Ausführung eines Drive-by-Downloads hin (T1204 User Execution).
**Mechanismus:** Exploits erlangen Codeausführung innerhalb des Browserprozesses oder bösartige Erweiterungen mit ausreichenden Berechtigungen starten Powershell.
Obwohl `wmiprvse.exe` ein legitimer Windows-Prozess ist, kann sein Starten von Powershell hochgradig verdächtig sein. Es deutet auf den Missbrauch von WMI für Ausführung [T1047] Windows Management Instrumentation), Persistenz ([T1546.003] WMI Event Subscription) oder Lateral Movement ([T1021.006] Remote Services: Windows Remote Management) hin.
**Mechanismus:** Angreifer verwenden `wmic.exe` (lokal oder remote), Powershells WMI-Cmdlets (`Invoke-WmiMethod`, `Get-WmiObject`) oder COM-APIs, um mit WMI-Klassen (`Win32_Process`, `Win32_ScheduledJob`, Ereignis-Consumer / Filter) zu interagieren und Befehle oder Skripte auszuführen. Die Ausführung wird von einem WMI-Provider gehandhabt, der in `wmiprvse.exe` gehostet wird.
Ein normalerweise harmloser Prozess wie `explorer.exe` oder sogar eine `svchost.exe`-Instanz (die nicht zum Task Scheduler gehört) startet Powershell mit bösartigen Kommandozeilenargumenten oder zeigt verdächtiges Netzwerkverhalten. Dies deutet auf potenzielles PPID Spoofing hin ([T1134](https://attack.mitre.org/techniques/T1134/) Access Token Manipulation, bezogene Techniken zur Prozessmanipulation).
**Mechanismus:** Angreifer verwenden spezifische Windows-API-Aufrufe (wie `CreateProcess`) mit Flags (`PROC_THREAD_ATTRIBUTE_PARENT_PROCESS`) während der Prozesserstellung, um einen beliebigen Parent-Prozess anzugeben.
Erkennungshinweis: Kann durch Vergleich der echten Parent-PID (manchmal von fortgeschrittenen EDRs oder über ETW Kernel-Prozessprotokolle protokolliert) mit der gemeldeten Parent-PID erkannt werden, oder durch Fokussierung auf das Verhalten des Kindprozesses (Kommandozeile, Netzwerkverbindungen) unabhängig vom gemeldeten Parent-Prozess.
Diese legitimen Windows-Binärdateien werden oft von Angreifern missbraucht, um die Ausführung zu verschleiern ([T1218] System Binary Proxy Execution). Wenn sie Powershell starten, ist dies oft ein Zeichen für bösartige Aktivitäten.
**Mechanismus:** Angreifer rufen diese LOLBINs (Living Off The Land Binaries) mit spezifischen Argumenten auf, die auf bösartige Skripte verweisen (lokal oder remote, z. B. `.sct`-Dateien für `regsvr32.exe`), welche dann Powershell-Befehle ausführen.
Wenn ein Angreifer beispielsweise Powershell aus einem Word-Makro heraus ausführen möchte, aber die Erkennung von `winword.exe -> powershell.exe` vermeiden will, kann er WMI verwenden, was zur Kette `wmiprvse.exe -> powershell.exe` führt , oder PPID-Spoofing mit Ziel `explorer.exe`, was zur (gefälschten) Kette `explorer.exe -> powershell.exe` führt.
Eine wichtige verwandte Evasionstechnik ist "Powershell without Powershell". Hierbei führen Angreifer Powershell-Logik aus, ohne `powershell.exe` zu starten, indem sie .NET-Assemblies direkt laden (z. B. über `rundll32.exe` oder `msbuild.exe`). Dies erzeugt zwar keinen `powershell.exe`-Prozess (und somit keinen Parent-Prozess für `powershell.exe`), umgeht aber die Überwachung, wenn diese sich ausschließlich auf die Prozesserstellung von `powershell.exe` konzentriert. Die Erkennung erfordert die Überwachung von LOLBINs, die `System.Management.Automation.dll` laden, oder anderer Verhaltensanomalien. Die Überwachung ungewöhnlicher Parent-Prozesse für `powershell.exe` ist notwendig, aber nicht ausreichend; die Überwachung ungewöhnlicher Modulladungen im Zusammenhang mit Powershell in anderen Prozessen ist ebenfalls für eine umfassende Erkennung erforderlich.
#event_simpleName = ProcessRollup2 event_platform=Win
| ImageFileName = /(\\Device\\HarddiskVolume\d+)?(?<FilePath>(\\|\/).*(\\|\/))(?<FileName>.+)$/
| format(format="[%s] > %s", field=[ParentBaseFileName, FileName], as=processLineage)
| FileName=?FileName
| groupBy([processLineage], function=([count(aid, as=executionCount), min("ProcessStartTime, as=firstRun"), max("ProcessStartTime", as=lastRun)]))
| formatTime(format="%c", field=firstRun, as="firstRun")
| formatTime(format="%c", field=lastRun, as="lastRun")
| sort(executionCount, order=desc)