Angriffstechnik: Missbrauch des UWP-Lebenszyklus und Windows-Jobobjekte
Angreifer nutzen zunehmend fortgeschrittene Methoden zur Umgehung moderner Endpoint Detection and Response (EDR)-Systeme. Eine besondere Technik besteht im gezielten Missbrauch des Anwendungslebenszyklus von Universal Windows Plattform (UWP)- Applikationen in Kombination mit Windows-Job-Objekten.
Dieser Artikel untersucht eine alternative Methode, Prozesse gezielt frühzeitig in einen angehaltenen Zustand zu versetzen, um Angriffstechniken wie Asynchronous Procedure Call (APC) Injection oder Thread Hijacking zu ermöglichen. Es ist zu beachten, dass die Technik auf undokumentierten APIs basiert und durch zukünftige Microsoft-Updates möglicherweise nicht mehr unterstützt wird.
Prozesse im eingefrorenen Zustand zu manipulieren und ihre Ausführung gezielt bis zu einer späteren Benutzerinteraktion hinauszuzögern, ist eine besonders effektive Technik. In vielen offensiven Szenarien werden Prozesse zunächst im angehaltenen Zustand erzeugt, gezielt manipuliert und erst anschließend zur Ausführung gebracht.
Zwei verbreitete Techniken, die sich dieses Vorgehen zunutze machen, sind:
- Early-Bird Injection
- Thread Hijacking
Early-Bird Injection
Bei der Early-Bird Injection wird der Zielprozess direkt im angehaltenen Zustand gestartet, indem beispielsweise die Flags CREATE_SUSPENDED oder DEBUG_PROCESS verwendet werden. Auf diese Weise erhält der Angreifer einen zeitlichen Vorsprung, um den Prozess gezielt zu manipulieren, bevor dessen reguläre Ausführung beginnt.
Thread Hijacking
Im Gegensatz zur Early-Bird Injection wird beim Thread Hijacking kein neuer Prozess gestartet. Stattdessen übernimmt der Angreifer die Kontrolle über einen bestehenden Thread innerhalb eines legitimen Prozesses. Dieser Thread wird zunächst mit SuspendThread pausiert, sodass gezielte Vorbereitungen möglich sind. Anschließend wird der Instruction Pointer durch die Windows-API SetThreadContext manipuliert. Sobald der Thread mit ResumeThread fortgesetzt wird, führt er den zuvor injizierten, manipulierten Code aus.
Was sind Universal Windows Plattform (UWP) Anwendungen?
Universal Windows Plattform (UWP) bezeichnet ein modernes Anwendungsmodell in Windows, das ursprünglich mit Windows 8 eingeführt und in Windows 10 weiterentwickelt wurde. UWP-Anwendungen, früher auch bekannt als Modern Apps, Metro Apps oder immersive Apps, basieren auf der Windows Runtime (WinRT) und folgen einem plattformübergreifenden Architekturansatz. Ziel ist es, eine Anwendung einheitlich auf verschiedenen Geräten ausführen zu können, vom Desktop-PC über Tablets und Xbox bis hin zu HoloLens und IoT-Systemen.
Eine zentrale Eigenschaft von UWP-Apps ist ihre starke Isolierung innerhalb einer sogenannten AppContainer-Sandbox. Technisch betrachtet greifen UWP-Anwendungen auf ein Subset von COM, Win32 und moderne WinRT-APIs zu. Die Ausführung erfolgt unter strikten Richtlinien, insbesondere im Hinblick auf Ressourcenverbrauch und Lebenszyklusmanagement. Eine UWP-Anwendung wird beispielsweise automatisch in einen angehaltenen Zustand versetzt, wenn sie im Hintergrund keine aktive Rolle spielt, ein Mechanismus, der ursprünglich zur Energieeinsparung entwickelt wurde.
Jede UWP-Anwendung ist durch eine eindeutige Paketidentität gekennzeichnet, die sich aus Komponenten wie Name, Version, Architektur und Herausgeber zusammensetzt. Kurz gesagt handelt es sich bei UWP-Anwendungen um ein standardisiertes App-Modell von Microsoft mit Fokus auf Sicherheit, deklarativer Struktur und geräteübergreifender Ausführung.
Prozesslebenszyklus von UWP-Anwendungen und deren Bedeutung für Angreifer
UWP-Applikationen folgen einem klar definierten Lebenszyklus, der dem ressourcensparenden App-Modell mobiler Betriebssysteme nachempfunden ist.
Nach dem Start durchlaufen solche Anwendungen üblicherweise vier Zustände:
- Running
- Suspending
- SuspendComplete
- Suspended
Diese Suspendierung erfolgt entweder automatisch durch das System oder gezielt über APIs, wie beispielsweise NtSetInformationJobObject, welche intern die Klasse JobObjectFreezeInformation verwendet.
Wird ein Prozess einem sogenannten Job-Objekt zugewiesen, so können alle in diesem Objekt enthaltenen Prozesse gemeinsam gesteuert und eingefroren werden. Diese Mechanik ist in legitimen Szenarien zur Ressourcenverwaltung gedacht, bietet jedoch in diesem Kontext neue Angrifsvektoren.
Jobobjekte
Job-Objekte sind Windows-interne Kernelobjekte, die zur Gruppierung und kollektiven Steuerung von Prozessen dienen. Sie ermöglichen es, Richtlinien wie Arbeitssatzgrößen, Prioritäten oder Laufzeitbeschränkungen auf eine ganze Gruppe von Prozessen gleichzeitig anzuwenden.
Für die hier beschriebene Angriffstechnik ist insbesondere die Fähigkeit interessant, über NtSetInformationJobObject alle zugeordneten Prozesse gleichzeitig einzufrieren, wodurch sich eine Art kontrolliertes „Einfrieren der Umgebung“ realisieren lässt. In Kombination mit UWP-Anwendungen, die bereits standardmäßig mit Suspend-/Resume-Mechanismen arbeiten, entsteht ein Szenario, das sich besonders effektiv für Injection-Techniken wie Early-Bird-Injection nutzen lässt.
Ein Proof-of-Concept wurde von Zero2504 unter dem Titel "Early Cryo Bird Injection" vorgestellt. In diesem Ablauf wird zunächst ein Jobobjekt erstellt und mithilfe der entsprechenden Information Class über die NtAPI in den eingefrorenen Zustand versetzt. Anschließend wird ein neuer Prozess erzeugt, bei dessen Erstellung über erweiterte STARTUPINFOEX-Strukturen ein Handle auf das zuvor erstellte Jobobjekt mitgegeben wird. Der so gestartete Prozess ist dadurch automatisch Teil des eingefrorenen Jobs und verbleibt zunächst vollständig inaktiv. In diesem Zustand kann gezielt Speicher innerhalb des Prozesses alloziert, Schadcode injiziert und der Prozess anschließend durch ein kontrolliertes Auftauen zur Ausführung gebracht werden.
Steuerung eingefrorener Prozesse mittels nativer NtAPI
Die zentrale Grundlage für die gezielte Steuerung von Prozessen im Kontext dieser Angriffstechnik bildet die Nutzung nativer Windows-Kernel-APIs, den sogenannten NtAPIs. Im Vordergrund stehen dabei drei Funktionen, die für das gezielte Einfrieren oder Reaktivieren von Prozessen über sogenannte Jobobjekte genutzt werden können:
NtSetInformationJobObject
Diese Funktion erlaubt es, über die Information-Class JobObjectFreezeInformation ein bestehendes Jobobjekt samt aller zugehörigen Prozesse gezielt in den Suspended-Zustand zu versetzen. Das System friert dabei die gesamte Prozessgruppe ein, wodurch alle darin enthaltenen Threads vollständig gestoppt werden.
PsFreezeProcess / PsThawProcess
Mit Windows 10 (und fortgeführt in Windows 11) wurde zusätzlich eine weitere Steuerung auf Kernel-Ebene eingeführt: Die Funktionen PsFreezeProcess und PsThawProcess ermöglichen es, Prozesse unabhängig vom Resume-Zustand auf Thread-Ebene einzufrieren und wieder aufzutauen. Besonders wichtig ist hierbei die Einführung eines sogenannten Freeze-Counters. Ein Prozess kann mehrmals hintereinander eingefroren werden, jedoch wird er erst dann wieder zur Ausführung freigegeben, wenn die Anzahl der entsprechenden Thaw-Aufrufe die Anzahl der Freeze-Aufrufe vollständig ausgleicht.
Ein weiterer sicherheitsrelevanter Effekt ist, dass ein neu erstellter Thread auch dann nicht automatisch ausgeführt wird, wenn NtResumeProcess aufgerufen wird, sofern sich der zugehörige Prozess noch in einem gefrorenen Zustand befindet. Dadurch wird es Angreifern möglich, präparierte Prozesse gezielt "in der Warteschleife" zu halten, bis ein geeigneter Auslösezeitpunkt erreicht ist, beispielsweise durch Benutzerinteraktion mit einer UWP-Oberfläche (SearchApp.exe).
JOBOBJECT_FREEZE_INFORMATION – Struktur:
Detektion eingefrorener Prozesse mit Windows-internen Strukturen
Ein wichtiger Bestandteil zur Erkennung des aktuellen Zustands eines Prozesses ist die Struktur PROCESS_EXTENDED_BASIC_INFORMATION. Diese Struktur enthält erweiterte Informationen zum Status eines Prozesses und geht über die üblichen Basisinformationen hinaus.
Relevant für unsere Analyse ist insbesondere das IsFrozen-Bit innerhalb des Flags-Feldes dieser Struktur. Dieses Bit signalisiert eindeutig, ob sich ein Prozess aktuell im eingefrorenen Zustand befindet. Der folgende Beispielcode demonstriert die Abfrage dieses Status.
Diese API bietet Angreifern die Möglichkeit, gezielt nach Prozessen zu suchen, die sich bereits im eingefrorenen Zustand befinden.
UWP-Systemprozesse als Initialpunkt: Missbrauch von SearchApp.exe und SystemSettings.exe
Ein besonders interessanter Aspekt dieser Angriffsmethodik ist die Möglichkeit, existierende UWP-Systemprozesse wie SearchApp.exe (Windows 10), SearchHost.exe (Windows 11) oder SystemSettings.exe zu instrumentalisieren. Diese Prozesse laufen auf nahezu jedem Windows System und sind standardmäßig Teil des Boot-Vorgangs, verbleiben jedoch zumeist im eingefrorenen Zustand, bis eine Benutzerinteraktion erfolgt.
Der Angreifer kann diese Gegebenheit ausnutzen, indem ein neu zu startender Prozess explizit in dasselbe Jobobjekt wie der Zielprozess eingefügt wird. Sobald der Benutzer beispielsweise das Startmenü öffnet oder die Systemeinstellungen aufruft, wird das Jobobjekt automatisch vom Betriebssystem aufgetaut. Dadurch werden auch alle anderen Prozesse innerhalb dieses Jobobjekts inklusive des vom Angreifer manipulierten Prozesses zur Ausführung gebracht.
Noch effektiver wird diese Technik im Fall von SystemSettings.exe. Anders als die zuvor genannten Prozesse ist SystemSettings.exe kein AppContainer-Prozess und besitzt daher weniger Einschränkungen hinsichtlich Ressourcen- und API-Zugriff. In durchgeführten Tests wurde beobachtet, dass der Prozess zwar in suspendiertem Zustand vorliegt, aber anschließend mittels ShellExecute-Aufruf durch den Benutzer reaktiviert wird.
API-Call Workflow
Hier werden konkret alle wichtigen Schritte nochmal aufgezählt und in einer Grafik verdeutlicht.
- Erstellung eines neuen Jobs
- UWP-Zielprozess dem neuen Job zuweisen
- Prüfen, ob der UWP-Prozess eingeforen ist
- Innerhalb desselben Jobs einen neuen Prozess erzeugen
- Speicher im Zielprozess reservieren
- DLL-Pfad oder Shellcode im reservierten Speicher ablegen
- Einreihen eines asynchronen Prozeduraufrufs (APC), Thread-Hijacking oder Erzeugen eines neuen Threads
- Injektion durch Benutzerinteraktion oder über die ShellExecute-API aktivieren
Proof of Concept im Video
Fazit
Wir haben die gängigen Top-Tier-EDR-Lösungen gegen diese Technik getestet und festgestellt, dass die meisten von ihnen diese Angriffsmethode nicht erkennen konnten. Eine Ausnahme bildet eine der führenden Plattformen, die den Angriff über die Regel „Hollowing_Inject“ identifizieren konnte.
Unsere eigenen Detection-Regeln sind so konzipiert, dass sie auch Anzeichen dieser Technik zuverlässig erfassen. Zwar existieren aktuell keine eindeutigen Sysmon-Events für Job-Objekte, doch deckt unser Regelwerk ein breites Spektrum an Indikatoren ab. Damit sind wir in der Lage, auch solche komplexen Angriffe zuverlässig zu erkennen.
Diese Technik zeigt, wie Angreifer komplexe Vorgehensweisen nutzen können, um altbewährte Methoden auf neue Art einzusetzen, wie in diesem Blogbeitrag demonstriert.
Referenzen
[1] Russinovich, M. E., Solomon, D. A. & Ionescu, A. (2016). Windows Internals, Part 1 & 2 (7. Aufl.). Microsoft Press.
[2] Zero2504. (2024). Early-Cryo-Bird-Injections [GitHub-Repository].
https://github.com/zero2504/Early-Cryo-Bird-Injections
[3] ntdoc.m417z.com. Windows Native API Documentation.
https://ntdoc.m417z.com/
[4] Microsoft Docs. Job Objects.
https://learn.microsoft.com/en-us/windows/win32/procthread/job-objects
[5] iRED Team. Early-Bird (APC-Queue) Code Injection.
https://www.ired.team/offensive-security/code-injection-process-injection/early-bird-apc-queue-code-injection
[6] iRED Team. Injecting to Remote Process via Thread Hijacking.
https://www.ired.team/offensive-security/code-injection-process-injection/injecting-to-remote-process-via-thread-hijacking