Renforcer la sécurité de PowerShell — journalisation, AMSI, mode de langage, JEA

Face à une succession de rapports indiquant que « PowerShell a été détourné lors d’une intrusion », certaines organisations cherchent à interdire totalement l’usage de PowerShell en interne. Mais ce choix ne se justifie ni sur le plan de l’efficacité réelle, ni sur celui de l’impact opérationnel. PowerShell constitue l’infrastructure d’administration de Windows elle-même : l’arrêter, c’est arrêter l’automatisation de l’exploitation. Un attaquant, de son côté, peut accomplir la même chose par un autre moyen.

La politique réaliste n’est pas l’interdiction, mais la visibilité et la restriction. Heureusement, à partir de PowerShell 5.0, les fonctionnalités nécessaires à la défense sont disponibles : la journalisation des blocs de script, qui consigne même le code obfusqué sous sa forme développée ; AMSI (Antimalware Scan Interface, le mécanisme Windows qui fait examiner le contenu d’un script par un produit antimalware), qui transmet le contenu à un produit antivirus avant l’exécution ; le mode de langage, qui restreint la syntaxe elle-même utilisable à l’exécution ; et JEA, qui « ne délègue que les opérations nécessaires ». En combinant ces éléments, on peut créer un état auditable sans arrêter l’activité.

Cet article rassemble, dans l’ordre d’efficacité, les points à configurer pour continuer à utiliser PowerShell en toute sécurité dans un environnement Windows interne. La stratégie d’exécution et la signature sont traitées dans « Stratégie d’exécution et signature de script PowerShell » ; cet article va au-delà.

Environnement ciblé et prérequis

1. La conclusion, d’abord

• La priorité absolue est d’activer la journalisation des blocs de script. Le code exécuté est consigné dans le journal des événements, et même le code obfusqué reste enregistré sous sa forme développée (ID d’événement 4104).²
• Activez également la transcription en parallèle. L’enregistrement de la session, entrées et sorties comprises, peut être centralisé sur un partage en écriture seule.²
• Une fois la journalisation activée, révisez aussi la taille des journaux. Avec la taille par défaut, ils sont écrasés en peu de temps.²
• Grâce à AMSI, le script est transmis au produit antivirus avant son exécution. Actif à partir de PowerShell 5.0, sur Windows 10 ou ultérieur.¹
• Désactivez l’ancien moteur PowerShell 2.0. S’il subsiste, il reste possible de basculer vers cet ancien moteur, où ni la journalisation ni AMSI ne s’appliquent.³
• La stratégie d’exécution n’est pas une frontière de sécurité. La documentation officielle le précise explicitement. N’en faites pas l’axe principal de votre défense.⁴
• Utilisez le mode de langage comme résultat de WDAC/AppLocker. Une configuration manuelle peut être contournée et ne fonctionne pas comme une véritable fonctionnalité de sécurité.⁵
• Pour la délégation de privilèges, utilisez JEA. Il permet d’autoriser « uniquement cette commande, avec ce paramètre », et de faire fonctionner l’exploitation sans jamais distribuer de privilèges d’administrateur.⁶

2. Que protège-t-on — la visibilité d’abord, la restriction ensuite

Les quatre mesures traitées dans cet article couvrent chacune une couche différente. Voici d’abord la vue d’ensemble.

flowchart TB
    U["Administrateurs, support technique, scripts d'automatisation<br/>(et un attaquant ayant pénétré le système)"]
    DEL["[Délégation] JEA (chapitre 7)<br/>Ne pas distribuer de privilèges d'administrateur, ne transmettre que les opérations autorisées"]
    LIM["[Restriction] Mode de langage + WDAC/AppLocker (chapitre 6)<br/>Restreindre le code exécutable et la syntaxe utilisable"]
    SCAN["[Inspection] AMSI (chapitre 4)<br/>Transmettre le contenu au produit antivirus juste avant l'exécution<br/>Fermer les voies de contournement en désactivant PowerShell 2.0"]
    RUN["Opérations dans PowerShell"]
    REC["[Enregistrement] Journalisation des blocs de script (4104), transcription (chapitre 3)<br/>Conserver la trace une fois l'obfuscation levée"]
    U --> DEL
    DEL --> LIM
    LIM --> SCAN
    SCAN --> RUN
    RUN --> REC

L’enregistrement crée un état où l’on peut « remonter la trace après coup », la délégation réduit le privilège lui-même, et l’inspection comme la restriction arrêtent les choses avant l’exécution. Ces quatre mesures ne se substituent pas les unes aux autres : elles couvrent des couches différentes. Cela dit, il existe un ordre de priorité pour leur mise en œuvre.

Dans de nombreux environnements, la situation s’améliore déjà considérablement rien qu’en réalisant les étapes 1 et 3. L’étape 4 a un coût de mise en œuvre élevé ; c’est un domaine à faire progresser en vérifiant son impact opérationnel au fur et à mesure.

3. Activer la journalisation — 4104 est la priorité absolue

La journalisation de PowerShell comporte trois niveaux.²

Ces trois éléments se configurent tous via la stratégie de groupe, sous « Configuration ordinateur > Modèles d’administration > Composants Windows > Windows PowerShell ». Il est également possible de les configurer directement dans le registre.²

# Active la journalisation des blocs de script (nécessite des privilèges d'administrateur ; généralement distribuée via GPO)
$key = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging'
New-Item -Path $key -Force | Out-Null
# -Type est un paramètre dynamique ajouté par le fournisseur de registre. Il permet de préciser le type de la valeur (DWord)
Set-ItemProperty -Path $key -Name 'EnableScriptBlockLogging' -Value 1 -Type DWord

# PowerShell 7 (pwsh) lit une clé de stratégie différente. Configurez les deux
$key = 'HKLM:\SOFTWARE\Policies\Microsoft\PowerShellCore\ScriptBlockLogging'
New-Item -Path $key -Force | Out-Null
Set-ItemProperty -Path $key -Name 'EnableScriptBlockLogging' -Value 1 -Type DWord

# Active la transcription et la centralise sur un partage en écriture seule
$key = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription'
New-Item -Path $key -Force | Out-Null
Set-ItemProperty -Path $key -Name 'EnableTranscripting'     -Value 1 -Type DWord
Set-ItemProperty -Path $key -Name 'OutputDirectory'         -Value '\\logsrv\pstranscripts$'
Set-ItemProperty -Path $key -Name 'EnableInvocationHeader'  -Value 1 -Type DWord

# Pour la transcription aussi, PowerShell 7 utilise une clé différente. Écrivez la même valeur
$key = 'HKLM:\SOFTWARE\Policies\Microsoft\PowerShellCore\Transcription'
New-Item -Path $key -Force | Out-Null
Set-ItemProperty -Path $key -Name 'EnableTranscripting'     -Value 1 -Type DWord
Set-ItemProperty -Path $key -Name 'OutputDirectory'         -Value '\\logsrv\pstranscripts$'
Set-ItemProperty -Path $key -Name 'EnableInvocationHeader'  -Value 1 -Type DWord

PowerShell 7 lit les stratégies sous PowerShellCore, et non sous Windows\PowerShell. Si vous vous contentez de configurer uniquement le côté 5.1, l’enregistrement des scripts exécutés sous pwsh manquera intégralement. Pour la journalisation des blocs de script comme pour la transcription, écrivez la même valeur dans les deux clés (si vous distribuez via GPO, configurez également chacun des modèles correspondants).

La valeur de la journalisation des blocs de script tient à sa résistance à l’obfuscation. Même une commande encodée en Base64 ou un code assemblé par concaténation de chaînes est enregistré sous sa forme développée au moment de l’exécution.² La possibilité de reconstituer « ce qui a été exécuté » lors de l’investigation d’une attaque dépend entièrement de la présence de ce réglage.

La vérification de l’enregistrement se fait avec Get-WinEvent (« Explorer efficacement le journal des événements avec Get-WinEvent »).

# Vérifie la journalisation des blocs de script du dernier jour.
# Comme Windows PowerShell (5.1) et PowerShell 7 écrivent dans des journaux différents,
# on cible les deux
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-PowerShell/Operational', 'PowerShellCore/Operational'
    ID        = 4104
    StartTime = (Get-Date).AddDays(-1)
} -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, LogName, @{ n='Script'; e={ $_.Message } } -First 20

Pour vérifier que l’activation a réussi, procédez selon ces trois points.

1. Après avoir appliqué le réglage, ouvrez une nouvelle session PowerShell. La journalisation des blocs de script ne s’applique qu’aux sessions démarrées après son activation.² Ne concluez pas à un échec en testant dans une fenêtre déjà ouverte.
2. Exécutez une commande repère dans la nouvelle session, et vérifiez qu’elle revient bien comme un événement 4104. Si la requête ci-dessus renvoie un événement contenant le fragment de code que vous venez d’exécuter, c’est actif. Si rien ne revient, vérifiez avec Get-ItemProperty la valeur de la clé de stratégie (EnableScriptBlockLogging à 1) et laquelle des clés, 5.1 ou 7, a reçu l’écriture.
3. Vérifiez que vous ne vous trompez pas de journal. Si l’exécution s’est faite sous pwsh, l’emplacement est PowerShellCore/Operational. Le malentendu le plus fréquent avec ce réglage est de ne regarder que Microsoft-Windows-PowerShell/Operational et de conclure à tort que « rien n’est enregistré ».

Une fois activée, révisez impérativement la taille des journaux. Avec la taille par défaut, ils tournent en quelques heures à quelques jours, et il ne reste plus rien au moment où l’on en a besoin.

Get-WinEvent -ListLog 'Microsoft-Windows-PowerShell/Operational', 'PowerShellCore/Operational' |
    Select-Object LogName, MaximumSizeInBytes, RecordCount
wevtutil sl Microsoft-Windows-PowerShell/Operational /ms:1073741824   # exemple d'extension à 1 Go
wevtutil sl PowerShellCore/Operational               /ms:1073741824   # ne pas oublier le côté PowerShell 7

# Vérifie que le changement a été appliqué : succès si MaximumSizeInBytes vaut 1073741824
Get-WinEvent -ListLog 'Microsoft-Windows-PowerShell/Operational', 'PowerShellCore/Operational' |
    Select-Object LogName, MaximumSizeInBytes

wevtutil sl n’affiche rien même en cas de succès : comparer MaximumSizeInBytes avant et après le réglage est donc le seul moyen de vérification. Le changement est refusé si vous n’exécutez pas avec des privilèges d’administrateur ; si la valeur ne change pas, suspectez d’abord ce point.

Faire de la destination d’agrégation des transcriptions un partage « où l’on peut écrire mais pas supprimer »

Le point essentiel est que la destination de sortie des transcriptions soit un partage où l’utilisateur peut écrire mais ne peut pas supprimer. Si vous les placez en local, elles seront effacées sur un poste compromis.

Configurez à la fois les autorisations de partage et les autorisations NTFS (le privilège effectif est le plus restrictif des deux). Le point essentiel est de n’accorder à l’utilisateur que « la création de fichiers dans le dossier » et « la lecture/écriture des fichiers qu’il a lui-même créés », et de ne jamais lui accorder la suppression (DE) ni la suppression de sous-dossiers et de fichiers (DC).

Clarifions d’emblée ce que cette configuration protège et ce qu’elle ne protège pas. Ce qu’elle protège, ce sont deux points : « ne toucher en aucun cas aux enregistrements d’autrui » et « ne pas pouvoir non plus supprimer ses propres enregistrements ». Ce qu’elle ne protège pas, c’est « l’écrasement de son propre enregistrement », ce qui ne peut pas être bloqué par la seule ACL (la raison est expliquée plus loin). Malgré cela, le simple fait qu’un compte compromis ne puisse plus effacer les traces d’autrui change considérablement la manière de circonscrire les dégâts. Si un poste tombe, les enregistrements des autres postes subsistent.

# À exécuter du côté du serveur d'agrégation des journaux (nécessite des privilèges d'administrateur)
$path = 'D:\PSTranscripts'
$null = New-Item -Path $path -ItemType Directory -Force

# Crée le partage. Les utilisateurs n'ont que la modification (écriture) ; seul le responsable des journaux a l'administration
New-SmbShare -Name 'pstranscripts$' -Path $path `
    -ChangeAccess 'EXAMPLE\Domain Users' -FullAccess 'EXAMPLE\LogAdmins'

# Coupe l'héritage depuis le dossier parent (second argument $false = ne pas conserver les ACE héritées).
# Si le contrôle total de CREATOR OWNER hérité par ce mécanisme subsiste,
# on se retrouve dans l'état « chacun peut supprimer les fichiers qu'il a créés », ce qui vide l'agrégation de son sens.
#
# Cependant, SetAccessRuleProtection ne retire que les « ACE héritées » ;
# les ACE attribuées directement à ce dossier restent en place. Le New-Item -Force ci-dessus
# réussit même sur un dossier existant, donc si une autorisation de modification a été
# accordée directement par le passé à Domain Users ou à Everyone, elle
# survivra même après l'exécution de toutes les lignes suivantes. L'utilisateur pourrait alors toujours écraser ou supprimer les transcriptions d'autrui.
# On retire donc d'abord toutes les attributions directes, avant de ne remettre en place que celles qui sont nécessaires
$acl = Get-Acl -Path $path
$acl.SetAccessRuleProtection($true, $false)

foreach ($ace in @($acl.Access)) { [void]$acl.RemoveAccessRuleSpecific($ace) }

# Une fois tout retiré, on ajoute le côté administration et SYSTEM dans le même $acl avant de l'appliquer en une seule fois.
# Si l'on fait « vider » puis « remettre en place » avec deux Set-Acl séparés, il existe un instant où personne n'a plus accès
foreach ($id in @('EXAMPLE\LogAdmins', 'SYSTEM')) {
    $acl.AddAccessRule([System.Security.AccessControl.FileSystemAccessRule]::new(
        $id, 'FullControl', 'ContainerInherit, ObjectInherit', 'None', 'Allow'))
}
Set-Acl -Path $path -AclObject $acl

# N'autorise l'utilisateur qu'à la « création » dans le dossier. Le point essentiel est de ne pas ajouter (OI) :
# cette autorisation n'est pas héritée par les fichiers du dossier
#   WD = création de fichier   AD = création de dossier   X = parcours du dossier   RA = lecture des attributs
#   ajouter (OI) reviendrait à accorder jusqu'à « l'écriture de données dans les fichiers existants »
icacls $path /grant 'EXAMPLE\Domain Users:(CI)(WD,AD,X,RA)'

# Permet à celui qui écrit de lire et écrire uniquement « les fichiers qu'il a lui-même créés ».
# CREATOR OWNER est remplacé par « le créateur » au moment de la création du fichier,
# donc cela ne s'applique pas aux fichiers d'autrui. On n'accorde pas DE (suppression)
#   RD,WD,AD = lecture, écriture, ajout de données   RA,WA = lecture/écriture des attributs
#   REA,WEA = lecture/écriture des attributs étendus   RC = lecture des autorisations
#   S = synchronisation. Inclus dans GENERIC_READ/GENERIC_WRITE, donc impossible à retirer
# On serait tenté de se limiter à AD (ajout) seul, mais dans ce cas pas une seule ligne de transcription ne pourrait être écrite (voir plus loin)
icacls $path /grant 'CREATOR OWNER:(OI)(IO)(RD,WD,AD,REA,WEA,RA,WA,RC,S)'

# C'est le point essentiel. Les lignes ci-dessus seules ne suffisent pas.
# L'utilisateur qui a créé le fichier en devient le « propriétaire ».
# Comme Windows accorde implicitement au propriétaire READ_CONTROL et WRITE_DAC,
# même sans avoir attribué WD ni DE, le propriétaire peut réécrire lui-même le DACL
# et se réattribuer les privilèges d'écrasement et de suppression. Autrement dit, un compte compromis
# peut effacer ses propres traces. Lorsqu'une ACE OWNER RIGHTS est présente, le système
# ignore les READ_CONTROL / WRITE_DAC implicites accordés au propriétaire
icacls $path /grant 'OWNER RIGHTS:(OI)(IO)(RA,REA)'

icacls $path        # vérifie le résultat de la configuration

Si vous réutilisez un dossier existant, purgez systématiquement les ACE accordées directement. SetAccessRuleProtection($true, $false) ne retire que les ACE héritées ; celles directement attachées au dossier restent en place.⁷ Comme New-Item -Force réussit même sur un dossier existant, réutiliser un dossier qui a un historique — par exemple « on avait temporairement accordé le privilège de modification à Domain Users » — laisse cette attribution directe survivre même après avoir restreint CREATOR OWNER par la suite, et l’utilisateur peut toujours écraser ou supprimer les transcriptions d’autrui. C’est pour cette raison que le code ci-dessus purge tout d’un coup avant de tout remettre en place. Ce n’est pas nécessaire si vous créez un dossier neuf, mais cela ne coûte rien de le faire quand même. Après application, vérifiez visuellement la sortie de icacls $path pour vous assurer qu’aucun sujet inattendu n’y figure.

C’est ici que la façon d’appliquer (OI) détermine la réussite ou l’échec de la mesure. Si vous accordez WD à l’utilisateur avec (OI), cette ACE est héritée par tous les fichiers du dossier, et il suffit de connaître le nom d’un fichier pour écraser ou tronquer la transcription d’autrui.⁷ Cela empêche d’atteindre l’objectif « l’enregistrement subsiste même après compromission du poste ou du compte ». Comme ci-dessus, séparez le privilège de création dans le dossier (non hérité) de la lecture/écriture des seuls fichiers qu’on a soi-même créés, via CREATOR OWNER.

Et ne supprimez surtout pas la ligne OWNER RIGHTS. L’utilisateur qui crée un fichier en devient le propriétaire. Windows accorde implicitement au propriétaire READ_CONTROL et WRITE_DAC :⁸ même sans avoir attribué DE dans une ACE, le propriétaire peut réécrire lui-même le DACL et se réattribuer le privilège de suppression. Tant que « on peut supprimer soi-même son propre enregistrement » reste possible, restreindre CREATOR OWNER ne sert à rien. En plaçant une ACE OWNER RIGHTS (S-1-3-4), le système ignore les READ_CONTROL / WRITE_DAC implicites accordés au propriétaire, et c’est seulement à partir de là que « on peut écrire mais pas supprimer » devient effectif.⁸

Pourquoi ne pas se limiter à AD (ajout) seul

On pourrait être tenté de penser : « puisqu’on ne veut pas d’écrasement, il suffit de donner AD seul à CREATOR OWNER ». Mais dans ce cas, pas une seule ligne de transcription ne sera écrite.

Sous Windows, « ne pouvoir qu’ajouter » ne se réalise que lorsque le rédacteur ouvre le fichier en spécifiant FILE_APPEND_DATA seul. La référence Microsoft définit FILE_APPEND_DATA ainsi : « (pour un fichier local, si ce drapeau est spécifié sans FILE_WRITE_DATA, les opérations d’écriture n’écrasent pas les données existantes) ».⁹ Autrement dit, l’ajout exclusif est une propriété de la façon dont on ouvre le fichier, et non quelque chose que l’on obtient simplement en plaçant AD dans une ACE.

Or, le point d’écriture de Start-Transcript ne s’ouvre pas en ajout exclusif. L’implémentation de PowerShell ouvre d’abord avec FileMode.OpenOrCreate + FileAccess.ReadWrite, et ne rouvre avec FileMode.Append + FileAccess.Write qu’en cas d’échec.¹⁰ Côté .NET, FileAccess.Read/Write sont respectivement transposés en GENERIC_READ/GENERIC_WRITE, et FileMode.Append est simplement remplacé en interne par FileMode.OpenOrCreate avant de se positionner en fin de fichier.¹¹ Il n’existe aucun chemin qui demande FILE_APPEND_DATA seul.

FILE_GENERIC_WRITE comprend FILE_WRITE_DATA, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, READ_CONTROL et SYNCHRONIZE ; FILE_GENERIC_READ comprend FILE_READ_DATA, FILE_READ_ATTRIBUTES, FILE_READ_EA, READ_CONTROL et SYNCHRONIZE.⁹ Le contrôle d’accès examine la totalité des droits demandés : ce CreateFile est donc refusé pour un utilisateur qui ne détient que AD,RA,REA. Même si le partage autorise la modification (Change), l’échec survient côté NTFS. En voulant protéger l’enregistrement, on finirait par l’arrêter lui-même.

C’est pourquoi l’ACL de cette section n’utilise pas AD seul, mais adopte la forme « autoriser la lecture/écriture, sans accorder DE (suppression), WDAC (changement de privilège) ni WO (changement de propriétaire) ». Le propriétaire peut écraser ou tronquer sa propre transcription. Acceptez que ce point ne puisse pas être bloqué par l’ACL seule.

Si vous voulez bloquer même l’écrasement, il ne reste qu’à écrire vers un emplacement que le rédacteur ne peut pas atteindre. Il existe trois options.

• Avec JEA, utilisez TranscriptDirectory du fichier de configuration de session (chapitre 7). Cette sortie n’est pas écrite par l’utilisateur connecté, mais par Local System ; la documentation Microsoft exige elle-même que « les utilisateurs standards n’aient aucun accès à ce dossier » et que l’accès soit « limité aux seuls administrateurs de sécurité chargés de l’audit ».¹² L’utilisateur n’a alors même pas besoin de privilège, et toute la problématique de cette section disparaît
• L’ingérer via le transfert d’événements Windows ou un SIEM. La journalisation des blocs de script (4104) apparaît dans le journal des événements, elle peut donc être transférée
• Mettre en place un processus de collecte maison qui ouvre le fichier en ajout exclusif. Si vous écrivez vous-même le code qui demande FILE_APPEND_DATA seul à l’ouverture, alors le AD côté ACE prend enfin son sens

Notez enfin que ce que l’ACL protège se limite strictement à « vis-à-vis des utilisateurs qui écrivent sur ce partage ». L’administrateur du serveur de fichiers peut prendre possession des fichiers, et si le poste est totalement compromis, il est possible d’altérer les données avant même leur écriture vers le partage. Comprenez la conception de privilèges de cette section comme garantissant que « les utilisateurs d’un même partage ne peuvent pas s’effacer mutuellement », rien de plus.

La signification des symboles de privilège icacls (WD, AD, DE, DC, etc.) et des indicateurs d’héritage ((OI), (CI), (IO)) est répertoriée dans la référence des commandes Windows.⁷ Notez également que cette configuration doit impérativement être testée une première fois sur une machine de validation avant d’être déployée. Comme la session en cours d’exécution continue d’ajouter des données au même fichier de transcription, restreindre trop les privilèges peut faire échouer l’enregistrement lui-même. Le plus sûr est de vérifier concrètement trois points : « l’écriture fonctionne depuis le poste de l’utilisateur », « l’utilisateur ne peut ni lire ni modifier les fichiers existants d’autrui », et « l’utilisateur ne peut pas supprimer ses propres fichiers ».

4. Fermer les voies de contournement — PowerShell 2.0 et AMSI

Grâce à AMSI (Antimalware Scan Interface), à partir de PowerShell 5.0, le contenu du script est transmis au produit antivirus juste avant l’exécution, et examiné une fois l’obfuscation levée.¹ Si vous utilisez un produit compatible, y compris Microsoft Defender, cela fonctionne sans configuration supplémentaire.

Le problème est que les anciens moteurs ne disposent pas de ce mécanisme. Si le moteur Windows PowerShell 2.0 reste activé, il subsiste la possibilité de basculer, via powershell.exe -Version 2, vers un environnement où ni la journalisation ni AMSI ne s’appliquent. Cette fonctionnalité est obsolète et sa désactivation est recommandée.³

# Vérifie l'état du moteur PowerShell 2.0 et le désactive (nécessite des privilèges d'administrateur ; un redémarrage peut être requis)
Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2* |
    Select-Object FeatureName, State

Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root -NoRestart

Notez que si PowerShell 7 (pwsh) est déployé, les clés de configuration comme l’emplacement des journaux diffèrent de ceux de 5.1 (la stratégie se trouve sous PowerShellCore, le journal est PowerShellCore/Operational). Dans un environnement où les deux sont utilisés, appliquez la configuration, l’ajustement de taille des journaux et les requêtes d’investigation aux deux versions. Pour la coexistence des versions, voir « Différences entre Windows PowerShell 5.1 et PowerShell 7 ».

5. Ne pas se tromper sur la place de la stratégie d’exécution

Clarifions de nouveau ce point. La stratégie d’exécution n’est pas une frontière de sécurité. La documentation officielle précise explicitement qu’il s’agit d’une fonctionnalité de sécurité destinée à empêcher un utilisateur d’exécuter involontairement un script, et non d’un mécanisme qui bloque une action malveillante.⁴

Cela dit, elle n’est pas sans valeur. La signature apporte une autre valeur : pouvoir vérifier que le module distribué n’a pas été altéré (« Distribution et mise à jour interne des modules PowerShell »). Ce qui compte, c’est de bien comprendre son rôle avant de l’utiliser ; croire que « passer en AllSigned suffit à sécuriser » est la compréhension la plus dangereuse qui soit.

6. Le mode de langage — à utiliser en combinaison avec le contrôle applicatif

Une session PowerShell possède un mode de langage, qui restreint les éléments de langage utilisables.⁵

Les trois modes restrictifs ne constituent pas une gradation, mais correspondent à des usages différents. ConstrainedLanguage vise « un environnement où une personne écrit et utilise des scripts, en n’y bloquant que l’usage de types dangereux », tandis que NoLanguage vise « ne laisser personne écrire de script du tout » ; ce dernier ne peut être mis en œuvre que dans un guichet limité comme celui de JEA.⁵

Le mode actuel peut être vérifié ainsi.

$ExecutionContext.SessionState.LanguageMode

Ce qui compte, c’est la méthode de configuration. Le mode de langage contraint fonctionne comme un basculement automatique de PowerShell lorsqu’un contrôle applicatif de type liste blanche est configuré via WDAC (Windows Defender Application Control) ou AppLocker.⁵ Une configuration manuelle, par exemple via une variable d’environnement, se contourne facilement et ne fonctionne pas comme une véritable fonctionnalité de sécurité. Comprenez que restreindre uniquement le mode de langage sans mettre en place de contrôle applicatif demande de l’effort pour un effet quasi nul.

7. JEA — déléguer « uniquement les opérations nécessaires »

Ce qui détermine l’ampleur réelle des dégâts est, dans la plupart des cas, l’étendue des privilèges. Dans une situation où « le support technique dispose de privilèges d’administrateur » ou où « tous les responsables d’exploitation appartiennent au groupe Domain Admin », la compromission d’un seul poste devient la compromission de toute l’entreprise.

JEA (Just Enough Administration) est un mécanisme qui délègue uniquement des opérations spécifiques, sans jamais transmettre de privilèges d’administrateur.⁶ Il répond exactement à un besoin comme « confier au support technique uniquement le redémarrage d’un service applicatif ».

Ce chapitre repose sur un prérequis différent — JEA s’appuie sur le traitement à distance

Alors que les chapitres 3 à 6 se bouclent entièrement avec une configuration locale, JEA est construit directement sur le mécanisme du traitement à distance de PowerShell (WinRM).¹³ « Déléguer avec JEA » signifie enregistrer, sur le serveur ciblé, un point de connexion dédié (une configuration de session), et y faire connecter l’utilisateur. La possibilité de le reproduire dans votre organisation se joue d’abord sur ce point.

Trois éléments sont nécessaires.

Autrement dit, les étapes 1 à 3 ci-dessous sont un travail à effectuer sur le serveur du côté délégué, avec des privilèges d’administrateur. Sur le poste de l’utilisateur, il suffit de pouvoir se connecter à ce serveur. La configuration et le durcissement du traitement à distance lui-même sont rassemblés dans « Introduction à PowerShell Remoting (WinRM) ».

Étape 1 : définir les opérations autorisées dans le fichier de fonctionnalités de rôle (.psrc)

Le fichier de fonctionnalités de rôle doit obligatoirement se trouver dans le dossier RoleCapabilities d’un module PowerShell. Créer simplement un dossier ne suffit pas à le faire reconnaître comme un module, et il ne pourra pas être résolu par son nom depuis RoleDefinitions, décrit plus loin. Il faut donc d’abord créer le module conteneur (un dossier doté d’un manifeste).⁶

# Crée le module qui contiendra les fonctionnalités de rôle (un manifeste est nécessaire)
$moduleRoot = 'C:\Program Files\WindowsPowerShell\Modules\KsJea'
$null = New-Item -Path "$moduleRoot\RoleCapabilities" -ItemType Directory -Force
# Le dossier du module doit contenir au moins un fichier portant le même nom que le dossier
$null = New-Item -Path "$moduleRoot\KsJea.psm1" -ItemType File -Force
New-ModuleManifest -Path "$moduleRoot\KsJea.psd1" -RootModule 'KsJea.psm1'

# Crée le gabarit du fichier de fonctionnalités de rôle (le nom de fichier devient le nom du rôle).
# Comme le nom de rôle est résolu « par le nom seul » parmi tous les modules de PSModulePath,
# un nom générique comme 'HelpDesk' peut entrer en collision avec le .psrc d'un autre module.
# En cas de collision, rien ne garantit lequel sera choisi, ce qui peut accorder des privilèges non voulus.
# Utilisez un nom unique préfixé par celui de l'organisation
New-PSRoleCapabilityFile -Path "$moduleRoot\RoleCapabilities\KsHelpDesk.psrc"

# Vérifie que le module est bien visible
Get-Module -Name KsJea -ListAvailable

# KsHelpDesk.psrc (extrait) — déclare « quoi » et « jusqu'où » autoriser
@{
    GUID           = '....'
    # Les commandes en lecture seule peuvent être exposées telles quelles
    VisibleCmdlets = @(
        'Get-Service',
        'Get-EventLog'
    )
    # Restart-Service, qui modifie l'état, n'est volontairement pas inclus dans VisibleCmdlets (voir plus loin)
    # VisibleFunctions ne fait que restreindre les « fonctions chargées dans la session »,
    # il ne définit pas les fonctions. Écrivez le contenu des fonctions personnalisées dans FunctionDefinitions,
    # puis mentionnez également leur nom dans VisibleFunctions (les deux sont nécessaires)
    VisibleFunctions = @('Get-KsAppStatus', 'Restart-KsAppService')
    FunctionDefinitions = @(
        @{
            Name        = 'Get-KsAppStatus'
            ScriptBlock = {
                # Le corps de la fonction s'exécute dans le mode de langage par défaut et n'est donc pas soumis aux contraintes de JEA.
                # Ne transmettez jamais l'entrée de l'utilisateur telle quelle à une commande dangereuse
                Get-Service -Name 'KsAppService' |
                    Microsoft.PowerShell.Utility\Select-Object Name, Status, StartType
            }
        },
        @{
            # Le redémarrage est exposé comme une fonction qui « ne reçoit sa cible que par argument »
            Name        = 'Restart-KsAppService'
            ScriptBlock = {
                param(
                    [Parameter(Mandatory)]
                    [ValidateSet('KsAppService', 'Spooler')]
                    [string] $Name
                )
                Microsoft.PowerShell.Management\Restart-Service -Name $Name
            }
        }
    )
    VisibleExternalCommands = @()
}

ValidateSet seul dans VisibleCmdlets ne suffit pas à restreindre en toute sécurité une commande qui change l’état du système. La restriction par Parameters et ValidateSet n’est évaluée que lorsque ce paramètre est effectivement lié. Comme Restart-Service peut recevoir un ServiceController par le pipeline,

Get-Service WinRM | Restart-Service

écrit ainsi, -Name n’est jamais lié, et ValidateSet est simplement contourné. Sur un point de terminaison censé n’autoriser que le redémarrage de KsAppService et Spooler, il devient possible de redémarrer n’importe quel service.

Le même phénomène se produit avec un autre jeu de paramètres. Même en ajoutant un ValidateSet sur LogName pour Get-WinEvent,

Get-WinEvent -ProviderName Microsoft-Windows-Security-Auditing -MaxEvents 1

écrit ainsi, LogName n’est pas lié et la restriction ne s’applique pas. Comme la session JEA s’exécute en tant qu’administrateur virtuel, il devient possible dans ce cas de lire jusqu’au journal Security.

C’est pourquoi l’exemple ci-dessus n’inclut pas Restart-Service dans VisibleCmdlets, et ne publie que la fonction wrapper qui ne reçoit sa cible que par argument (Restart-KsAppService). Si le seul chemin d’entrée est l’argument, il n’y a aucun moyen de le contourner.

La restriction par Parameters et ValidateSet ne fonctionne que « quand ce paramètre est lié ». Pour une commande dont la liaison peut être évitée via l’entrée du pipeline ou un autre jeu de paramètres, la restriction elle-même devient inopérante. Considérez que, en règle générale, une commande dont vous voulez restreindre les arguments doit être enveloppée dans une fonction wrapper.

Il y a ici deux pièges de conception faciles à rencontrer. Le premier est que VisibleFunctions ne crée aucune fonction. Une fonction dont seul le nom est mentionné n’existe pas dans la session, et l’utilisateur voit « cette commande n’existe pas ». Définissez vos fonctions personnalisées via FunctionDefinitions, puis mentionnez-les également dans VisibleFunctions.¹⁴ Si leur nombre augmente, il devient plus facile à gérer de les extraire dans un module de script et de publier les fonctions de ce module via VisibleFunctions.

Le second est que le corps de la fonction n’est pas soumis aux contraintes de JEA.¹⁴ Si vous voulez utiliser des commandes contraintes que JEA remplace, comme Select-Object, avec leur comportement d’origine, appelez-les avec leur nom complet, comme Microsoft.PowerShell.Utility\Select-Object ci-dessus. Autrement dit, tout est possible à l’intérieur d’une fonction : évitez absolument d’écrire un code qui transmettrait une entrée utilisateur à Invoke-Expression.

Étape 2 : définir, dans le fichier de configuration de session (.pssc), qui se voit attribuer quel rôle

# SessionType : serveur distant restreint (NoLanguage par défaut)
# RunAsVirtualAccount : s'exécute en tant que compte administrateur virtuel
# TranscriptDirectory : enregistre le contenu exécuté
$pssc = @{
    Path                = '.\KsHelpDesk.pssc'
    SessionType         = 'RestrictedRemoteServer'
    RunAsVirtualAccount = $true
    TranscriptDirectory = 'C:\JeaTranscripts'
    RoleDefinitions     = @{ 'EXAMPLE\HelpDesk' = @{ RoleCapabilities = 'KsHelpDesk' } }
}
New-PSSessionConfigurationFile @pssc

Étape 3 : enregistrer

Register-PSSessionConfiguration -Name 'KsHelpDesk' -Path .\KsHelpDesk.pssc -Force

Côté utilisateur, la connexion se fait ainsi.

Enter-PSSession -ComputerName 'appsrv01' -ConfigurationName 'KsHelpDesk'
# Seules les commandes autorisées sont utilisables. Restart-Service aussi se limite aux services indiqués

JEA repose sur trois points essentiels.⁶

• L’utilisateur ne détient pas de privilège d’administrateur. L’exécution se fait du côté du compte virtuel
• La session est configurée comme un serveur distant restreint. Le mode de langage y est restreint par défaut, empêchant l’exécution de code arbitraire
• Le contenu exécuté est enregistré sous forme de transcription. On peut auditer qui a fait quoi

Notez que, comme indiqué précédemment, le fichier de fonctionnalités de rôle doit se trouver sous le dossier RoleCapabilities d’un module, et suppose que ce module soit trouvable depuis $env:PSModulePath. Si le nom de rôle indiqué dans RoleDefinitions ne peut pas être résolu, vérifiez d’abord avec Get-Module -ListAvailable que le module est visible.⁶

Le point de terminaison enregistré peut être listé avec Get-PSSessionConfiguration. Comme indiqué au début, JEA suppose une configuration d’exécution à distance ; en cas d’échec de connexion, commencez le diagnostic du côté WinRM plutôt que du côté de la définition JEA (« Introduction à PowerShell Remoting (WinRM) »).

8. Liste de contrôle pratique

9. Conclusion

• Interdire PowerShell a une efficacité réelle faible et arrête l’activité. La politique à adopter est « la visibilité et la restriction ».
• La priorité absolue est l’activation de la journalisation des blocs de script (4104). Même le code obfusqué est enregistré sous sa forme développée. Réalisez-la en même temps que l’augmentation de la taille des journaux.
• Pour la transcription, le point essentiel est de la centraliser sur un partage que l’utilisateur ne peut pas supprimer.
• Désactivez le moteur PowerShell 2.0, afin de ne laisser subsister aucune voie où ni la journalisation ni AMSI ne s’appliquent.
• La stratégie d’exécution n’est pas une frontière de sécurité. La signature a une valeur en tant que détection d’altération, mais n’en faites pas l’axe principal de votre défense.
• L’étendue des privilèges détermine l’étendue des dégâts. En déléguant « uniquement les opérations nécessaires » via JEA, l’exploitation peut fonctionner sans jamais distribuer de privilèges d’administrateur.

Téléchargement du code d’exemple

Le code présenté dans cet article est distribué sous une forme directement exécutable. Le paquet contient l’activation de la configuration des journaux et la création d’un point de terminaison JEA.

Télécharger le code d’exemple (zip)

Les exemples de cet article dépendant de Windows et du tenant, ils n’ont pas fait l’objet d’une validation d’exécution. L’analyse syntaxique et l’analyse statique via PSScriptAnalyzer ont été réalisées pour tous les fichiers, mais vérifiez impérativement leur comportement sur votre propre machine de validation.

# Analyse syntaxique + analyse statique (exécutable même hors Windows)
./Invoke-SampleTests.ps1

Les valeurs de configuration (chemins, noms de serveur, identifiants de locataire, etc.) sont des exemples. Ne les exécutez pas telles quelles en production : adaptez-les à votre propre environnement.

Articles connexes

• Stratégie d’exécution et signature de script PowerShell — sortir de l’exploitation qui « couvre tout avec Bypass »
• Explorer efficacement le journal des événements avec Get-WinEvent — la vitesse du filtrage détermine le temps d’investigation
• Introduction à PowerShell Remoting (WinRM) — administrer plusieurs postes Windows d’un seul coup
• La gestion sécurisée des identifiants sous PowerShell — bannir les mots de passe en clair des scripts
• Liste de contrôle minimale de sécurité pour une application Windows
• Lire le « Top 10 des menaces de sécurité de l’information 2026 » de l’IPA du point de vue des systèmes métier

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge la revue de configuration de sécurité des environnements d’exploitation Windows, la conception opérationnelle incluant la délégation de privilèges (JEA), ainsi que le conseil sur la mise en place et l’exploitation des journaux d’audit.

• Conseil technique et revue de conception
• Investigation des incidents et analyse des causes
• Modification et maintenance de logiciels Windows existants
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Faut-il interdire PowerShell en interne comme mesure de sécurité ?

Ce n'est pas recommandé, car l'efficacité réelle est faible et les effets de bord sont importants. PowerShell constitue l'infrastructure d'administration de Windows elle-même ; il n'est en réalité qu'une fonctionnalité au-dessus de .NET. Bloquer l'exécutable n'empêche pas d'appeler la même API par un autre moyen, ce qui en fait rarement un obstacle réel pour un attaquant, alors que l'administration légitime et l'automatisation, elles, s'arrêtent à coup sûr. La politique réaliste n'est pas l'interdiction mais « la visibilité et la restriction ». Consignez ce qui a été exécuté avec la journalisation des blocs de script, désactivez les anciennes versions, et si nécessaire, réduisez le périmètre exécutable avec le mode de langage ou JEA.

En activant la journalisation des blocs de script, ne va-t-on pas se retrouver submergé par le volume de journaux ?

Le volume augmente effectivement, donc activez-la en même temps que vous ajustez la taille des journaux. Si vous laissez le journal Microsoft-Windows-PowerShell/Operational à sa taille maximale par défaut, il sera écrasé en peu de temps et ne conservera plus ce dont vous avez besoin au moment critique. En pratique, prévoyez une taille de journal suffisante et, si nécessaire, agrégez avec un SIEM ou le transfert d'événements. Notez qu'il existe aussi un réglage plus détaillé qui enregistre jusqu'au « début et à la fin de chaque appel », mais comme son volume de sortie est très important, on active habituellement uniquement la journalisation par défaut des blocs de script.

Passer la stratégie d'exécution à AllSigned constitue-t-il une mesure de sécurité ?

La stratégie d'exécution n'est pas une frontière de sécurité. La documentation officielle précise elle-même qu'il s'agit d'un mécanisme destiné à empêcher un utilisateur d'exécuter involontairement un script dangereux, et non à arrêter une action malveillante, car il existe plusieurs façons de le contourner. La signature a une autre valeur, celle de pouvoir vérifier l'intégrité de ce qui est distribué, mais l'axe principal de la défense doit reposer sur la visibilité par la journalisation, l'inspection par AMSI, et la restriction des privilèges par le mode de langage ou JEA.

Le mode de langage contraint (ConstrainedLanguage) peut-il être configuré manuellement ?

Le configurer manuellement, par exemple via une variable d'environnement, n'est pas recommandé, car le contournement est facile et cela ne fonctionne pas comme une véritable fonctionnalité de sécurité. Le mode de langage contraint est conçu, à l'origine, pour être un basculement automatique de PowerShell résultant de la mise en place d'un contrôle applicatif via WDAC (Windows Defender Application Control) ou AppLocker. Restreindre uniquement le mode de langage sans mettre en place de contrôle applicatif n'apporte pas de défense réellement efficace.

Je voudrais confier au support technique uniquement le redémarrage d'un service précis sur un serveur.

JEA (Just Enough Administration) est le mécanisme conçu pour cet usage. Vous définissez, dans un fichier de fonctionnalités de rôle, « cette commande, ce paramètre, uniquement cette valeur sont autorisés », puis vous l'enregistrez comme configuration de session. L'utilisateur peut alors exécuter uniquement les opérations autorisées via un compte virtuel, sans jamais détenir de privilèges d'administrateur. La session est configurée comme un serveur distant restreint, et par défaut le mode de langage y est également limité, ce qui ne laisse aucune marge pour exécuter du code arbitraire. Le contenu exécuté peut être consigné sous forme de transcription.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.