Depuis janvier 2024, des e‑mails échangés au sein d’un même tenant Microsoft 365 sont parfois placés en quarantaine pour « URL detonation reputation – High confidence phish / Malware ». Ce guide opérationnel détaille les causes, le diagnostic et des remédiations efficaces sans affaiblir la sécurité.
Contexte et symptômes
Plusieurs organisations constatent, depuis la mi‑janvier 2024, la mise en quarantaine de courriels exclusivement internes (expéditeur et destinataire au sein du même tenant Microsoft 365). Le motif exposé dans la quarantaine et/ou dans les journaux de détection est : « URL detonation reputation – High confidence phish / Malware », alors que l’Explorateur de menaces n’affiche parfois aucune URL visible dans le message.
- Les messages touchés sont souvent critiques (communications de direction, notifications applicatives, alertes métiers).
- Les quarantaines se produisent de façon intermittente : une soumission peut être marquée « should have been blocked », puis « should not have been blocked » quelques heures plus tard.
- Le tenant utilise fréquemment le profil Standard des Preset Security Policies, avec un filtre antimalware common attachments parfois trop large pour le contexte.
Pourquoi ces blocages surviennent
Réécriture et traçage d’URL
Des services de routage et de distribution d’e‑mails (p. ex. click‑tracking de plate‑formes d’envoi) réécrivent les liens sortants afin de mesurer les clics. La version réécrite est une URL de redirection : au moment de l’analyse (detonation), elle peut être inconnue ou de réputation faible et déclencher un verdict sévère, parfois classé « Malware », alors même que le contenu initial est légitime.
Niveau de protection et filtres
En profil Standard, Defender for Office 365 applique un équilibre entre sécurité et délivrabilité. Toutefois, certaines pièces jointes (extensions incluses dans le filtre common attachments) et des URLs jugées risquées par réputation dynamique peuvent suffire à provoquer une quarantaine. Passer en Strict augmente la sensibilité et, si le taux de faux positifs est déjà élevé, peut aggraver le symptôme.
Réputation dynamique et verdicts fluctuants
La réputation d’une URL évolue en minutes ou heures. Des soumissions identiques peuvent temporairement produire des verdicts différents (should have been blocked vs should not have been blocked) en fonction de signaux de télémétrie et de consolidations back‑end. Cette variabilité explique les faux positifs « aléatoires » perçus côté utilisateur.
Ce que révèlent réellement les en‑têtes
Lorsque l’Explorateur de menaces n’affiche pas d’URL, les en‑têtes SMTP contiennent souvent la clé de lecture. Les lignes suivantes sont particulièrement utiles :
X-MS-Exchange-Organization-URLDetonation-Results: indique le résultat de la détonation, l’horodatage et parfois un extrait de l’URL réécrite.X-Forefront-Antispam-Report: expose des signaux (catégorisation, score SCL, etc.).Authentication-Results: statut SPF, DKIM, DMARC (doivent idéalement être pass et alignés).
Authentication-Results: spf=pass (sender IP ...) smtp.mailfrom=exemple.tld;
dkim=pass header.d=exemple.tld; dmarc=pass action=none header.from=exemple.tld
X-Forefront-Antispam-Report: ...; CAT:PHISH; SCL:9; ...
X-MS-Exchange-Organization-URLDetonation-Results: 1;1;2024-01-17T08:55:42.434Z;
UrlDetonationVerdict=Malware;
Url=https://u1234567.example-tracker.net/ls/click?upn=... Dans ce type de scénario, l’expéditeur interne est légitime, mais la présence (éventuelle ou injectée automatiquement) d’un lien réécrit vers un domaine de suivi déclenche la détonation.
Diagnostic pas à pas
- Récupérer les preuves : ID de message (Message‑ID et NetworkMessageId si disponible), en‑têtes complets, échantillon
.eml, horodatage UTC du flux complet (soumission, quarantaine, éventuelle purge ZAP). - Comparer avec Threat Explorer : repérer la catégorie (Malware vs Phish/High confidence), le DeliveryAction (Quarantine, Blocked, Deleted) et s’il existe une URL connue liée à la détection.
- Analyser l’URL réécrite : si l’URL n’apparaît pas dans l’Explorateur, la retrouver dans les en‑têtes. Vérifier si elle provient d’un service de click‑tracking.
- Vérifier les politiques : Preset Security Policies (Standard/Strict), Safe Links, Safe Attachments, filtre common attachments, politiques antispam et seuil Bulk.
- Soumettre le faux positif : dans le portail de sécurité, envoyer l’échantillon comme False positive et documenter l’impact sur le business.
- Ouvrir un ticket : joindre ID de message, en‑têtes, échantillon et preuve de la réécriture d’URL. Mentionner explicitement la demande d’allow‑listing global du domaine de réécriture si le flux est réellement sûr.
Checklist condensée
| Étape | Action | Livrable |
|---|---|---|
| Preuves | Exporter en‑têtes et .eml | Fichier horodaté + ID de message |
| Explorateur | Comparer catégories/Actions | Capture ou rapport |
| URL | Extraire l’URL réécrite | Domaine/chemin incriminé |
| Politiques | Revue Standard/Strict + filtres | Plan d’ajustement minimal |
| Soumission | Envoyer le faux positif | ID de soumission |
| Support | Ouvrir ticket et escalader | Référence case + T2/T3 |
Mesures de remédiation recommandées
| Axe | Mesure préconisée | Remarques |
|---|---|---|
| Diagnostic | Ouvrir un ticket Microsoft 365 en fournissant ID de message, en‑têtes complets et échantillon | Permet d’impliquer le support T3 et d’analyser la réputation côté back‑end |
| Soumettre chaque faux positif via Submissions dans le portail de sécurité | Accélère l’apprentissage et la correction des verdicts | |
| Réduction des faux positifs | Ajuster le filtre common attachments de l’antimalware | Retirer les extensions non pertinentes pour vos flux |
| Créer une Safe Attachments policy ciblée (listes internes, expéditeurs applicatifs de confiance) | Limiter strictement aux flux maîtrisés | |
| Maintenir le profil Standard tant que les faux positifs ne sont pas réduits | Éviter de passer prématurément à Strict | |
| URLs | Tester des envois sans click‑tracking / réécriture d’URL | Permet d’isoler la responsabilité du tracking |
| Si nécessaire, demander l’allow‑listing global (opéré par Microsoft) des domaines/chemins générés | Mesure généralement obtenue au stade T3, durable et sans affaiblir vos politiques | |
| Antispam | Ajuster le seuil Bulk email threshold et/ou ajouter les expéditeurs applicatifs internes en Safe Senders | N’affecte pas la détection de logiciels malveillants |
| Suivi | Mettre en place des requêtes Advanced Hunting pour surveiller les quarantaines anormales | Réagit avant que l’incident n’atteigne des VIP |
Modèle de Safe Attachments ciblé
- Créer une nouvelle politique Safe Attachments dédiée à une DL interne (ex. « notifs‑app@… ») ou à des connecteurs applicatifs connus.
- Activer « Monitor » ou « Replace » plutôt que « Block » sur cette cible, le temps d’observer.
- Exiger SPF/DKIM/DMARC alignés pour ces expéditeurs, et interdire toute redirection externe non nécessaire.
Gérer la réécriture d’URL
- Test A/B : désactiver temporairement le click‑tracking sur un échantillon d’envois internes et vérifier la délivrabilité.
- Preuves : lier les quarantaines au domaine de tracking via l’en‑tête
URLDetonation-Resultset via les logs MDO. - Escalade : solliciter Microsoft pour un allow‑listing global des domaines/chemins de réécriture utilisés par votre plateforme d’envoi.
ZAP, Safe Links et risque de ré‑isolement
ZAP (Zero‑hour Auto Purge) peut retirer rétroactivement un message déjà délivré si un verdict ultérieur le classe malveillant. C’est pourquoi l’allow‑list global du domaine de réécriture, lorsqu’il est légitime, est la solution la plus robuste : elle évite que la montée en réputation « naturelle » n’entraîne des yoyos de verdicts jusqu’à stabilisation.
Surveillance proactive avec Advanced Hunting (KQL)
Les requêtes ci‑dessous ciblent les quarantaines « intra‑tenant » associées à des signaux de détonation d’URL. Remplacez contoso.com par votre domaine.
Quarantaines internes associées à des URL
let domain = "contoso.com";
EmailEvents
| where Timestamp > ago(14d)
| where SenderFromDomain == domain and RecipientDomain == domain
| where DeliveryAction in ("Quarantine","Blocked","Deleted")
| where ThreatTypes has_any ("Malware","Phish","HighConfidencePhish")
| project Timestamp, NetworkMessageId, InternetMessageId, SenderFromAddress,
RecipientEmailAddress, Subject, DeliveryAction, ThreatTypes, DetectionMethods
| join kind=leftouter (
EmailUrlInfo
| project NetworkMessageId, Url, UrlDomain, UrlCategory, Action, Verdict
) on NetworkMessageId
| summarize Events=count(), AffectedRecipients=dcount(RecipientEmailAddress)
by UrlDomain, Verdict, UrlCategory
| order by Events descSurveillance des VIP internes
let vip = dynamic(["ceo@contoso.com","cto@contoso.com","ops@contoso.com"]);
EmailEvents
| where Timestamp > ago(14d)
| where RecipientEmailAddress in (vip)
| where DeliveryAction in ("Quarantine","Blocked","Deleted")
| summarize Count=count() by RecipientEmailAddress, ThreatTypes, DeliveryAction
| order by Count descDétection de ZAP post‑livraison
// Suivre les messages livrés puis re‑quarantainés
EmailEvents
| where Timestamp > ago(14d)
| summarize AnyQuarantine = any(DeliveryAction == "Quarantine"),
AnyDelivered = any(DeliveryAction == "Delivered")
by NetworkMessageId, InternetMessageId, Subject
| where AnyDelivered and AnyQuarantineAstuce : créez des alertes programmées sur ces requêtes (seuils par heure/jour) et notifiez l’équipe messagerie via un canal d’astreinte.
Procédure d’escalade au support
Lors de l’ouverture du ticket, fournissez un dossier complet :
- ID de message (InternetMessageId et NetworkMessageId), horodatage UTC, locataire impacté, boîtes aux lettres touchées.
- En‑têtes complets avec la ligne
X-MS-Exchange-Organization-URLDetonation-Resultscontenant l’URL réécrite. - Échantillon
.emlou export depuis la quarantaine, plus captures de l’Explorateur de menaces. - Description d’impact (ex. notifications applicatives non délivrées, messages de la direction bloqués).
- Demande explicite d’allow‑listing global du domaine/chemin de réécriture utilisé par votre plateforme d’envoi, avec justification métier.
Modèle de texte pour accélérer l’analyse
Contexte : faux positifs « URL detonation reputation – High confidence phish / Malware »
Scope : intra-tenant (expéditeur et destinataire en @contoso.com)
Impact : notifications applicatives et messages VIP bloqués (quarantaines intermittentes)
Preuves : en-têtes + .eml + NetworkMessageId ci-joints
Hypothèse : réputation instable de l’URL de click-tracking {domaine/chemin}
Demande : examen Tier 3 et ajout en allow-list global du domaine/chemin si confirméRésultat obtenu
Après escalade et soumissions répétées de messages/URLs, le support Tier 3 a ajouté le domaine de réécriture à la global allow list. Les quarantaines inappropriées ont cessé immédiatement, confirmant que la réputation de l’URL réécrite était l’unique facteur déclencheur. L’organisation a ainsi rétabli la délivrabilité de ses courriels internes sans affaiblir ses politiques globales.
Informations complémentaires utiles
Cycle de vie d’une URL
Une URL inconnue peut passer de « Low reputation » à « Benign » en quelques heures sous l’effet de requêtes répétées et de la consolidation des signaux. L’allow‑list global supprime cette latence pour les domaines de tracking contrôlés et fiables.
Bonnes pratiques minimisant les faux positifs
- Assurer l’alignement SPF, DKIM et DMARC sur tous les domaines applicatifs.
- Conserver une journalisation externe (export de Message Trace) pour horodater et prouver l’acheminement.
- Documenter dans le plan de réponse aux incidents la procédure de restauration d’un message bloqué nécessaire au business.
- Limiter les safe lists aux flux strictement maîtrisés ; éviter les dérogations globales au niveau tenant lorsque non indispensables.
Pièges à éviter
- Passer en profil Strict pour « forcer » la sécurité : vous amplifiez souvent les faux positifs tant que la cause racine (réputation d’URL réécrite) n’est pas traitée.
- Créer des autorisations trop larges (domaine générique de tracking) sans restreindre par chemin ou contexte d’usage.
- Ignorer ZAP : un message délivré peut être retiré a posteriori si la réputation se dégrade.
Indicateurs de succès et gouvernance
| Indicateur | Objectif | Fenêtre d’observation |
|---|---|---|
| Taux de quarantaines intra‑tenant | < 0,1 % des messages internes | 7 à 14 jours après remédiation |
| Temps moyen de restauration | < 15 min pour les VIP | Glissant hebdomadaire |
| Faux positifs récurrents | 0 (après allow‑list global) | Continu |
| Conformité SPF/DKIM/DMARC | 100 % des domaines applicatifs | Mensuel |
Annexes utiles
Exemples de requêtes supplémentaires KQL
Top domaines d’URL réécrites déclenchant une action
EmailUrlInfo
| where Timestamp > ago(30d)
| where Action in ("Blocked","ClickedAndBlocked") or Verdict in ("Malware","Phish")
| summarize Events=count(), AffectedMsgs=dcount(NetworkMessageId) by UrlDomain, Verdict
| order by Events descFlux intra‑tenant impactés par pièce jointe
let domain = "contoso.com";
EmailEvents
| where Timestamp > ago(14d)
| where SenderFromDomain == domain and RecipientDomain == domain
| where DeliveryAction in ("Quarantine","Blocked","Deleted")
| join kind=leftouter (EmailAttachmentInfo | project NetworkMessageId, FileName, SHA256) on NetworkMessageId
| summarize Total=count(), DistinctFiles=dcount(SHA256) by FileName
| order by Total descPowerShell : extraire les messages en quarantaine
# Exchange Online PowerShell
Get-QuarantineMessage -StartReceivedDate (Get-Date).AddDays(-7) -EndReceivedDate (Get-Date) -PageSize 200 |
Where-Object { $_.Reason -in @("Malware","HighConfidencePhish") } |
Select-Object Received, Sender, Subject, Reason, PolicyType, IdentityModèle de playbook de restauration
- Détection : alerte Advanced Hunting dès franchissement d’un seuil.
- Qualification : vérification en‑têtes + visibilité Threat Explorer.
- Décision : si flux critique et faux positif avéré, release via quarantaine et notification au propriétaire du processus.
- Prévention : soumission du faux positif + mise à jour des listes ou politiques ciblées.
- Post‑mortem : fiche d’incident, racine cause, action longue durée (allow‑list global si pertinent).
Conclusion
Les quarantaines intra‑tenant pour « URL detonation reputation – High confidence phish / Malware » sont le plus souvent la conséquence d’URL réécrites par des services de tracking dont la réputation est instable. En combinant preuves techniques (en‑têtes, KQL), soumissions répétées et escalade vers le support pour un allow‑listing global ciblé, on obtient une correction pérenne sans assouplir indûment les politiques de sécurité. Conservez une surveillance proactive et un playbook de restauration pour protéger la continuité métier.