Incursion dans le piratage sans malware, Partie III : Scripts VBA obfusqués pour le fun et le profit

Après avoir traité des techniques de piratage sans malware dans les deux derniers billets, nous sommes prêts à nous attaquer à un spécimen dangereux. Je puise dans le site Hybrid Analysis pour trouver ces féroces créatures. Même si les informations fournies par HA pour chaque échantillon (appels au système, trafic Internet, etc.) devraient suffire à satisfaire la plupart des professionnels de la sécurité informatique, il y a certains avantages à explorer un peu plus en profondeur un de ces échantillons de scripts VBA lourdement obfusqués pour voir ce qu’ils ont vraiment dans les tripes.

Si vous jouez à la maison, je suggère de faire cela dans un bac à sable tel que AWS ou, si vous utilisez votre propre ordinateur portable, de vous assurer d’afficher les commentaires pour les appels du système qui lancent le PowerShell.

Les mains dans le cambouis des scripts VBA obfusqués

Le malware que j’ai fini par trouver dans Hybrid Analysis est un script VBA imbriqué dans un document Word. Comme je l’ai déjà dit la dernière fois, pour voir le script réel, vous devrez utiliser l’OfficeMalScanner de Frank Boldewin.

Après avoir extrait le script dont nous avons eu un aperçu dans le dernier billet, j’ai décidé de charger la bête dans la bibliothèque de macros de MS Word. J’ai ensuite mis les mains dedans (glurps) à l’aide du débogueur intégré.

Mon objectif était de mieux comprendre les obfuscations afin de jouer aux analystes en criminologie et découvrir les problèmes auxquels ils sont confrontés.

Si c’est la première fois que vous examinez un de ces scripts obfusqués dans un débogueur, vous allez probablement avoir quelques sueurs froides lorsque vous vous fraierez un chemin dans le code d’une complexité étourdissante et vous ouvrirez de grands yeux lorsque la variable L_JEK se verra affecter la chaîne « 77767E6C797A6F6 ».

Une véritable partie de plaisir.

Avec ce script VBA obfusqué, j’ai appris que seule une très petite part du script fait le véritable boulot. Le reste ne sert qu’à brouiller les pistes.

Puisqu’on aborde les choses sérieuses, j’ai fait une capture d’écran de l’infime portion de code qui effectue la manœuvre fatale consistant à configurer la ligne de commande PowerShell qui sera lancée au final par la macro VBA.

Un jeu d’enfant. Le code VBA conserve la représentation hexadécimale de la ligne de commande dans quelques variables puis la traduit en une chaîne de caractères. Le seul « piège » est que les valeurs hexadécimales ont été décalées de 7.

Donc, par exemple, la première partie de la chaîne hexadécimale provient de L_JEK (voir plus haut). Si vous prenez 77 et retirez 7, vous obtenez la valeur hexadécimale 70. Faites de même pour 76, et vous obtenez la valeur hexadécimale 6F. Cherchez-les dans une table ascii et vous verrez qu’elles correspondent aux deux premières lettres de « powershell ».

Cette obfuscation n’est pas très futée, mais elle n’a pas besoin de l’être !

Tout ce qu’elle doit faire, c’est franchir les antivirus qui recherchent des mots clés évidents ou leurs représentations ascii. Et cet exemple précis y parvient assez bien.

Pour terminer, lorsque le code a créé la ligne de commande, il la lance via la fonction CreateProcess (ci-dessous).

Réfléchissez-y. Un document Word a été envoyé dans un e-mail de phishing à un employé. À l’ouverture de ce document, ce script VBA lance automatiquement une session PowerShell pour démarrer la phase suivante de l’attaque. Aucun fichier binaire n’est impliqué, et les scripts soigneusement obfusqués échappent aux scans.

Diabolique !

Pour en savoir plus, j’ai extrait une autre macro de Hybrid Analytics (ci-dessous) simplement pour voir ce que l’on peut trouver d’autre. Ce second exemple fait la même chose que le code ci-dessus.

Il est un peu plus astucieux dans sa façon de créer la ligne de commande. Il contient une fonction de décodage nommée « d » qui filtre les caractères d’une chaîne de base en la comparant à une chaîne secondaire.

Digne d’un collégien, mais cela a le mérite de faire le travail : le code échappe aux antivirus et trompe l’équipe informatique qui jette un œil rapide sur les journaux pour rechercher toute activité suspecte.

Prochain arrêt

Dans ma première série de billets sur l’obfuscation, j’ai montré que la journalisation des événements de Windows capture suffisamment d’informations sur les sessions PowerShell — si vous avez activé les modules appropriés — pour procéder à une analyse approfondie après les faits.

Bien entendu, tout le génie des attaques sans malware réside dans la difficulté à déterminer si les scripts PowerShell agissent de manière répréhensible en cours d’exécution en procédant à l’analyse syntaxique de base de la ligne de commande par le biais des journaux des événements.

Pourquoi ?

Des sessions PowerShell sont lancées en permanence, et le PowerShell toxique d’un hacker peut présenter des similitudes avec un autre outil PowerShell de l’administrateur informatique. Par conséquent, si vous émettez une alerte à chaque fois qu’un script télécharge quelque chose depuis Internet, vous enverrez bien trop de faux positifs.

Bien sûr, tout cela nous mène au sujet favori de ce blog : l’incapacité des défenses du périmètre à bloquer les attaques de phishing et les malwares FUD, et l’efficacité de l’Analyse du comportement des utilisateurs.

En bref : essayer d’empêcher les hackers de franchir les défenses du périmètre est une bataille perdue d’avance. La meilleure stratégie consiste à identifier les événements inhabituels au niveau des accès aux fichiers et des applications puis de désactiver les comptes ou de prendre une autre mesure pour remédier à la faille.

La leçon est terminée pour aujourd’hui. Dans le prochain billet, nous examinerons des types plus perfectionnés d’attaques sans malware.