Préparation d'un tenant Microsoft 365 pour le DFIR

Règle d'or de l'intervention cloud

Ne vous connectez jamais à un tenant compromis avec les identifiants d’un administrateur existant du client. Ces comptes peuvent être piégés, surveillés par l’adversaire ou compromis par vol de session. Toute action d’investigation doit obligatoirement émaner d’une identité cloud-only dédiée et nominative créée spécifiquement pour le CSIRT.

Concept

Lorsqu’une équipe de réponse à incident (CSIRT / CERT) ou un analyste forensique intervient sur un environnement Microsoft 365, la première priorité consiste à établir une tête de pont d’investigation sécurisée, traçable et non compromise.

La préparation du tenant n’est pas une simple formalité administrative : c’est un acte médicolégal fondamental. Elle garantit la valeur juridique des preuves collectées, évite d’alerter l’acteur malveillant et empêche les blocages techniques impromptus liés aux politiques d’accès conditionnel.

+---------------------------------------------------------------------------------------------------+
|                        CHAÎNE D'EMBARQUEMENT & PRÉPARATION DU TENANT EN DFIR                      |
|                                                                                                   |
|   +-------------------------------------------------------------------------------------------+   |
|   |                       PHASE 1 : PROVISIONING D'IDENTITÉS CLOUD-ONLY                       |   |
|   |   UPN dédié : sec-dfir-analyste01@client.onmicrosoft.com (Jamais synchronisé du On-Prem) |   |
|   |   Émission via Temporary Access Pass (TAP) | Zéro mot de passe statique partagé           |   |
|   +---------------------------------------------+---------------------------------------------+   |
|                                                 |                                                 |
|                                                 v                                                 |
|   +-------------------------------------------------------------------------------------------+   |
|   |                       PHASE 2 : DURCISSEMENT AUTHENTIFICATION & MFA                       |   |
|   |   Clé matérielle obligatoire (FIDO2) ou Microsoft Authenticator avec Number Matching      |   |
|   |   Exclusion des politiques legacy | Enrôlement sécurisé hors-bande (Out-of-Band)          |   |
|   +---------------------------------------------+---------------------------------------------+   |
|                                                 |                                                 |
|                                                 v                                                 |
|   +-------------------------------------------------------------------------------------------+   |
|   |                       PHASE 3 : AUDIT & ALIGNEMENT DE L'ACCÈS CONDITIONNEL                |   |
|   |   Audit des emplacements nommés | Whitelist des adresses IP fixes de sortie du CSIRT      |   |
|   |   Validation des filtres d'applications clientes | Prévention des blocages intempestifs   |   |
|   +---------------------------------------------+---------------------------------------------+   |
|                                                 |                                                 |
|                                                 v                                                 |
|   +-------------------------------------------------------------------------------------------+   |
|   |                       PHASE 4 : ATTRIBUTION DES RÔLES EN MOINDRE PRIVILÈGE                |   |
|   |   Entra ID : Global Reader + Security Reader | Purview : View-Only Audit Logs             |   |
|   |   Exchange : View-Only Recipients | Élévation temporaire contrôlée via PIM                |   |
|   +-------------------------------------------------------------------------------------------+   |
+---------------------------------------------------------------------------------------------------+

---

Pourquoi c’est important en DFIR

L’improvisation des accès en début d’incident produit immanquablement des désastres opérationnels :

1. Rupture de la chaîne de preuve : si plusieurs analystes et administrateurs internes utilisent un compte partagé générique admin_temp@client.com, l’imputabilité des actions dans l’Unified Audit Log est détruite. Il devient impossible de prouver devant un tribunal si une recherche sur une boîte mail a été ordonnée par l’expert judiciaire ou par l’attaquant.
2. Alerte de l’adversaire : si un intervenant utilise un compte compromis, les outils de surveillance de session de l’attaquant détectent immédiatement des connexions depuis des IP inconnues, provoquant une fuite précipitée de données ou le chiffrement destructeur de l’infrastructure.
3. Blocage de l’analyste : des politiques d’accès conditionnel mal appréhendées (blocage des postes non gérés par Intune, filtrage géographique strict) peuvent verrouiller les accès de l’analyste au moment le plus critique de l’intervention.
4. Pollution des comptes de secours : employer les comptes de secours (“Break-Glass”) pour le travail quotidien prive l’organisation de son ultime filet de sécurité en cas de crise majeure.

---

Comment ça fonctionne

1. L’impératif du compte “cloud-only”

Les comptes d’investigation doivent impérativement être créés directement dans le cloud, sous le domaine racine du tenant (client.onmicrosoft.com).

• Raison technique : un compte synchronisé depuis l’Active Directory interne (OnPremisesSyncEnabled: True) dépend de la sécurité des contrôleurs de domaine et du serveur Entra Connect (Fiche 39 : entra Connect). Si l’attaquant contrôle l’AD interne, il peut réinitialiser à volonté le mot de passe de l’analyste cloud depuis le site physique.

2. Embarquement sécurisé par temporary access pass (TAP)

Pour éviter la transmission non sécurisée de mots de passe temporaires par courriel ou messagerie instantanée :

1. L’administrateur du client génère un Temporary Access Pass (TAP) à usage unique, valide pendant 1 heure.
2. L’analyste se connecte sur myprofile.microsoft.com à l’aide de ce passe temporaire via un canal sécurisé hors-bande (Signal, téléphone).
3. L’analyste enrôle sa propre clé de sécurité physique FIDO2 (YubiKey) ou son application Microsoft Authenticator.
4. Aucun mot de passe statique ne transite sur le réseau.

3. Ajustement de l’accès conditionnel

L’administrateur doit adapter ses politiques de filtrage réseau :

• Intégrer les adresses IP publiques de sortie du CSIRT dans les Emplacements Nommés de Confiance (Named Locations).
• Exclure le groupe des comptes d’investigation des règles exigeant des Appareils Conformes (le poste de l’analyste n’étant pas géré par le MDM Intune du client).

4. Faisceau de rôles en moindre privilège

Le réflexe courant consistant à attribuer le rôle Global Administrator est une faute professionnelle : il crée une responsabilité juridique démesurée et ne confère même pas les droits d’audit dans Microsoft Purview (Fiche 05 : global Reader). Le bouquet minimal d’investigation requiert :

• Entra ID : Global Reader + Security Reader.
• Microsoft purview : View-Only Audit Logs (ou groupe View-Only Organization Management).
• Exchange online : View-Only Recipients ou Compliance Management.

---

Ce qui est possible

Un protocole rigoureux permet de :

• Garantir la non-répudiation : chaque extraction et chaque recherche est tracée sous l’identité nominative exclusive de l’expert.
• Assurer une lecture forensique complète : interroger l’intégralité des flux de journalisation sans risquer de modifier ou de corrompre l’environnement de production.
• Opérer en toute discrétion : mener l’analyse en dehors des canaux de messagerie et des comptes potentiellement surveillés par l’intrus.

---

Ce qui n’est pas possible

• Invisibilité totale dans les logs d’audit : la création du compte forensique et ses connexions génèrent obligatoirement des traces dans les journaux d’audit Entra. Si l’attaquant possède déjà les droits d’Administrateur Général, il peut observer l’apparition du compte sec-dfir-analyste01.
• Récupération des données antérieures à la rétention : la préparation du tenant fige le présent et le futur, mais ne peut en aucun cas ressusciter des journaux déjà purgés avant le début de l’intervention (Fiche 18 : Rétention d’Audit).

---

Conditions nécessaires

1. Canal de communication hors-bande validé : échange préalable de clés Signal ou confirmation vocale avec le directeur de crise du client.
2. Plages d’IP fixes déclarées : fourniture des adresses IP publiques de sortie de l’équipe de réponse à incident.
3. Mandat d’intervention signé : autorisation légale expresse de collecte et d’analyse des données du tenant.

---

Artefacts et journaux

Action Réalisée	Journal Concerné	Nom de l’Événement	Portée Probatoire
Création du compte forensique	Entra Directory Audit	Add user	Établit l’horodatage officiel de début d’intervention.
Génération du TAP	Entra Directory Audit	Generate temporary access pass	Démontre un embarquement sécurisé sans mot de passe partagé.
Enrôlement FIDO2 / MFA	Entra Directory Audit	User registered security info	Prouve l’emploi d’une authentification forte par l’analyste.
Octroi des rôles d’audit	Entra Directory Audit	Add member to role	Documente la stricte limitation aux privilèges de lecture.
Déclaration de l’IP du CSIRT	Entra Directory Audit	Add named location	Justifie la légitimité des connexions depuis les IP du CERT.

---

Méthodologie d’investigation

1. Fourniture du script d’onboarding à l’administrateur : Transmettre le script PowerShell de création de compte cloud-only avec attribution des rôles en lecture seule :

   # 1. Création du compte cloud-only d'investigation
   $PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
   $PasswordProfile.ForceChangePasswordNextLogin = $true
   $PasswordProfile.Password = "Mot-De-Passe-Unique-Complexe!"
   
   $User = New-MgUser -DisplayName "CSIRT Analyste Forensique 01" `
     -UserPrincipalName "sec-dfir-analyste01@client.onmicrosoft.com" `
     -AccountEnabled $true -MailNickname "sec-dfir-analyste01" `
     -PasswordProfile $PasswordProfile
   
   # 2. Attribution du rôle Global Reader
   $Role = Get-MgDirectoryRole | Where-Object {$_.DisplayName -eq "Global Reader"}
   New-MgDirectoryRoleMember -DirectoryRoleId $Role.Id -DirectoryObjectId $User.Id

2. Attribution des privilèges purview : Assigner le rôle d’audit dans le portail de conformité Purview :

   Connect-IPPSSession
   Add-RoleGroupMember -Identity "View-Only Organization Management" -Member "sec-dfir-analyste01@client.onmicrosoft.com"

3. Validation de l’accès et de l’authentification : Réaliser une première connexion interactive depuis la machine d’analyse pour valider le MFA et vérifier l’absence de blocage d’accès conditionnel.

4. Contrôle de l’activation globale de l’audit : Vérifier formellement que l’Unified Audit Log est actif sur le tenant :

   Connect-ExchangeOnline
   Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

---

Exemple concret / cas d’école

Scénario : l’enquête parasitée par un compte partagé

Lors d’une fraude au président en cours, le responsable informatique crée en hâte un compte générique audit@entreprise.fr et communique le mot de passe par SMS à l’analyste externe. L’attaquant, qui avait préalablement compromis le téléphone portable du responsable informatique, intercepte le message.

La dérive :

1. L’attaquant se connecte sur audit@entreprise.fr dix minutes avant l’analyste avec le mot de passe partagé.
2. Il observe les recherches exécutées dans Purview et identifie immédiatement les boîtes mail placées sous surveillance.
3. Il efface ses règles de transfert malveillantes et tente une exfiltration massive de données confidentielles avant que l’analyste n’ait pu geler les preuves.

La remédiation : Le CSIRT ordonne la neutralisation immédiate du compte générique, bascule sur des comptes cloud-only nominatifs protégés par clés FIDO2 et isole l’ensemble des flux d’investigation sur un canal étanche.

---

Pièges et confusions fréquentes

Piège Fréquent	Réalité Opérationnelle	Conséquence Forensique
Utiliser un compte synchronisé AD	Si l’AD local est compromis, l’attaquant peut réinitialiser le compte de l’analyste cloud.	Compromission de la session de l’investigateur par rebond on-premises.
Valider le MFA de l’analyste par SMS	Le SMS est exposé aux attaques de SIM-swapping et au phishing AiTM.	Fragilisation de la sécurité des accès de l’équipe de réponse à incident.
Oublier les rôles purview	Le rôle Global Reader seul ne permet pas d’interroger l’Unified Audit Log.	Perte de temps critique durant les premières heures d’intervention.

---

Points clés à retenir

1. Les comptes cloud-only sont obligatoires : ne jamais utiliser de compte synchronisé Active Directory pour enquêter sur le cloud.
2. Le MFA résistant au phishing est la règle : clé physique FIDO2 ou Microsoft Authenticator avec Number Matching sans exception.
3. L’imputabilité protège les analystes : les comptes nominatifs séparent clairement les actions de l’enquête de celles de l’intrus.
4. Associer rôles d’annuaire et rôles de conformité : Global Reader doit impérativement être complété par les droits d’audit Purview.

---

État de la fonctionnalité en 2026

Changements récents

• Généralisation du temporary access pass (TAP) : procédure standard d’enrôlement initial sans aucun mot de passe temporaire manipulé en clair.
• PIM for groups : les accès d’investigation peuvent désormais être groupés dans un groupe de sécurité éligible PIM, attribuant d’un seul coup les rôles Entra et Purview pour une durée bornée.

Fonctionnalités dépréciées

• Les mots de passe d’application (App Passwords) pour contourner le MFA sont totalement bannis.

---

Références

• Microsoft Learn : déploiement de Privileged Identity Management (PIM)
• Microsoft Learn : configurer le passe d’accès temporaire dans Microsoft Entra ID
• Microsoft Learn : autorisations dans le portail de conformité Microsoft Purview
• Hermes Codex : global Reader en DFIR : capacités, limites et pièges