AppLocker et WDAC : contrôle d'application via GPO¶

AppLocker : modèle de règles et collections¶

Trois types de règles¶

AppLocker distingue trois méthodes d'identification d'un exécutable. Le choix du type détermine à la fois la robustesse et la maintenabilité de la règle.

Publisher — Identifie un fichier par sa signature Authenticode. La règle peut cibler l'éditeur seul, l'éditeur + le produit, l'éditeur + le produit + le binaire, ou descendre jusqu'à une version exacte.

Path — Identifie un fichier par son chemin système ou ses wildcards. Simple à créer, mais contournable : un utilisateur qui peut écrire dans le répertoire peut substituer un binaire.

Hash — Identifie un fichier par son empreinte SHA-256. Impossible à contourner, mais fragile : toute mise à jour du fichier invalide la règle et nécessite une régénération manuelle.

Quatre collections¶

AppLocker organise ses règles en collections distinctes. Chaque collection contrôle une catégorie de fichiers et possède son propre journal d'événements.

Évaluation SID : qui est concerné ?¶

AppLocker est une technologie user-space. Chaque règle peut cibler :

• Everyone — tous les utilisateurs, y compris les admins
• Un groupe AD spécifique — évaluation par SID au moment de l'exécution
• BUILTIN\Administrators — les admins locaux peuvent être exemptés

Par défaut, les règles AppLocker exemptent les membres du groupe BUILTIN\Administrators. Cette exemption est une décision de design délibérée, mais elle signifie qu'un compte administrateur local peut contourner AppLocker sans aucune modification de GPO.

AppLocker : déploiement via GPO¶

La CSE AppLocker¶

AppLocker est implémenté comme une Client-Side Extension. Sa CSE possède un GUID fixe enregistré sous GPExtensions :

Emplacement des règles dans la GPO¶

Les règles AppLocker sont stockées dans la GPO sous :

Computer Configuration
  └── Policies
        └── Windows Settings
              └── Security Settings
                    └── Application Control Policies
                          └── AppLocker

Dans SYSVOL, les données XML correspondantes se trouvent dans :

\\DOMAIN\SYSVOL\DOMAIN\Policies\{GPO-GUID}\Machine\Microsoft\Windows NT\AppLocker\

Chaque collection génère un fichier XML séparé : Exe.xml, Msi.xml, Script.xml, Appx.xml.

Mode Audit vs mode Enforce¶

AppLocker supporte deux modes opérationnels configurables par collection indépendamment.

Audit only — AppLocker évalue les règles mais ne bloque pas. Tout fichier qui aurait été bloqué génère un Event ID dans le journal correspondant. Ce mode est indispensable avant tout déploiement en production.

Enforce rules — AppLocker bloque l'exécution des fichiers non autorisés. L'utilisateur reçoit un message de refus. L'événement est journalisé.

Exemple de règle Publisher en XML¶

<FilePublisherRule Id="a9e18c21-ff8f-43cf-b9fc-db40eed693ba"
                   Name="Allow Microsoft-signed PowerShell"
                   Description=""
                   UserOrGroupSid="S-1-1-0"
                   Action="Allow">
  <Conditions>
    <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
                            ProductName="MICROSOFT® WINDOWS® OPERATING SYSTEM"
                            BinaryName="POWERSHELL.EXE">
      <BinaryVersionRange LowSection="*" HighSection="*" />
    </FilePublisherCondition>
  </Conditions>
</FilePublisherRule>

<!-- Event ID 8002 dans Microsoft-Windows-AppLocker/EXE and DLL -->
<!-- powershell.exe autorisé par la règle Publisher ci-dessus -->
<!-- Aucun blocage, aucune interaction utilisateur -->

AppLocker : Event IDs de référence¶

Table des Event IDs¶

Les journaux AppLocker se trouvent sous Applications and Services Logs\Microsoft\Windows\AppLocker\.

Extraction PowerShell des événements de blocage¶

Get-WinEvent -LogName 'Microsoft-Windows-AppLocker/EXE and DLL' |
    Where-Object { $_.Id -eq 8003 } |
    Select-Object TimeCreated,
                  @{N='User';E={$_.Properties[3].Value}},
                  @{N='FilePath';E={$_.Properties[1].Value}},
                  @{N='PolicyName';E={$_.Properties[7].Value}} |
    Sort-Object TimeCreated -Descending |
    Format-Table -AutoSize

Title="Résultat attendu — extrait typique après 48h en mode Audit"
TimeCreated           User                FilePath                              PolicyName
-----------           ----                --------                              ----------
2026-04-04 08:32:11   CORP\jsmith         C:\Users\jsmith\AppData\...\setup.exe (Default Rule)
2026-04-04 07:15:43   CORP\mbrown         C:\Temp\PuTTY.exe                     (Default Rule)

:material-kernel: WDAC : Windows Defender Application Control¶

Positionnement architectural¶

WDAC est fondamentalement différent d'AppLocker. Là où AppLocker est une extension du service de Group Policy qui s'exécute en user-space, WDAC est un composant du noyau Windows (ci.dll — Code Integrity).

WDAC évalue chaque binaire avant que le noyau l'exécute ou charge la DLL. Cette évaluation se produit indépendamment de l'identité de l'utilisateur, du contexte de processus, ou des droits administrateurs.

La politique WDAC : XML → .p7b¶

Une politique WDAC commence toujours sous forme de fichier XML. Ce fichier définit les niveaux de confiance, les signataires autorisés, les options de politique et les règles de fichiers.

La politique XML est ensuite compilée en un fichier binaire .p7b (ou .bin selon la version OS) avant déploiement. Ce fichier binaire est signé pour empêcher toute modification.

# Step 1: Generate a base policy from the default Windows mode
New-CIPolicy -Level Publisher -Fallback Hash `
             -FilePath "C:\Policies\BasePolicy.xml" `
             -UserPEs

# Step 2: Convert XML to binary .p7b
ConvertFrom-CIPolicy -XmlFilePath "C:\Policies\BasePolicy.xml" `
                     -BinaryFilePath "C:\Policies\SIPolicy.p7b"

title="Résultat attendu"
[*] Scanning user-mode PEs...
[*] Policy generated: C:\Policies\BasePolicy.xml
[*] Binary policy written: C:\Policies\SIPolicy.p7b (47 KB)

Niveaux de confiance (Trust Levels)¶

WDAC évalue les fichiers selon une hiérarchie de signataires. Le paramètre -Level de New-CIPolicy définit le niveau de granularité des règles générées.

:material-options: Options de politique importantes¶

Les options de politique WDAC se configurent dans le XML via la balise <Rule>. Les plus importantes en production :

Mode Audit vs mode Enforce dans WDAC¶

Comme AppLocker, WDAC supporte deux modes. La différence est que le mode est encodé dans la politique elle-même via l'option 3.

Audit Mode (option 3 présente) — WDAC évalue les fichiers et journalise les violations dans Microsoft-Windows-CodeIntegrity/Operational sans bloquer. C'est le mode de déploiement initial obligatoire.

Enforce Mode (option 3 absente) — WDAC bloque le chargement de tout code non autorisé, y compris les drivers. Un noyau bloqué pendant le démarrage peut rendre le système inaccessible.

Déploiement WDAC via GPO¶

Emplacement dans SYSVOL¶

Le déploiement WDAC via GPO repose sur un mécanisme simple : copier le fichier .p7b dans un emplacement spécifique de SYSVOL, puis utiliser une GPO pour pointer les machines vers ce fichier.

Le paramètre GPO se trouve dans :

Computer Configuration
  └── Policies
        └── Administrative Templates
              └── System
                    └── Device Guard
                          └── Deploy Windows Defender Application Control

Le chemin UNC configuré pointe vers le .p7b dans SYSVOL :

\\DOMAIN\SYSVOL\DOMAIN\WDAC\SIPolicy.p7b

Prise d'effet de la politique¶

Contrairement à AppLocker, WDAC ne prend pas effet immédiatement après l'application de la GPO. La politique est copiée au gpupdate /force, mais elle n'est activée qu'au prochain redémarrage (pour les politiques de démarrage) ou lors du prochain chargement de code (pour certains composants).

# Check currently enforced WDAC policy
Get-CIPolicy -BinaryFilePath C:\Windows\System32\CodeIntegrity\SIPolicy.p7b |
    Select-Object PolicyName, PolicyID, PolicyVersion, Rules

Déploiement via MDM (Intune) vs GPO¶

Pour les environnements hybrides ou cloud-first, WDAC peut être déployé via Intune (MDM) sans passer par SYSVOL. Le canal MDM utilise le CSP ./Device/Vendor/MSFT/ApplicationControl.

Diagramme de décision : évaluation d'une exécution¶

Le diagramme suivant illustre le chemin d'évaluation complet qu'emprunte Windows lors de l'exécution d'un fichier, en présence d'AppLocker et/ou de WDAC.

flowchart TD
    A([Demande d'exécution]) --> B{WDAC actif ?}

    B -- Non --> C{AppLocker configuré ?}
    B -- Oui --> D{ci.dll : politique WDAC}

    D --> E{Fichier autorisé\npar WDAC ?}
    E -- Non, Enforce --> F([BLOCAGE kernel\nEvent 3077])
    E -- Non, Audit --> G([Event 3076\nAucun blocage])
    E -- Oui --> C

    C -- Non --> H([Exécution libre])
    C -- Oui --> I{AppIDSvc Running ?}

    I -- Non --> H
    I -- Oui --> J{Collection configurée ?}

    J -- Non --> H
    J -- Oui --> K{Règle Deny\nexplicite ?}

    K -- Oui --> L([BLOCAGE AppLocker\nEvent 8004])
    K -- Non --> M{Règle Allow\ncorrespondante ?}

    M -- Oui --> N{Mode Enforce ?}
    M -- Non --> O{Mode Enforce ?}

    N -- Oui --> P([Exécution autorisée\nEvent 8002])
    N -- Non --> Q([Exécution autorisée\nEvent 8002])

    O -- Oui --> L
    O -- Non --> R([Aurait été bloqué\nEvent 8003])

    style F fill:#c62828,color:#fff
    style L fill:#c62828,color:#fff
    style G fill:#f57f17,color:#fff
    style R fill:#f57f17,color:#fff
    style P fill:#2e7d32,color:#fff
    style H fill:#2e7d32,color:#fff
    style Q fill:#2e7d32,color:#fff

Migration AppLocker → WDAC¶

L'outil ConvertFrom-CIPolicy¶

Microsoft fournit un outil PowerShell pour convertir une politique AppLocker en XML WDAC :

# Step 1: Export current AppLocker policy to XML
Get-AppLockerPolicy -Effective -Xml | Out-File "C:\Migration\AppLockerPolicy.xml"

# Step 2: Convert AppLocker XML to WDAC-compatible CI policy
ConvertFrom-AppLockerPolicy -XMLFilePath "C:\Migration\AppLockerPolicy.xml" `
                            -Destination "C:\Migration\WdacFromAppLocker.xml"

# Step 3: Review and merge with a base WDAC policy
Merge-CIPolicy -PolicyPaths "C:\Migration\WdacFromAppLocker.xml",
                              "C:\Policies\BasePolicy.xml" `
               -OutputFilePath "C:\Policies\MergedPolicy.xml"

title="Résultat attendu"
[*] Converting AppLocker Executable Rules... 14 rules converted
[*] Converting AppLocker Script Rules... 8 rules converted
[*] WARNING: 3 Path rules converted to broad wildcards — review required
[*] WARNING: 2 Publisher rules have no WDAC equivalent — manual remediation needed
[*] Output: C:\Migration\WdacFromAppLocker.xml

Correspondances imparfaites¶

La conversion n'est pas bijective. Certains types de règles AppLocker n'ont pas d'équivalent direct dans WDAC.

Règles Publisher avec version exacte — AppLocker supporte une plage de versions précise (ex: 5.1.0.0 à 5.1.9999.9999). WDAC ne supporte que la version minimale. Les plages haute sont ignorées.

Règles Path avec variables d'environnement — AppLocker supporte %PROGRAMFILES% dans les règles Path. La conversion WDAC remplace ces variables par des wildcards larges. Il faut vérifier que ces wildcards ne sont pas trop permissifs.

Règles SID-based — AppLocker peut cibler un groupe AD spécifique. WDAC n'a pas de notion de SID utilisateur : la politique s'applique à la machine entière. Les règles AppLocker ciblant des groupes spécifiques devront être scindées en politiques WDAC distinctes par segment de machines.

:material-checklist: Checklist de migration¶

Managed Installer¶

Le concept¶

Le Managed Installer est une fonctionnalité WDAC qui permet de marquer un processus de déploiement (SCCM/MECM, Intune) comme source de confiance. Tout binaire installé par ce processus marqué est automatiquement autorisé par WDAC, sans nécessiter une règle Publisher ou Hash explicite.

C'est la solution au problème fondamental du contrôle d'application en entreprise : comment autoriser automatiquement les logiciels déployés par l'outil de management sans les lister un par un ?

Fonctionnement technique¶

Le Managed Installer repose sur deux mécanismes complémentaires.

AppLocker comme étiqueteur — Paradoxalement, le Managed Installer utilise AppLocker pour marquer les binaires déployés. Une règle AppLocker spéciale (type ManagedInstaller) identifie le processus de déploiement (ex: ccmexec.exe). Lorsque ce processus écrit un fichier sur le disque, Windows appose un Extended Attribute (EA) sur le fichier.

WDAC comme consommateur — Quand WDAC évalue un fichier portant cet EA, il l'autorise automatiquement (si l'option 14 Enabled:Managed Installer est présente dans la politique WDAC).

<FilePublisherRule Id="6cc9a840-b0fd-4f86-aca7-8424a22b4b37"
                   Name="SCCM CCMExec — Managed Installer"
                   Description="Mark MECM agent as Managed Installer"
                   UserOrGroupSid="S-1-1-0"
                   Action="Allow">
  <Conditions>
    <FilePublisherCondition
        PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
        ProductName="MICROSOFT ENDPOINT CONFIGURATION MANAGER"
        BinaryName="CCMEXEC.EXE">
      <BinaryVersionRange LowSection="*" HighSection="*" />
    </FilePublisherCondition>
  </Conditions>
</FilePublisherRule>

Limites du Managed Installer¶

L'EA est héritable mais pas infalsifiable — Un attaquant qui peut écrire via ccmexec.exe peut potentiellement faire autoriser un binaire malveillant. Le Managed Installer ne remplace pas une bonne hygiène de sécurité sur l'agent SCCM.

L'EA n'est pas persistant cross-volume — Si un fichier étiqueté est copié sur un autre volume, l'EA n'est pas transféré. Le fichier doit être réinstallé par le Managed Installer sur le volume destination.

AppLocker doit être actif — Le mécanisme d'étiquetage repose sur AppLocker, même si WDAC est l'autorité finale. AppIDSvc doit fonctionner pour que l'étiquetage se produise.

WDAC : Event IDs de référence¶

Table des Event IDs¶

Le journal WDAC se trouve sous Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational.

Exploitation PowerShell des événements WDAC¶

$Events = Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' |
    Where-Object { $_.Id -eq 3076 }

$Events |
    ForEach-Object {
        [PSCustomObject]@{
            Time      = $_.TimeCreated
            FilePath  = $_.Properties[1].Value
            Publisher = $_.Properties[8].Value
            Hash      = $_.Properties[10].Value
        }
    } |
    Group-Object FilePath |
    Sort-Object Count -Descending |
    Select-Object -First 20 Count, Name |
    Format-Table -AutoSize

title="Résultat attendu — classement des fichiers les plus fréquemment auditionnés"
Count  Name
-----  ----
  142  C:\Program Files\Vendor\App\updater.exe
   87  C:\Windows\Temp\install_helper.exe
   34  C:\Users\Public\Downloads\setup.exe
   12  C:\Program Files (x86)\Legacy\legacy.dll

Générer des règles depuis les événements Audit¶

# Generate supplemental policy from Audit log events
New-CIPolicy -Audit -Level FilePublisher -Fallback Publisher `
             -FilePath "C:\Policies\SupplementalFromAudit.xml" `
             -Days 14

title="Résultat attendu"
[*] Scanning Audit events from last 14 days...
[*] 38 unique files found in audit log
[*] 35 rules generated at FilePublisher level
[*] 3 rules fell back to Publisher level (no valid file signature)
[*] Policy written: C:\Policies\SupplementalFromAudit.xml

AppLocker vs WDAC : tableau de décision¶

Le choix entre AppLocker et WDAC dépend du contexte de sécurité, de la version OS, et de la posture admin envisagée.

Références croisées¶

Pour le contexte des stratégies de sécurité endpoint plus larges :

• Stratégies de sécurité GPO — politiques de mot de passe, audit avancé, droits utilisateur
• Sécurité endpoint — vue d'ensemble de la posture endpoint
• SCCM/MECM et GPO — intégration Managed Installer avec MECM