Process Parameter Poisoning (P³): Wie Angreifer moderne EDR-Lösungen umgehen können

Das Wichtigste im Überblick

• Process Parameter Poisoning (P³) nutzt legitime Windows-Prozessparameter zur Übertragung von Shellcode.
• Im Gegensatz zu klassischen Process-Injection-Techniken werden APIs wie WriteProcessMemory oder VirtualAllocEx vollständig vermieden.
• Dadurch sinkt die Sichtbarkeit des Angriffs für viele Endpoint Detection and Response (EDR)-Lösungen.
• Die Angriffstechnik nutzt den Process Environment Block (PEB) und die darin gespeicherten Prozessparameter.
• Ein grundlegendes Verständnis der Windows-Prozessarchitektur ist entscheidend, um diese Angriffsmethode erkennen und geeignete Detection-Regeln entwickeln zu können.

Für wen eignet sich dieser Artikel?

Dieser Beitrag richtet sich an alle, die sich mit der Erkennung und Abwehr moderner Cyberangriffe beschäftigen oder ihre Kenntnisse über aktuelle Angriffstechniken vertiefen möchten. Besonders profitieren SOC-Analysten, Threat Hunter, Detection Engineers, Incident Response Teams, Security Architects sowie Windows-Administratoren, die Einblicke in neue Methoden der Process Injection und deren Auswirkungen auf moderne EDR-Lösungen gewinnen möchten. Aber auch IT-Entscheider und Sicherheitsverantwortliche erhalten ein besseres Verständnis dafür, warum sich Angriffstechniken kontinuierlich weiterentwickeln und welche Bedeutung Threat Detection, Threat Intelligence und Detection Engineering für eine wirksame Cyberabwehr haben.

Warum klassische Process Injection heute immer schwieriger wird

Seit vielen Jahren gehört Process Injection zu den Standardtechniken moderner Malware. Ziel ist es, Schadcode nicht im eigenen Prozess auszuführen, sondern innerhalb eines anderen, vertrauenswürdigeren Prozesses. Dadurch wirkt die schädliche Aktivität unauffälliger und Sicherheitslösungen können den Angriff schwerer einer verdächtigen Anwendung zuordnen.

Der klassische Ablauf einer Process Injection ist dabei meist ähnlich:

1. Ein Zielprozess wird geöffnet oder neu gestartet.
2. Speicher im Zielprozess wird reserviert.
3. Der Schadcode wird in diesen Speicher geschrieben.
4. Die Speicherrechte werden angepasst, damit der Code ausgeführt werden kann.
5. Anschließend startet ein neuer Thread die Ausführung des Schadcodes.

Gerade diese Schritte hinterlassen jedoch charakteristische Spuren. Moderne EDR-Lösungen überwachen insbesondere API-Aufrufe wie WriteProcessMemory, VirtualAllocEx, NtWriteVirtualMemory oder NtAllocateVirtualMemory, da sie typische Indikatoren für Process Injection darstellen. Genau hier setzen heutige Erkennungsmechanismen an.

Die Idee hinter Process Parameter Poisoning

Daraus ergibt sich eine entscheidende Frage: Wie lässt sich Code in einen anderen Prozess übertragen, ohne die typischen APIs für Speicherallokation oder Speicherzugriffe zu verwenden?

Die Antwort liegt in einem Bereich, der beim Start jedes Windows-Prozesses ohnehin genutzt wird: den Prozessparametern.

Beim Erstellen eines neuen Prozesses über CreateProcessW übergibt Windows automatisch verschiedene Informationen an den neuen Prozess. Dazu gehören unter anderem:

• die Command Line
• Umgebungsvariablen (Environment)
• Informationen aus der STARTUPINFO-Struktur

Diese Parameter werden standardmäßig an den neuen Prozess kopiert und dort für dessen Initialisierung verwendet. Process Parameter Poisoning nutzt genau diesen regulären Mechanismus, um Daten (im beschriebenen Fall Shellcode) in den Zielprozess zu übertragen, ohne die klassischen Speicherzugriffe auszuführen, die von vielen EDR-Lösungen überwacht werden.

Der Process Environment Block (PEB) – das Herzstück der Technik

Damit Windows einen neuen Prozess korrekt starten kann, legt das Betriebssystem für jeden Prozess den sogenannten Process Environment Block (PEB) an.

Diese Datenstruktur enthält zahlreiche Informationen über den laufenden Prozess, darunter:

• geladene Module
• Laufzeitinformationen
• den Heap
• sowie sämtliche Prozessparameter.

Besonders interessant ist dabei die Struktur RTL_USER_PROCESS_PARAMETERS, in der unter anderem folgende Informationen gespeichert werden:

• CommandLine
• Environment
• ImagePathName
• ShellInfo
• weitere Startparameter.

Genau diese Bereiche eignen sich für die Übertragung von Shellcode, da ihre Inhalte beim Erstellen eines neuen Prozesses automatisch übernommen werden. Statt neuen Speicher anzulegen oder vorhandenen Speicher zu überschreiben, wird der Schadcode bereits beim Erzeugen des Prozesses als scheinbar legitimer Parameter übergeben. Erst später lokalisiert der Angreifer diese Daten in dem Zielprozess und bereitet ihre Ausführung vor.

Welche Prozessparameter eignen sich für P³?

Für die Übertragung von Daten kommen insbesondere drei Prozessparameter infrage:

Command Line

Die Befehlszeile eines Prozesses wird automatisch im PEB gespeichert. Da sie Zeichenketten aufnehmen kann, lässt sie sich grundsätzlich auch für die Übertragung größerer Datenmengen verwenden.

Environment Block

Auch Umgebungsvariablen werden beim Prozessstart vollständig übernommen. Dadurch entsteht ein weiterer legitimer Speicherbereich innerhalb des Zielprozesses.

ShellInfo

Besonders interessant ist das Feld lpReserved innerhalb der STARTUPINFO-Struktur. Obwohl Microsoft dieses Feld als "für interne Zwecke reserviert" dokumentiert, zeigen die Autoren, dass dessen Inhalt in die ShellInfo innerhalb des PEB übernommen wird und sich ebenfalls für die Übertragung von Daten nutzen lässt.

Ausblick auf Teil 2

Nachdem wir die Grundlagen von Process Parameter Poisoning kennengelernt haben, wird es im nächsten Teil technisch.

Wir zeigen Schritt für Schritt, wie ein Prozess mit manipulierten Parametern gestartet wird, wie sich die übertragenen Daten im Process Environment Block wiederfinden lassen und weshalb diese Vorgehensweise viele klassische Erkennungsmechanismen moderner EDR-Lösungen umgeht. Dabei betrachten wir auch die unterschiedlichen Injektionsvarianten sowie die Besonderheiten der Shellcode-Ausführung.