Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

De la Théorie à la pratique





















Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Ricardo Matias, incloudio : Au détour d’un spam… Ou l’étude de l’innovation cybercriminelle

mai 2016 par Ricardo Matias – Consultant en sécurité applicative, incloudio

Tout commence par un simple email reçu dans le dossier « Indésirables » avec une demande de facturation et une pièce jointe contenant un fichier Zip. Un grand classique de phishing pour les ransomwares en fait. Mais la curiosité l’emporte à regarder le contenu pour voir un énième EXE masqué en PDF ou un document Word. En fait, non ! Le fichier Zip est un fichier JavaScript : notre cybercriminel compte sur la crédulité de l’utilisateur pour qu’il clique dessus et que ce script soit exécuté. Exécuter, oui, mais que fait vraiment ce script ? C’est ce que nous avons essayé de savoir avec un peu de reverse-engineering.

Tout d’abord, nous avons passé ce script à VirusTotal afin de savoir s’il est considéré par les anti-virus comme un script malveillant. Il est repéré par 21 antivirus sur 56, comme étant, pour la plupart, un script de téléchargement malveillant.

En ouvrant le fichier avec un éditeur de texte, on remarque que le fichier est totalement illisible de la manière dont il est formaté. La première ligne laisse penser à un « packing ».

Il est très simple de dépacker ce fichier via des sites en ligne qui permettent donc de dépacker le code mais aussi de le rendre lisible tel que le site http://matthewfl.com/unPacker.html.

Le code du fichier JavaScript est alors plus compréhensible. Cependant, on remarque alors un grand nombre de lignes de code (plus de mille lignes). En analysant brièvement le code, on voit que les noms des fonctions et des variables ne sont pas parlants. De plus, certaines conditions sont incohérentes. Il s’agit d’obfuscation de code, c’est-à-dire un stratagème utilisé pour ralentir voire éviter que toute personne ne puisse aisément comprendre ce que fait le code en question. Ici, plusieurs techniques d’obfuscation semblent être utilisées.

La première et la plus évidente, consiste à ne pas utiliser des noms de variables et de fonctions évidents, c’est-à-dire que les noms donnés ne permettent pas au premier abord de connaître à quoi elles sont associées, à quelles types d’actions… Vient alors l’introduction dans le code d’actions inutiles, de variables jamais utilisées ou encore de conditions jamais remplies pour être utilisées. Le but est d’injecter un maximum de ligne pour perdre l’analyste et de dissimuler la charge active et ses actions précises. Une fois le code refactoré au strict nécessaire, il est facile de retrouver les charges utiles. On obtient alors une fonction servant de charge active permettant de créer un fichier WScript en appelant diverses fonctions Windows. Cette fonction instancie des variables et appelle les fonctions définit précédemment pour décoder les chaînes de caractère et crée alors ledit fichier.

On remarque aussi que d’autres fonctions sont appelées pour les chaînes de caractères tel que les fonctions zmK ou DnLTa. Cela aussi de cacher certaines informations tel que le site servant au téléchargement du malware ou servant de serveur C&C.

Pour décrire rapidement les opérations menées par cette fonction, elle appelle une bibliothèque (MSXML2.XMLHTTP) pour procéder à une requête XML en utilisant HTTP. Elle prépare cette requête et vérifie le bon envoi (commentaire //Status). En cas de réussite, elle créée un fichier, reprend le contenu de la réponse reçue précédemment et le stocke dans le fichier et exécute celui-ci via la commande cmd.exe /c puis supprime toute trace du présent fichier.

Nous avons pu extraire quel serveur servait de stockage et/ou de serveur C&C : le nom de domaine est enregistré au nom d’un lycée anglais. Il semble que l’un des serveurs ait été compromis et servent maintenant à l’hébergement de souches virales. De plus, en recherchant le fichier loads_nigga.php avec notre moteur de recherche favori, nous avons trouvé d’autres sites ayant été compromis et servant potentiellement à ce type d’attaques. Malheureusement, à la réception de l’email, le nom de domaine utilisé n’était plus actif et donc, il nous est impossible de savoir quel genre de malware était utilisé dans cette campagne.

En synthèse, le schéma d’attaque est devenu classique depuis 2015 mais des nouveautés apparaissent pour essayer de leurrer les outils de sécurité comme les antivirus et antispam mais aussi les analystes.

Innovant ou pas, les techniques de contournement continuent d’évoluer et les méthodes de protection restent les mêmes : vigilance et sécurité.

Vigilance des utilisateurs car ces derniers sont les déclencheurs de l’infection virale dans la plupart de ces schémas d’attaques. Il est donc essentiel de continuer à sensibiliser ses collaborateurs à ce type d’attaques afin qu’ils n’ouvrent pas de pièces jointes suspectes. Aussi, il est important d’éviter l’exécution des macros sur Word. La vigilance doit aussi se porter sur l’émetteur de l’email et la qualité de rédaction de l’email (mauvais français, pas d’accent ou pas de ponctuation). On n’ouvre pas les emails des inconnus et on ne clique pas sans réfléchir sur les pièces jointes.

Sécurité des serveurs car même si aucune donnée critique n’est stocké sur un serveur web (e-commerce, CRM…) pour n’être qu’un site institutionnel, il est primordial de gérer ses vulnérabilités et de les corriger. En effet, un serveur vulnérable aux mains d’un cybercriminel peut servir à du simple minage de bitcoin mais aussi servir pour mener des attaques, rejoindre un réseau de botnets (spams ou déni de service), de serveur C&C ou, comme dans notre cas, de distributeur de malwares. On pratique donc le vulnerability management et le patch management sur l’ensemble de ses serveurs web.




Voir les articles précédents

    

Voir les articles suivants