Transfert de messagerie suspect : établir où les messages sont réellement partis

Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.

Une alerte signale une nouvelle règle de transfert vers une adresse inconnue. La tentation est de supprimer la règle, de réinitialiser le mot de passe et de clore le dossier. Il reste pourtant deux questions : quels messages ont réellement suivi ce chemin, et qu’est-ce qui empêche le même accès de recréer la règle ?

MITRE ATT&CK décrit l’abus des règles de transfert sous T1114.003, dans la collecte de courriels. Un changement de mot de passe peut laisser un transfert déjà configuré en place. Cette référence aide à formuler une hypothèse d’enquête ; elle ne classe pas automatiquement toute règle comme malveillante. Source : MITRE ATT&CK, Email Forwarding Rule

La méthode proposée ici distingue configuration, historique et effets observés. Les exemples techniques concernent Exchange Online, mais la démarche reste indépendante du SIEM et de l’outil de traitement des dossiers. Elle ne suppose aucune capacité produit Seculogik disponible.

1. Ouvrir le dossier avec trois états distincts

Notre recommandation : séparer dès le départ ce qui est configuré, ce qui était possible sur la période et ce qui est observé dans les traces.

Une règle activée décrit une instruction de traitement. Son existence seule ne démontre ni que ses conditions ont été rencontrées, ni que le destinataire a reçu un message. À l’inverse, une règle absente au moment de l’enquête ne décrit pas nécessairement la configuration d’hier.

Consignez la boîte concernée, l’organisation, l’heure de détection, le premier changement connu et la destination exacte. Ajoutez la raison du signalement : adresse inconnue, changement non approuvé, utilisateur qui nie l’action ou messages qui disparaissent. Un nom de règle banal n’apporte aucune garantie ; un domaine externe n’est pas non plus, à lui seul, une preuve d’attaque.

Contactez le propriétaire par un canal dont la fiabilité est établie. Si la messagerie est potentiellement compromise, évitez de lui confier seule la validation de sa propre sécurité.

2. Photographier le mécanisme avant de le modifier

Microsoft distingue les paramètres de transfert de la boîte et les règles de boîte de réception. Sa procédure de réponse recommande d’examiner les deux, y compris les règles masquées avec l’option IncludeHidden de Get-InboxRule. Source : Microsoft, réponse à un compte de messagerie compromis

Pour une personne habilitée, ces deux lectures constituent un point de départ, à adapter à l’identité exacte de la boîte :

Get-Mailbox -Identity <mailbox> |
  Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

Get-InboxRule -Mailbox <mailbox> -IncludeHidden |
  Format-List Identity,Name,Enabled,Description,RedirectTo,ForwardTo,ForwardAsAttachmentTo

Conservez ensuite le détail des règles pertinentes : conditions, exceptions, actions, état et ordre de traitement. Référencez l’export, son heure et son origine. Si plusieurs boîtes sont touchées ou si un acteur disposait de droits d’administration, élargissez l’examen aux mécanismes de transport plutôt que de généraliser le résultat d’une seule boîte.

Cette collecte doit rester proportionnée. Le dossier initial peut souvent commencer par des identifiants, paramètres et traces, sans copier le contenu de tous les messages. Préserver les éléments utiles ne doit pas retarder un confinement urgent autorisé : notez alors ce qui n’a pas pu être capturé.

3. Retrouver l’auteur technique et le changement

La documentation Microsoft associe notamment New-InboxRule, Set-InboxRule et Remove-InboxRule aux créations, modifications et suppressions de règles. Elle sépare la consultation de l’état courant de la recherche dans l’audit. Source : Microsoft, identifier les modifications des règles de messagerie

Le transfert au niveau de la boîte relève d’un autre chemin : Microsoft indique de rechercher l’activité Set-Mailbox et ses paramètres pour déterminer qui l’a configuré. Limiter l’enquête à la création d’une règle de boîte de réception peut donc manquer le changement utile. Source : Microsoft, investigation avec le journal d’audit

Notre recommandation : relier chaque modification à l’identité technique enregistrée, à la boîte cible, à l’heure et aux paramètres disponibles. Comparez cet ensemble aux changements approuvés et au contexte de connexion. L’identité enregistrée permet d’attribuer une opération à un compte ou à un contexte technique ; elle ne suffit pas à identifier la personne qui le contrôlait.

Évitez aussi de filtrer uniquement sur le propriétaire de la boîte : un administrateur ou un autre acteur autorisé peut être à l’origine du changement. Si les résultats sont vides, vérifiez le périmètre et les filtres avant d’en tirer une conclusion.

4. Établir le trajet réel des messages

Dans Exchange Online, le suivi des messages permet d’examiner leur traitement par le service et leur état, notamment réception, rejet, mise en attente ou livraison. Les périodes, délais et limites dépendent du type de rapport. Source : Microsoft, suivi des messages dans Exchange Online

Construisez un relevé de preuves reliant les messages pertinents, leurs destinataires, les heures et les états retrouvés. Faites apparaître séparément les messages livrés vers la destination suspecte, les tentatives bloquées et les messages dont le devenir reste inconnu. Un état de transport ne démontre pas à lui seul qu’une personne a lu le contenu.

Examinez aussi les contrôles qui pouvaient s’appliquer. Microsoft documente plusieurs mécanismes de contrôle du transfert externe, dont les stratégies antispam sortantes, les domaines distants et les règles de flux de messagerie. Une configuration de transfert ne décrit donc pas, seule, le résultat effectif. Source : Microsoft, contrôle du transfert automatique externe

N’utilisez pas la politique actuelle comme preuve automatique du blocage passé. Recherchez son historique lorsqu’il est disponible. Une destination interne mérite également une vérification : qui pouvait accéder à cette boîte et que faisait-elle ensuite ?

5. Borner l’exposition sans fabriquer un total

Notre recommandation : présenter une période confirmée par les éléments retrouvés, puis une période possible mais non résolue. La première commence avec les observations disponibles ; elle ne prétend pas identifier le véritable début de l’incident.

Documentez les limites de collecte, de conservation et de recherche. Les actions auditées et leur disponibilité doivent être vérifiées dans l’environnement ; Microsoft distingue notamment les contextes propriétaire, délégué et administrateur, et décrit des paramètres et exceptions d’audit. Source : Microsoft, gérer l’audit des boîtes aux lettres

Exemple fictif de formulation : « Des traces confirment une livraison vers la destination examinée pour les messages référencés dans le dossier. Les autres messages de la période ne sont pas tous couverts par les données disponibles. » Évitez de transformer ce constat en « toute la boîte a été exfiltrée » ou en « aucune donnée n’est sortie ».

Pour évaluer les conséquences, associez ensuite les responsables habilités aux catégories de données réellement concernées. Le SOC apporte les preuves et leurs limites ; il ne remplace pas les décisions métier ou juridiques.

6. Vérifier une réponse ciblée

Le plan de réponse doit traiter le mécanisme indésirable et l’accès qui a permis de l’installer. Les changements, révocations et restrictions relèvent des personnes habilitées, avec un périmètre explicite et une prise en compte des usages légitimes.

Nous recommandons de valider la fermeture en quatre points :

1. Relire la configuration après la mesure, plutôt que de se contenter du succès de la commande.
2. Vérifier que l’accès suspect a été traité selon son mécanisme, sans supposer qu’une seule action couvre tous les chemins.
3. Si un test est nécessaire, employer un message synthétique sans données sensibles et des destinataires contrôlés. Ne jamais réactiver un transfert vers la destination suspecte pour le tester.
4. Définir une fenêtre de surveillance de réapparition des changements et des flux, avec un responsable et un critère de clôture.

Le dossier final doit permettre de répondre simplement : quel changement était non autorisé, quels effets sont établis, quelles données restent hors visibilité, quelle mesure a été prise et quelle vérification en confirme l’effet ?

Pour compléter cette enquête, consultez notre méthode sur les sessions suspectes après une connexion MFA et celle sur les droits accordés par consentement OAuth. Elles traitent d’autres chemins d’accès, à examiner selon les indices du dossier.