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 de la confusion, Partie II (Vous êtes ici)

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.

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.

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 :

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 :

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 !

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.