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