GPO — Bloquer PowerShell et CMD pour les non-admins

Le problème

Un utilisateur standard n’a aucune raison légitime d’ouvrir une console PowerShell ou une invite de commandes. Lui en laisser l’accès, c’est laisser une porte ouverte : un attaquant qui obtient une session utilisateur peut utiliser PowerShell comme outil de reconnaissance, de mouvement latéral ou d’exécution. Fermer cette porte réduit la surface d’attaque.

Soyons clairs sur le périmètre : cette GPO ne protège pas contre les ransomwares. Un crypto-locker moderne embarque son propre moteur d’exécution et ne dépend pas de powershell.exe ou cmd.exe présents sur la machine. Bloquer la console est une mesure de durcissement (réduction de surface d’attaque, defense-in-depth), pas un rempart anti-malware. La vraie protection anti-ransomware passe par le retrait des droits admin locaux, le whitelisting applicatif complet, et des sauvegardes hors-ligne.

Cela dit, réduire la surface d’attaque a du sens en soi. C’est l’objectif de cette GPO.

SRP est mort, vive AppLocker

Historiquement, on bloquait des exécutables via les Software Restriction Policies (SRP). Sur Windows 11 récent (24H2), ce n’est plus une option : Microsoft a déprécié SRP depuis Windows 10 build 1803 et l’a largement neutralisé sur les versions modernes. Compter dessus aujourd’hui, c’est compter sur une fonctionnalité morte.

La solution moderne, c’est AppLocker. Officiellement réservé aux éditions Enterprise et Education, il fonctionne en pratique sur Windows 11 Pro via GPO — Microsoft ne le supporte pas officiellement sur Pro, mais ça marche. Le point d’attention principal : AppLocker dépend du service Identité de l’application (AppIDSvc), qui doit tourner sur les machines.

L’avantage d’AppLocker sur les méthodes naïves

Une approche courante mais faillible consiste à utiliser le paramètre “Ne pas exécuter les applications Windows spécifiées” pour bloquer powershell.exe et cmd.exe. Le problème : sur Windows 11, le terminal par défaut est Windows Terminal (wt.exe), qui héberge PowerShell et CMD. Bloquer powershell.exe par cette méthode n’empêche pas de le lancer depuis Windows Terminal.

AppLocker, lui, bloque l’exécutable quel que soit son conteneur. Que powershell.exe soit lancé directement, depuis le menu Démarrer ou depuis Windows Terminal, AppLocker l’intercepte. C’est la bonne méthode.

Création de la GPO

Dans la GPMC :

Clic droit sur l'OU cible → Create a GPO in this domain and link it here
Nom : Block Console Non-Admins

Lier sur STATIONS.

Étape 1 — Activer le service Identité de l’application

AppLocker ne fait rien si ce service ne tourne pas. On le force en démarrage automatique via la GPO :

Computer Configuration → Policies → Windows Settings → Security Settings → System Services
→ "Identité de l'application" (Application Identity)
→ Définir ce paramètre de stratégie → Automatique

Étape 2 — Créer les règles par défaut AppLocker

Avant toute règle de blocage, il faut les règles par défaut, sinon AppLocker bloque tout Windows.

Computer Configuration → Policies → Windows Settings → Security Settings
→ Application Control Policies → AppLocker → Executable Rules
→ Clic droit → Créer des règles par défaut

Cela crée trois règles d’autorisation : tout le monde peut exécuter ce qui est dans Program Files et Windows, et les administrateurs peuvent tout exécuter. Ces règles sont indispensables — sans elles, AppLocker passe en mode “tout est bloqué sauf ce qui est explicitement autorisé” et casse le système.

Étape 3 — Créer les règles Deny

Pour chaque exécutable à bloquer, clic droit sur Règles de l'exécutable → Créer une règle :

• Autorisations : Refuser, groupe Utilisateurs du domaine (Domain Users) — cible tous les non-admins
• Conditions : Chemin d'accès

Quatre règles à créer :

Pourquoi cibler “Utilisateurs du domaine” et non “Tout le monde” : une règle Deny l’emporte toujours sur une règle Allow dans AppLocker. En ciblant uniquement Domain Users, les administrateurs (qui ne sont pas dans ce blocage et bénéficient de la règle par défaut “Administrateurs → tout autoriser”) conservent l’accès aux consoles. Les non-admins sont bloqués, les admins passent.

La règle PowerShell 7 (pwsh.exe) est préventive si tu n’as pas PowerShell 7 déployé — elle ne gêne rien et couvre le cas où il serait installé plus tard.

Limites connues d’AppLocker

Soyons honnêtes sur ce que cette protection vaut. AppLocker basé sur les chemins peut être contourné : un utilisateur qui copie powershell.exe ailleurs et le renomme échappe à une règle de chemin. Pour une protection plus robuste, on utiliserait des règles basées sur l’éditeur (signature) ou le hash. Mais pour de la réduction de surface d’attaque face à un usage opportuniste, le blocage par chemin est suffisant et simple à maintenir.

Et le rappel qui vaut la peine d’être répété : la mesure la plus efficace reste de ne pas donner de droits admin locaux aux utilisateurs. AppLocker est un complément, pas un substitut.

Vérification post-déploiement

Après gpupdate /force et reboot sur une machine de test, connecté en utilisateur standard :

Tenter d’ouvrir PowerShell ou CMD doit afficher un message de blocage par stratégie de groupe. Côté admin, vérifier les tentatives bloquées :

Get-AppLockerFileInformation -EventLog -EventType Denied -Statistics

Vérifier aussi que le service tourne :

Get-Service AppIDSvc | Select-Object Name, Status, StartType

Récapitulatif

Bibliothèque GPO — retour à l’index