Kill chain de compromission de compte M365

Dans les cyberattaques d’entreprise contemporaines, la compromission d’une identité cloud n’est presque jamais un incident isolé. Elle constitue au contraire le pivot initial d’une intrusion multi-étapes sophistiquée et orchestrée. La Kill Chain de Compromission de Compte Microsoft 365 adapte les modèles doctrinaux de cyber kill chain aux spécificités du plan d’identité Microsoft Entra ID, des services SaaS (Exchange Online, SharePoint, Teams) et des flux de jetons OAuth 2.0 / OpenID Connect.

Les équipes de réponse à incident échouent fréquemment à circonscrire les attaques cloud lorsqu’elles traitent la compromission de compte (ATO) de manière ponctuelle — en se limitant à réinitialiser le mot de passe de la victime, laissant intactes les applications OAuth malveillantes, les méthodes MFA de secours injectées par l’attaquant, les règles de redirection invisibles et les sessions actives.

Ce guide détaille les 7 phases complètes de la Kill Chain M365, leurs mécanismes techniques sous-jacents, les artefacts forensiques associés et les exigences probatoires nécessaires pour étayer chaque étape de l’investigation.

1. Architecture globale des 7 phases de la kill chain M365

Contrairement aux intrusions Active Directory locales où les attaquants manipulent des tickets Kerberos, des condensats NTLM et des liaisons RPC, les intrusions Microsoft 365 s’opèrent quasi exclusivement via HTTPS (APIs REST, Microsoft Graph, OData, SOAP) et des JSON Web Tokens (JWT) :

graph TD
    subgraph "Phase 1 : Reconnaissance"
        P1_RECON[Énumération des Cibles & Découverte du Tenant<br/>API GetCredentialType, Configuration OpenID, Récolte SPF/MX]
    end

    subgraph "Phase 2 : Ingress Initial"
        P2_INGRESS[Exécution du Vecteur d'Accès Initial<br/>Phishing AiTM, Device Code Flow, Consentement OAuth, Password Spray]
    end

    subgraph "Phase 3 : Authentification & Vol de Jetons"
        P3_AUTH[Contournement MFA & Capture de Session<br/>Vol des Cookies ESTSAUTH, Abus du PRT, Fatigue MFA Push]
    end

    subgraph "Phase 4 : Persistance & Backdoors"
        P4_PERSIST[Injection de Mécanismes et Méthodes Secondaires<br/>Enrôlement de Méthode MFA, Application OAuth Malveillante, Règles de Boîte]
    end

    subgraph "Phase 5 : Découverte Interne"
        P5_DISC[Reconnaissance Interne du Tenant Cloud<br/>Énumération MS Graph, Récolte GAL, Recherche SharePoint]
    end

    subgraph "Phase 6 : Mouvement Latéral & Élévation"
        P6_LATERAL[Phishing Interne, Abus PIM & Détournement de Rôles<br/>Attribution d'App Roles, Manipulation de Groupes, Franchissement de Tiers]
    end

    subgraph "Phase 7 : Exfiltration & Impact"
        P7_IMPACT[Fraude Financière & Exfiltration de Données Sensibles<br/>Fraude au Virement BEC, Synchronisation Massive de Boîte, Téléchargement SharePoint]
    end

    P1_RECON --> P2_INGRESS
    P2_INGRESS --> P3_AUTH
    P3_AUTH --> P4_PERSIST
    P4_PERSIST --> P5_DISC
    P5_DISC --> P6_LATERAL
    P6_LATERAL --> P7_IMPACT

2. Décomposition technique et forensique par phase

Phase 1 : reconnaissance & énumération des cibles

Avant de tenter une authentification, l’attaquant profile passivement et activement le tenant cible :

Technique	Mécanisme Architectural	Artefact / Point de Terminaison Forensique	Outils Cybercriminels Typiques
Découverte du tenant	Interrogation des métadonnées OpenID pour obtenir le Tenant ID et les domaines personnalisés.	`https://login.microsoftonline.com/<domaine>/.well-known/openid-configuration`	AADInternals, curl, scripts Python
Énumération d’utilisateurs	Sondage de l’API `GetCredentialType` pour valider les UPNs réels sans incrémenter les verrous de mot de passe.	`POST https://login.microsoftonline.com/common/GetCredentialType` (`IfExistsResult` : 0 = Valide, 1 = Inexistant)	AADInternals, SprayingToolkit
Découverte de fédération	Identification du mode d’authentification (Géré, Seamless SSO, ou fédération ADFS).	Requête sur `Get-UserRealm.auth` renvoyant `IsFederated : True/False`	BloodHound Azure, Roadtools

Phase 2 : ingress initial

L’adversaire interagit directement avec l’utilisateur ou la frontière d’authentification pour capter des identifiants ou des autorisations :

graph TD
    VEC{Vecteur d'Ingress Initial}

    VEC -->|Proxy Inverse AiTM| AITM[Evilginx / Muraena<br/>La victime saisit identifiants + MFA sur un faux domaine]
    VEC -->|Device Code Flow| DCF[Phishing RFC 8628<br/>La victime saisit un user_code sur devicelogin]
    VEC -->|Consentement OAuth| CONSENT[Application Multi-Tenant Malveillante<br/>La victime clique sur Accepter les permissions]
    VEC -->|Password Spraying| SPRAY[Tests Distribués de Mots de Passe Courants<br/>Sondage des protocoles hérités ou web]

Reverse proxy AiTM : l’attaquant relaie le trafic de la victime vers les serveurs légitimes de Microsoft, interceptant au passage les identifiants et les cookies de session (voir Fiche 21 : Mécanismes du Reverse Proxy AiTM).
Abus du device code flow : l’attaquant transmet un code de liaison (user_code) et convainc la victime d’autoriser une application CLI (voir Fiche 25 : Abus du Device Code Flow).
Attaque par consentement illicite : l’attaquant fait valider des autorisations applicatives étendues (Mail.ReadWrite, offline_access) (voir Fiche 23 : Attaques par Consentement OAuth).
Password spraying : campagnes d’authentification lentes et distribuées pour contourner le verrouillage intelligent Entra Smart Lockout (voir Fiche 24 : Password Spray & Brute Force).

Phase 3 : authentification & capture de jetons

Une fois les éléments d’authentification interceptés, l’attaquant acquiert une session valide :

Rejeu des cookies de session :
- Les cookies dérobés ESTSAUTH et ESTSAUTHPERSISTENT sont injectés dans le navigateur de l’attaquant ou dans un outil d’automatisation headless.
- L’adversaire interroge les services cloud depuis sa propre infrastructure IP, court-circuitant le MFA puisque la session est déjà validée par Microsoft.
Abus du primary refresh token (PRT) :
- Sur un poste Windows compromis, un malware exploite le service Cloud AP pour demander silencieusement des jetons applicatifs sans aucune interaction utilisateur.
Fatigue MFA (push bombing) :
- Envoi répété de notifications Microsoft Authenticator jusqu’à ce que la victime clique sur « Approuver » par agacement ou erreur.

Signatures télémétriques :

SigninLogs : détection d’une connexion réussie (ResultType = 0) depuis une adresse IP ou un User-Agent étranger immédiatement après une validation MFA opérée depuis le réseau légitime de la victime.
Événements de risque entra ID protection : Atypical travel, Unfamiliar sign-in properties, Anomalous token (voir Fiche 12 : Forensique Entra ID Protection).

Phase 4 : persistance & backdoors

Sachant que les mots de passe finissent toujours par être renouvelés, l’adversaire installe immédiatement des mécanismes de persistance parallèles :

graph TD
    ACCESS[Compte Compromis Authentifié] --> P_MFA[Enrôlement de Méthode MFA Complice<br/>Clé FIDO2, Numéro de Téléphone, Authenticator]
    ACCESS --> P_APP[Consentement d'Application OAuth<br/>offline_access -> Jetons Graph API permanents]
    ACCESS --> P_RULE[Injection de Règles de Boîte / Transfert<br/>Redirection des emails financiers vers l'attaquant]
    ACCESS --> P_DEL[Attribution de Délégations de Boîte<br/>FullAccess ou SendAs à un compte invité]

Artefacts forensiques générés :

Logs d’audit entra ID (AuditLogs) :
- User registered security info (Ajout d’une méthode MFA ou d’un numéro de téléphone tiers).
- Add service principal / Consent to application (Autorisation d’une application OAuth tierce).
Unified audit log purview (ExchangeItem / AzureActiveDirectory) :
- New-InboxRule / Set-InboxRule (Règles cachées supprimant ou redirigeant des messages).
- Add-MailboxPermission (Octroi de privilèges délégués).

Phase 5 : découverte interne

Le maintien de l’accès étant assuré, l’attaquant cartographie le tenant et cible les informations stratégiques :

Énumération de l’annuaire via Microsoft graph :
- Inventaire des comptes utilisateurs, des groupes de sécurité et des rôles d’administration (GET /v1.0/users, GET /v1.0/directoryRoles).
Récolte de la liste globale d’adresses (GAL) :
- Identification de l’organigramme interne, de la direction générale, des responsables financiers et de la comptabilité fournisseurs.
Chasse aux mots-clés dans SharePoint & OneDrive :
- Requêtes ciblées via les moteurs de recherche Purview : "virement", "RIB", "facture", "confidentiel", "mots de passe", "acquisition".
- Sur les tenants dotés d’Audit Premium, ces requêtes génèrent les événements SearchQueryInitiatedSharePoint et SearchQueryInitiatedExchange dans le UAL.

Phase 6 : mouvement latéral & élévation de privilèges

L’adversaire tire parti de la confiance accordée au compte compromis pour étendre son emprise :

Phishing interne (BEC interne) :
- Envoi de messages de hameçonnage à d’autres collaborateurs depuis la boîte interne légitime. Le courrier ne traversant pas les passerelles anti-spam externes, le taux de clic dépasse fréquemment 60 %.
Abus de privileged identity management (PIM) :
- Si le compte est éligible à un rôle d’administration (ex. Exchange Administrator, User Administrator), l’attaquant active le rôle via l’API PIM (POST /v1.0/privilegedAccess/aadRoles/roleAssignmentRequests).
Empoisonnement de fichiers teams & SharePoint :
- Dépôt de documents piégés ou de scripts malveillants dans des canaux Teams partagés.

Phase 7 : exfiltration & impact

Cette phase matérialise l’objectif final de l’attaquant :

graph TD
    OBJ{Objectif Final de l'Attaquant}

    OBJ -->|Fraude au Virement| BEC[Compromission de Messagerie BEC<br/>1. Surveillance des factures par règles de boîte<br/>2. Interception des échanges fournisseurs<br/>3. Usurpation SendAs avec nouveau RIB bancaire]

    OBJ -->|Espionnage Industriel| EXFIL[Exfiltration Massive<br/>1. Synchronisation de boîte via Graph API<br/>2. Téléchargement en masse SharePoint/OneDrive<br/>3. Export des historiques de conversation Teams]

    OBJ -->|Extorsion & Rançongiciel| EXTORT[Rançonnage & Destruction<br/>1. Exfiltration de données personnelles RGPD<br/>2. Purge définitive des boîtes (HardDelete)<br/>3. Menace de divulgation publique]

Fraude au virement (BEC) : substitution de coordonnées bancaires lors d’une transaction légitime via SendAs ou SendOnBehalf (voir Fiche 17 : Audit de Boîte Mail).
Exfiltration massive de messagerie : utilisation d’ActiveSync ou de requêtes Graph API pour télécharger l’intégralité des messages, générant des événements MailItemsAccessed (Sync).
Vol de documents cloud : téléchargement automatisé de bibliothèques SharePoint/OneDrive, matérialisé par des milliers d’événements FileDownloaded (RecordType 6) dans le UAL.

3. Matrice de progression probatoire pour l’analyste DFIR

Chaque élément technique d’un rapport forensique doit respecter scrupuleusement la grille de qualification probatoire suivante :

Seuil Probatoire	Définition Technique	Exemple Forensique Réel
Possible	L’architecture autorise théoriquement l’attaque.	Le protocole IMAP est supporté sur le tenant.
Configuré	La configuration en place permet techniquement l’accès.	Les règles d’Accès Conditionnel ne bloquent pas l’authentification héritée.
Autorisé	Le compte dispose de la licence et des permissions nécessaires.	Le compte utilisateur dispose d’une licence Exchange Online Plan 2 active.
Accessible	Le chemin réseau et les frontières étaient joignables.	Les serveurs EOP ont accepté une connexion TCP 25 depuis l’IP de l’attaquant.
Utilisé	L’adversaire a concrètement sollicité le mécanisme.	Les logs `SigninLogs` indiquent `ClientAppUsed = IMAP4` avec `ResultType = 0`.
Observé	L’opération a produit un enregistrement d’audit tangible.	`CloudAppEvents` consigne `MailItemsAccessed (Sync)` sur le dossier `\Inbox`.
Prouvé	La corrélation bout en bout démontre l’impact irréfutable.	Les identifiants de messages résolus correspondent aux factures dont le RIB a été modifié.

4. Protocole d’endiguement d’urgence du compte compromis

Lorsqu’un compte est compromis, la réponse technique doit impérativement suivre cet ordre strict pour éviter toute reprise de contrôle par l’attaquant :

graph TD
    STEP1[1. Révocation des Sessions & Jetons Refresh<br/>Revoke-MgUserSignSession] --> STEP2[2. Réinitialisation du Mot de Passe<br/>Invalider les condensats d'authentification]
    STEP2 --> STEP3[3. Audit & Purge des Méthodes MFA<br/>Supprimer numéros, jetons et clés FIDO inconnus]
    STEP3 --> STEP4[4. Révocation des Applications & Consentements OAuth<br/>Remove-MgOauth2PermissionGrant]
    STEP4 --> STEP5[5. Suppression des Règles et Délégations de Boîte<br/>Remove-InboxRule, Remove-MailboxPermission]
    STEP5 --> STEP6[6. Révocation des Rôles PIM Actifs<br/>Couper les privilèges d'administration temporaires]

Script PowerShell d’endiguement d’urgence :

# Connexion avec les privilèges requis
# Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
# Connect-ExchangeOnline

$targetUser = "victim@target.com"
Write-Host "[*] Déclenchement de l'endiguement d'urgence pour : $targetUser" -ForegroundColor Yellow

# Étape 1 : Révocation immédiate de toutes les sessions actives et jetons
Revoke-MgUserSignSession -UserId $targetUser
Write-Host "[+] Toutes les sessions Entra ID actives ont été révoquées." -ForegroundColor Green

# Étape 2 : Contrôle des méthodes MFA enregistrées
$mfaMethods = Get-MgUserAuthenticationMethod -UserId $targetUser
Write-Host "[!] Examinez attentivement les méthodes MFA associées au compte :" -ForegroundColor Cyan
$mfaMethods | Select-Object Id, AdditionalProperties

# Étape 3 : Suppression des règles de boîte suspectes
$inboxRules = Get-InboxRule -Mailbox $targetUser
foreach ($rule in $inboxRules) {
    if ($rule.ForwardTo -or $rule.RedirectTo -or $rule.DeleteMessage) {
        Write-Warning "[!] Règle suspecte identifiée : $($rule.Name) -> Transfert : $($rule.ForwardTo) Suppression : $($rule.DeleteMessage)"
        # Remove-InboxRule -Mailbox $targetUser -Identity $rule.Identity -Confirm:$false
    }
}

# Étape 4 : Audit des consentements applicatifs OAuth accordés par l'utilisateur
$userGrants = Get-MgOauth2PermissionGrant -Filter "principalId eq '$((Get-MgUser -UserId $targetUser).Id)'"
Write-Host "[*] Consentements applicatifs détectés pour l'utilisateur : $($userGrants.Count)" -ForegroundColor Cyan
$userGrants | Select-Object ClientId, ResourceId, Scope