Quand un compte Microsoft 365 est compromis, la majorité des équipes de sécurité se concentrent sur la réinitialisation du mot de passe et la révocation des sessions. C'est nécessaire, mais largement insuffisant. L'attaquant qui a eu accès à la boîte mail pendant quelques heures a pu poser un mécanisme de persistance Exchange Online qui continuera d'opérer silencieusement longtemps après que le compte a été « récupéré » : les règles de transport et les règles de redirection de boîte de réception.
Comment fonctionnent ces règles comme vecteur de persistance
Exchange Online offre deux niveaux de règles distinctes, souvent confondus. Les règles de transport (Mail Flow Rules) sont configurées au niveau du tenant par un administrateur Exchange ou un compte disposant du rôle adéquat. Elles agissent sur tous les messages en transit avant leur livraison. Les règles de boîte de réception (Inbox Rules), elles, sont configurées au niveau de chaque utilisateur — via Outlook, OWA, ou directement par API Graph et PowerShell — et s'appliquent aux messages déjà reçus.
Un attaquant ayant obtenu un accès temporaire à un compte utilisateur standard peut créer une règle de boîte de réception qui transfère automatiquement tous les e-mails contenant des mots-clés sensibles ("virement", "contrat", "confidentiel") vers une adresse externe qu'il contrôle. S'il a compromis un compte admin Exchange, il peut aller plus loin : créer une règle de transport qui copie les messages de plusieurs utilisateurs vers une boîte de collecte externe, sans jamais toucher à nouveau aux comptes individuels.
Pourquoi ces règles passent inaperçues
La discrétion de ce mécanisme tient à plusieurs facteurs structurels. D'abord, les règles de boîte de réception sont perçues comme une fonctionnalité légitime et banale — chaque utilisateur en crée pour organiser sa messagerie. Les équipes IT n'ont pas l'habitude de les auditer de façon proactive. Ensuite, le transfert sortant ne génère pas d'alerte native dans Exchange Online par défaut : il n'y a pas de notification à l'utilisateur, pas de bannière visible, pas d'entrée dans les journaux qu'un œil humain consulterait spontanément.
Un scénario type illustre bien le problème : un attaquant compromet un compte via un phishing ciblé un vendredi soir. Il crée une règle de redirection en quelques secondes via l'API Graph, puis se déconnecte. L'équipe sécurité détecte la connexion suspecte le lundi matin, réinitialise le mot de passe — mais la règle est toujours active. Pendant tout le week-end et les jours suivants, chaque e-mail entrant dans cette boîte a été copié vers l'adresse de l'attaquant. Sans audit des règles au moment de la réponse à incident, personne ne le saura.
Détecter ces règles via Microsoft Purview et l'Unified Audit Log
L'Unified Audit Log (UAL), accessible via Microsoft Purview Compliance Portal ou via PowerShell, enregistre les événements liés à la création, modification et suppression de règles Exchange Online. Les opérations à surveiller en priorité sont les suivantes.
Pour les règles de boîte de réception, les événements pertinents sont New-InboxRule, Set-InboxRule et UpdateInboxRules. Ce dernier est celui qu'Outlook génère lorsqu'un utilisateur crée une règle via l'interface graphique — il est distinct de New-InboxRule qui correspond à une création via PowerShell ou API. Cette différence est importante : une règle créée via API sans jamais passer par l'interface utilisateur est un signal fort d'activité automatisée suspecte.
La requête PowerShell de base pour extraire ces événements depuis l'UAL :
- Connectez-vous via
Connect-ExchangeOnlineetConnect-IPPSSession - Utilisez
Search-UnifiedAuditLog -StartDate <date> -EndDate <date> -Operations New-InboxRule,Set-InboxRule,UpdateInboxRules -ResultSize 5000 - Filtrez les résultats pour identifier les règles contenant les paramètres
ForwardTo,ForwardAsAttachmentToouRedirectTopointant vers des domaines externes - Croisez avec
New-TransportRuleetSet-TransportRulepour les règles de transport
Microsoft Defender for Office 365 propose également des alertes préconfigurées sur la création de règles de redirection externe — vérifiez que la stratégie "Email forwarding rule" est activée dans votre tenant et que le seuil de déclenchement est correctement paramétré.
Ce que révèle l'analyse des données d'audit
Lors d'une analyse post-compromission, plusieurs éléments dans les logs méritent une attention particulière. La valeur du champ ClientIPAddress associé à la création de la règle : si elle diffère de l'IP habituelle de l'utilisateur ou provient d'un pays incohérent avec son profil, c'est un indicateur fort. Le champ UserId permet de vérifier si la règle a été créée par l'utilisateur lui-même ou par un autre compte (par exemple un admin qui aurait été compromis séparément). Enfin, l'horodatage : une règle créée à 2h du matin un dimanche, quelques minutes après une connexion depuis une IP inconnue, parle d'elle-même.
Pour les équipes SOC qui souhaitent industrialiser cette détection, le catalogue de labs Exchange et M365 disponible sur la plateforme inclut des scénarios d'attaque reproductibles couvrant précisément ce type de persistance post-compromission.
Remédiation : ne pas s'arrêter au mot de passe
La réponse à incident sur un compte M365 compromis doit systématiquement inclure un audit complet des règles actives, qu'elles soient de transport ou de boîte de réception. En pratique, cela signifie exécuter Get-InboxRule -Mailbox <UPN> pour chaque boîte suspecte, et Get-TransportRule au niveau du tenant. Toute règle contenant un transfert vers un domaine externe non approuvé doit être considérée comme malveillante jusqu'à preuve du contraire.
Pensez également à vérifier les connecteurs SMTP sortants et les permissions de délégation de boîte mail, deux autres vecteurs souvent négligés lors des investigations. Si vous n'avez pas encore évalué la couverture de détection de votre SOC sur les scénarios M365, un diagnostic de maturité cyber peut aider à objectiver les angles morts avant qu'un incident les révèle.
Questions fréquentes
Une règle de redirection créée par un attaquant reste-t-elle active après réinitialisation du mot de passe ?
Oui, c'est précisément le danger. La réinitialisation du mot de passe révoque les sessions actives mais ne supprime pas les règles de boîte de réception ni les règles de transport déjà créées. Ces règles persistent dans la configuration Exchange Online jusqu'à suppression explicite, indépendamment de l'état d'authentification du compte.
Quelle est la différence entre New-InboxRule et UpdateInboxRules dans l'Unified Audit Log ?
New-InboxRule est généré lorsqu'une règle est créée via PowerShell ou l'API Microsoft Graph. UpdateInboxRules est l'événement produit par le client Outlook classique lorsqu'un utilisateur crée ou modifie une règle via l'interface graphique. Une création via API sans événement Outlook associé peut indiquer une action programmatique, potentiellement automatisée par un attaquant.
Les règles de transport nécessitent-elles des droits administrateurs pour être créées ?
Oui. Contrairement aux règles de boîte de réception qui sont accessibles à tout utilisateur sur sa propre boîte, les règles de transport (Mail Flow Rules) exigent le rôle Exchange Administrator ou un rôle délégué équivalent. Si une règle de transport suspecte est détectée, la compromission d'un compte admin Exchange est à investiguer en priorité.
Peut-on bloquer la création de règles de redirection externe de façon préventive ?
Oui. Il est possible de créer une règle de transport bloquant tout transfert automatique vers des domaines externes, en ciblant l'en-tête X-MS-Exchange-Inbox-Rules-Loop ou en utilisant la condition AutoForwardEnabled. Microsoft propose également une politique de transport anti-forward activable au niveau du tenant, que beaucoup d'organisations laissent désactivée par défaut.