S’il y a bien un sujet chaud patate en ce moment, c’est tout ce qui touche de près ou de loin au phishing. Lorsque je regarde mon feed d’actualité LinkedIn, il n’y a pas un jour où je vois des posts sur le sujet… Ça peut aller d’un post décryptant l’utilisation d’un faux site à des attaques de phishing en masse ! Ainsi, vous devez redoubler de vigilance sur les e-mails que vous envoyez pour qu’ils ne soient pas considérés comme du spam et/ou du phishing mais aussi sur les e-mails que vous recevez pour éviter de vous faire voler des données professionnelles voir personnelles… Il y a quelques longues semaines déjà, je recevais un e-mail envoyé par Badsender… Hum… Pas vraiment à vrai dire ! Bref, je vous propose qu’on le décortique et décrypte afin de savoir comment j’ai su qu’il ne venait pas vraiment de nos serveurs de messagerie !
L’expéditeur… Le trompe œil par excellence !
Mon premier réflexe quand je reçois un e-mail est de toujours regarder le trio libellé expéditeur, adresse expéditrice, objet. Et je dois dire qu’avec cet e-mail, tout ici est fait pour tromper ! Regardons chaque élément :
Le libellé expéditeur
Le libellé expéditeur utilisé est plutôt rassurant puisqu’il reprend le nom de la société : badsender.com
Si vous êtes abonnés à notre newsletter, le libellé expéditeur reste toujours le même à savoir Badsender (avec un B majuscule). J’ai quand même regardé tout ce qui a été envoyé via notre nom de domaine (que ce soit des BAT, des e-mails internes ou autres notifications envoyées par notre hébergeur), je n’ai trouvé aucun autre libellé expéditeur.
On ne va pas se le cacher mais le fait de mettre badsender.com fait que l’on a déjà des suspicions sur la légitimité de cet e-mail même si l’erreur reste humaine !
L’adresse expéditrice
Au premier abord il y a de quoi tromper monsieur tout le monde ! L’adresse utilisée appartient à notre nom de domaine : mailer-daemon@badsender.com… Elle peut paraître légitime ! Il faut savoir que l’alias mailer-daemon est généralement utilisé lorsqu’un e-mail n’a pas pu être délivré, dans ce cas un message de non-délivrance est envoyé à l’expéditeur. Par contre, le mailer-daemon n’interviendra pas pour vous signaler un problème de mail entrant…
J’ai tout de même réalisé deux vérifications qui ont amené une certitude… Cet e-mail ne vient vraiment pas de nous, voici le pourquoi du comment !
— J’ai envoyé un e-mail depuis ma boite pro vers une adresse qui n’existe pas : fsfkfergkjdfklsdjferlkjfekjf@gmail.com et j’ai eu le retour ci-dessous :
Si l’on regarde l’expéditeur de l’e-mail (l’adresse complète utilisée est MAILER-DAEMON@infomaniak.com), celui-ci n’est autre que notre hébergeur Infomaniak. Ceci indique qu’en cas de problème avec notre messagerie, c’est bien leur adresse mailer-daemon qui est utilisé et non la nôtre.
— J’ai également vérifié si l’adresse expéditrice existait bien chez nous et j’ai eu la réponse suivante : 550 5.1.1 mailer-daemon@badsender.com: Recipient address rejected: User unknown in virtual mailbox table
Donc là, pas de doute à avoir ! Une adresse expéditrice qui n’existe pas pour envoyer des e-mails… Ce n’est clairement pas notre genre ! De plus, lorsque nous avons changé d’infrastructure IT, nous n’avons pas migré ou configuré cette adresse et la seule adresse fournie gracieusement par Infomaniak était POSTMASTER).
L’objet
Enfin, l’objet utilisé Erreur de courrier entrant peut paraître légitime… N’ayant jamais eu de problème ou de notification avec Infomaniak, je me suis amusé à simuler des envois vers une adresse qui n’existe pas pour voir comment réagissent nos chers FAI français (Free, La Poste, Orange et SFR). Voici les résultats :
- Free › Adresse expéditrice : mailer-daemon@smtp.free.fr › Libellé expéditeur : Mail Delivery System › Objet : Undelivered Mail Returned to Sender
- La Poste › Adresse expéditrice : mailer-daemon@laposte.net › Libellé expéditeur : Mail Delivery System › Objet : Undelivered Mail Returned to Sender
- Orange › Adresse expéditrice : mailer-daemon@orange.fr › Libellé expéditeur : Mail Delivery System › Objet : Undelivered Mail Returned to Sender
- SFR › Adresse expéditrice : mailer-daemon@sfr.fr › Libellé expéditeur : Mail Delivery System › Objet : Undelivered Mail Returned to Sender
Ce qui est sûr… Ni Free, ni La Poste, ni Orange, ni SFR n’utilise un objet en français ! Est-ce que une méconnaissance de la personne malveillante sur le sujet ?
L’entête SMTP… La diseuse de bonne aventure !
Après n’avoir pas vraiment été très convaincu par l’expéditeur de l’e-mail, je voulais savoir d’où cet e-mail provenait. Et là, il n’y a qu’une chose à faire, aller vérifier l’entête SMTP de l’e-mail, il vous dira tout… ou presque ! D’ailleurs, je vous conseille d’aller lire un article que j’avais écrit sur le sujet : Comment lire une entête SMTP ?
Même si toutes les informations contenues dans une entête SMTP ne serviront pas, certaines donnent de précieux indices sur l’expéditeur. Ainsi, dans le cadre de mon analyse, je me suis exclusivement concentré sur les éléments importants (et leur résultat) de l’entête. Toutefois, un élément va manquer à l’appel, à savoir la signature DKIM. Ceci reste logique sinon ça voudrait dire que ce pirate ait réussi à s’introduire sur un de nos outils de routage pour émettre des e-mails en notre nom ou qu’il a réussi à déchiffrer notre signature DKIM !
L’adresse return-path
Le premier élément à regarder est l’adresse return-path, il y contient le domaine MailFrom, là où l’authentification SPF se trouve :
- Adresse return-path › return-path: <mailer-daemon@badsender.com>
Ici, pas de mauvaises surprises, la personne malveillante a opté pour notre nom de domaine sur les domaines liés à l’expéditeur (FROM) et à l’enveloppe de l’e-mail (MAILFROM).
L’IP
Deuxième élément de ma liste, l’IP qui a été utilisée. Il suffit de chercher d’où elle provient grâce à son enregistrement WHOIS (cf. sa carte d’identité).
Besoin d'aide ?
Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.
- IP › received: from [185.157.77.30] (185.157.77.30 [185.157.77.30]) by ns.oshu.co.jp (deepsmtpd.so)
Je vérifie toujours cette information via le site Domain Tools. J’y retrouve deux informations clés :
— IP Location : Ukraine Kremenchuk Zemlyaniy Dmitro Leonidovich
— ASN : AS42159 DELTAHOST-AS, UA (registered Aug 17, 2009)
Et là bingo ! Les informations que je trouve sur l’enregistrement WHOIS de l’IP me disent clairement qu’elles ne proviennent pas d’une de nos plateformes de routage, ni de notre hébergeur (qui est Suisse) mais d’un hébergeur ukrainien appelé Deltahost !
L’authentification SPF
Troisième élément de ma liste, vérifier le résultat produit par l’authentification SPF :
- Authentification SPF › authentication-results: mx.infomaniak.com; spf=permerror smtp.mailfrom=badsender.com
Vu que l’IP est totalement inconnue pour nous, le résultat produit par la vérification de SPF est une erreur permanente, ce qui est logique car nous n’avons jamais autorisé l’IP appartenant à Deltahost à émettre des e-mails avec notre nom de domaine. Autre point important, n’ayant pas déclaré de qualifieur SPF -all mais seulement ~all, l’e-mail frauduleux a été accepté par Infomaniak.
L’authentification DMARC
Dernier élément de ma liste, vérifier le résultat produit par l’authentification DMARC :
- Authentification DMARC › authentication-results: mx.infomaniak.com; dmarc=fail (p=none dis=none) header.from=badsender.com
Le résultat est sans appel : FAIL ! Ce qui est logique puisque SPF étant en échec et DKIM non présent, nous avons ici 0% de conformité. Malheureusement pour nous, notre politique de sécurité DMARC étant à NONE, l’e-mail n’a pas été refusé, ni placé en spam 🙁
Le message… Le trompeur trompé !
Dernier point à analyser, le contenu de l’e-mail. Et là, j’ai eu un air de déjà-vu ! J’entends par là que le contenu ne m’est pas inconnu, je l’ai déjà vu quelque part… J’ai donc décidé de fouiller dans mes anciens e-mails avant de trouver ce que je cherchais…
Avant de passer chez Infomaniak, nous utilisions la suite Office 365 et j’avais eu cet e-mail à plusieurs reprises quand j’envoyais un e-mail à un destinataire dont l’adresse e-mail n’existait pas ou plus ! Bref, je suis tombé sur un copy-cat ou un amoureux de Microsoft (je vous laisse choisir la bonne réponse :p). Il ne s’est contenté de changer deux ou trois informations pour le rendre crédible !
Dernière chose, l’URL du CTA n’a aucun sens et ressemble typiquement à ce que l’on peut voir dans des e-mails de phishing :
Pas terrible ! Il aura pu faire mieux…
Les solutions pour se prémunir… Un minimum !
À chaque problème… sa solution ! Je n’ai pas été le seul chez Badsender à recevoir cet e-mail. Ça a été l’occasion pour nous de renforcer nos défenses en durcissant les règles de sécurité sur nos domaines et en particulier badsender.com.
- L’enregistrement SPF passe de SOFTFAIL (~all) à STRICT (-all) : l’objectif ici est de dire aux fai/webmails que si l’IP ne figure pas sur la liste des IP autorisées, il doit rejeter l’e-mail !
- L’enregistrement DMARC passe de NONE à QUARANTINE puis REJECT (début 2023) : l’objectif ici est de dire aux fai/webmails appliquant DMARC que tout e-mail en échec ou non conforme à DMARC doit être mis en spam (QUARANTINE) puis rejecté (REJECT).
- Continuer à monitorer DMARC pour connaitre l’activité de nos domaines : vu que nous durcissons notre politique de sécurité, il est important pour nous de savoir si des flux légitimes ne seraient pas conformes à DMARC (et donc les rendre conforme) et si des personnes malveillantes (comme notre faux ami) cherche à utiliser nos domaines pour émettre du spam !
- Réduire le nombre d’outils de routage que l’on utilise, garder toujours la même configuration (adresse expéditrice vs. IP) pour reconnaitre facilement nos e-mails.
- Faire de la prévention en interne (chacun signale les e-mails potentiellement dangereux qu’il reçoit !) mais aussi auprès de nos clients via les coaching / audits ! Et pour finir signaler ces e-mails de phishing à des organismes spécialisés, en particulier Signal-Spam.
Il y aura encore d’autres actions qui seront mises en place prochainement, je n’hésiterai pas à mettre à jour cet article 🙂
Pour conclure…
Même si ça a été très décevant / frustrant que cet e-mail de phishing soit arrivé dans notre boite de réception, cet article vous montre bien que personne n’est à l’abri de se faire piéger. D’ailleurs, au moment où j’écris cet article, deux de nos clients nous ont alerté d’actes de piraterie… Bref, ça n’arrive pas qu’aux autres !
N’hésitez pas à vérifier vos différentes configurations (ou password) afin de vous assurer que vos domaines ou comptes sont bien protégés. Si vous avez des doutes ou si vous avez besoin de conseils sur l’optimisation de leurs protections, contactez-nous 🙂
