Entre administrateurs systèmes et experts en cybersécurité, le débat est récurrent : faut-il bloquer l’exécution des scripts PowerShell ? D’un côté, on vante sa puissance pour automatiser et sécuriser les tâches. De l’autre, on redoute sa capacité à lancer des attaques invisibles. Cet article propose un tour d’horizon des risques, des usages légitimes, et des meilleures pratiques à adopter selon votre profil utilisateur.
Qu’est-ce que la stratégie d’exécution PowerShell ?
La stratégie d’exécution de PowerShell détermine les conditions dans lesquelles les scripts peuvent être exécutés sur un système Windows. Elle vise à prévenir l’exécution accidentelle ou non autorisée de scripts potentiellement malveillants. Toutefois, il est essentiel de comprendre que cette stratégie n’est pas une mesure de sécurité infaillible car elle peut être contournée.
PowerShell propose plusieurs niveaux de stratégie d’exécution :
- Restricted : Par défaut sur les clients Windows, cette stratégie empêche l’exécution de tous les scripts. Seules les commandes interactives sont autorisées.
- AllSigned : Tous les scripts doivent être signés par un éditeur de confiance.
- RemoteSigned : Les scripts téléchargés depuis Internet doivent être signés par un éditeur de confiance. Les scripts locaux non signés sont autorisés.
- Unrestricted : Tous les scripts peuvent être exécutés, mais une alerte est affichée pour ceux provenant d’Internet.
- Bypass : Aucune restriction ni avertissement. Cette stratégie est souvent utilisée dans des environnements spécifiques où la sécurité est gérée autrement.
- Undefined : Aucune stratégie définie. Si toutes les portées sont indéfinies, la stratégie effective est Restricted sur les clients Windows.
PowerShell : outil d’administration ou vecteur d’attaque ?
PowerShell est l’un des outils les plus puissants de l’écosystème Windows : conçu pour automatiser la gestion des systèmes, il permet d’accéder à des fonctions système profondes, d’exécuter des scripts à distance et de gérer la configuration des postes clients. Ces capacités en font un allié indispensable pour les administrateurs mais également un redoutable levier pour les attaquants. Les hackers et les pentesters exploitent fréquemment PowerShell pour exécuter du code malveillant en mémoire, sans laisser de trace sur le disque et contourner les antivirus classiques. Son intégration native à Windows et sa compatibilité avec .NET en font un vecteur d’attaque particulièrement difficile à détecter.
Face à cette dualité, la question d’un durcissement de la stratégie d’exécution revient souvent. Faut-il restreindre, voire désactiver totalement l’exécution de scripts PowerShell ? Si cette mesure peut limiter certaines attaques opportunistes, elle reste symbolique dans les environnements avancés : de nombreux contournements sont possibles et les menaces actuelles reposent souvent sur des techniques bien plus sophistiquées. Le véritable enjeu n’est donc pas tant d’interdire PowerShell, mais de surveiller, filtrer et tracer son usage à travers des outils de journalisation, de signature de scripts et de détection comportementale.
Comment vérifier la stratégie d’exécution PowerShell actuelle ?
Avant de modifier quoi que ce soit, il est essentiel de connaître la stratégie d’exécution en place sur votre système. PowerShell permet de le faire en une seule commande :
Get-ExecutionPolicy -List
Cette commande affiche la stratégie d’exécution par niveau de priorité (MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine). La stratégie effectivement appliquée est celle avec la priorité la plus haute, selon l’ordre listé.
Par exemple :
Scope ExecutionPolicy
----- ----------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine RemoteSigned
Dans ce cas, c’est la stratégie RemoteSigned définie au niveau LocalMachine qui s’applique. En l’absence totale de configuration (Undefined partout), c’est la stratégie par défaut qui s’applique : Restricted sur Windows client, RemoteSigned sur Windows Server.
Les bonnes pratiques pour sécuriser les postes Windows
Par défaut, la plupart des postes Windows sont configurés en Restricted, ce qui empêche l’exécution de tout script PowerShell. Si cela peut sembler sécurisant, cette restriction totale est vite contournée ou désactivée par les utilisateurs ou les logiciels. Une alternative plus équilibrée consiste à passer en RemoteSigned qui autorise les scripts locaux non signés tout en exigeant une signature numérique pour les scripts téléchargés depuis Internet. Cela réduit considérablement les risques liés aux malwares véhiculés par email ou sites malveillants, sans bloquer les tâches courantes des administrateurs.
Signer ses propres scripts PowerShell pour garantir leur intégrité
Pour aller plus loin dans la sécurité, il est fortement recommandé de signer tous les scripts internes. Cela permet de vérifier qu’ils proviennent d’une source fiable et qu’ils n’ont pas été modifiés. Il est possible de générer un certificat autosigné en interne ou d’utiliser une autorité de certification (CA) de l’entreprise. Signer les scripts devient alors une barrière contre les injections malveillantes, tout en assurant une traçabilité des actions automatisées.
Appliquer les règles de sécurité via les GPO (Group Policy)
Les stratégies de groupe (GPO) permettent d’uniformiser et de verrouiller la configuration des postes Windows dans un parc informatique. Il est possible d’y définir la stratégie d’exécution PowerShell, d’empêcher les modifications locales et d’appliquer d’autres restrictions spécifiques. Cela évite les dérives manuelles et garantit que les postes restent conformes aux standards de sécurité établis. Pour les environnements professionnels, les GPO représentent la colonne vertébrale d’une stratégie cohérente de sécurisation.
Activer la journalisation PowerShell (log ID 4104, etc.)
Même avec une stratégie bien définie, la surveillance active des actions PowerShell reste indispensable. Windows Event Viewer permet d’activer la journalisation détaillée via l’option « Script Block Logging », qui enregistre chaque bloc de script exécuté (événement 4104).
Ces logs sont essentiels pour détecter des comportements suspects, identifier des tentatives de contournement ou enquêter après une intrusion. Ils peuvent être centralisés via un SIEM pour une détection en temps réel.
Sécuriser sans bloquer : l’équilibre à trouver
La sécurisation de PowerShell ne passe pas uniquement par l’interdiction ou la désactivation. Elle repose sur un ensemble de bonnes pratiques : stratégie d’exécution adaptée, signature des scripts, centralisation des règles et audit continu. Plutôt que de désactiver un outil aussi utile que PowerShell, il est plus pertinent de l’encadrer, de le surveiller et de l’inscrire dans une démarche de défense en profondeur. C’est à cette condition que les postes Windows peuvent rester à la fois efficaces et protégés.
Sources et ressources
Cet article vous a-t-il été utile ?
