Points clés à retenir (TL;DR)
Synthèse exécutive- Quand un compte externe (fournisseur, partenaire) est compromis et envoie de l'hameçonnage à vos employés, il faut un runbook clair : vérifier, mesurer la portée, bloquer, supprimer, valider.
- Ne jamais se fier au texte d'un courriel : la seule preuve d'authenticité, ce sont les en‑têtes (
Authentication‑Results: DKIM / DMARC). - Mesurez la portée réelle avec un Message Trace par sujet, tous expéditeurs confondus — pas seulement l'expéditeur connu — pour attraper les vagues secondaires.
- Un courriel peut avoir été livré, mis en quarantaine, ou supprimé : vérifiez les trois, car chacun demande une action différente.
- Terminez toujours par une validation finale : confirmer qu'aucune copie ne subsiste, plutôt que se fier à la mémoire d'un script précédent.
Contexte : deux courriels à ne pas confondre
Le scénario est classique : un partenaire externe vous informe (ou vous découvrez) qu’un de ses comptes a été compromis et a servi à envoyer de l’hameçonnage à ses contacts — dont vos employés. Dès le départ, deux courriels distincts circulent, et il ne faut pas les mélanger :
| Courriel | Nature |
|---|---|
| L’avis de compromission (« un courriel frauduleux a été envoyé… ») | Généralement légitime — envoyé par le fournisseur après coup |
| Le courriel d’hameçonnage original qu’il annonce | Le vrai danger — envoyé depuis le compte compromis, avec un lien malveillant |
Les deux se vérifient indépendamment : l’un ne garantit rien sur l’autre.
Étape 1 — Vérifier l’authenticité via les en‑têtes
Le texte peut mentir ; les en‑têtes, non. Récupérez une copie réellement reçue et lisez Authentication‑Results (DKIM/DMARC). Avec Microsoft Graph :
$user = "utilisateur.destinataire@exemple.test"
$sujet = "Sujet exact du courriel suspect"
$uri = "https://graph.microsoft.com/v1.0/users/$user/messages" +
"?`$search=`"subject:$sujet`"" +
"&`$select=id,subject,from,receivedDateTime,internetMessageHeaders"
$resp = Invoke-MgGraphRequest -Method GET -Uri $uri -Headers @{ ConsistencyLevel = "eventual" }
foreach ($m in $resp.value) {
Write-Host "=== $($m.subject) | from=$($m.from.emailAddress.address) ==="
foreach ($h in $m.internetMessageHeaders) {
if ($h.name -in @('Authentication-Results','Received-SPF','Return-Path')) {
Write-Host "$($h.name): $($h.value)"
}
}
}Interprétation :
| Résultat | Interprétation |
|---|---|
dkim=pass + dmarc=pass |
Le courriel vient réellement du domaine annoncé → légitime (même s’il semble alarmant) |
spf=fail mais DKIM/DMARC pass |
Normal si le message transite par une passerelle de sécurité avant Microsoft — ne pas paniquer sur ce seul point |
DKIM absent ou fail |
Signal fort d’usurpation → traiter comme malveillant |
Étape 2 — Mesurer la portée réelle
Cherchez par sujet exact, tous expéditeurs confondus (pas seulement l’expéditeur connu) : cela révèle les vagues secondaires — relances, transferts internes, réponses — qu’on ne soupçonnerait pas. Avec Exchange Online :
$debut = (Get-Date).AddDays(-10)
$fin = Get-Date
Get-MessageTraceV2 -StartDate $debut -EndDate $fin -Subject "Sujet exact du courriel suspect" |
Select-Object Received, SenderAddress, RecipientAddress, Status |
Sort-Object Received |
Format-Table -AutoSize⚠️ Rappel : le Message Trace ne remonte qu’environ 90 jours. Au‑delà, passez par la passerelle de sécurité (voir notre guide dédié).
Étape 3 — Où le message a‑t‑il réellement atterri ?
Un même courriel peut avoir trois destins. Vérifiez‑les dans l’ordre :
- Quarantaine (Microsoft Defender) : s’il y est, il n’a pas été livré — ne pas le relâcher, le supprimer de la quarantaine.
- Verdict de la passerelle de sécurité externe : elle peut l’avoir bloqué en amont.
- La boîte elle‑même : si les deux premiers ne montrent rien, le message a été livré → il faut le retirer.
Étape 4 — Bloquer l’expéditeur et l’URL
Empêchez toute relance en ajoutant l’expéditeur et le domaine/URL malveillant à la liste de blocage (politique anti‑hameçonnage / Tenant Allow/Block List). Bloquez à la fois l’adresse exacte et le domaine, car l’attaquant peut varier l’expéditeur.
Étape 5 — Le piège des transferts internes
Point souvent manqué : un employé qui transfère le courriel suspect à un collègue (« est‑ce légitime ? ») crée une copie qui n’est pas repassée par la passerelle externe — elle échappe donc au filtrage. Cherchez aussi ces transferts internes (même sujet, expéditeurs internes) et traitez‑les comme les originaux.
Étape 6 — Supprimer les copies livrées
Pour les copies confirmées livrées, lancez une recherche et purge (eDiscovery / Search‑Mailbox ou l’outil de suppression de masse de votre tenant), ciblée par sujet et expéditeur, sur toutes les boîtes concernées. Documentez le nombre de copies trouvées et supprimées.
Étape 7 — Validation finale (obligatoire)
Ne vous fiez pas à la mémoire du script de suppression : revérifiez. Relancez une recherche sur le même critère (sujet + expéditeur) et confirmez un résultat à zéro sur l’ensemble du tenant. Tant que ce n’est pas zéro, l’incident n’est pas clos.
La checklist du runbook
- ✅ En‑têtes vérifiés (DKIM/DMARC) sur une copie réelle.
- ✅ Portée mesurée par sujet, tous expéditeurs.
- ✅ Quarantaine, passerelle et boîtes vérifiées.
- ✅ Expéditeur + URL bloqués.
- ✅ Transferts internes recherchés.
- ✅ Copies supprimées.
- ✅ Validation finale à zéro.
Pièges à retenir
- Un
spf=failseul ne prouve rien si DKIM/DMARC passent (effet normal d’une passerelle). - Chercher uniquement l’expéditeur connu fait rater les vagues secondaires : cherchez par sujet.
- Les transferts internes contournent le filtrage externe.
- Toujours valider à zéro à la fin — ne jamais présumer.
À retenir
Face à un compte externe compromis, la rigueur prime sur la vitesse brute : vérifier (en‑têtes) → mesurer (par sujet) → localiser (quarantaine/passerelle/boîte) → bloquer → supprimer → valider à zéro. Un runbook écrit et testé transforme un moment de panique en procédure maîtrisée, et garantit qu’aucune copie piégée ne subsiste dans votre environnement.
Vous voulez un runbook de réponse à incident courriel, écrit et testé pour votre environnement Microsoft 365 ? Parlez à WeITSM.
