Votre IP vient d’entrer au SBL de Spamhaus. Vos rapports DMARC, eux, ne montrent rien : aucun échec d’alignement, aucune signature invalide. Le phishing qui a produit ce tableau n’a pas usurpé votre domaine. Il a volé une session déjà ouverte, puis a expédié depuis la vraie boîte.
Next.ink en publie l’autopsie le 21 septembre 2026 : un kit récupéré et analysé par la rédaction, conçu pour des comptes Outlook protégés par une double authentification. Le procédé porte un nom, adversary-in-the-middle (AiTM). La charge malveillante tient dans une page d’environ 10 ko. En juillet 2022, le Threat Intelligence de Microsoft comptait déjà plus de 10 000 organisations visées par ce type de campagne, lancée en septembre 2021. Next.ink rapproche ce kit d’une attaque de même nature, CodeStorm, présentée par Hexastrike quelques mois plus tôt. Ces kits se vendent clés en main, à des groupes qui n’ont plus besoin de maîtriser la technique.
Comment une session ouverte devient une porte dérobée
Le mécanisme tient en une interposition. L’attaquant déploie un serveur mandataire entre la victime et le vrai portail Outlook : chaque requête HTTP transite par lui, dans les deux sens. La page affichée est identique au site Microsoft parce qu’elle l’est réellement ; seule l’URL trahit la substitution. Au passage, le serveur intercepte le mot de passe et le cookie de session, ce jeton qui prouve au serveur web que l’utilisateur est déjà authentifié.
Microsoft le formule sans détour : le cookie volé authentifie l’attaquant à la place de l’utilisateur, quelle que soit la méthode de connexion choisie. L’authentification multifacteur ne contient ici aucune faille exploitable ; elle est contournée en amont. Pour l’email, la conséquence est directe. Le voleur opère la boîte réelle, sans usurper le domaine. Chaque message part avec la signature DKIM valide et la réputation du domaine légitime, si bien qu’un enregistrement DMARC en p=reject reste muet. Les fonctions sont écrites à l’envers et la charge réelle se reconstitue à l’exécution par un eval() JavaScript : le kit aveugle les antivirus, jamais les headers. Côté email, le camouflage est inutile puisque le message part de la vraie boîte.
La réputation d’expéditeur encaisse le coup
Microsoft a observé la suite dans la même campagne : les attaquants exploitent les identifiants et le cookie volés pour entrer dans les boîtes aux lettres, puis lancent des campagnes de fraude au président contre d’autres cibles. L’email part de votre infrastructure, signé par votre domaine, avec toute sa réputation d’expéditeur derrière lui.
La conséquence se mesure au complaint rate que remontent les FBL de Gmail et d’Outlook. Il grimpe sur un domaine qui n’a pourtant rien envoyé de frauduleux de son propre chef. Les fournisseurs de boîtes dégradent alors le placement et la seedlist affiche des scores en baisse. Une IP jusque-là propre peut finir sur le SBL de Spamhaus. Plus le phishing est crédible, plus il provoque de signalements ; la réputation d’expéditeur du domaine légitime se dégrade en proportion.
Surtout, le rapport DMARC n’aide pas à anticiper. Les messages frauduleux y apparaissent alignés, donc légitimes, sans aucun échec SPF ou DKIM à analyser. C’est l’angle mort du postmaster qui ne surveille que l’authentification.
Ce que la couche email peut faire
La sécurité email native traite l’usurpation de domaine, un problème distinct. Contre le vol de session, la parade se joue en amont de l’email, côté identité. Microsoft recommandait dès 2022 de compléter l’authentification multifacteur par des politiques d’accès conditionnel, qui évaluent chaque connexion sur des signaux d’identité : l’adresse IP, la localisation, le statut du poste, l’appartenance à un groupe. Les clés de sécurité FIDO2 et les passkeys vont plus loin : l’assertion qu’elles signent est liée au domaine d’origine, si bien que le serveur mandataire, même interposé, ne peut pas la rejouer vers le vrai portail.
Deux réflexes côté délivrabilité gardent leur utilité. Le flux sortant d’un domaine se surveille : les échecs d’alignement que remontent les rapports DMARC, mais aussi le Smart Network Data Services (SNDS) de Microsoft, qui expose à l’expéditeur le volume de messages vus depuis son IP et le taux de messages envoyés vers des pièges, deux signaux indépendants de l’alignement DNS. L’hygiène de liste s’entretient aussi sur les adresses de vos propres collaborateurs, pour contenir le périmètre qu’un attaquant exploite après une compromission.
Les réflexes du postmaster après le vol
Le vol se voit au flux sortant : un volume inhabituel, des destinataires qui ne ressemblent pas à votre liste. Le taux de plainte remonté par les FBL grimpe lui aussi. Les règles de boîte méritent la même vigilance : une fois le compte compromis, l’attaquant ajoute souvent une règle de transfert discrète qui copie les réponses ou les factures vers une adresse externe, sans rien changer à l’affichage.
- Révoquez les sessions actives du compte compromis. C’est le geste le plus urgent : il invalide le cookie volé.
- Changez le mot de passe et réactivez l’authentification multifacteur depuis un poste sain, puis forcez la déconnexion des appareils inconnus.
- Passez la boîte en revue : règles de transfert et de suppression, applications tierces autorisées, signature d’expéditeur altérée, réponses automatiques.
- Si le compte volé était administrateur, vérifiez les alias et les comptes de service provisionnés sur le tenant.
- Croisez les heures de connexion et les adresses IP inhabituelles avec les envois du flux sortant.
Une fois la brèche colmatée, engagez la demande de délistage du SBL en documentant ce qui a été corrigé : une demande déposée avant que la source des envois soit éteinte a toutes les chances d’être rejetée.
La prochaine variante visera un autre fournisseur, avec la même mécanique. Le DNS continuera de valider des messages qu’il n’a jamais vus partir.
