Règles de boîte de réception d'un pirate : les repérer

En bref. La trace la plus fréquente d'un BEC dans Microsoft 365 est une règle de boîte de réception que l'utilisateur n'a pas créée : transfert vers une adresse externe, suppression, marquage comme lu, ou déplacement vers RSS Feeds, Archive ou Conversation History, souvent filtrée sur « facture », « paiement » ou « banque », souvent nommée « . ». Dans le journal d'audit unifié, cherchez New-InboxRule, Set-InboxRule, Enable-InboxRule et UpdateInboxRules, ainsi que Set-Mailbox avec ForwardingSmtpAddress. Vérifiez l'IP et la session d'où vient chaque règle. Pour l'état actuel, exécutez Get-InboxRule -Mailbox <utilisateur> -IncludeHidden.

Les règles de boîte de réception sont peu coûteuses, discrètes et efficaces. L'attaquant qui détourne une conversation avec un fournisseur a besoin que la victime ne voie pas la réponse « vous avez vraiment changé de RIB ? ». Une règle suffit. Une autre envoie une copie de chaque message sur les paiements vers une boîte externe, pour continuer à lire après la réinitialisation du mot de passe. MITRE les répertorie sous Email Hiding Rules (T1564.008) et Email Forwarding Rule (T1114.003).

À quoi ressemblent les règles malveillantes

Les publications de Microsoft sur les campagnes AiTM menant au BEC décrivent des règles qui déplacent le courrier d'un domaine expéditeur donné vers le dossier Archive en le marquant comme lu, et des règles qui déplacent tout le courrier entrant vers Archive en le marquant comme lu (juillet 2022, juin 2023). Le guide de Microsoft sur les comptes compromis cite les règles qui transfèrent vers des adresses inconnues et celles qui déplacent les messages vers Notes, Junk Email ou RSS Subscriptions (Microsoft Learn).

Aucune caractéristique isolée ne prouve quoi que ce soit. Des utilisateurs transfèrent vraiment du courrier vers une adresse personnelle, et certains nomment mal leurs règles. C'est la combinaison, et surtout la session qui a créé la règle, qui compte.

Retrouver la création des règles dans le journal d'audit unifié

Un contrôle PowerShell minimal sur un export déjà chargé dans $all (voir le guide d'export) :

$all | Where-Object { $_.Operations -in 'New-InboxRule','Set-InboxRule','UpdateInboxRules','Set-Mailbox' } |
  ForEach-Object {
    $d = $_.AuditData | ConvertFrom-Json
    [pscustomobject]@{
      Time   = $d.CreationTime; User = $d.UserId; Op = $d.Operation
      IP     = $d.ClientIP; Session = $d.AppAccessContext.AADSessionId
      Params = ($d.Parameters | ForEach-Object { "$($_.Name)=$($_.Value)" }) -join '; '
    }
  } | Sort-Object Time | Format-Table -Wrap

Reportez ensuite le ClientIP et la session de chaque règle dans les journaux de connexion. Une règle créée depuis l'IP et le Session ID d'une session rejouée n'est pas la règle de l'utilisateur ; le pivot par session explique comment le démontrer.

Vérifier l'état actuel avec Get-InboxRule

Le journal d'audit dit ce qui s'est passé ; la boîte dit ce qui existe encore. Les vérifications recommandées par Microsoft (Microsoft Learn) :

Get-Mailbox -Identity user@example.com | Format-List Forwarding*Address,DeliverTo*
Get-InboxRule -Mailbox user@example.com -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity

Un ForwardingSmtpAddress non vide signifie un transfert SMTP vers un destinataire externe ; ForwardingAddress, vers un destinataire interne. -IncludeHidden renvoie les règles que les clients habituels n'affichent pas. Comparez la liste avec l'historique d'audit : une règle présente aujourd'hui mais sans événement de création dans l'export a été créée avant la fenêtre d'export (élargissez la recherche), ou par un chemin que l'export ne couvre pas.

Vérifiez aussi les cachettes : ouvrez RSS Feeds, Archive, Conversation History, Notes et Deleted Items (Éléments supprimés) dans la boîte de la victime. L'e-mail d'alerte du fournisseur s'y trouve souvent, non lu.

Le transfert au niveau du tenant

Les stratégies anti-spam sortant contrôlent le transfert automatique vers des destinataires externes avec trois réglages : Automatic – System-controlled (la valeur par défaut, dont le comportement varie selon l'organisation), On et Off. Microsoft recommande de choisir explicitement On ou Off ; en mode bloqué, le transfert par règle et le transfert de boîte vers l'extérieur sont tous deux arrêtés avec un NDR 5.7.520 (Microsoft Learn). Une règle de transfert dans le journal d'audit ne prouve donc pas que le courrier est réellement sorti : vérifiez cette stratégie, les paramètres de domaines distants et le suivi des messages.

Comment M365 Forensics évalue les règles

L'analyseur dans le navigateur a une règle par motif, toutes visibles dans son rules.json :

« Interne » est déduit des domaines des comptes du tenant qui apparaissent dans les journaux. Si l'attaquant a créé la règle depuis une session suspecte, le constat de corrélation (« Actions effectuées depuis la session ou l'IP de l'attaquant ») s'y ajoute et le verdict devient Compromission probable. Dans l'exemple fictif intégré, une règle légitime « Newsletters » créée depuis l'IP du bureau n'est pas signalée, tandis que les règles « . » et « .. » de l'attaquant déclenchent chacune plusieurs constats (masquage, mots-clés ou transfert externe, nom absurde, session de l'attaquant).

Une fois la règle trouvée

Ne vous contentez pas de supprimer la règle. Elle prouve que quelqu'un d'autre a utilisé le compte, et elle n'est peut-être qu'un mécanisme de persistance parmi d'autres. Suivez la première heure de réponse : révoquer les sessions, supprimer règles et transferts, retirer les méthodes MFA de l'attaquant et les applications autorisées, réinitialiser les identifiants, puis établir ce qui a été transféré, lu et envoyé. Conservez un export de la règle (et de son enregistrement d'audit) avant de la supprimer.

Questions fréquentes

Comment voir les règles de boîte de réception masquées dans Microsoft 365 ?

Exécutez Get-InboxRule -Mailbox <utilisateur> -IncludeHidden dans Exchange Online PowerShell. Outlook et les paramètres web n'affichent pas toutes les règles ; le journal d'audit indique quand chaque règle a été créée et depuis quelle IP.

Qu'est-ce qui rend une règle de boîte de réception suspecte ?

Une règle que l'utilisateur n'a pas créée et qui transfère ou redirige le courrier vers l'extérieur, le supprime, le marque comme lu ou le déplace vers un dossier que personne ne lit (RSS Feeds, Archive, Conversation History), souvent filtrée sur des mots comme facture, paiement ou banque, et souvent avec un nom d'un seul caractère.

Supprimer la règle suffit-il ?

Non. La règle prouve que quelqu'un d'autre a utilisé le compte. Révoquez les sessions, supprimez le transfert, les méthodes MFA et les consentements d'applications de l'attaquant, réinitialisez les identifiants, et vérifiez ce qui a été transféré et envoyé.

Pour aller plus loin

• Microsoft Learn : Détecter et corriger les attaques par règles Outlook et injection de formulaires personnalisés
• Glossaire : règle de boîte de réception, compromission de messagerie professionnelle
• Gmail a lui aussi des filtres et du transfert : googleworkspaceforensics.com.