Aller au contenu
Hermes Codex

Analyse des journaux d'audit Microsoft entra

Tandis que les journaux de connexion enregistrent les franchissements du périmètre d’authentification, les journaux d’audit d’annuaire Microsoft Entra ID (Directory Audit Logs) consignent la manière dont l’annuaire lui-même est modifié. Lors d’une cyberattaque dans le cloud, un pirate ne se contente presque jamais d’utiliser passivement des identifiants volés : il altère les objets de l’annuaire pour installer sa persistance, élever ses privilèges, contourner les politiques de sécurité et exfiltrer des ressources stratégiques.

Les journaux d’audit d’Entra ID enregistrent chaque mutation administrative, programmatique et de cycle de vie : création d’utilisateurs, modifications de groupes, attributions de rôles d’annuaire, activations Privileged Identity Management (PIM), consentements accordés à des applications OAuth, injections de certificats ou de secrets sur des principaux de service et modifications des politiques de sécurité.

Cette fiche fournit une analyse forensique complète des journaux d’audit Entra, de leur schéma JSON, des événements critiques d’attaque et des requêtes de détection en environnement de production.

Concept

Section intitulée « Concept »

Les journaux d’audit d’Entra ID fonctionnent comme un registre immuable consignant l’ensemble des transitions d’état sur les objets du plan de contrôle :

graph TD
    subgraph "Moteur de mutation de l'annuaire Entra ID"
        ADMIN[Action Admin / Script / Élévation PIM]
        APP[Application automatisée / Principal de service]


        ADMIN -->|Exécution de la modification| CORE[Magasin central Entra Directory]
        APP -->|Exécution de la modification| CORE


        CORE -->|Génération de l'événement d'audit| PIPELINE[Pipeline d'ingestion d'audit]


        PIPELINE --> AUDIT_LOG["Journaux d'Audit d'Annuaire<br/>(AuditLogs dans Sentinel / Graph API)"]


        AUDIT_LOG --> CAT1[Cycle de vie Utilisateurs & Groupes]
        AUDIT_LOG --> CAT2[Gestion des Rôles & Activations PIM]
        AUDIT_LOG --> CAT3[Enregistrement d'Apps & Injection de Secrets]
        AUDIT_LOG --> CAT4[Octroi de Consentements OAuth]
        AUDIT_LOG --> CAT5[Accès Conditionnel & Politiques de Sécurité]
    end

Catégories fondamentales

Section intitulée « Catégories fondamentales »
  • UserManagement & GroupManagement : création et désactivation de comptes, réinitialisation de mots de passe, modifications des membres de groupes de sécurité ou de groupes assignables à des rôles.
  • RoleManagement : attributions directes et éligibilités de rôles hautement privilégiés (Global Administrator), révocations et approbations PIM.
  • ApplicationManagement : enregistrement d’applications, création de principaux de service et ajout de secrets clients ou certificats (vecteur privilégié de persistance).
  • ConsentManagement : octrois de consentements utilisateur et administrateur pour des autorisations déléguées ou applicatives (OAuth2PermissionGrant).
  • Policy : création, modification ou suppression de politiques d’accès conditionnel, d’emplacements nommés ou de méthodes d’authentification.

Pourquoi c’est important en DFIR

Section intitulée « Pourquoi c’est important en DFIR »

Les journaux d’audit d’annuaire constituent la source de preuve formelle permettant de reconstituer les manœuvres post-compromission d’un adversaire :

  1. Détection des backdoors applicatives : les attaquants injectent fréquemment un secret ou un certificat sur une application d’entreprise légitime existante pour disposer d’un accès API persistant et silencieux qui survit aux réinitialisations de mots de passe.
  2. Reconstitution de l’élévation de privilèges : identification précise du moment où un compte compromis a été ajouté à un groupe d’administration ou a activé un rôle PIM avec un faux motif de ticket.
  3. Mise en évidence des attaques par consentement illicite (illicit consent grant) : repérage des cas où un utilisateur ou un administrateur a consenti des privilèges excessifs (Mail.ReadWrite, Files.ReadWrite.All) à une application multi-tenant malveillante.
  4. Détection de l’évasion de défenses (altération de politiques) : preuve formelle qu’un attaquant a modifié une règle d’accès conditionnel pour exclure son adresse IP ou désactiver l’obligation de MFA.
  5. Surveillance des méthodes d’authentification frauduleuses : détection de l’ajout d’une clé FIDO2 ou d’une application d’authentification secondaire sur le compte d’une victime pour garantir un accès pérenne.

Dissection du schéma JSON : les champs clés

Section intitulée « Dissection du schéma JSON : les champs clés »

Lors de l’interrogation via Microsoft Graph API (/auditLogs/directoryAudits) ou Azure Log Analytics (AuditLogs), les champs suivants forment la structure de preuve indispensable :

Champ (Graph API)Champ (Log Analytics)Signification forensique et interprétation
idCorrelationId / IdGUID unique de l’événement. À corréler avec les logs de connexion pour identifier la session administrative à l’origine de l’action.
activityDateTimeTimeGeneratedHorodatage UTC précis de la validation de la modification dans l’annuaire.
activityDisplayNameOperationNameNom explicite de l’opération (ex. “Add member to role”, “Update application - Certificates and secrets management”).
categoryCategoryDomaine opérationnel : RoleManagement, ApplicationManagement, UserManagement, Policy.
loggedByServiceLoggedByServiceSous-système à l’origine de l’événement : Core Directory, PIM, Self-service Password Reset.
initiatedByInitiatedByIdentité de l’acteur. Soit un Utilisateur (userPrincipalName, ipAddress, id), soit une Application (appId, displayName).
targetResourcesTargetResourcesTableau des objets modifiés. Contient id, displayName, type (“User”, “Role”, “Application”) et modifiedProperties.
modifiedPropertiesTableau JSON interne dans TargetResourcesLe joyau de la preuve forensique. Détaille displayName, oldValue et newValue pour chaque propriété modifiée.
additionalDetailsAdditionalDetailsMétadonnées complémentaires : User-Agent, justificatif de ticket PIM, identifiant de session.
resultResultRésultat de l’opération : success ou failure.
resultReasonResultReasonMotif du rejet en cas d’échec (ex. privilèges insuffisants, rejet d’approbation PIM).

Opérations d’audit critiques pour le DFIR

Section intitulée « Opérations d’audit critiques pour le DFIR »

L’analyste DFIR doit surveiller en priorité absolue les opérations activityDisplayName suivantes :

Intitulé de l’opérationCatégorieVecteur d’attaque associé / Contexte
Add member to roleRoleManagementAttribution directe d’un rôle d’annuaire à haut privilège (ex. Global Admin, Privileged Auth Admin).
Add eligible member to roleRoleManagementAttribution d’une éligibilité PIM permettant à l’attaquant de s’élever à la demande.
Add member to groupGroupManagementAjout d’un compte à un groupe synchronisé vers l’Active Directory local ou doté de rôles.
Update application - Certificates and secrets managementApplicationManagementPERSISTANCE CRITIQUE : Injection d’un secret client ou d’un certificat sur une application.
Add service principal credentialsApplicationManagementAjout d’informations d’identification sur un principal de service existant pour automatisation malveillante.
Consent to applicationConsentManagementOctroi d’autorisations OAuth (ex. lecture de courriers ou de fichiers) à une application externe.
Update policy / Delete policyPolicyModification ou suppression d’une règle d’accès conditionnel ou d’une méthode d’authentification.
Admin registered security infoUserManagementUn administrateur a configuré un nouveau numéro de téléphone ou une clé FIDO2 sur un compte.
User registered security infoUserManagementL’utilisateur ciblé a enregistré une nouvelle méthode MFA (persistance post-compromission).
Hard delete userUserManagementEffacement de traces : suppression définitive d’un compte fantôme ou d’un objet compromis.

Ce qui est possible vs ce qui n’est pas possible

Section intitulée « Ce qui est possible vs ce qui n’est pas possible »

Ce qui est possible

Section intitulée « Ce qui est possible »
  • Reconstituer le différentiel exact des modifications : comparer oldValue et newValue dans modifiedProperties pour identifier précisément ce qui a changé (ex. quelle IP a été ajoutée à un emplacement nommé).
  • Identifier l’auteur formel de la modification : établir si l’action émane d’un administrateur humain (avec son IP et son compte) ou d’un principal de service via l’API Graph.
  • Auditer la chaîne d’approbation PIM : retrouver les demandes d’élévation, les approbateurs et le motif de ticket saisi.
  • Détecter les backdoors applicatives dormantes : mettre au jour les applications d’entreprise créées ou modifiées avec des droits API exorbitants.

Ce qui n’est pas possible

Section intitulée « Ce qui n’est pas possible »
  • Tracer la lecture de données utiles : les journaux d’audit indiquent qu’une application a obtenu le droit Mail.ReadWrite ; ils n’indiquent pas quels e-mails ont été lus (ceci requiert l’UAL Purview ou les Graph Activity Logs).
  • Récupérer l’historique sur un tenant expiré : les événements antérieurs à 7 jours sur Entra Free ou 30 jours sur P1/P2 sont définitivement effacés sans archivage Log Analytics.
  • Visualiser la valeur en clair d’un secret : lorsqu’un attaquant génère un secret client, le journal consigne son nom et sa date d’expiration, mais jamais la valeur secrète elle-même.
  • Détecter la reconnaissance passive : un administrateur ou un pirate énumérant les utilisateurs ou les groupes via l’interface ou PowerShell ne génère aucun log dans Directory Audits (les opérations de lecture d’annuaire ne sont pas enregistrées ici).

Méthodologie d’investigation : extraction et détection KQL

Section intitulée « Méthodologie d’investigation : extraction et détection KQL »
Fenêtre de terminal
# ==============================================================================
# Hermes Codex - Extracteur des journaux d'audit d'annuaire Entra ID
# Exporte les modifications d'annuaire, de rôles et d'applications
# ==============================================================================


Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Reports -ErrorAction Stop
Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All" -NoWelcome


$DaysBack = 30
$StartDate = (Get-Date).AddDays(-$DaysBack).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
$OutDir = "./Entra_DirectoryAudits_$(Get-Date -Format 'yyyyMMdd')"
New-Item -ItemType Directory -Path $OutDir -Force | Out-Null


Write-Host "[*] Extraction des audits d'annuaire Entra depuis $StartDate..." -ForegroundColor Cyan


$filter = "activityDateTime ge $StartDate"
$auditUri = "https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?`$filter=$filter&`$top=500"


$allAudits = [System.Collections.Generic.List[PSObject]]::new()
do {
    $resp = Invoke-MgGraphRequest -Method GET -Uri $auditUri
    if ($resp.value) { $allAudits.AddRange($resp.value) }
    $auditUri = $resp.'@odata.nextLink'
    Write-Host "    [+] $($allAudits.Count) enregistrements collectés..." -ForegroundColor Gray
    Start-Sleep -Milliseconds 150
} while ($null -ne $auditUri)


$outputFile = "$OutDir/DirectoryAudits_30Jours.jsonl"
$allAudits | ForEach-Object { $_ | ConvertTo-Json -Compress -Depth 10 } | Set-Content -Path $outputFile


$hash = Get-FileHash -Path $outputFile -Algorithm SHA256
Write-Host "[✓] Extraction terminée : $($allAudits.Count) événements. SHA-256 : $($hash.Hash)" -ForegroundColor Green

Exemple d’investigation : la backdoor applicative furtive

Section intitulée « Exemple d’investigation : la backdoor applicative furtive »

Contexte de l’incident

Section intitulée « Contexte de l’incident »

Un pirate compromet les identifiants d’un technicien du support informatique disposant du rôle Cloud Application Administrator.

Reconstitution chronologique dans les journaux d’audit

Section intitulée « Reconstitution chronologique dans les journaux d’audit »
  1. Accès initial : À 02h14 UTC, le pirate s’authentifie depuis une IP étrangère (tracée dans m365-09).
  2. Reconnaissance : le pirate énumère les applications d’entreprise existantes via PowerShell (aucun log d’audit généré car il s’agit d’une simple lecture).
  3. L’action de persistance (02h22:15 UTC) :
    • OperationName : Update application - Certificates and secrets management.
    • InitiatedBy.user.userPrincipalName : admin_support@entreprise.fr.
    • TargetResources[0].displayName : Reporting-Finances-Automate (une application métier légitime et approuvée).
    • TargetResources[0].modifiedProperties :
      • displayName : KeyDescription.
      • oldValue : [].
      • newValue : [{"KeyIdentifier":"3a8f...","DisplayName":"CertificatMaintenance2026","EndDateTime":"2028-09-16T00:00:00Z"}].
  4. Exploitation :
    • L’application Reporting-Finances-Automate disposait déjà de permissions applicatives étendues (Exchange.ManageAsApp et User.ReadWrite.All).
    • En ajoutant un secret à une application existante au lieu d’en créer une nouvelle, l’attaquant a évité de déclencher les alertes SOC sur la création de nouvelles applications.
    • Il a ensuite basculé l’ensemble de ses requêtes via l’identité du Principal de service, échappant ainsi aux règles d’accès conditionnel ciblant les utilisateurs et survivant à la réinitialisation du mot de passe du technicien.

Sans l’examen minutieux de modifiedProperties dans les journaux d’audit Entra, l’équipe de réponse à incident aurait réinitialisé le mot de passe du technicien en pensant l’incident clos, laissant à l’attaquant un accès administratif permanent et indétectable.

Doctrine transversale : télémétrie d’audit vs preuve formelle

Section intitulée « Doctrine transversale : télémétrie d’audit vs preuve formelle »

Toute altération constatée dans les journaux d’audit doit être évaluée selon les 7 niveaux de certitude de Hermes Codex :

+-------------------------------------------------------------------------------+
|                      LES 7 NIVEAUX DE CERTITUDE FORENSIQUE                     |
|                                                                               |
|  1. Possible     -> La plateforme supporte l'opération d'administration.       |
|  2. Configuré   -> L'audit d'annuaire est actif et diffusé vers Log Analytics.|
|  3. Autorisé    -> L'identité disposait des privilèges RBAC requis.           |
|  4. Accessible  -> L'identité pouvait joindre les interfaces d'administration.|
|  5. Utilisé     -> La mutation a été soumise et validée par l'annuaire.       |
|  6. Observé     -> L'enregistrement figure dans AuditLogs avec ses propriétés.|
|  7. Prouvé      -> La corrélation prouve l'action malveillante et la fraude.  |
+-------------------------------------------------------------------------------+

Distinctions forensiques dans les journaux d’audit

Section intitulée « Distinctions forensiques dans les journaux d’audit »
  1. Autorisé != utilisé : un compte possédait le rôle Privileged Role Administrator (autorisé à nommer des administrateurs généraux). Cela ne prouve aucunement qu’il l’a fait tant qu’aucun événement Add member to role n’est observé dans AuditLogs.
  2. Utilisé != malveillant : l’ajout d’un secret sur une application (Add service principal credentials) est une tâche de maintenance courante en entreprise. Pour prouver qu’elle est malveillante, l’analyste doit démontrer :
    • Que la session à l’origine de l’action était compromise (discordance d’IP, jeton AiTM).
    • Qu’aucun ticket de changement DevOps ne correspond à la date et à l’heure de l’événement.
    • Que le principal de service a ensuite été utilisé depuis une infrastructure inconnue.
  3. Observé != prouvé : un log avec Result = "success" prouve qu’une modification a eu lieu. Pour prouver l’intrusion complète, l’analyste doit relier cette mutation à la chaîne d’attaque globale (phishing initial -> connexion anormale -> création de backdoor -> exfiltration dans l’UAL).

Pièges et confusions fréquentes

Section intitulée « Pièges et confusions fréquentes »
PiègeCause techniqueConséquence pour l’enquêteAction corrective
Chercher les règles de messagerie dans l’audit entraLes règles de boîte aux lettres relèvent d’Exchange Online, pas de l’annuaire Entra.Aucune trace de règle de transfert trouvée dans les logs d’audit d’annuaire.Rechercher New-InboxRule ou Set-Mailbox dans l’UAL Purview (m365-13).
Négliger les modifications initiées par des applicationsNe filtrer que sur InitiatedBy.user en ignorant les actions menées par InitiatedBy.app.Les actions automatisées de l’attaquant via des scripts Graph restent invisibles.Analyser systématiquement les deux branches InitiatedBy.user et InitiatedBy.app.
S’arrêter à la réinitialisation du mot de passeOublier d’auditer l’ajout de secrets applicatifs pendant la fenêtre de compromission.L’attaquant conserve un accès programmatique total malgré le changement de mot de passe.Auditer systématiquement l’opération Update application - Certificates and secrets management.
Ignorer les objets imbriqués dans ModifiedPropertiesmodifiedProperties est un tableau d’objets JSON au sein de TargetResources.Les exports CSV plats tronquent les anciennes et nouvelles valeurs.Déplier les objets avec mvexpand en KQL ou parser le JSON en PowerShell.
Croire que la consultation d’annuaire est journaliséeLes journaux d’audit ne consignent que les modifications (écriture, mise à jour, suppression).Conclure à tort à l’absence de reconnaissance interne car aucun log d’audit n’apparaît.Activer les Microsoft graph activity logs vers Log Analytics pour tracer les requêtes en lecture.

État de la fonctionnalité en 2026

Section intitulée « État de la fonctionnalité en 2026 »

Changements récents

Section intitulée « Changements récents »
  • Télémétrie PIM 2.0 enrichie : les activations de rôles intègrent nativement les approbations multi-personnes, les identifiants de tickets et les méthodes d’élévation step-up.
  • Régulation sur la durée de vie des secrets : entra ID applique des limites strictes sur la durée de validité des secrets applicatifs et émet des alertes d’audit proactives.
  • Audits de synchronisation inter-tenants : prise en compte exhaustive des modifications de confiance B2B Direct Connect et des stratégies d’accès inter-organisations.

Fonctionnalités dépréciées

Section intitulée « Fonctionnalités dépréciées »
  • API azure AD graph (graph.windows.net) : définitivement retirée. Toute collecte programmatique d’audits d’annuaire doit cibler Microsoft Graph (graph.microsoft.com/v1.0/auditLogs/directoryAudits).
  • Module PowerShell MSOnline (Get-MsolAuditLog) : totalement obsolète. Remplacé par Microsoft.Graph.Reports.

Limitations actuelles

Section intitulée « Limitations actuelles »
  • Absence de journalisation native des lectures : les requêtes d’énumération en lecture (GET /users, GET /groups) ne sont pas capturées dans les logs d’audit. La détection de reconnaissance interne requiert la configuration des Microsoft Graph Activity Logs.
  • Masquage de la valeur en clair du secret : par mesure de sécurité, Microsoft ne consigne jamais le texte en clair du secret généré ; l’analyste n’a accès qu’à l’identifiant de clé, au nom et à l’expiration.

Points clés à retenir

Section intitulée « Points clés à retenir »
  1. Les journaux d’audit d’annuaire tracent la persistance et l’escalade : lors de la compromission d’un compte administrateur, auditer immédiatement ApplicationManagement et RoleManagement.
  2. Le champ modifiedProperties est la preuve reine : toujours comparer l’ancienne et la nouvelle valeur pour qualifier la modification.
  3. Se méfier des backdoors applicatives : les pirates contournent les réinitialisations de mot de passe en injectant des secrets sur des applications d’entreprise existantes.
  4. Surveiller l’enregistrement des méthodes MFA : détecter l’enrôlement d’une clé FIDO2 ou d’un téléphone tiers sur le compte de la victime.
  5. La lecture passive ne laisse pas de trace d’audit ici : l’absence de log n’exclut pas une reconnaissance ; exploiter les Graph Activity Logs pour investiguer les lectures.

Références

Section intitulée « Références »