Aller au contenu | Aller au menu | Aller à la recherche

blog.ruliane.net

Étude de cas d'un malware

Tout le monde a déjà reçu un e-mail suspect, venant d'un inconnu, et demandant d'exécuter une pièce jointe sans délai. Et naturellement, tout internaute sensé supprime rapidement ce message dangereux.
Pour une fois, j'ai préféré voir ce qui se cache derrière ces messages douteux.

Tout a commencé par un mail de hameçonnage. Tout à fait banal, sauf que celui-ci était suffisamment bien fait pour attirer mon attention. Voyez plutôt :
Message_1.png

Je suis le premier à dire qu'il faut être benêt pour ouvrir la première pièce jointe venue. Et pourtant, je dois reconnaître que cette campagne de fishing est très bien faite ; suffisamment pour berner un utilisateur lambda, notamment en milieu professionnel.
Qu'est-ce qui fait la force de ce message ?

  • Il se prétend avoir été envoyé par Administrator@mondomaine, ce qui donne une légitimité au message.
  • Le message est concis et vague, mais suffisamment technique pour embrouiller un utilisateur non-averti.
  • Plus fort : la signature reprend le domaine précédé de "http://www". Il se trouve que cette adresse n'existe pas dans mon cas, mais dans la plupart des cas cette simple ligne achèvera de convaincre du bien-fondé du message.

La grande force de ce message, à mon sens, est sa simplicité. Bref : il tape juste.

Petite curiosité en passant : j'ai reçu, la même nuit, un tout autre message de fishing avec la même pièce jointe. Lui aussi est plutôt bien fait :
Message_2.png

Plutôt que de classer ce message une fois pour toutes, j'ai entrepris de décortiquer la pièce jointe pour comprendre le fonctionnement et le but de cette campagne.

La pièce jointe est un fichier .doc. Il ne s'agit pas d'un fichier exécutable et on connaît d'ores et déjà la cible potentielle : l'utilisateur lambda sous Windows, utilisant Microsoft Word. Bref, probablement une attaque non-ciblée classique.

J'envisage deux vecteurs d'attaque possible :

  • soit le message exploite une faille de Word pour infecter l'ordinateur de la victime ;
  • soit il lance une macro Word pour arriver à ses fins.


Avant toute chose, je sais que je vais manipuler des fichiers nuisibles. C'est pourquoi toutes les opérations seront effectuées dans un environnement virtuel déconnecté du réseau.

Je télécharge donc la pièce jointe et me retrouve avec un fichier Exchange_id4187885.doc. Afin d'en savoir un peu plus sur lui, voici ce que nous apprend la commande file de Linux : file.png

Pas de doute, il va falloir l'ouvrir avec Word pour constater son comportement. C'est ce que je fais (non sans avoir vérifié que l'exécution des macros est désactivé) et me retrouve face à ce document : Word.png

Décidément, son créateur est très malin. Voyez l'astuce pour pousser l'utilisateur à activer les macros : un charabia incompréhensible et insensé, précédé de la mention If you document has incorrect encoding - enable macro (la faute est d'origine).

Me voilà fixé : il s'agit bien d'utiliser des macros pour effectuer les basses besognes. Qu'à cela ne tienne, voyons ce que font ces macros.

Premier problème : les macros sont protégés par un mot de passe. J'ignorais que c'était possible. Après recherche sur internet, je trouve ce script Powershell permettant de retirer la protection d'une macro.
Note : il ne s'agit pas simplement de lancer le script. Il faut ensuite ouvrir le document, puis sur chaque module, écraser le mot de passe avec un nouveau et désactiver la protection.

Le document comporte l'objet ThisDocument ainsi que deux modules : Module1 et Module2. Voyons ThisDocument :
Macro.png

Ici commence un long travail. En effet, le code est "obfusqué", c'est-à-dire rendu incompréhensible par un humain. Je dois donc l'adapter pour le comprendre. Je détaille peu cette étape ici, bien ce que ce soit la plus longue. C'est la première fois que j'ai affaire à ça, et j'ai donc tout fait à la main. Peut-être existe-t-il des outils pour faciliter la tâche.
Voici les différentes actions, sans ordre particulier :

  • supprimer les lignes inutiles ;
  • remplacer les constantes par leur valeur ;
  • ajouter quelques commentaires et renommer certaines fonctions ;
  • éventuellement, regrouper le code dans ThisDocument ;


Une fois la macro lisible, je peux étudier son fonctionnement :

La macro exécutée fait appel à des fonctions de Module1 et Module2. Elle télécharge des informations depuis un serveur (probablement piraté) afin de générer trois fichiers .bat, .vbs et .ps1, eux-mêmes obfusqués.
Puis ces trois fichiers sont exécutés. Leur tâche est de récupérer un fichier exécutable depuis internet, et le lancer. Enfin, ils s'auto-suppriment afin de ne laisser aucune trace sur la machine de la victime.
Malware.png

Il est intéressant de noter que le fichier exécutable était vraisemblablement téléchargé depuis un serveur piraté, mais qu'à l'heure où j'écris ce billet, le responsable de la machine a dû s'apercevoir que son serveur a été compromis car il a pris des mesures conservatoires : en effet, le fichier .exe n'est plus accessible, le port 80 (HTTP) est filtré et le site a été basculé sur le port 81.
nmap.png
Alors, la propagation de ce malware est-elle stoppée ? Pas forcément. Souvenez-vous, une grosse partie des scripts intermédiaires est récupérée depuis internet. Il suffit donc au pirate de mettre à jour ces informations pour changer l'URL de téléchargement du fichier exécutable. Finalement, la macro n'est qu'un point d'entrée. La suite est presque entièrement pilotable grâce à des morceaux de code et des fichiers que le pirate a pris soin de répartir sur différents serveurs.

Étant donné que le fichier exécutable n'est plus accessible, impossible de pousser les investigations plus loin... pour cette fois-ci.

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

La discussion continue ailleurs

URL de rétrolien : http://blog.ruliane.net/index.php?trackback/24

Fil des commentaires de ce billet