~/docs/resources/enquete-soc-regle-transfert-externe-persistance-post-compromission.mdDerniere modification : maintenant

AUDIENCE:Analystes SOC, responders M365, équipes messagerie qui doivent trancher entre suppression, blocage d’indicateurs, révocation de sessions ou incident BEC.

PROMESSE:Suivre un enchaînement de pivots simple et reproductible pour passer d’une alerte “forwarding” à une décision explicite, avec les preuves minimales à conserver.

Enquête SOC : règle de transfert externe comme persistance après compromission

Un chemin unique de l’alerte email jusqu’aux règles de boîte, pour décider vite et documenter correctement.

Objectif : relier un message livré à son expéditeur technique, ses destinataires, les interactions, puis les actions post-réception (connexions, consentements, règles).

##Le problème à résoudre (et ce qui fait perdre du temps)

Une règle de transfert externe peut être une persistance après compromission.

Le risque n’est pas seulement le phishing. Le risque est l’exfiltration continue d’emails vers l’extérieur.

Votre enjeu SOC est de relier le message initial à ce qui se passe après : clics, connexions, règles de boîte, consentements.

Erreur fréquente : décider sur le nom affiché de l’expéditeur, ou sur un mot comme “urgent”, au lieu de pivoter sur les éléments techniques.

##Ce que vous devez relier, dans le bon ordre

-Le message reçu et son expéditeur technique (pas le nom affiché).
-Les URL et pièces jointes réellement présentes dans le message.
-L’étendue : qui a reçu, ouvert, cliqué, répondu.
-Les événements après réception : connexions, règles de boîte, consentements OAuth.
-La décision finale attendue : supprimer le message, bloquer les indicateurs, révoquer les sessions, ou ouvrir un incident BEC.
-Les preuves minimales à conserver pour justifier cette décision.

##Chemin d’investigation (pivots obligatoires)

[01]Partir de l’alerte et identifier le message exact (ID, horodatage, destinataires).

[02]Analyser les en-têtes, l’URL et la pièce jointe. Extraire les indicateurs utiles.

[03]Mesurer les destinataires et les interactions (ouverture, clic, réponse, transfert).

[04]Vérifier les connexions après le message, puis les règles de boîte et consentements OAuth.

[05]Conclure : suppression / blocage d’indicateurs / révocation de sessions / incident BEC.

Fiche pédagogique 1/3 : Règle de transfert externe expliqué — Fiche 1/3 - débutant essentiel

##Preuves à collecter (minimum viable)

Groupe 1 : Message et artefacts (avant toute action)

->En-têtes du message (trace complète disponible).
->URL observées (telles qu’encodées dans le mail).
->Pièces jointes : nom, type, hachage si vous l’avez, et mode de livraison.

Groupe 2 : Étendue et interactions

->Liste des destinataires internes impactés (utilisateurs, boîtes partagées).
->Qui a ouvert, cliqué, répondu, ou transféré (même partiel).
->Copie des actions déjà lancées (purge, quarantaine, remédiation).

Groupe 3 : Après réception : signaux de persistance

->Connexions liées aux comptes des destinataires (fenêtre autour de la réception).
->Règles de boîte : nouvelles règles, modifications, règles de transfert externe.
->Consentements OAuth ajoutés ou modifiés après le message (si visibles dans vos outils).

Fiche pédagogique 2/3 : Règle de transfert externe expliqué — Fiche 2/3 - débutant guidé

##Carte de contrôle : télémétrie → vérification → décision

Une vue “contrôles” pour ne rien oublier. Chaque bloc doit produire une trace simple et une action possible.

1) En-têtes email

├─Relier le message à l’expéditeur technique (domaines réels, chemins d’acheminement).
├─Comparer expéditeur technique vs nom affiché (écart = signal, pas preuve).
└─Valider la présence réelle d’URL et de pièces jointes dans le contenu.

2) URL et pièce jointe

├─Classer : URL de collecte d’identifiants, redirection, téléchargement, ou lien “banal”.
├─Si indicateurs confirmés : préparer le blocage (en restant cohérent avec vos procédures).
└─Si doute : conserver les artefacts et continuer le pivot “étendue et interactions”.

3) Connexions, règles de boîte, consentements (post-réception)

├─Chercher un changement après le message : nouvelle règle, nouveau transfert, consentement ajouté.
├─Si règle de transfert externe apparaît après réception : traiter comme persistance potentielle.
└─Décider : révocation de sessions et ouverture incident BEC si impact ou compromission probable.

Fiche pédagogique 3/3 : Règle de transfert externe expliqué — Fiche 3/3 - débutant enrichi

##Questions de décision (pour trancher sans sur-réagir)

Quelle observation me permet de décider entre “suppression du message” et “incident BEC” ?

Décidez “suppression seule” si vous ne voyez pas de chaîne post-réception (pas de clic utile, pas de connexion suspecte, pas de règle/consentement). Basculez vers “incident BEC” si vous reliez le message à un changement après réception (connexions anormales, règle de transfert externe, consentement OAuth).

Pourquoi le nom affiché de l’expéditeur n’est pas un critère de décision ?

Parce que c’est facile à falsifier. Utilisez-le au mieux comme signal de tri, puis pivotez sur l’expéditeur technique via les en-têtes et la trace de livraison.

Quel est le mécanisme central à ne pas rater ?

Relier le message reçu à son expéditeur technique, ses destinataires, ses clics et les actions effectuées après réception. Référence : Microsoft Defender for Office 365 (Threat Explorer) décrit cette logique d’investigation et de pivots : https://learn.microsoft.com/en-us/defender-office-365/threat-explorer-investigate-delivered-malicious-email