GhostLocker: Neutralisierung von EDR-Lösungen mittels AppLocker

Einleitung

Nach meinem Artikel über Fairy-Law, in dem ich Kernel-Mitigationen einsetzte, um Endpoint Detection & Response (EDR)-Lösungen zu deaktivieren, wies diversenok darauf hin, dass IFEO-Ausschlüsse (Image File Execution Options) für Drittanbieteranwendungen zu invasiv seien. Dies führte zu einem besseren Ansatz: der Nutzung der inhärenten Rechte, die Administratoren bereits durch AppLocker besitzen.

Das Konzept wurde von diversenok inspiriert, der hervorhob, dass Administratoren legitimerweise jede Software auf ihren Systemen kontrollieren können. Aus dieser Erkenntnis entwickelte ich eine Technik, die AppLocker als nativen Windows-Kontrollmechanismus einsetzt. Diese Forschung untersucht die technische Implementierung von AppLocker zur EDR-Kontrolle, vergleicht sie mit WDAC und stellt ein praktisches Proof-of-Concept-Tool vor.

AppLocker: Architektur der Anwendungs-Whitelisting

AppLocker wurde mit Windows 7 eingeführt und in Windows 8.1, 10 (Enterprise) sowie Windows Server 2012/R2/2016+ erweitert. Es handelt sich um ein Anwendungs-Whitelisting-Framework, das es Administratoren ermöglicht, präzise festzulegen, welche ausführbaren Dateien, Skripte oder Installationsprogramme für bestimmte Benutzer oder Gruppen ausgeführt werden dürfen.

Interne Architektur (Windows-Internals-Perspektive)

User-Mode- und Kernel-Komponenten:

AppIDSvc (Application Identity Service)

• Läuft unter dem Konto LocalService
• Überwacht Registrierungsänderungen an AppLocker-Richtlinienpfaden
• Übersetzt XML-basierte Regeldefinitionen in binäre SDDL (Security Descriptor Definition Language)
• Kommuniziert Richtlinienaktualisierungen über DeviceIoControl an den Kernel-Treiber

AppID.sys (Kernel-Treiber)

• Fängt Prozesserstellungsereignisse über Callback-Mechanismen ab
• Führt die Regelauswertung mit SeSrpAccessCheck durch
• Überwacht optional DLL-Ladevorgänge (standardmäßig aus Leistungsgründen deaktiviert)

Klarstellung:
Während AppID.sys die Regelauswertung im Kernel-Modus durchführt, ist die DLL-Durchsetzung nicht autonom.
Der Kernel-Treiber überwacht DLL-Ladevorgänge nicht aktiv selbst. Stattdessen müssen User-Mode-Komponenten den Treiber explizit per IOCTL abfragen, um festzustellen, ob ein DLL-Ladevorgang erlaubt ist.
Infolgedessen fungieren AppLocker-DLL-Regeln effektiv als clientseitiger Schutzmechanismus.

Regeltypen und Durchsetzung

AppLocker unterstützt zwei primäre Regelkategorien:

Allow-Regeln (Zulassen): Erlauben explizit die Ausführung definierter Anwendungen

Deny-Regeln (Verweigern): Blockieren explizit die Ausführung definierter Anwendungen

• Deny-Regeln haben immer Vorrang vor Allow-Regeln
• Können Ausnahmen für bestimmte Bedingungen enthalten
• Unterstützen die Zielausrichtung auf Benutzer- und Gruppenebene

Regelkriterien (AppID-Attribute):

• Pfadbasierte Regeln: C:\Program Files\Security\*.exe
• Hash-basierte Regeln: SHA256-Authenticode-Hash-Validierung
• Herausgeberregeln: Überprüfung von digitaler Signatur, Version und Produktname
• Dateiattributregeln: Firmenname, Produktversion usw.

Registrierungsspeicherorte:

HKLM\Software\Policies\Microsoft\Windows\SrpV2     (XML-Richtlinienspeicher, persistent)
HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp\Exe  (SDDL-Binärformat, aktive Durchsetzung)
HKLM\SYSTEM\CurrentControlSet\Control\AppID\CertStore (Zertifikatscache)

Durchsetzung bei Diensten & SYSTEM-Prozessen (häufig übersehen)

Standardmäßig setzt AppLocker Regeln nicht bei Diensten oder SYSTEM-Prozessen durch.
Es gibt keine grafische Benutzeroberflächenoption, um dieses Verhalten zu aktivieren.

Die Durchsetzung für Dienste kann nur über die XML-Richtlinie mit RuleCollectionExtensions aktiviert werden.

Der folgende Richtlinienabschnitt ist erforderlich, um AppLocker-Regeln für Dienste durchzusetzen:

<RuleCollectionExtensions>
  <ThresholdExtensions>
    <Services EnforcementMode="Enabled"/>
  </ThresholdExtensions>
  <RedstoneExtensions>
    <SystemApps Allow="Enabled"/>
  </RedstoneExtensions>
</RuleCollectionExtensions>

Wie die Namen der Erweiterungen andeuten, werden diese Optionen nur unter Windows 10+ unterstützt und sind in früheren Versionen nicht verfügbar. Siehe Microsoft – AppLocker-Regelsammlungserweiterungen

Ablauf der Durchsetzung:

1. Windows benachrichtigt den AppID-Treiber bei der Prozesserstellung
2. AppID.sys wertet die Anwendungsattribute aus
3. Basierend auf den AppLocker-Regeln wird der Prozess zugelassen oder blockiert
4. Bei Blockierung wird die Prozesserstellung mit STATUS_ACCESS_DISABLED_BY_POLICY_OTHER abgebrochen

Kritische Einschränkung:

⚠️ AppLocker beendet keine laufenden Prozesse.

Die Durchsetzung von AppLocker gilt nur für neue Prozesserstellungsereignisse. Bereits laufende EDR-Prozesse werden bis zum Neustart des Systems weiter ausgeführt. Dies ist eine grundlegende architektonische Einschränkung.

Hinweis zur Telemetrie des Kernel-Treibers:

Selbst nach der Blockierung von EDR-Userland-Executables bleiben Kernel-Treiber (*.sys) aktiv und funktionsfähig. Diese Treiber:

• Registrieren weiterhin Kernel-Callbacks (Prozess, Thread, Imageload, Registrierung)
• Sammeln weiterhin Telemetriedaten
• Überwachen weiterhin Systemereignisse

Umfangreiche Tests zeigen jedoch, dass diese Telemetrie funktional wirkungslos wird. Ohne Userland-Analyse-Engines, Korrelationssysteme und Meldemechanismen können die rohen Telemetriedaten nicht zu verwertbaren Erkennungen verarbeitet werden. EDR-Lösungen sind stark von Userland-Komponenten abhängig für:

• Ereigniskorrelation und verhaltensbasierte Analyse
• Machine-Learning-Inferenz
• Alert-Erzeugung und Reaktionsorchestrierung
• Kommunikation mit Verwaltungskonsolen

GhostLocker: Proof-of-Concept-Implementierung

Tool-Überblick

GhostLocker ist eine C++-Implementierung, die die Bereitstellung von AppLocker-Richtlinien automatisiert, um EDR-Executables zu blockieren.

Analyse der technischen Implementierung

Implementierungsvarianten

GhostLocker bietet zwei Implementierungsvarianten:

main.cpp – Dynamische Aufzählungsversion

Diese Version zählt laufende Prozesse auf und ermittelt ihre vollständigen Image-Pfade mithilfe nativer APIs (NtQuerySystemInformation).
Die aufgelösten absoluten Pfade werden dann verwendet, um präzise AppLocker-Deny-Regeln zu generieren.

Das Tool verwendet CreateToolhelp32Snapshot mit TH32CS_SNAPPROCESS, um alle laufenden Prozesse aufzuzählen. Es vergleicht Prozessnamen mithilfe von case-insensitive Matching (_wcsicmp) mit einer vordefinierten Zielliste.

Warum dieser Ansatz?

• Leichte und schnelle Aufzählung
• Keine erweiterten Rechte zum Lesen der Prozessliste erforderlich
• Case-insensitive Matching behandelt Namensvariationen

1. Prozessaufzählung (FindTargetsAndQueryPaths)

const wchar_t* targetNames[] = {
    L"MpDefenderCoreService.exe",
    L"MsMpEng.exe",
    L"WinDefend.exe",
    L"EDR_Component_Name.exe",
};

2. Pfadauflösung über NtQuerySystemInformation

SYSTEM_PROCESS_ID_INFORMATION spi = { 0 };
spi.ProcessId = PID;
spi.ImageName.MaximumLength = 1024;
spi.ImageName.Buffer = (PWSTR)allocBuffer;

status = NtQuerySystemInformation(
    SystemProcessIdInformation,
    &spi,
    sizeof(spi),
    0
);

Technische Details:

• Verwendet die undokumentierte Informationsklasse SystemProcessIdInformation (0x58)
• Gibt das NT-Gerätepfadformat zurück: \Device\HarddiskVolume3\Windows\System32\...
• Erfordert die Konvertierung in das Win32-Pfadformat für die AppLocker-Kompatibilität

Pfadkonvertierungslogik:

std::wstring ForceHarddiskVolumeToC(const std::wstring& ntPath)
{
    const std::wstring prefix = L"\\Device\\HarddiskVolume3\\";
    if (ntPath.rfind(prefix, 0) == 0)
    {
        std::wstring rest = ntPath.substr(prefix.length());
        return L"C:\\" + rest;
    }
    return ntPath;
}

Einschränkung: Feste Annahme von HarddiskVolume3. Sollte verbessert werden, um die Volumennummern dynamisch aufzulösen.

3. Generierung der PowerShell-Richtlinie

Das Tool enthält ein vollständiges PowerShell-Skript, das:

a) Zielpfade validiert

foreach ($exe in $ExeToBlock) {
    if (!(Test-Path $exe)) {
        Write-Host '[!] ERROR: File does not exist:' $exe -ForegroundColor Red
        exit 1
    }
}

b) Dynamische Deny-Regeln generiert

foreach ($exe in $ExeToBlock) {
    $id   = [guid]::NewGuid().ToString()
    $name = Split-Path $exe -Leaf
    
    $dynamicBlockRules += '<FilePathRule Id="' + $id + '" Name="Block ' + $name + 
                          '" Description="Blocked by policy" UserOrGroupSid="S-1-1-0" Action="Deny">'
    $dynamicBlockRules += '<Conditions><FilePathCondition Path="' + $exe + '" /></Conditions>'
    $dynamicBlockRules += '</FilePathRule>'
}

Wichtige Richtlinienelemente:

• UserOrGroupSid="S-1-1-0": Gilt für Jeder (alle Benutzer)
• Action="Deny": Explizite Blockierregel
• EnforcementMode="Enabled": Aktive Durchsetzung für EXE-Regeln
• Deny-Regeln werden vor den Fallback-Allow-Regeln eingefügt (Vorrang)

c) Anwendung der Richtlinie

Set-AppLockerPolicy -XmlPolicy $tempPath -ErrorAction Stop
gpupdate /force | Out-Null

4. Base64-Kodierung und Ausführung

void RunPowerShellInMemory()
{
    std::wstring script = BuildFullPowerShellScript();
    const BYTE* bytes = reinterpret_cast<const BYTE*>(script.c_str());
    size_t byteLen = script.size() * sizeof(wchar_t);
    
    std::wstring encoded = Base64Encode(bytes, byteLen);
    std::wstring params = L"-NoProfile -ExecutionPolicy Bypass -EncodedCommand ";
    params += encoded;
    
    ShellExecuteW(NULL, L"runas", L"powershell.exe", params.c_str(), NULL, SW_SHOW);
}

Technische Begründung:

• UTF-16LE-Kodierung: PowerShell -EncodedCommand erwartet UTF-16LE
• Base64-Kodierung: Umgeht Zeicheneinschränkungen der Befehlszeile
• -ExecutionPolicy Bypass: Ignoriert die Skriptausführungsrichtlinie
• runas-Verb: Löst die UAC-Erhöhung für Administratorrechte aus

main_improved.cpp – Statische Wildcard-basierte Version

Nach der Klarstellung durch diversenok wurde deutlich, dass AppLocker-Pfadregeln Wildcard-Matching unterstützen und keine vollständigen ausführbaren Pfade erfordern.

Diese verbesserte Version entfernt die gesamte Prozessaufzählung und native Pfadauflösungslogik und verlässt sich stattdessen auf statische Wildcard-Regeln wie: *\MsMpEng.exe

Anforderungen

⚠️ Voraussetzungen für eine erfolgreiche Bereitstellung:

• Muss aus einem erhöhten (Administrator-)Kontext ausgeführt werden
• Der AppIDSvc-Dienst muss ausgeführt werden: sc start AppIDSvc
• Nach der Bereitstellung ist ein Systemneustart für die vollständige Wirksamkeit erforderlich
• Die Ziel-EDR-Prozesse müssen während der Aufzählungsphase ausgeführt werden

Forschungsergebnisse: Tests mit echten EDR-Lösungen

Testmethodik

Es wurden umfangreiche kontrollierte Tests mit mehreren kommerziellen EDR-Lösungen durchgeführt, um die Wirksamkeit zu bewerten.

Testumgebung:

• Windows 11 (25H2)
• Mehrere kommerzielle EDR-Produkte (Namen nicht genannt)
• Basis-Erkennung: einfache Prozessinjektionstechniken
• Vorab-Überprüfung: bestätigte EDR-Erkennungsfähigkeiten

Zentrale Ergebnisse

Erkennungsfähigkeiten nach der Blockierung

Versagen der Verhaltensanalyse:

• Alle getesteten EDR-Lösungen erzeugten nach der AppLocker-Blockierung keine Alerts
• Zuvor erkannte einfache Injektionen blieben unerkannt
• Für verdächtige Aktivitäten wurden keine verhaltensbasierten Erkennungen ausgelöst

Perspektive der Verwaltungskonsole:

• Agents meldeten weiterhin den Status "online" und "geschützt"
• Zeitstempel der letzten Verbindung wurden normal aktualisiert
• Kein Hinweis auf eine Kompromittierung über die Verwaltungsoberfläche

Telemetrieanalyse des Kernel-Treibers

Obwohl die Kernel-Treiber weiterhin liefen und Telemetriedatenströme sammelten, machte das Fehlen von Userland-Verarbeitungskomponenten die gesammelten Daten wirkungslos.

Was weiterhin funktioniert:

• Kernel-Callbacks feuern normal (Prozess, Thread, Imageload, Registrierung usw.)
• Die Erfassung roher Telemetriedaten bleibt bestehen
• Die Kommunikation zwischen Treibern kann funktionieren

Kritische Erkenntnis:

Die moderne EDR-Architektur stützt sich auf eine enge Kopplung zwischen Kernel-Treibern und Userland-Analyse-Engines. Das Aufbrechen dieser Kopplung blendet die EDR-Lösung trotz fortgesetzter Telemetrieerfassung effektiv aus.

Screenshot (Aufzählen und Anwenden der AppLocker-Richtlinie):

Screenshot (Deaktiviertes WinDefend):

Screenshot von Version 2

Vergleich: WDAC vs. AppLocker

Was ist WDAC?

Windows Defender Application Control (WDAC) wurde in Windows 10 eingeführt und stellt Microsofts modernes Anwendungssteuerungs-Framework dar.
Es setzt Richtlinien sowohl für User-Mode- als auch für Kernel-Mode-Binaries durch.

WDAC-Architektur:

Kerneigenschaften:

• Systemweite Durchsetzung (alle Benutzer, alle Sitzungen)
• Durchsetzung vor dem Boot
• Default-Deny-Modell
• Code-Integrity-Richtlinien-Engine (CI)
• Durchsetzung der Treibersignierung im Kernel

WDAC-Richtlinienspeicher:

C:\Windows\System32\CodeIntegrity\SIPolicy.p7b    (Aktive Richtlinie, signiert)
C:\Windows\System32\CodeIntegrity\CIPolicies\     (Mehrere Richtlinien)
EFI-Systempartition (UEFI-Durchsetzung)

WDAC als Angriffsvektor: Krueger

Krueger demonstrierte den WDAC-Missbrauch zur Blockierung von EDR-Treibern:

Hauptunterschied:

• WDAC blockiert beim Ladezeitpunkt des Treibers (Kernel)
• AppLocker blockiert beim Zeitpunkt der Prozesserstellung (Userland)

Detaillierte Vergleichsmatrix

Praktische Angriffsüberlegungen

Wann AppLocker verwenden (GhostLocker):

• Ziel ist nur die Blockierung von Userland-Prozessen
• Die Kernel-Treibertelemetrie soll erhalten bleiben (weniger verdächtig)
• Benutzerbezogene Richtlinien für gezielte Blockierung erforderlich

Wann WDAC verwenden (Krueger-Stil):

• Vollständige Blockierung auf Treiberebene erforderlich
• Ziel hat keine WDAC-Durchsetzung

Erkennungs- und Präventionshinweise

1. Bewertung der Richtlinie vor der Ausführung

Windows stellt die API Get-AppLockerFileInformation bereit, mit der getestet werden kann, ob eine bestimmte ausführbare Datei unter der aktuellen AppLocker-Richtlinie blockiert würde.

Eine EDR-Lösung kann diesen Mechanismus nutzen, um proaktiv zu prüfen, ob ihre eigenen Binaries oder Dienste nach einer Richtlinienänderung an der Ausführung gehindert würden.
Wenn eine Kernkomponente von "erlaubt" auf "verweigert" wechselt, sollte dies als Manipulationsbedingung mit hoher Konfidenz behandelt werden.

2. Überwachung von AppLocker-Richtlinienänderungen

AppLocker-Richtlinienaktualisierungen werden über explizite IOCTL-Aufrufe aus dem User-Mode an AppID.sys kommuniziert.
Dies bietet einen klaren Signalspfad, der anzeigt, dass sich der Durchsetzungsstatus geändert hat.

Kernel-Treiber können diese Benachrichtigungen beobachten und mit anschließenden Ausführungsfehlern geschützter Dienste korrelieren, wodurch eine genaue Erkennung richtlinienbasierter Neutralisierung ermöglicht wird.

3. Persistenz- und Neustart-Korrelation

AppLocker-Richtlinien bleiben über Neustarts hinweg an genau definierten Registrierungsspeicherorten bestehen.
EDR-Lösungen können den relevanten Richtlinienzustand vor dem Neustart als Snapshot erfassen und nach dem Systemstart die Konsistenz der Durchsetzung überprüfen.

Eine Diskrepanz zwischen dem erwarteten Ausführungszustand und der Durchsetzung nach dem Neustart deutet stark auf eine absichtliche Richtlinienmanipulation hin.

4. Integrierte Ausschlussmechanismen

Windows enthält native Mechanismen zum Ausschließen von Prozessen von der SRP-/AppLocker-Durchsetzung.
Von Sicherheitsprodukten wird erwartet, dass sie sich in diese Mechanismen integrieren, um die betriebliche Kontinuität zu gewährleisten.

Die Nichtberücksichtigung dieser Ausschlüsse ist keine Einschränkung von AppLocker, sondern vielmehr ein architektonisches Versehen im geschützten Produkt.

Zusammenfassung

Keine dieser Erkennungsstrategien erfordert die Umgehung von AppLocker oder die Verletzung von Windows-Sicherheitsgrenzen.
Sie stützen sich ausschließlich auf dokumentiertes Verhalten und Schnittstellen, die bereits vom Betriebssystem bereitgestellt werden.

Fazit

GhostLocker demonstriert, dass AppLocker, ein legitimes Windows-Sicherheitsfeature, zur Neutralisierung von EDR-Lösungen durch Userland-Prozessblockierung bewaffnet werden kann.
Diese Forschung hebt grundlegende architektonische Schwachstellen aktueller EDR-Designs hervor, die die Erfassung von Kernel-Telemetrie eng mit Userland-Analyse-Engines koppeln.

Zentrale Erkenntnisse:

1. Wirksamkeit von AppLocker: Blockiert erfolgreich EDR-Userland-Prozesse mehrerer Anbieter
2. Architektonische Schwachstelle: Kernel-Treiber laufen weiter, werden aber ohne Userland-Verarbeitung funktional blind
3. Erkennungsblindheit: Getestete EDR-Lösungen zeigten nach der Blockierung ein vollständiges Versagen der Erkennung
4. Täuschung der Verwaltungskonsole: Agents erscheinen trotz Kompromittierung als "online" und "geschützt"
5. Systemnative Technik: Verwendet legitime Windows-Funktionen

Für eine zukünftige C#-Implementierung:

• Reine .NET-Ausführung im Speicher (bessere OPSEC)
• Direkte API-Nutzung ohne PowerShell-Abhängigkeiten

Haftungsausschluss

Diese Forschung dient ausschließlich Bildungs- und Defensiv-Sicherheitszwecken.
Die beschriebenen Techniken sollten nur in autorisierten Testumgebungen mit ausdrücklicher Genehmigung verwendet werden.

Referenzen & weiterführende Literatur

• Windows Internals, Part 1 & 2 (7th Edition)
• AppLocker Technical Reference
• WDAC Design Guide
• Krueger: WDAC Abuse Tool

Beiträge aus der Community willkommen

Wenn Sie daran interessiert sind, zu GhostLocker beizutragen, insbesondere zur C#-Implementierung, sind Sie herzlich willkommen.