Obfuscation du PowerShell : s’infiltrer en profitant de la confusion, Partie II

Cet article fait partie de la série « Obfuscation du PowerShell ». Consultez les autres parties : Obfuscation du PowerShell : s’infiltrer en profitant de la confusion, Partie I Obfuscation du PowerShell : s’infiltrer en profitant...
Michael Buckbee
4 minute de lecture
Dernière mise à jour 28 octobre 2021

Cet article fait partie de la série « Obfuscation du PowerShell ». Consultez les autres parties :

Prenons un peu de recul par rapport à l’exercice du dernier billet, qui consistait à rendre les commandes PowerShell illisibles. Le recours à l’obfuscation de code pour éviter d’être détecté par les antivirus et autres outils de recherche de menaces (ou pour éviter l’ingénierie inverse) n’a rien de nouveau. En cherchant un peu dans les archives, on trouve ceci (écrit en Perl).  Pas de quoi en faire un plat, alors ?

La principale différence vient du fait que les hackers peuvent se passer de programme malveillant en se contentant d’utiliser ce bon vieux PowerShell à presque toutes les étapes d’une attaque. Et grâce à l’obfuscation, ce système basé sur le PowerShell se pare d’un « bouclier occulteur » efficace.  Et nous savons tous que les boucliers occulteurs apportent un avantage imparable à leur propriétaire !

Les équipes de sécurité informatique doivent prendre en compte cette nouvelle menace.

Accédez à une série de cours sur l’automatisation des tâches Active Directory à l'aide de PowerShell et obtenez 3 crédits CPE (cours en anglais)

"PowerShell peut vous aider à automatiser des choses allant de la création de rapports AD à la création de boîtes aux lettres Exchange... et même à contrôler votre système d'arrosage."

La journalisation Windows PowerShell est assez efficace !

Apparemment, je suis allé un peu vite en besogne la dernière fois, lorsque j’ai donné mon avis sur les capacités de journalisation de PowerShell, activées via la Gestion des stratégies de groupe. J’ai montré un exemple dans lequel j’ai téléchargé et exécuté une cmdlet PowerShell à partir d’un site Web distant :

Je pensais que la journalisation PowerShell ne montrerait pas le programme malveillant intégré à la chaîne téléchargée depuis le site Web.

Je me trompais.

Si vous activez la journalisation du module PowerShell via la Gestion des stratégies de groupe, le code PowerShell distant apparaît en effet dans le journal. Pour vous rafraîchir la mémoire, j’utilisais PowerShell version 4 et (je pense) la dernière version de Windows Management Framework (WMF), censée autoriser une journalisation plus précise.

Une journalisation PowerShell plus efficace peut être activée dans la Gestion des stratégies de groupe !

C’est un détail mineur, mais cela signifie que les hackers obfusqueraient aussi la charge utile initiale.

Je pensais aussi à tort que les obfuscations obtenues par Invoke-Obfuscation n’apparaîtraient pas sous forme désobfusquée dans le journal. À titre d’exemple, dans le dernier billet, j’ai essayé une des obfuscations de chaîne pour produire ceci :

Il ne s’agit, en fait, que d’une concaténation de chaînes séparées assemblées au moment de l’exécution pour former une cmdlet.

Pour les besoins de ce billet, j’ai essayé d’autres options de brouillage de Invoke-Obfuscation pour voir comment la ligne de commande apparaît dans le Journal des événements.

J’ai testé cette option de réorganisation de chaînes (ci-dessous) qui exploite plusieurs astuces dans PowerShell.

Vous avez remarqué la première partie $env:comspec[4,15,25] ? Elle prend la variable d’environnement $env:comspec et extrait les 4ème, 15ème et 25ème caractères pour générer « IEX », l’alias PowerShell de Invoke-Expression. L’opérateur join prend le tableau et le convertit en chaîne.

La portion suivante de cette expression PowerShell utilise l’opérateur de mise en forme f. Si, dans vos travaux de programmation, vous avez déjà utilisé des commandes de type sprintf, vous reconnaîtrez immédiatement ces capacités. Toutefois, avec PowerShell, vous avez la possibilité de préciser la position de l’élément dans la liste de paramètres extraite pour obtenir la chaîne. Par conséquent, {20}, {5}, {9}, {2} commencent à assembler encore une autre cmdlet Invoke_Expression .

Oui, cela devient très vite compliqué !

J’ai aussi laissé Invoke-Obfuscation opérer une sélection à la carte dans son menu d’obfuscation. Il a généré le charabia suivant :

Après tous ces essais, j’ai consulté l’Afficheur d’événements et constaté qu’une fois les capacités de journalisation activées Windows peut  percer le brouillard et déterminer le PowerShell sous-jacent :

L’obfuscation est lourde, mais une fois la journalisation du Module Powershell activée, les cmdlets sous-jacentes sont visibles dans le journal.

Cela signifie-t-il que l’obfuscation PowerShell est toujours désobfusquée dans le Journal des événements Windows et que les détecteurs de menaces ont la possibilité d’établir des correspondances entre les modèles comme ils le font habituellement ?

La réponse est non !

Invoke-Obfuscation vous laisse aussi coder les scripts PowerShell en ASCII brut, Hex, et oui, même en binaire. Et cette obfuscation du codage semble être plus forte que la journalisation des événements :

la cmdlet sous-jacente représentée par cette obfuscation Hex n’a pas été détectée.

Quantifier la confusion

Il semblerait donc que les hackers aient l’avantage : un bouclier occulteur qui rend leurs scripts invisibles des systèmes de défense ou, tout au moins, les rend extrêmement confus.

La présentation donnée à la conférence Black Hat, mentionnée dans le premier billet, fait référence aux travaux menés par Lee Holmes, de Microsoft, oui ce même Lee Holmes, portant sur la détection de programme malveillants obfusqués au moyen de modèles probabilistes et de techniques d’apprentissage automatique.

Si cela vous intéresse, vous pouvez lire l’article présenté lors de la conférence. Holmes a emprunté des techniques au traitement du langage naturel pour analyser la fréquence des caractères dans les scripts PowerShell obfusqués par rapport aux formes bénignes. Il y a des différences !

Ces points qui se détachent sous la tendance principale montrent que la fréquence des caractères du PowerShell obfusqué diffère de celle des scripts standard.

Du reste, Holmes est passé à un modèle de régression logistique plus compliqué, consistant principalement à classer le code PowerShell en scripts malveillants obfusqués et scripts normaux. Il a ensuite mis son logit à l’épreuve en examinant minutieusement l’analyse syntaxique des commandes effectuée par PowerShell. Il a ainsi rassemblé des statistiques sur les niveaux d’imbrication, etc. et identifié un système de classification convenable présentant une précision d’environ 96 %. Loin d’être parfait, mais un bon début !

Quelques réflexions

Si j’adresse un coup de chapeau à Microsoft pour les améliorations apportées à la journalisation de PowerShell, les lacunes sont toujours suffisamment nombreuses pour que l’exécution des scripts reste indétectable. Et cela suppose que les équipes informatiques sachent activer la journalisation PowerShell !

Le modèle d’apprentissage automatique de Lee Holmes suggère qu’il est possible de détecter ces scripts furtifs dans la nature.

Toutefois, cela signifie que l’on en revient à la recherche de programmes malveillants, une approche dont nous savons qu’elle n’est pas suffisamment efficace. Vous ne pouvez pas rivaliser avec les hackers qui changent et adaptent leur code sans relâche pour tromper les détecteurs.

Où est-ce que je veux en venir ? Bien sûr, vous activez la journalisation PowerShell et vous vous efforcez de maintenir votre logiciel de détection à jour, mais au final, vous devez disposer d’une solide défense secondaire basée sur la recherche d’activités de post-exploitation impliquant d’accéder aux fichiers de vos données sensibles.

Vous devez intercepter ce qui passe entre les mailles des outils d’analyse des journaux PowerShell ! Demandez une démonstration dès aujourd’hui.

Que dois-je faire maintenant ?

Vous trouverez ci-dessous trois solutions pour poursuivre vos efforts visant à réduire les risques liés aux données dans votre entreprise:

1

Planifiez une démonstration avec nous pour voir Varonis en action. Nous personnaliserons la session en fonction des besoins de votre organisation en matière de sécurité des données et répondrons à vos questions.

2

Consultez un exemple de notre évaluation des risques liés aux données et découvrez les risques qui pourraient subsister dans votre environnement. Cette évaluation est gratuite et vous montre clairement comment procéder à une remédiation automatisée.

3

Suivez-nous sur LinkedIn, YouTube et X (Twitter) for pour obtenir des informations sur tous les aspects de la sécurité des données, y compris la DSPM, la détection des menaces, la sécurité de l’IA et plus encore.

Essayez Varonis gratuitement.

Obtenez un rapport détaillé sur les risques liés aux données basé sur les données de votre entreprise.
Se déploie en quelques minutes.

Keep reading

Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.

obfuscation-du-powershell-:-s’infiltrer-en-profitant-de-la-confusion,-partie-i
Obfuscation du PowerShell : s’infiltrer en profitant de la confusion, Partie I
Cet article fait partie de la série « Obfuscation du PowerShell ». Consultez les autres parties : Obfuscation du PowerShell : s’infiltrer en profitant de la confusion, Partie I (Vous êtes ici) Obfuscation du PowerShell :...
5-façons-de-protéger-active-directory-avec-varonis
5 façons de protéger Active Directory avec Varonis
Le moyen le plus rapide de s’infiltrer dans un réseau est de passer par Active Directory (AD) – c’est lui qui détient les clés de tout le royaume. Si vous devez accéder...
scripts-powershell :-tutoriel-destiné-aux-débutant(e)s
Scripts PowerShell : tutoriel destiné aux débutant(e)s
Vous découvrez les scripts PowerShell ? Parcourez ces tutoriels pour apprendre à écrire et exécuter des scripts de base, des cmdlets PowerShell, des alias, des tubes et bien plus encore.
guide-de-portée-des-variables-dans-powershell-:-utilisation-de-la-portée-dans-les-scripts-et-les-modules
Guide de portée des variables dans PowerShell : Utilisation de la portée dans les scripts et les modules
La portée des variables dans PowerShell peut être source de confusion lors de l'écriture de scripts et de fonctions. Cet article traite des portées ou étendues (« scopes ») PowerShell en relation avec les scripts et les modules.