AppLocker et WDAC¶

1. Pourquoi le contrôle applicatif est une des mesures les plus efficaces¶

Un antivirus détecte. Un EDR corrèle. Le contrôle applicatif, lui, retire à l'attaquant la permission d'exécuter son propre code.

Dans beaucoup d'incidents Windows, la chaîne d'attaque passe par une étape simple : un fichier arrive sur le poste, est déposé dans un emplacement inscriptible par l'utilisateur, puis un processus autorisé l'exécute.

Si cette exécution est refusée, plusieurs familles d'attaque échouent plus tôt : payloads téléchargés, scripts opportunistes, loaders copiés dans %TEMP%, installateurs MSI détournés, et binaires non approuvés lancés hors des répertoires de confiance.

Le gain défensif est élevé parce que la mesure agit avant l'élévation de privilèges ou avant la persistance. Elle coupe la capacité d'exécution, pas seulement la détection a posteriori.

Le contrôle applicatif est particulièrement rentable contre :

• les malwares distribués par phishing ou téléchargement manuel ;
• les scripts .ps1, .js, .vbs, .cmd, .bat déposés dans le profil utilisateur ;
• les binaires portables exécutés depuis %APPDATA%, %LOCALAPPDATA%, %TEMP% ou Downloads ;
• certaines chaînes Living-off-the-Land où un binaire légitime tente de lancer un contenu non approuvé.

Il ne remplace pas Defender, ASR, Credential Guard ou un EDR. Il change la question. On ne demande plus "est-ce malveillant ?", mais "est-ce explicitement autorisé ?".

Cette bascule de logique est puissante dans un environnement d'entreprise. Elle favorise les logiciels signés, inventoriés, déployés et maintenus par l'organisation. Elle pénalise les exécutions opportunistes et les écarts hors processus.

2. AppLocker¶

AppLocker est le mécanisme de contrôle applicatif historique de Windows côté poste et serveur. Il reste utile pour un durcissement progressif, surtout si vous voulez commencer vite avec des règles compréhensibles et lisibles dans une GPO.

Microsoft le positionne comme une mesure de défense en profondeur, pas comme le mécanisme le plus robuste pour empêcher l'exécution de code. Cette nuance est importante pour le comparer à WDAC.

2.1 Ce qu'AppLocker contrôle¶

AppLocker structure sa politique par collections de règles. Chaque collection cible une famille d'objets précise.

La couverture est large côté espace utilisateur. En revanche, AppLocker n'est pas un moteur d'intégrité de code noyau. Il ne remplace pas la logique Code Integrity de WDAC.

2.2 Modes : Audit vs Enforce¶

AppLocker supporte deux usages opérationnels essentiels : l'observation et l'application. En pratique, il faut toujours commencer par l'observation.

Le mode Audit only est utile pour identifier :

• les scripts internes encore lancés depuis des répertoires utilisateurs ;
• les installateurs techniques exécutés depuis des partages ou des profils ;
• les outils de support utilisés localement hors catalogue ;
• les mises à jour éditeur qui changent de chemin ou de signature.

Une erreur fréquente consiste à interpréter un pilote "calme" comme un pilote prêt. Si la collecte d'événements n'est pas centralisée, l'absence de bruit peut simplement signifier l'absence de visibilité.

2.3 Types de règles : éditeur, chemin, hash¶

AppLocker propose trois conditions principales pour identifier ce qui est autorisé ou refusé. Le bon choix dépend du niveau de stabilité du logiciel.

Les règles Publisher sont généralement le meilleur compromis. Elles tolèrent les mises à jour si vous utilisez correctement les bornes de version. Elles réduisent aussi le volume d'administration.

Les règles Path sont adaptées aux répertoires strictement maîtrisés, comme %WINDIR% ou %PROGRAMFILES%. Elles ne doivent pas servir à autoriser des zones modifiables par l'utilisateur.

Les règles Hash conviennent aux outils rares, non signés et stables. Elles deviennent coûteuses si l'application se met à jour fréquemment.

2.4 Déploiement via GPO¶

Le chemin GPO AppLocker est le suivant :

Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > AppLocker

Dans beaucoup de documentations internes, le nœud Policies est omis à l'écrit. Dans l'éditeur GPO, il apparaît bien dans l'arborescence.

Le point d'entrée pratique est gpmc.msc. Ouvrez-le via Win + R, puis éditez la GPO ciblée.

Un déploiement propre isole AppLocker dans une GPO dédiée. Évitez de le mélanger avec des dizaines d'autres paramètres. La lecture, le dépannage et le rollback seront plus simples.

2.5 Journaux utiles¶

Pour observer AppLocker, ouvrez eventvwr.msc via Win + R. Les journaux se trouvent sous : Applications and Services Logs > Microsoft > Windows > AppLocker

Vous y trouverez plusieurs sous-journaux selon la collection :

• EXE and DLL ;
• MSI and Script ;
• Packaged app-Deployment ;
• Packaged app-Execution .

Ce sont les premiers journaux à regarder en phase d'audit. Ils montrent ce qui aurait été bloqué, et donc ce qui doit être autorisé explicitement ou déplacé.

2.6 Limitation majeure : éditions Windows¶

Le point de vigilance historique sur AppLocker est son support par édition. Pendant longtemps, l'application via GPO concernait surtout Windows Enterprise, Education et les éditions Server.

Cette règle empirique reste utile si votre parc contient des builds anciens. Elle évite de supposer à tort une application homogène partout.

Il existe toutefois une nuance importante : Microsoft indique qu'à partir de Windows 10 2004 avec KB5024351 et sur toutes les versions Windows 11, une édition spécifique n'est plus requise pour enforcer AppLocker.

En pratique, la bonne formulation est donc la suivante :

• pour un parc hétérogène ou ancien, traitez AppLocker comme un contrôle historiquement lié à Enterprise/Education/Server ;
• pour un parc récent homogène Windows 10 2004+ corrigé ou Windows 11, vérifiez la matrice de support réelle avant d'écarter AppLocker.

3. WDAC¶

WDAC, ou Windows Defender Application Control, est le mécanisme d'intégrité de code de référence pour durcir l'exécution sur Windows. Microsoft le présente aujourd'hui sous le nom App Control for Business.

L'idée centrale diffère d'AppLocker. WDAC s'ancre dans la logique Code Integrity du système, avec une décision appliquée plus bas dans la pile.

3.1 Différences clés avec AppLocker¶

AppLocker agit surtout au niveau applicatif. WDAC s'intègre à l'intégrité de code Windows et peut contrôler le code noyau ainsi que le code user-mode si l'option UMCI est activée.

Cette différence d'architecture a une conséquence opérationnelle : les contournements historiquement documentés sont plus fréquents côté AppLocker que côté WDAC.

Cette phrase doit être lue comme une inférence défensive : Microsoft ne publie pas un compteur officiel de "bypass connus", mais sa recommandation d'utiliser WDAC pour une protection forte reflète bien cette différence de surface de contournement.

3.2 Politique WDAC : XML puis binaire¶

Une politique WDAC est d'abord décrite en XML. Elle contient les règles d'intégrité de code, les options de politique, et les identités de fichiers autorisés.

Cette politique est ensuite convertie en forme binaire pour le déploiement. Dans le schéma historique single-policy utilisé par GPO, on rencontre le binaire SiPolicy.p7b.

Dans les déploiements modernes, surtout multi-policy, vous rencontrerez aussi des formats .cip. La présence de cette nuance ne change pas le principe demandé ici : on part d'un XML, puis on applique une politique binaire.

3.3 Modes : Audit vs Enforcement¶

Comme AppLocker, WDAC doit être introduit par étapes. Le mode audit n'est pas un luxe. C'est le seul moyen raisonnable de mesurer l'impact réel.

Microsoft recommande explicitement de commencer par Enabled:Audit Mode. Le retrait de cette option fait basculer la politique en mode appliqué.

Si vous activez UMCI, les exécutables user-mode et les scripts entrent dans le périmètre. C'est indispensable si vous voulez que WDAC couvre réellement les scripts et binaires déposés dans le contexte utilisateur.

3.4 Déploiement via GPO ou MDM¶

Le déploiement GPO WDAC classique passe par :

Computer Configuration > Administrative Templates > System > Device Guard > Deploy App Control for Business

Ce mécanisme GPO supporte surtout le single-policy format. Microsoft recommande d'autres méthodes de déploiement pour les scénarios plus modernes sur Windows 10 1903+ et Windows 11.

Le déploiement MDM reste pertinent dans un parc moderne, notamment pour des terminaux gérés par Intune. Le bénéfice est une gestion plus cohérente des politiques récentes.

3.5 Vérification et journaux¶

Pour vérifier la présence de configuration liée à WDAC, la clé registre souvent inspectée est :

HKLM\SYSTEM\CurrentControlSet\Control\CI\Config

Cette clé est un point de contrôle utile, mais elle ne doit pas être le seul indicateur de validation. Le meilleur réflexe reste la corrélation avec les journaux Code Integrity.

Les emplacements utiles sont :

• HKLM\SYSTEM\CurrentControlSet\Control\CI\Config pour l'état de configuration visible dans le registre ;
• C:\Windows\System32\CodeIntegrity\ pour les fichiers de politique présents sur le poste ;
• Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational pour la télémétrie d'application et de blocage.

Ouvrez regedit ou eventvwr.msc via Win + R. Sur un poste pilote, contrôlez toujours registre et journaux avant de conclure qu'une politique est correctement active.

4. AppLocker vs WDAC¶

Le bon choix dépend du niveau d'exigence. AppLocker est plus simple à démarrer. WDAC est plus exigeant, mais aussi plus solide.

Si votre priorité est le time to value, AppLocker peut produire un gain rapide. Si votre priorité est la résistance au contournement, WDAC est le choix plus cohérent.

Dans les grands environnements, on voit souvent une trajectoire réaliste : AppLocker pour assainir rapidement, puis WDAC pour le niveau de maîtrise supérieur.

5. Règles de base recommandées¶

Une base saine vise d'abord les emplacements inscriptibles par l'utilisateur. Ce sont les zones favorites des loaders, scripts opportunistes et exécutables téléchargés à la volée.

La logique recommandée est simple : autoriser depuis les répertoires système ou maîtrisés, refuser depuis les répertoires utilisateurs à risque, et gérer les exceptions de manière explicite.

Les trois refus les plus rentables à introduire tôt sont souvent :

• exécutions depuis %OSDRIVE%\Users\*\AppData\Local\Temp\* ;
• exécutions depuis %OSDRIVE%\Users\*\AppData\Roaming\* ;
• scripts et installateurs lancés depuis %USERPROFILE%\Downloads\* .

Ces règles doivent être testées. Certaines équipes de support, chaînes de déploiement ou applications métier utilisent encore ces emplacements de manière légitime.

6. Flux de décision AppLocker / WDAC¶

Le schéma ci-dessous résume le point de décision. Le fichier peut exister sur le poste. La question est de savoir si Windows lui permet de s'exécuter.

flowchart TD
    A["Demande d'exécution<br/>EXE, DLL, script, MSI, AppX"] --> B{"Mécanisme actif ?"}
    B -->|AppLocker| C["Évaluation des règles<br/>Publisher / Path / Hash"]
    B -->|WDAC| D["Évaluation Code Integrity<br/>Politique machine"]
    C --> E{"Objet autorisé ?"}
    D --> F{"Objet autorisé ?"}
    E -->|Oui| G["Exécution autorisée"]
    E -->|Non| H["Exécution bloquée<br/>ou journalisée en audit"]
    F -->|Oui| G
    F -->|Non| H
    H --> I["Analyse des événements<br/>AppLocker ou CodeIntegrity"]
    I --> J["Ajustement des exceptions<br/>ou maintien du blocage"]

7. Pièges et points d'exploitation¶

Le plus gros risque n'est pas technique. C'est le déploiement sans inventaire, sans audit, sans exceptions propres et sans trajectoire de rollback.

7.1 Faux positifs¶

Les faux positifs arrivent souvent dans trois catégories :

• outils internes non signés ;
• mises à jour d'éditeurs qui changent d'emplacement ou de certificat ;
• scripts de déploiement exécutés depuis des répertoires temporaires.

Les zones utilisateur sont particulièrement piégeuses. Elles hébergent à la fois beaucoup de bruit légitime et beaucoup d'activité réellement indésirable.

7.2 Gestion des exceptions¶

Une exception doit être la plus étroite possible. C'est vrai pour AppLocker comme pour WDAC.

Bon ordre de préférence :

1. exception par éditeur ;
2. exception par version ou produit ;
3. exception par hash ;
4. exception par chemin uniquement si le chemin est strictement maîtrisé.

Pour WDAC, la logique d'exception peut passer par une politique complémentaire. Pour AppLocker, elle passe souvent par des règles d'autorisation plus spécifiques. Dans les deux cas, la discipline de design compte plus que l'outil.

7.3 Impact sur les scripts de déploiement¶

Les scripts de packaging et les agents de déploiement sont souvent les premières victimes. Beaucoup extraient des fichiers dans %TEMP%, ou exécutent des composants transitoires hors de %PROGRAMFILES%.

7.4 AppLocker : pièges spécifiques¶

Si vous activez des règles Executable sans préparer les applications packagées, les apps packagées peuvent être bloquées faute de règles adaptées.

Autre piège courant : activer la collection DLL en production sans pilote suffisant. Le volume d'impact peut monter très vite.

7.5 WDAC : pièges spécifiques¶

Une politique WDAC mal conçue est plus sévère qu'une GPO AppLocker trop stricte. Elle s'insère plus profondément dans la décision d'exécution. Le plan de récupération doit être pensé avant la généralisation.

Sur les politiques signées, certaines opérations exigent un redémarrage. Sur les postes avec memory integrity, Microsoft documente un point de vigilance pour l'activation de nouvelles politiques de base signées.

Le meilleur déploiement est incrémental :

• anneau pilote technique ;
• anneau IT ;
• petit périmètre métier ;
• généralisation progressive.

Collectez les journaux avant chaque élargissement. Ne corrigez pas les faux positifs en ouvrant de grands chemins. Corrigez-les en rendant les exceptions plus intelligentes.