10 failles des filtres email : les signaux subtils que votre passerelle rate

⚡TL;DR

• Les passerelles email bloquent le spam évident mais ratent les attaques sophistiquées qui exploitent des failles subtiles dans les en-têtes
• 10 indicateurs précis dans les en-têtes trahissent les emails malveillants : décalage d'enveloppe, DKIM tiers, Reply-To divergent, chaîne Received anormale et six autres signaux techniques
• Chaque indicateur est déconstruit du point de vue de l'attaquant (comment il l'exploite) et du défenseur (comment le détecter)
• L'analyse des en-têtes après la passerelle est la dernière ligne de défense pour le 1% d'emails qui franchissent tous les filtres

Votre passerelle email affiche un taux de blocage de 99,5%. Le rapport mensuel est rassurant, les tableaux de bord sont au vert, et votre équipe sécurité passe au sujet suivant. Le problème se cache dans les 0,5% restants. Sur un volume de 200 000 emails mensuels, cela représente 1 000 messages non filtrés. Parmi eux, il suffit d'un seul email de spear-phishing ciblant le bon employé pour compromettre un compte à privilèges, exfiltrer des données ou déclencher un ransomware. Le coût moyen d'une brèche initiée par phishing atteint 4,8 millions de dollars (IBM, Cost of a Data Breach 2025), et le temps moyen pour détecter un compromis par phishing est de 207 jours (IBM, 2025). Selon le rapport Verizon DBIR 2025, le temps médian entre la réception d'un email de phishing et le premier clic est de 21 secondes. Vos utilisateurs ne réfléchissent pas : ils réagissent.

Les passerelles de sécurité email (Secure Email Gateways, SEG) comme Proofpoint, Mimecast, Barracuda ou Microsoft Defender for Office 365 analysent le contenu, la réputation IP, les signatures connues et les heuristiques comportementales. Mais elles partagent un angle mort commun : les signaux subtils dans les en-têtes SMTP et MIME que les attaquants sophistiqués manipulent pour franchir les filtres sans déclencher d'alerte. Les chiffres sont nets : les passerelles ratent 30 à 50% des menaces avancées, et le volume d'emails malveillants contournant les SEG a bondi de 105% en un an, soit un email malveillant toutes les 19 secondes qui franchit les filtres (Cofense, Annual State of Email Security 2026). Sans surprise, 91% des responsables sécurité se déclarent frustrés par les performances de leur SEG (Egress, Email Security Risk Report 2024). Ce n'est pas un problème théorique. En 2025, le groupe Tycoon2FA a exploité des failles de routage MX et d'authentification email pour générer 13 millions d'emails malveillants en un seul mois, contournant les passerelles de milliers d'organisations. Au total, 78% des organisations ont subi au moins une brèche email dans les 12 derniers mois (Barracuda, 2025).

Cet article décortique 10 indicateurs précis dans les en-têtes email que la plupart des passerelles ignorent ou sous-évaluent. Pour chaque indicateur, la perspective de l'attaquant (comment il l'exploite) et celle du défenseur (comment le détecter) sont détaillées avec des exemples concrets d'en-têtes. Si vous êtes ingénieur sécurité, analyste SOC, administrateur email ou RSSI, ces 10 signaux devraient faire partie de votre grille d'analyse post-passerelle.

Pourquoi les filtres email ne suffisent pas ?

Ce que les passerelles vérifient (et ce qu'elles ignorent)

Les passerelles email modernes reposent sur plusieurs couches de filtrage. La réputation IP vérifie si l'adresse du serveur émetteur figure sur des listes noires (Spamhaus, Barracuda, SpamCop). L'analyse de contenu recherche des mots-clés suspects, des URLs malveillantes et des pièces jointes dangereuses. Les signatures anti-malware comparent les fichiers à des bases de définitions connues. Les heuristiques comportementales détectent les schémas de mass-mailing et les anomalies statistiques.

Cette architecture fonctionne contre le spam de masse et les campagnes de phishing génériques. Un serveur avec une IP sur liste noire, un email contenant « Cliquez ici pour récupérer votre lot » et une pièce jointe .exe se font bloquer avant même d'atteindre la boîte de réception. Le taux de blocage de 99% est réel pour ce type de menaces.

Mais les attaquants qui ciblent votre organisation ne font rien de tout cela. Ils envoient depuis des IP propres (louées sur des ESP légitimes), rédigent des messages crédibles et manipulent les en-têtes SMTP pour que le message ressemble à un email légitime. Fait notable : 82,6% des emails de phishing analysés utilisent désormais une forme d'IA pour la rédaction (KnowBe4, Phishing Threat Trends 2025), et le taux de clic sur ces emails générés par IA atteint 54%, contre 12% pour les emails rédigés manuellement (Brightside AI, 2025). Par ailleurs, 76,4% des attaques phishing contiennent au moins un trait polymorphe, c'est-à-dire que chaque email envoyé est légèrement différent pour échapper aux signatures statiques (KnowBe4, 2025). La passerelle voit un email qui « passe » tous ses critères standards et le laisse entrer.

Ce que les passerelles ignorent largement, ce sont les signaux de cohérence dans les en-têtes. Un email légitime présente une cohérence interne : le domaine du From correspond au domaine du Return-Path et du Message-ID, la signature DKIM couvre le bon domaine, la chaîne Received est logique et les en-têtes propriétaires de la plateforme d'hébergement sont présents. Quand un attaquant forge un email, il reproduit les en-têtes visibles (From, Subject, Date) mais laisse des incohérences dans les en-têtes techniques que seul un examen approfondi révèle. Les passerelles ne font pas cet examen.

Le paradoxe de l'adaptation

Plus un filtre est strict, plus l'attaquant s'adapte. Les groupes de menaces avancées (APT, opérations de spear-phishing ciblé) testent systématiquement leurs emails contre les passerelles du marché avant de lancer une campagne. Des services clandestins proposent du « SEG testing » : l'attaquant soumet son email et reçoit un rapport indiquant quelles passerelles le bloquent et lesquelles le laissent passer. C'est un processus itératif. L'attaquant ajuste les en-têtes, le contenu et l'infrastructure d'envoi jusqu'à obtenir un taux de passage satisfaisant.

Le résultat : les emails qui arrivent dans la boîte de réception après la passerelle ne sont pas des tentatives ratées. Ce sont les tentatives les plus abouties, celles qui ont été optimisées pour contourner vos défenses spécifiques. C'est un biais cognitif courant chez les équipes sécurité : considérer que ce qui franchit la passerelle est « probablement légitime ». En réalité, c'est exactement l'inverse. Ce qui franchit la passerelle après un filtrage strict est potentiellement plus dangereux que le spam moyen, parce que cela a été conçu pour passer.

Ce phénomène explique pourquoi les utilisateurs formés à reconnaître les signes visuels du phishing continuent de se faire piéger. Les emails qui franchissent la passerelle ne contiennent plus de fautes d'orthographe, de mises en page approximatives ou d'URLs évidentes. Ils ressemblent à des emails légitimes parce qu'ils ont été optimisés pour cela. La seule différence réside dans les en-têtes techniques, invisibles pour l'utilisateur final.

La dernière ligne de défense : l'analyse post-passerelle

C'est pourquoi l'analyse des en-têtes après le filtrage est critique. Les 10 indicateurs détaillés dans cet article ne remplacent pas la passerelle : ils complètent la détection en examinant des signaux que les filtres automatisés ne vérifient pas ou vérifient mal. Cette analyse peut être manuelle (pour les incidents individuels), semi-automatisée (règles de transport Exchange/Gmail) ou intégrée à un SIEM pour la détection à grande échelle.

Les 10 indicateurs que votre passerelle rate

1. Décalage Return-Path / From (décalage d'enveloppe)

Comment l'attaquant l'exploite. Le protocole SMTP sépare deux identités distinctes : l'expéditeur d'enveloppe (MAIL FROM, visible dans l'en-tête Return-Path) et l'expéditeur affiché (en-tête From). L'attaquant configure son serveur pour envoyer avec un Return-Path qu'il contrôle (bounce@attaquant-infra.net) tout en affichant un From crédible (direction@captaindns.com). La plupart des clients email n'affichent que le From. Le destinataire voit un email qui semble provenir de la direction, sans se douter que l'enveloppe pointe ailleurs.

Pourquoi les filtres le ratent. Les passerelles vérifient SPF sur le Return-Path et DKIM sur le From, mais rares sont celles qui comparent activement les deux et alertent sur un décalage. Un SPF pass sur le Return-Path et un DKIM pass sur un domaine tiers suffisent souvent à laisser passer le message.

Ce que le défenseur doit vérifier. Comparer le domaine dans Return-Path avec le domaine dans From. S'ils diffèrent sans raison légitime (mailing list, ESP configuré), c'est un signal fort.

Exemple d'en-tête :

Return-Path: <bounce-7842@attaquant-infra.net>
From: "Direction Générale" <direction@captaindns.com>

Le décalage est visible immédiatement : l'enveloppe vient de attaquant-infra.net, le From affiche captaindns.com. Un email légitime envoyé via un ESP aurait un Return-Path contenant le domaine de l'ESP configuré dans le SPF du domaine expéditeur, pas un domaine tiers inconnu.

Quand le décalage est légitime. Il est normal que le Return-Path diffère du From dans certains cas : les ESP (SendGrid, Mailgun, Amazon SES) utilisent leur propre domaine pour le Return-Path afin de gérer les rebonds. Les listes de diffusion réécrivent le Return-Path. La clé est de vérifier si le domaine du Return-Path est celui d'un service connu et configuré dans le SPF du domaine du From. Un Return-Path vers un domaine inconnu (attaquant-infra.net) associé à un From d'entreprise (captaindns.com) sans lien SPF est un signal fort.

2. DKIM signé par un domaine tiers (signature déléguée)

Comment l'attaquant l'exploite. L'attaquant crée un compte sur un ESP légitime (SendGrid, Mailgun, Amazon SES) et configure DKIM pour son propre domaine. Il envoie ensuite un email avec un From usurpé (compta@captaindns.com). Le message porte une signature DKIM valide, mais signée par le domaine de l'attaquant (d=attaquant-marketing.com), pas par captaindns.com. La passerelle voit « dkim=pass » et considère le message comme authentifié.

Pourquoi les filtres le ratent. Les passerelles vérifient que la signature DKIM est techniquement valide (la clé publique correspond, le hash du corps est correct). Mais la plupart ne vérifient pas si le domaine signataire (d=) correspond au domaine du From. C'est le rôle de l'alignement DMARC, et beaucoup d'organisations n'ont pas encore déployé DMARC en mode strict.

Ce que le défenseur doit vérifier. Dans l'en-tête DKIM-Signature, comparer le champ d= avec le domaine du From. S'ils ne correspondent pas, l'email est signé par un tiers qui n'a aucune autorité sur le domaine affiché.

Exemple d'en-tête :

DKIM-Signature: v=1; a=rsa-sha256; d=attaquant-marketing.com;
    s=sel2026; c=relaxed/relaxed;
    h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
From: "Service Comptabilité" <compta@captaindns.com>

Le d=attaquant-marketing.com ne correspond pas au From captaindns.com. La signature est techniquement valide mais l'alignement est rompu.

3. SPF pass mais alignement DMARC échoué

Comment l'attaquant l'exploite. L'attaquant envoie depuis un serveur dont l'IP est autorisée par le SPF d'un domaine qu'il contrôle (son propre domaine ou un domaine d'ESP). Le MAIL FROM (enveloppe) utilise ce domaine autorisé, ce qui donne un SPF pass. Mais le From (en-tête) affiche le domaine de la cible (rh@captaindns.com). SPF passe, DKIM est absent ou signé par un autre domaine, et DMARC échoue en alignement. Si le domaine cible a une politique DMARC p=none, aucune action n'est prise. Et cette faille est massive : 84,2% des attaques de phishing analysées passent les contrôles DMARC (Egress, Email Security Risk Report 2024), en grande partie parce que 47% des domaines email n'ont aucune configuration DMARC (Barracuda, 2025), 63% des implémenteurs restent en p=none (Mailgun/Email on Acid, 2025) et seulement 4% des domaines appliquent p=reject (Valimail, 2025).

Pourquoi les filtres le ratent. La passerelle voit spf=pass dans les résultats d'authentification et attribue un score positif. Le fait que l'alignement DMARC échoue est souvent sous-pondéré si la politique est p=none. Le résultat net : le message passe le filtrage avec un « score d'authentification acceptable ».

Ce que le défenseur doit vérifier. Dans l'en-tête Authentication-Results, chercher la combinaison spf=pass avec dmarc=fail. Cette combinaison indique que le SPF a passé sur un domaine différent du From, signe classique d'usurpation.

Exemple d'en-tête :

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 198.51.100.42)
        smtp.mailfrom=bounces.attaquant-esp.com;
    dkim=none;
    dmarc=fail (p=none dis=none) header.from=captaindns.com

Le spf=pass concerne attaquant-esp.com (enveloppe), pas captaindns.com (From). DMARC échoue car aucun mécanisme (SPF ou DKIM) n'est aligné avec le domaine du From. La politique p=none laisse passer.

4. Reply-To vers un domaine différent du From

Comment l'attaquant l'exploite. L'attaquant forge un From crédible (support@captaindns.com) mais insère un Reply-To vers une adresse qu'il contrôle (support-captaindns@protonmail.com ou support@captaindns-helpdesk.com). Quand le destinataire répond, sa réponse part vers l'attaquant. C'est une technique redoutablement efficace pour le BEC (Business Email Compromise), qui a causé 55,5 milliards de dollars de pertes cumulées sur dix ans (FBI IC3, 2024). Le premier email ne contient ni lien ni pièce jointe, ce qui évite toute détection par analyse de contenu.

Pourquoi les filtres le ratent. Le Reply-To est un en-tête informatif, pas un mécanisme d'authentification. Les passerelles ne comparent généralement pas le domaine du Reply-To avec celui du From. Un email sans URL suspecte ni pièce jointe, avec un SPF pass et un contenu textuel propre, franchit les filtres sans difficulté.

Ce que le défenseur doit vérifier. Comparer le domaine de l'en-tête Reply-To avec celui du From. Un décalage vers un domaine gratuit (Gmail, ProtonMail, Outlook.com) ou un domaine similaire (typosquatting) est un signal fort de BEC.

Exemple d'en-tête :

From: "Jean Dupont - DAF" <jean.dupont@captaindns.com>
Reply-To: jean.dupont.captaindns@protonmail.com
Subject: Virement urgent - facture fournisseur

Le From affiche une adresse interne crédible. Le Reply-To redirige vers un compte ProtonMail que l'attaquant contrôle. Si le destinataire répond sans vérifier, la conversation se poursuit avec l'attaquant.

Variantes avancées. Les attaquants les plus sophistiqués n'utilisent pas un domaine gratuit évident. Ils enregistrent un domaine de typosquatting proche du domaine cible : captaindns-support.com, captaindns.net, captaindnss.com. Ces domaines sont plus difficiles à détecter dans une lecture rapide du Reply-To. Une autre variante consiste à utiliser un sous-domaine trompeur : captaindns.service-desk.com (le vrai domaine est service-desk.com, pas captaindns). Pour la détection automatisée, maintenez une liste blanche de domaines Reply-To autorisés et signalez tout ce qui n'y figure pas.

5. Chaîne Received anormalement courte ou longue

Comment l'attaquant l'exploite. Chaque serveur qui traite un email ajoute un en-tête Received en haut de la pile. Un email légitime traverse généralement 3 à 5 hops (serveur de l'expéditeur, passerelle sortante, MX du destinataire, passerelle entrante, serveur de boîte de réception). L'attaquant peut manipuler cette chaîne de deux manières. Première option : envoyer directement depuis un script vers le MX du destinataire, produisant une chaîne avec seulement 1 ou 2 hops, signe d'un envoi non standard. Deuxième option : injecter de faux en-têtes Received pour simuler un transit par des serveurs légitimes, allongeant artificiellement la chaîne.

Pourquoi les filtres le ratent. Les passerelles ne comptent pas systématiquement le nombre de hops ni ne vérifient la cohérence temporelle entre les Received. Un email avec 8 hops dont 3 sont falsifiés passe les contrôles standards si les en-têtes forgés sont bien formatés.

Ce que le défenseur doit vérifier. Compter les en-têtes Received et vérifier deux choses. D'abord, la cohérence temporelle : les timestamps doivent progresser du bas (premier hop) vers le haut (dernier hop). Un saut dans le temps (un hop daté avant le précédent) indique un en-tête forgé. Ensuite, le nombre de hops : moins de 2 ou plus de 7 est anormal pour un email professionnel standard.

Exemple d'en-tête (chaîne suspecte, trop courte) :

Received: from mail-gw.captaindns.com (10.0.1.5) by mailbox.captaindns.com;
    Thu, 27 Mar 2026 09:15:22 +0100
Received: from unknown (HELO send-node-14.attaquant.net) (45.77.200.18)
    by mail-gw.captaindns.com; Thu, 27 Mar 2026 09:15:20 +0100

Seulement 2 hops. Pas de serveur sortant, pas de passerelle de l'expéditeur. Le message a été envoyé directement depuis un nœud d'envoi vers le MX de captaindns.com, signe d'un envoi scripté, pas d'un serveur de messagerie d'entreprise.

La technique des en-têtes Received forgés. Un attaquant plus sophistiqué insère de faux en-têtes Received pour simuler un transit par des serveurs légitimes. Il ajoute par exemple un hop Received: from mail-out.captaindns.com (10.0.1.2) by gateway.captaindns.com en bas de la pile. Le piège : les serveurs de réception ajoutent les en-têtes Received en haut de la pile, pas en bas. Les en-têtes du bas sont les plus anciens et les premiers à avoir été ajoutés. Un en-tête Received qui prétend provenir d'un serveur interne mais qui se trouve en bas de la pile (avant le premier hop légitime) est un en-tête forgé par l'émetteur. Vérifiez toujours la cohérence de la chaîne en commençant par le bas.

6. Absence de TLS sur le premier hop (STARTTLS manquant)

Comment l'attaquant l'exploite. L'attaquant utilise un serveur configuré sans support TLS ou désactive volontairement STARTTLS. L'objectif n'est pas le chiffrement lui-même, mais ce que révèle son absence. Un serveur de messagerie légitime en 2026 supporte STARTTLS. Un serveur qui envoie en clair est probablement un script, un outil d'attaque ou un serveur compromis. L'absence de TLS peut aussi indiquer une attaque par downgrade SMTP, où un attaquant intercepte la négociation TLS pour forcer la transmission en clair.

Pourquoi les filtres le ratent. Les passerelles ne bloquent pas les emails reçus sans TLS. Le protocole SMTP est conçu pour fonctionner en clair avec TLS comme extension optionnelle. Beaucoup de passerelles acceptent les connexions non chiffrées pour ne pas perdre de courrier légitime provenant de serveurs anciens. Le fait que le premier hop soit en clair n'est pas un critère de filtrage standard.

Ce que le défenseur doit vérifier. Dans le premier en-tête Received (le plus bas dans la pile), chercher la mention with ESMTPS (connexion TLS) versus with SMTP ou with ESMTP (connexion en clair). Un email professionnel en 2026 devrait toujours transiter avec TLS activé sur le premier hop.

Exemple d'en-tête :

Received: from send-node.attaquant.net (45.77.200.18)
    by mail-gw.captaindns.com with SMTP;
    Thu, 27 Mar 2026 09:15:20 +0100

La mention with SMTP (sans le S de ESMTPS) indique une connexion en clair. Un serveur de messagerie d'entreprise légitime aurait with ESMTPS ou with TLS. Cette absence de chiffrement est un signal faible mais significatif quand combiné à d'autres indicateurs.

7. X-Mailer ou User-Agent suspect

Comment l'attaquant l'exploite. Les clients de messagerie et les serveurs insèrent un en-tête X-Mailer ou User-Agent identifiant le logiciel utilisé. Les attaquants utilisent des scripts Python (bibliothèque smtplib ou aiosmtplib), des outils de mass-mailing (GoPhish, King Phisher, Social Engineering Toolkit) ou des frameworks maison. Certains attaquants omettent cet en-tête (ce qui est déjà un signal), d'autres le forgent pour imiter un client légitime (Outlook, Thunderbird). Les forgeries sont souvent imparfaites : une version inexistante, un format de chaîne incohérent, ou un X-Mailer qui ne correspond pas aux autres en-têtes présents.

Pourquoi les filtres le ratent. Le X-Mailer n'est pas un en-tête standardisé par les RFC. Les passerelles ne le considèrent pas comme un critère de sécurité et ne maintiennent pas de base de signatures de clients malveillants. Un email envoyé depuis GoPhish avec un X-Mailer forgé Microsoft Outlook 16.0 passe les filtres si le contenu et la réputation IP sont propres.

Ce que le défenseur doit vérifier. Rechercher l'en-tête X-Mailer ou User-Agent. Un User-Agent Python (Python/3.11 aiosmtplib/2.0) est un signal fort. L'absence totale de X-Mailer sur un email censé provenir d'Outlook est suspecte. Une version d'Outlook qui n'existe pas (par exemple Microsoft Outlook 17.5 quand la dernière version est 16.x) trahit une forgerie.

Exemple d'en-tête :

X-Mailer: Python/3.11 aiosmtplib/2.0.1
From: "Service IT" <it-support@captaindns.com>
Subject: Mise à jour obligatoire de votre mot de passe

Un email de « mise à jour de mot de passe » envoyé depuis un script Python. Aucun service IT légitime n'envoie des emails critiques via un script Python avec aiosmtplib. Cet en-tête trahit un outil d'attaque ou un test de phishing interne.

8. Message-ID avec domaine incohérent

Comment l'attaquant l'exploite. L'en-tête Message-ID est un identifiant unique généré par le serveur d'envoi. Il contient typiquement un hash ou un identifiant aléatoire suivi du domaine du serveur qui l'a généré. L'attaquant qui usurpe le From @captaindns.com mais envoie depuis son propre serveur génère un Message-ID avec son propre domaine ou un identifiant générique. Ce décalage entre le domaine du From et le domaine dans le Message-ID révèle l'infrastructure réelle de l'attaquant.

Pourquoi les filtres le ratent. Le Message-ID est utilisé pour le suivi des fils de conversation et la déduplication, pas pour la sécurité. Les passerelles ne comparent pas le domaine du Message-ID avec le domaine du From. C'est un en-tête technique que peu de systèmes de filtrage analysent sous l'angle de la cohérence.

Ce que le défenseur doit vérifier. Extraire le domaine après le @ dans le Message-ID et le comparer au domaine du From. Un décalage indique que le message a été généré par un serveur qui n'appartient pas au domaine affiché.

Exemple d'en-tête :

Message-ID: <a3f8e2c1-9b47-4d6e-b5a2-1c7d3e9f0482@vps-node-14.attaquant.net>
From: "Ressources Humaines" <rh@captaindns.com>

Le Message-ID révèle le serveur réel : vps-node-14.attaquant.net. Un email légitime de captaindns.com aurait un Message-ID contenant captaindns.com ou le domaine de l'ESP utilisé (par exemple amazonses.com si l'organisation utilise Amazon SES).

9. En-têtes X-MS-Exchange ou X-Google manquants

Comment l'attaquant l'exploite. Les grandes plateformes de messagerie insèrent des en-têtes propriétaires spécifiques. Microsoft 365 ajoute X-MS-Exchange-Organization-AuthSource, X-MS-Exchange-Organization-AuthAs, X-MS-Has-Attach, X-MS-TNEF-Correlator et d'autres. Gmail ajoute X-Gm-Message-State, X-Google-DKIM-Signature, X-Google-Smtp-Source. Quand un email prétend venir d'un domaine hébergé sur Microsoft 365 mais ne contient aucun de ces en-têtes, il n'a pas transité par la plateforme Microsoft. L'attaquant qui forge le From @captaindns.com (domaine hébergé sur M365) mais envoie depuis son propre serveur ne peut pas reproduire ces en-têtes propriétaires de manière crédible.

Pourquoi les filtres le ratent. Les passerelles tierces (non Microsoft, non Google) ne connaissent pas la liste des en-têtes propriétaires attendus pour chaque plateforme. Même les passerelles intégrées (Defender, Gmail) ne vérifient pas systématiquement la cohérence entre le domaine From et la présence des en-têtes attendus de la plateforme d'hébergement.

Ce que le défenseur doit vérifier. Identifier la plateforme d'hébergement du domaine du From (M365, Google Workspace, autre). Vérifier que les en-têtes propriétaires correspondants sont présents. Un email @captaindns.com (hébergé sur M365) sans aucun en-tête X-MS-Exchange-* n'a pas transité par Microsoft 365.

Exemple d'en-tête (email suspect, From M365 mais sans en-têtes Exchange) :

From: "Direction Financière" <daf@captaindns.com>
To: comptabilite@captaindns.com
Subject: Validation urgente - virement international
Date: Thu, 27 Mar 2026 09:15:00 +0100
Message-ID: <random-id@send-node.attaquant.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Aucun en-tête X-MS-Exchange-*, aucun X-MS-Has-Attach, aucun X-OriginatorOrg. Si captaindns.com est hébergé sur Microsoft 365, cet email n'a pas transité par la plateforme. C'est une forgerie envoyée depuis un serveur externe.

10. Content-Type multipart avec pièce jointe .html encapsulée

Comment l'attaquant l'exploite. L'attaquant encapsule une page HTML de vol d'identifiants (credential harvesting) dans le corps MIME du message. Contrairement à une pièce jointe classique (.exe, .zip) qui déclenche les alertes, un fichier .html est souvent considéré comme inoffensif par les passerelles. Quand l'utilisateur ouvre la pièce jointe HTML, son navigateur charge une page de connexion factice qui imite Microsoft 365, Google Workspace ou un autre service. Les identifiants saisis sont envoyés au serveur de l'attaquant. La page HTML peut fonctionner entièrement hors ligne (pas de téléchargement de ressources externes), ce qui rend la détection par les sandboxes plus difficile.

Pourquoi les filtres le ratent. Les fichiers HTML ne sont pas des exécutables et ne contiennent pas de code malveillant au sens traditionnel (pas de shellcode, pas de macro). Les passerelles qui analysent les pièces jointes se concentrent sur les formats à risque (.exe, .docm, .xlsm, .js, .vbs). Un fichier HTML est du contenu web statique, et beaucoup de filtres le laissent passer. Certaines passerelles analysent les URLs dans le HTML, mais si la page fonctionne hors ligne avec du JavaScript embarqué, il n'y a pas d'URL à bloquer au moment de la livraison.

Ce que le défenseur doit vérifier. Dans les en-têtes MIME, chercher une partie avec Content-Type: text/html et Content-Disposition: attachment. La combinaison HTML + attachment est un signal fort. Analyser le contenu du fichier HTML : la présence de balises <form>, <input type="password"> ou de JavaScript obfusqué dans une pièce jointe HTML est quasi-certaine d'être malveillante.

Exemple d'en-tête :

Content-Type: multipart/mixed;
    boundary="----=_NextPart_001_0042_01D8F3A2.B5C7E890"

------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bonjour, veuillez consulter le document de s=C3=A9curit=C3=A9 en pi=C3=A8ce jointe.

------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/html; name="security-update-captaindns.html"
Content-Disposition: attachment; filename="security-update-captaindns.html"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCjxoZWFkPjx0aXRsZT5DYXB0YWluRE5T...

Le boundary MIME contient une pièce jointe security-update-captaindns.html. Le corps en base64 décode vers une page HTML avec un formulaire de connexion. Un email légitime de CaptainDNS n'enverrait jamais un fichier HTML en pièce jointe pour une « mise à jour de sécurité ».

Techniques d'évasion dans le HTML embarqué. Les attaquants utilisent plusieurs techniques pour échapper aux sandboxes qui analysent les pièces jointes HTML. Le JavaScript peut être obfusqué (encodage base64, concaténation de chaînes, exécution dynamique de code). La page peut vérifier si elle s'exécute dans un navigateur réel (détection de résolution d'écran, de mouvement de souris, de plugins) et ne déclencher le formulaire de phishing que si les conditions sont remplies. Certaines pages HTML utilisent le protocole data: ou des Blob URLs pour construire dynamiquement le formulaire, rendant l'analyse statique inefficace. En 2025 et 2026, les pièces jointes .svg contenant du JavaScript embarqué sont devenues une variante de plus en plus courante de cette technique, car les SVG sont encore moins surveillés que les fichiers HTML.

Combiner les indicateurs : la puissance du scoring multi-signaux

Pris individuellement, chaque indicateur peut avoir une explication légitime. Un Return-Path différent du From est normal quand un ESP envoie au nom d'une organisation. Un DKIM signé par un domaine tiers est standard avec SendGrid ou Amazon SES. Une chaîne Received courte peut provenir d'un serveur sur site qui envoie directement.

La puissance de ces 10 indicateurs apparaît quand on les combine. Un email présentant un seul indicateur mérite une vérification. Un email présentant trois indicateurs ou plus est presque certainement malveillant. Le principe est le scoring multi-signaux : attribuer un score à chaque indicateur détecté et escalader quand le score cumulé dépasse un seuil.

Exemple de scoring pour un email suspect :

Indicateur détecté	Score
Return-Path ≠ From (domaine inconnu)	+2
DKIM signé par un domaine tiers non ESP	+2
SPF pass + DMARC fail	+3
Reply-To vers domaine gratuit	+3
Chaîne Received < 3 hops	+1
Absence de TLS sur premier hop	+1
X-Mailer Python/script	+2
Message-ID domaine ≠ From	+2
Absence en-têtes X-MS-Exchange (domaine M365)	+3
Pièce jointe HTML	+2

Un seuil de 5 points déclenche un signalement pour revue SOC. Un seuil de 8 points déclenche une mise en quarantaine automatique. Ce scoring peut être implémenté dans les règles de transport Exchange/Gmail ou dans un SIEM.

En pratique, les emails de spear-phishing sophistiqués combinent généralement 3 à 5 indicateurs. Les indicateurs 1 (décalage Return-Path), 3 (SPF pass + DMARC fail) et 8 (Message-ID incohérent) apparaissent ensemble dans la majorité des cas d'usurpation de domaine. Les indicateurs 4 (Reply-To divergent) et 9 (absence d'en-têtes propriétaires) caractérisent les attaques BEC (Business Email Compromise). La combinaison 5 (chaîne Received courte) + 6 (absence TLS) + 7 (X-Mailer script) trahit un envoi depuis un outil d'attaque.

La leçon est claire : ne jugez jamais un email sur un seul indicateur. Construisez un scoring multi-signaux adapté à votre environnement et calibrez les seuils en analysant vos emails légitimes et vos incidents passés.

Comment détecter ces signaux après la passerelle ?

Analyse manuelle avec un outil d'inspection

Pour les incidents individuels (un utilisateur signale un email suspect), l'analyse manuelle des en-têtes reste la méthode la plus rapide. L'utilisateur exporte les en-têtes bruts depuis son client email (dans Outlook : Fichier > Propriétés > En-têtes Internet ; dans Gmail : les trois points > Afficher l'original). L'analyste SOC colle les en-têtes dans un outil d'analyse qui décompose chaque en-tête et met en évidence les anomalies.

Les points à vérifier en priorité lors de l'analyse manuelle :

1. Return-Path vs From : domaines identiques ou justification légitime du décalage ?
2. DKIM d= vs From : la signature couvre-t-elle le bon domaine ?
3. Authentication-Results : combinaison spf=pass + dmarc=fail ?
4. Reply-To : domaine cohérent avec le From ?
5. Received chain : nombre de hops, cohérence temporelle, présence de TLS ?
6. Message-ID : domaine cohérent avec le From ?
7. En-têtes propriétaires : présents si le domaine est hébergé sur M365/Gmail ?
8. MIME parts : pièce jointe HTML suspecte ?

Règles de transport Exchange/Gmail pour le marquage automatique

Pour une détection systématique, les règles de transport (mail flow rules) dans Exchange Online ou les règles de routage dans Google Workspace permettent de marquer automatiquement les messages présentant certains indicateurs.

Exemple de règle Exchange Online pour détecter le décalage Reply-To :

Condition : l'en-tête Reply-To contient un domaine différent du domaine du From, ET le domaine du Reply-To n'est pas dans une liste blanche (domaines internes, ESP autorisés). Action : ajouter un bandeau d'avertissement au message (« Ce message a un Reply-To différent de l'expéditeur affiché ») et le marquer pour revue SOC.

Exemple de règle pour détecter l'absence d'en-têtes M365 :

Condition : le domaine du From est un domaine interne hébergé sur M365, ET l'en-tête X-MS-Exchange-Organization-AuthSource est absent. Action : placer en quarantaine pour revue manuelle.

Ces règles ne remplacent pas la passerelle mais ajoutent une couche de détection post-filtrage ciblée sur les signaux que la passerelle ignore.

Intégration SIEM pour la détection à grande échelle

Pour les organisations avec un volume d'emails significatif, l'intégration avec un SIEM (Microsoft Sentinel, Splunk, Elastic Security) permet d'automatiser la détection et la corrélation. Les logs de transport Exchange ou Gmail contiennent les résultats d'authentification, les en-têtes clés et les métadonnées de routage. Des règles de détection personnalisées recherchent les schémas suivants :

• Volume anormal d'emails avec dmarc=fail action=none pour un domaine interne
• Emails entrants avec Reply-To vers des domaines gratuits quand le From est un domaine interne
• Messages sans en-têtes X-MS-Exchange-* quand le domaine From est hébergé sur M365
• Pièces jointes HTML dans des emails entrants avec un From interne

La corrélation SIEM permet aussi de croiser un email suspect avec les connexions réseau : si un utilisateur ouvre une pièce jointe HTML à 09h15 et qu'une connexion suspecte à M365 depuis une IP étrangère apparaît à 09h18, l'incident est détecté en quasi temps réel.

Le lien avec la délivrabilité et le spam

Les 10 indicateurs décrits dans cet article ne concernent pas uniquement la sécurité. Ils affectent aussi la délivrabilité de vos propres emails. Si votre domaine présente les mêmes signaux qu'un email de phishing (Return-Path incohérent, DKIM non aligné, DMARC en p=none), les passerelles des destinataires vont traiter vos messages avec suspicion. Vos emails légitimes finissent en spam parce que votre configuration DNS et vos en-têtes déclenchent les mêmes signaux que les attaquants exploitent.

Corriger vos propres en-têtes (aligner SPF et DKIM, passer DMARC en p=reject, configurer des Message-ID cohérents) a donc un double bénéfice : renforcer la sécurité de votre domaine contre l'usurpation ET améliorer la délivrabilité de vos emails légitimes. C'est la même grille de lecture appliquée à deux objectifs complémentaires.

🎯 Plan d'action

1. Auditer vos 50 derniers emails suspects : récupérez les en-têtes des emails signalés par vos utilisateurs au cours du dernier mois et analysez-les à travers les 10 indicateurs. Cet audit révèle les types d'attaques qui franchissent votre passerelle.
2. Créer des règles de transport pour les indicateurs 1, 4 et 5 : le décalage Return-Path/From, le Reply-To divergent et la chaîne Received anormale sont les trois signaux les plus faciles à détecter automatiquement via des règles Exchange ou Gmail.
3. Renforcer DMARC vers p=quarantine ou p=reject : tant que votre politique DMARC est p=none, les indicateurs 1, 2 et 3 restent exploitables sans conséquence pour l'attaquant. Rappelons que seulement 4% des domaines appliquent p=reject (Valimail, 2025) : chaque domaine qui migre réduit la surface d'attaque pour tout l'écosystème. Utilisez notre outil de vérification DMARC (lien dans le bandeau ci-dessus) pour auditer votre politique actuelle.
4. Former les équipes SOC aux signaux d'alerte des en-têtes : les employés formés signalent quatre fois plus de menaces que les non formés, soit 21% contre 5% (Verizon DBIR, 2025). Les 10 indicateurs de cet article devraient faire partie de la procédure standard d'analyse d'incidents email. Créez une liste de contrôle imprimable que les analystes consultent lors de chaque investigation.
5. Intégrer l'analyse d'en-têtes dans le processus d'incident response : les organisations qui intègrent l'IA dans leur pipeline de sécurité réduisent le cycle de brèche de 80 jours et économisent en moyenne 1,9 million de dollars par incident (IBM, Cost of a Data Breach 2025). Chaque email suspect signalé doit passer par une analyse post-passerelle systématique avant d'être classé comme faux positif.
6. Re-tester mensuellement avec des emails de test : envoyez-vous des emails qui reproduisent chacun des 10 indicateurs. Si votre passerelle les laisse passer et que vos règles de transport ne les signalent pas, vos défenses ont un angle mort.

FAQ

Pourquoi ma passerelle email ne détecte-t-elle pas ces signaux ?

Les passerelles sont optimisées pour le filtrage de masse : réputation IP, contenu suspect, signatures malware. Les 10 indicateurs décrits ici relèvent de la cohérence des en-têtes, un domaine que les passerelles n'analysent pas en profondeur. Le décalage Return-Path/From ou l'absence d'en-têtes propriétaires ne sont pas des critères de filtrage standards dans la plupart des SEG du marché.

Quels filtres email sont les plus vulnérables à ces contournements ?

Les passerelles qui se concentrent exclusivement sur la réputation IP et l'analyse de contenu sont les plus vulnérables. Les solutions qui intègrent l'analyse comportementale et la vérification d'alignement DMARC sont mieux positionnées, mais aucune passerelle du marché ne vérifie les 10 indicateurs de manière exhaustive. C'est pourquoi l'analyse post-passerelle reste nécessaire.

Comment créer une règle de transport Exchange pour détecter le décalage Reply-To ?

Dans le Exchange Admin Center, créez une règle de flux de courrier avec la condition « Un en-tête de message inclut » sur l'en-tête Reply-To. Combinez avec la condition « Le domaine de l'expéditeur est » pour cibler les domaines internes. L'action recommandée est d'ajouter un avertissement visible au destinataire et de marquer le message pour revue SOC. Testez en mode audit pendant deux semaines avant d'activer le blocage.

L'analyse des en-têtes peut-elle être automatisée ?

Oui. Les résultats d'authentification et les en-têtes clés sont accessibles dans les logs de transport Exchange Online et Gmail. Un SIEM (Sentinel, Splunk, Elastic) peut ingérer ces logs et appliquer des règles de détection sur les 10 indicateurs. Pour les organisations sans SIEM, les règles de transport Exchange/Gmail offrent un premier niveau d'automatisation accessible.

Ces techniques de contournement fonctionnent-elles contre Gmail et Outlook natifs ?

Gmail et Outlook disposent de leurs propres couches de filtrage (Gmail utilise des modèles ML avancés, Outlook intègre Defender). Ces filtres sont meilleurs que la moyenne sur l'alignement DMARC et la détection de Reply-To suspect. Mais ils ne sont pas infaillibles : les indicateurs 5 (chaîne Received anormale), 7 (X-Mailer suspect), 8 (Message-ID incohérent) et 10 (pièce jointe HTML) restent des angles morts même pour ces plateformes.

Comment former mon équipe SOC à l'analyse des en-têtes ?

Commencez par un atelier pratique de 2 heures avec des emails réels (anonymisés) présentant chacun des 10 indicateurs. Créez une liste de contrôle imprimable que les analystes consultent lors de chaque investigation. Intégrez l'analyse d'en-têtes dans les exercices de simulation sur table et les simulations de phishing internes. L'objectif est que chaque analyste SOC puisse identifier les 10 indicateurs en moins de 5 minutes par email.

Faut-il remplacer ma passerelle email pour se protéger ?

Non. Les 10 indicateurs sont des compléments à la passerelle, pas des substituts. La passerelle reste indispensable pour bloquer le spam de masse, les malwares connus et les campagnes de phishing génériques. L'objectif est d'ajouter une couche de détection post-passerelle (règles de transport, analyse SOC, SIEM) ciblée sur les attaques sophistiquées que le filtrage standard ne capte pas.

Comment tester si ma passerelle rate ces signaux ?

Envoyez-vous des emails de test reproduisant chacun des 10 indicateurs depuis un serveur externe. Pour le décalage Return-Path : configurez un MAIL FROM différent du From. Pour le DKIM tiers : signez avec un domaine différent. Pour le Reply-To : insérez un Reply-To vers un domaine externe. Documentez quels emails passent la passerelle et quels sont bloqués. Ce test révèle les angles morts spécifiques de votre configuration.

📖 Glossaire

• Return-Path : en-tête inséré par le serveur de réception contenant l'adresse de l'enveloppe SMTP (MAIL FROM). Utilisé pour les notifications de non-livraison (rebonds). Vérifié par SPF.
• DKIM-Signature : en-tête contenant la signature cryptographique d'un message. Le champ d= identifie le domaine signataire, s= le sélecteur de la clé publique.
• Alignement DMARC : vérification que le domaine du From correspond au domaine vérifié par SPF (alignement SPF) ou au domaine signataire DKIM (alignement DKIM). L'alignement peut être strict (correspondance exacte) ou relaxed (correspondance sur le domaine organisationnel).
• Reply-To : en-tête optionnel indiquant l'adresse vers laquelle les réponses doivent être dirigées. Peut différer du From.
• Chaîne Received : série d'en-têtes ajoutés par chaque serveur (hop) ayant traité le message. Lus de haut en bas, ils retracent le parcours du message du dernier hop (haut) au premier (bas).
• STARTTLS : extension SMTP qui permet d'initier une connexion chiffrée TLS sur une connexion SMTP existante. Visible dans les en-têtes Received par la mention with ESMTPS.
• X-Mailer : en-tête optionnel identifiant le logiciel client utilisé pour envoyer le message. Non standardisé par les RFC, mais largement utilisé par les clients de messagerie.
• Message-ID : identifiant unique attribué à chaque message par le serveur d'envoi. Format : <identifiant@domaine>. Utilisé pour le chaînage des conversations et la déduplication.
• MIME (Multipurpose Internet Mail Extensions) : standard d'encodage des emails permettant les pièces jointes, le contenu HTML et les caractères non-ASCII. Défini par l'en-tête Content-Type.
• Content-Disposition : en-tête MIME indiquant si une partie du message doit être affichée en ligne (inline) ou proposée en téléchargement (attachment).
• Expéditeur d'enveloppe (envelope sender) : adresse SMTP utilisée lors de la commande MAIL FROM dans la session SMTP. Distincte de l'adresse dans l'en-tête From visible par le destinataire.

---

Vos en-têtes cachent-ils des signaux suspects ? Collez vos en-têtes bruts dans notre analyseur d'en-têtes email pour un diagnostic automatique couvrant l'authentification, le routage et les anomalies décrites dans cet article.

---

Sources

• RFC 5322 - Internet Message Format
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 7208 - Sender Policy Framework (SPF)
• Microsoft - Enhanced Filtering for Connectors in Exchange Online
• MITRE ATT&CK T1566 - Phishing