GhostLocker : Neutralisation d'EDR basée sur AppLocker

Introduction

Après mon article sur Fairy-Law, où j'utilisais des mitigations noyau pour désactiver les solutions Endpoint Detection & Response (EDR), diversenok a fait remarquer que les exclusions IFEO (Image File Execution Options) étaient trop invasives pour les applications tierces. Cela a conduit à une meilleure approche : exploiter le pouvoir inhérent que les administrateurs possèdent déjà via AppLocker.

Le concept a été inspiré par diversenok, qui a souligné que les administrateurs peuvent légitimement contrôler n'importe quel logiciel sur leurs systèmes. À partir de cette idée, j'ai développé une technique utilisant AppLocker comme mécanisme de contrôle natif de Windows. Cette recherche explore la mise en œuvre technique d'AppLocker pour le contrôle des EDR, la compare à WDAC et présente un outil de preuve de concept pratique.

---

AppLocker : Architecture de liste blanche d'applications

AppLocker a été introduit avec Windows 7 et amélioré dans Windows 8.1, 10 (Entreprise) et Windows Server 2012/R2/2016+. C'est un framework de liste blanche d'applications qui permet aux administrateurs de définir précisément quels exécutables, scripts ou installateurs peuvent s'exécuter pour des utilisateurs ou des groupes spécifiques.

Architecture interne (perspective Windows Internals)

Composants mode utilisateur et noyau :

AppIDSvc (Application Identity Service)

• S'exécute sous le compte LocalService
• Surveille les modifications du registre sur les chemins de stratégie AppLocker
• Traduit les définitions de règles basées sur XML en SDDL binaire (Security Descriptor Definition Language)
• Communique les mises à jour de stratégie au pilote noyau via DeviceIoControl

AppID.sys (Pilote noyau)

• Intercepte les événements de création de processus via des mécanismes de callback
• Effectue l'évaluation des règles en utilisant SeSrpAccessCheck
• Surveille optionnellement les chargements de DLL (désactivé par défaut pour des raisons de performance)

Clarification :
Bien que AppID.sys effectue l'évaluation des règles en mode noyau, l'application des règles DLL n'est pas autonome.
Le pilote noyau ne surveille pas activement les chargements de DLL par lui-même. Au lieu de cela, les composants en mode utilisateur doivent explicitement interroger le pilote via IOCTL pour déterminer si un chargement de DLL est autorisé.
Par conséquent, les règles DLL d'AppLocker agissent en réalité comme un mécanisme de protection côté client.

Types de règles et application

AppLocker prend en charge deux catégories principales de règles :

Règles d'autorisation (Allow) : autorisent explicitement l'exécution des applications définies

Règles de refus (Deny) : bloquent explicitement l'exécution des applications définies

• Les règles de refus ont toujours priorité sur les règles d'autorisation
• Peuvent inclure des exceptions pour des conditions spécifiques
• Prennent en charge le ciblage au niveau utilisateur et groupe

Critères de règles (attributs AppID) :

• Règles basées sur le chemin : C:\Program Files\Security\*.exe
• Règles basées sur le hachage : validation du hachage Authenticode SHA256
• Règles d'éditeur (Publisher) : vérification de la signature numérique, de la version, du nom du produit
• Règles d'attributs de fichier : nom de la société, version du produit, etc.

Emplacements de stockage dans le registre :

HKLM\Software\Policies\Microsoft\Windows\SrpV2     (stockage de la stratégie XML, persistant)
HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp\Exe  (format binaire SDDL, application active)
HKLM\SYSTEM\CurrentControlSet\Control\AppID\CertStore (cache de certificats)

Application sur les services et processus SYSTEM (souvent négligée)

Par défaut, AppLocker n'applique pas les règles aux services ou aux processus SYSTEM.
Il n'existe aucune option d'interface graphique pour activer ce comportement.

L'application des règles pour les services ne peut être activée que via la stratégie XML en utilisant RuleCollectionExtensions.

La section de stratégie suivante est requise pour appliquer les règles AppLocker aux services :

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

Comme l'indiquent les noms des extensions, ces options ne sont prises en charge que sur Windows 10+ et ne sont pas disponibles sur les versions antérieures. Voir Microsoft - Extensions de collection de règles AppLocker

Flux d'application :

1. Windows notifie le pilote AppID lors de la création d'un processus
2. AppID.sys évalue les attributs de l'application
3. Selon les règles AppLocker, il autorise ou bloque le processus
4. Si bloqué, la création du processus est interrompue avec STATUS_ACCESS_DISABLED_BY_POLICY_OTHER

Limitation critique :

⚠️ AppLocker ne termine PAS les processus en cours d'exécution.

L'application d'AppLocker ne concerne que les nouveaux événements de création de processus. Les processus EDR déjà en cours d'exécution continuent de s'exécuter jusqu'au redémarrage du système. C'est une contrainte architecturale fondamentale.

Réserve sur la télémétrie des pilotes noyau :

Même après avoir bloqué les exécutables EDR en espace utilisateur, les pilotes noyau (*.sys) restent actifs et opérationnels. Ces pilotes continuent :

• D'enregistrer des callbacks noyau (processus, threads, chargement d'images, registre)
• De collecter des données de télémétrie
• De surveiller les événements système

Cependant, des tests approfondis révèlent que cette télémétrie devient fonctionnellement inefficace. Sans moteurs d'analyse en espace utilisateur, systèmes de corrélation et mécanismes de rapport, les données de télémétrie brutes ne peuvent pas être transformées en détections exploitables. Les solutions EDR s'appuient fortement sur les composants en espace utilisateur pour :

• La corrélation d'événements et l'analyse comportementale
• L'inférence par apprentissage automatique
• La génération d'alertes et l'orchestration des réponses
• La communication avec les consoles de gestion

---

GhostLocker : Implémentation de preuve de concept

Présentation de l'outil

GhostLocker est une implémentation en C++ qui automatise le déploiement de stratégies AppLocker pour bloquer les exécutables EDR.

Analyse de l'implémentation technique

Variantes d'implémentation

GhostLocker propose deux variantes d'implémentation :

main.cpp – Version à énumération dynamique

Cette version énumère les processus en cours d'exécution et résout leurs chemins d'image complets en utilisant les API natives (NtQuerySystemInformation).
Les chemins absolus résolus sont ensuite utilisés pour générer des règles de refus AppLocker précises.

L'outil utilise CreateToolhelp32Snapshot avec TH32CS_SNAPPROCESS pour énumérer tous les processus en cours d'exécution. Il compare les noms de processus à une liste cible prédéfinie en utilisant une correspondance insensible à la casse (_wcsicmp).

Pourquoi cette approche ?

• Énumération légère et rapide
• Aucun privilège élevé requis pour lire la liste des processus
• La correspondance insensible à la casse gère les variations de noms

1. Énumération des processus (FindTargetsAndQueryPaths)

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

2. Résolution du chemin via NtQuerySystemInformation