Audit Avancé Microsoft 365 : Corréler Journaux et Logs Azure

L'audit Microsoft 365 corréler journaux logs Azure est aujourd'hui une compétence fondamentale pour tout responsable sécurité qui gère un tenant M365. L'approche en silo — analyser Exchange Online séparément d'Azure AD, de SharePoint, et de Microsoft Defender — laisse passer des attaques sophistiquées qui n'existent que dans la corrélation inter-sources. En 2026, les acteurs avancés ciblent spécifiquement les angles morts entre les sources de logs M365, et ce n'est pas un hasard : ce sont des vecteurs délibérément choisis pour leur discrétion. Un attaquant qui vole un token OAuth ne génère aucune alerte d'authentification classique — il n'y a pas d'échec de MFA, pas de tentative de brute force, pas d'anomalie visible dans un seul journal. C'est uniquement en croisant le Unified Audit Log avec les Azure AD Sign-in Logs que l'on détecte l'anomalie de géolocalisation qui trahit un token replay. Sur toutes les investigations Microsoft 365 que je mène pour mes clients, la mise en place d'une corrélation via Microsoft Sentinel réduit le MTTR d'un facteur 3 par rapport à l'analyse manuelle des logs. Ce guide vous donne les requêtes KQL, l'architecture et le raisonnement défensif pour passer à ce niveau de maturité dans votre organisation.

Architecture des journaux Microsoft 365 : comprendre les sources

Avant d'écrire une seule ligne de KQL, il faut maîtriser la cartographie des sources de logs dans l'écosystème Microsoft 365. Ce n'est pas une formalité — des dizaines d'équipes sécurité que j'ai accompagnées collectaient des logs sans savoir ce qu'elles manquaient. La conséquence directe est une posture de détection avec des angles morts que les attaquants avancés exploitent méthodiquement.

Le Unified Audit Log (UAL) est la source centrale : il agrège les événements d'Exchange Online (lecture d'emails, transferts, règles Inbox), SharePoint Online (téléchargements, partages, modifications de permissions), Microsoft Teams (messages, réunions, invitations externes), Azure AD (changements de configuration, rôles, applications) et OneDrive (accès fichiers, synchronisations). C'est votre colonne vertébrale forensique pour M365. Sans lui, toute investigation de compromission de compte est aveugle.

Les Azure AD Sign-in Logs tracent chaque authentification avec son contexte complet : adresse IP source, localisation géographique, device compliance, niveau de risque évalué par Identity Protection, et résultat de la vérification MFA. Ces logs sont séparés de l'UAL et nécessitent un connecteur distinct dans Sentinel. Leur croisement avec l'UAL est ce qui permet de détecter les attaques de token theft — la technique la plus répandue pour contourner le MFA en 2026.

Microsoft Defender for Office 365 produit des logs sur les menaces email : détections de phishing, clics sur Safe Links (y compris les clics sur des URLs malveillantes que l'utilisateur a forcés malgré l'avertissement), pièces jointes bloquées par Safe Attachments, et campagnes d'attaque détectées par le moteur de threat intelligence Microsoft. Ces logs permettent de remonter à l'email de phishing initial qui a déclenché une chaîne d'attaque plus large.

Defender for Endpoint ajoute la visibilité sur les terminaux Windows : processus créés, connexions réseau, modifications de registre, scripts PowerShell exécutés. Combiné avec les logs M365, il permet de tracer le mouvement latéral d'un attaquant qui passe de l'email de phishing à l'exécution sur le poste de travail, puis au pivot vers d'autres ressources du tenant.

Rétentions à connaître : l'UAL est conservé 90 jours en M365 E3 et 1 an en M365 E5 (ou avec l'add-on Microsoft 365 Audit Premium). Les Sign-in Logs Azure AD ont une rétention de 30 jours dans le portail Azure AD Free et P1/P2, sauf si vous les envoyez dans Log Analytics. C'est précisément pourquoi l'intégration Sentinel est critique : vous conservez l'historique aussi longtemps que votre workspace Log Analytics le permet.

Connecter Microsoft 365 Defender à Microsoft Sentinel

La configuration du connecteur est la première étape opérationnelle. Depuis le portail Microsoft Sentinel, naviguez vers Content Hub, recherchez "Microsoft 365 Defender" et installez la solution. Une fois installée, accédez à Data Connectors, sélectionnez Microsoft 365 Defender et cliquez sur Connect.

Ce connecteur active l'ingestion des tables suivantes dans votre workspace Log Analytics :

• OfficeActivity — contenu du Unified Audit Log (Exchange, SharePoint, Teams, OneDrive, Azure AD admin)
• SigninLogs et AADNonInteractiveUserSignInLogs — toutes les authentifications Azure AD interactives et non-interactives
• EmailEvents et EmailAttachmentInfo — événements Defender for Office 365
• DeviceEvents et DeviceProcessEvents — télémétrie Defender for Endpoint
• SecurityAlert et SecurityIncident — alertes et incidents consolidés

Je recommande d'activer en priorité OfficeActivity et SigninLogs. Ce sont les deux tables qui couvrent 80% des scénarios d'attaque M365 courants. Ajoutez DeviceEvents uniquement si vous avez Defender for Endpoint déployé sur vos postes, sinon vous payez de l'ingestion inutile dans Log Analytics. L'activation se fait en quelques clics, mais la vraie valeur vient de la configuration des règles analytiques ensuite.

Référence officielle Microsoft pour la configuration du connecteur : Microsoft Sentinel — Connecteur Microsoft 365 Defender. Les prérequis sont : rôle Security Administrator ou Global Administrator sur le tenant M365, et rôle Contributor sur le workspace Log Analytics cible.

Requêtes KQL fondamentales pour la corrélation UAL

KQL (Kusto Query Language) est le langage de requête de Log Analytics et Sentinel. Sa puissance réside dans les opérateurs de jointure et d'agrégation temporelle qui permettent de corréler des événements issus de tables différentes dans la même fenêtre d'analyse. Voici les requêtes de base que j'utilise sur chaque engagement Microsoft 365.

La requête suivante détecte un utilisateur qui télécharge massivement des fichiers SharePoint depuis une IP à risque dans la même fenêtre temporelle — un pattern classique d'exfiltration de données avant la fuite du tenant :

// Corrélation : téléchargements massifs SharePoint + connexion à risque Azure AD
// Fenêtre : 24 heures glissantes
// Seuil à calibrer selon votre baseline utilisateur
let suspiciousDownloads = OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation == "FileDownloaded"
| summarize DownloadCount = count(),
            Files = make_set(SourceFileName, 50)
  by UserId, ClientIP, bin(TimeGenerated, 1h)
| where DownloadCount > 100;

let riskySignins = SigninLogs
| where TimeGenerated > ago(24h)
| where RiskLevelDuringSignIn in ("high", "medium")
| project UserPrincipalName, IPAddress, Location, RiskLevelDuringSignIn, TimeGenerated;

suspiciousDownloads
| join kind=inner riskySignins
  on $left.UserId == $right.UserPrincipalName
| project UserId, DownloadCount, Files, ClientIP, Location, RiskLevelDuringSignIn
| sort by DownloadCount desc

Le seuil de 100 téléchargements par heure est un point de départ conservateur. Sur un environnement M365 standard avec des utilisateurs qui synchronisent OneDrive, vous voudrez affiner ce seuil après observation du comportement normal (baseline) de vos utilisateurs pendant au moins deux semaines avant d'activer la règle en production.

Détecter les règles Inbox malveillantes via KQL

Les règles Inbox malveillantes sont l'une des techniques de persistance les plus utilisées après une compromission de compte Microsoft 365. L'attaquant crée une règle qui transfère silencieusement tous les emails entrants vers une adresse externe, ou supprime les emails de notification de sécurité envoyés par Microsoft. Cette technique est répertoriée sous MITRE ATT&CK T1114.003 (Email Collection: Email Forwarding Rule).

Sur la majorité des investigations de compromission de compte M365 que je conduis, cette requête remonte au moins une règle malveillante créée dans les 24 à 48 heures suivant la compromission initiale. L'attaquant l'installe rapidement pour maintenir sa visibilité sur les communications de la victime, notamment les demandes de réinitialisation de mot de passe qui lui permettraient de perdre son accès.

// Détection règles Inbox malveillantes — persistance post-compromission
// MITRE ATT&CK T1114.003 : Email Forwarding Rule
OfficeActivity
| where TimeGenerated > ago(7d)
| where Operation in ("New-InboxRule", "Set-InboxRule")
| extend RuleDetails = parse_json(Parameters)
| where RuleDetails contains "ForwardTo"
   or RuleDetails contains "RedirectTo"
   or RuleDetails contains "DeleteMessage"
   or RuleDetails contains "MoveToFolder"
| project TimeGenerated, UserId, Operation, RuleDetails, ClientIP
| sort by TimeGenerated desc

Comment détecter une attaque de token replay dans Microsoft 365 ?

Le token theft ou vol de token OAuth est l'une des attaques les plus difficiles à détecter dans Microsoft 365 car elle contourne complètement le MFA. L'attaquant n'a pas besoin de connaître le mot de passe ni de passer la vérification MFA — il lui suffit de rejouer un token d'accès valide volé depuis le poste de la victime (via un malware infostealer, un AitM proxy comme Evilginx, ou une injection de session).

Le signal de détection principal est l'impossible travel : le même token utilisé depuis deux localisations géographiquement impossibles dans un intervalle de temps court. Azure AD Identity Protection le détecte dans certains cas, mais pas toujours — la détection KQL manuelle dans Sentinel reste nécessaire pour les cas aux frontières du modèle ML d'Identity Protection.

// Détection Token Replay Attack : même utilisateur, 2 pays différents en < 1 heure
// Sans prompt MFA (singleFactorAuthentication = token réutilisé, pas d'auth fraîche)
SigninLogs
| where TimeGenerated > ago(24h)
| where AuthenticationRequirement == "singleFactorAuthentication"
| summarize
    IPList = make_set(IPAddress),
    CountryList = make_set(tostring(LocationDetails.countryOrRegion)),
    SigninCount = count()
  by UserPrincipalName, AppDisplayName, bin(TimeGenerated, 1h)
| where array_length(CountryList) > 1
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPList, CountryList, SigninCount
| sort by SigninCount desc

L'absence de prompt MFA (singleFactorAuthentication) combinée à deux pays différents dans la même heure est un marqueur quasi-certain de token replay. Dans ce cas, la réponse immédiate est la révocation de tous les tokens de l'utilisateur via PowerShell :

# Révoquer tous les refresh tokens d'un utilisateur compromis
# Nécessite le module Microsoft.Graph PowerShell
Connect-MgGraph -Scopes "User.ReadWrite.All"

# Révocation immédiate — force une ré-authentification complète avec MFA
Revoke-MgUserSignInSession -UserId "[email protected]"

# Vérifier que la révocation est effective
Get-MgUser -UserId "[email protected]" | Select-Object SignInSessionsValidFromDateTime

Connecteur Azure AD Identity Protection : risques utilisateurs et sign-ins

Azure AD Identity Protection produit deux catégories d'alertes qui alimentent Sentinel via le connecteur dédié : les risques de sign-in (Impossible Travel, Malicious IP, Atypical Travel, Anonymous IP address, Unfamiliar sign-in properties) et les risques utilisateur (Leaked Credentials détectés sur le darkweb via Microsoft Threat Intelligence, Password Spray Attack détecté, comportement anomal).

La requête KQL pour surveiller les utilisateurs à risque élevé signalés par Identity Protection :

// Utilisateurs à risque élevé selon Azure AD Identity Protection
// Table AADRiskyUsers — mise à jour en temps quasi-réel par le moteur ML Microsoft
AADRiskyUsers
| where RiskLevel == "high" and RiskState == "atRisk"
| project UserPrincipalName, RiskLevel, RiskState, RiskDetail, RiskLastUpdatedDateTime
| sort by RiskLastUpdatedDateTime desc

Je recommande de créer une règle analytique Sentinel sur cette requête avec une fréquence de 15 minutes et un seuil de 0 résultats. Chaque utilisateur à risque élevé doit déclencher un incident Sentinel qui s'intègre dans votre flux SOAR pour une réponse automatisée : blocage via Conditional Access, notification au responsable sécurité, et forçage de réinitialisation du mot de passe et du MFA.

Extraction des incidents Microsoft Defender XDR via l'API Graph

Pour les équipes qui souhaitent intégrer les incidents Defender XDR dans leur outillage custom (ticketing, SOAR maison, rapport de direction), l'API Microsoft Graph Security expose un endpoint dédié aux incidents. Ce script Python illustre l'extraction et l'export :

#!/usr/bin/env python3
# Extraction des incidents Microsoft Defender XDR via l'API Microsoft Graph Security
# Prerequis : pip install azure-identity requests
# Permissions applicative requise : SecurityIncident.Read.All

import requests
import json
from azure.identity import ClientSecretCredential
from datetime import datetime, timedelta

# Configuration — utiliser Azure Key Vault ou variables d'environnement en production
TENANT_ID = "votre-tenant-id"
CLIENT_ID = "votre-app-client-id"
CLIENT_SECRET = "votre-app-secret"

def get_access_token():
    # Obtenir un token Microsoft Graph pour l'API Security
    credential = ClientSecretCredential(
        tenant_id=TENANT_ID,
        client_id=CLIENT_ID,
        client_secret=CLIENT_SECRET
    )
    token = credential.get_token("https://graph.microsoft.com/.default")
    return token.token

def get_incidents(token, days_back=7):
    # Recuperer les incidents Defender XDR des X derniers jours
    headers = {
        "Authorization": f"Bearer {token}",
        "Content-Type": "application/json"
    }
    cutoff = (datetime.utcnow() - timedelta(days=days_back)).strftime("%Y-%m-%dT%H:%M:%SZ")
    url = (
        "https://graph.microsoft.com/v1.0/security/incidents"
        f"?$filter=createdDateTime ge {cutoff}&$top=100&$orderby=createdDateTime desc"
    )
    response = requests.get(url, headers=headers)
    response.raise_for_status()
    return response.json().get("value", [])

def main():
    token = get_access_token()
    incidents = get_incidents(token, days_back=7)
    print(f"Incidents trouves : {len(incidents)}")
    for incident in incidents:
        severity = incident.get("severity", "unknown")
        name = incident.get("displayName", "N/A")
        status = incident.get("status", "N/A")
        print(f"  [{severity.upper()}] {name} -- {status}")
    with open("defender_incidents.json", "w", encoding="utf-8") as f:
        json.dump(incidents, f, indent=2, default=str)
    print("Export : defender_incidents.json")

if __name__ == "__main__":
    main()

Ce script nécessite l'enregistrement d'une application Azure AD avec la permission applicative SecurityIncident.Read.All accordée par un administrateur. Ne stockez jamais les secrets d'application en dur dans le code — utilisez Azure Key Vault ou les variables d'environnement de votre pipeline CI/CD.

Créer des règles analytiques Sentinel depuis vos investigations réelles

Le vrai retour sur investissement de Microsoft Sentinel vient de la capacité à industrialiser chaque investigation manuelle en règle de détection automatique. Chaque fois que vous tracez manuellement une attaque dans les logs M365, vous devez vous poser la question : quelle requête KQL aurait détecté cette attaque automatiquement ? Cette discipline transforme votre SIEM en un système d'apprentissage continu plutôt qu'en simple archive de logs.

Le workflow que j'applique systématiquement sur chaque engagement :

1. Incident déclenché ou signalé par un utilisateur ou un partenaire externe
2. Investigation manuelle : timeline d'activité, tables KQL croisées, identification du vecteur initial et de la chaîne d'attaque complète
3. Formalisation du pattern : quels champs discriminants, quels seuils, quelle fenêtre temporelle, quels faux positifs potentiels ?
4. Écriture de la requête KQL dans Sentinel → Analytics → Scheduled Query Rule
5. Test en mode simulation (bouton "Run query results") sur les 30 derniers jours pour valider et calibrer
6. Activation avec fréquence adaptée au signal : 5 minutes pour les alertes critiques type token theft, 1 heure pour les patterns lents type exfiltration progressive

Pour la règle analytique sur le token theft, la configuration cible dans Sentinel est la suivante : fréquence d'exécution toutes les 5 minutes, fenêtre temporelle de la requête de 1 heure, seuil d'alerte à 0 résultats (tout résultat déclenche une alerte), sévérité High, et MITRE ATT&CK mapping sur T1528 (Steal Application Access Token) et T1550.001 (Use Alternate Authentication Material).

La documentation de référence CISA sur les meilleures pratiques de sécurité M365 fournit un cadre complémentaire pour la configuration des alertes : CISA — Microsoft 365 Security Best Practices.

Quels logs Microsoft 365 ingérer en priorité dans Microsoft Sentinel ?

La question du coût d'ingestion est incontournable dans Sentinel : vous payez au gigaoctet ingéré dans Log Analytics. La stratégie est de prioriser les sources à forte valeur de détection par rapport à leur volume, et de filtrer à la source les événements à faible signal via les Data Collection Rules (DCR).

Je recommande de commencer avec OfficeActivity et SigninLogs avec filtrage des opérations à très fort volume (FileSynced sur OneDrive, sign-ins depuis des devices compliant connus sur le réseau corporate). Vous pouvez réduire le volume de 40 à 60% avec un filtrage judicieux sans perdre de signal de détection. Le Commitment Tier à 100 Go/jour offre 29% de réduction par rapport au Pay-As-You-Go — calculez votre seuil de rentabilité avant de vous engager.

Playbook d'investigation : compromission de compte Microsoft 365

Lorsqu'un compte M365 est signalé comme compromis — que ce soit par une alerte Sentinel, un utilisateur qui remarque une activité suspecte, ou un partenaire externe — voici la séquence d'investigation que j'applique. Chaque étape est tracée et documentée pour les besoins éventuels de notification CNIL (délai 72 heures) ou de rapport d'assurance cyber.

Étape 1 — Identifier l'étendue : Quels services M365 l'attaquant a-t-il accédés ? Requête OfficeActivity sur les 30 derniers jours filtrée sur l'UserId compromis, groupée par Operation et RecordType. Identifiez les accès Exchange (lecture et transfert d'emails), SharePoint (téléchargements), Teams (messages envoyés depuis le compte) et les actions d'administration Azure AD.

Étape 2 — Timeline complète de l'activité : Construire une chronologie précise depuis les SigninLogs et OfficeActivity combinés. Identifiez le premier signe d'activité anormale — c'est souvent plusieurs jours avant la détection effective. L'accès via un client inhabituel (UserAgent inconnu), depuis une IP Tor ou un datacenter, est souvent le premier indicateur visible rétrospectivement.

Étape 3 — Règles Inbox malveillantes : Exécuter la requête KQL de détection des New-InboxRule et Set-InboxRule sur les 90 derniers jours pour le compte compromis. Documenter toutes les règles existantes et identifier celles créées après la date de compromission estimée.

Étape 4 — Audit des applications OAuth autorisées : Via Azure AD → Enterprise Applications → filtre "Consented by user" — identifier les applications OAuth auxquelles l'utilisateur a accordé des permissions. Un attaquant peut maintenir sa persistance via une application OAuth enregistrée avec des permissions Mail.Read ou Files.ReadWrite qui lui permet d'accéder aux données même après réinitialisation du mot de passe.

Étape 5 — Containment : Réinitialisation du mot de passe, révocation de tous les refresh tokens, désactivation des règles Inbox malveillantes identifiées, révocation des applications OAuth suspectes, forçage d'une ré-inscription MFA sur un device de confiance vérifié physiquement.

Étape 6 — Collecte des preuves : Export UAL via PowerShell (Search-UnifiedAuditLog), export Sign-in Logs via l'API Graph ou le portail Azure AD, capture des règles Inbox au moment de la découverte. Ces exports sont nécessaires pour la notification CNIL si des données personnelles ont été compromises.

Pour approfondir les techniques d'audit Microsoft 365 avancé, notre guide sur l'audit avancé Microsoft 365 et les journaux d'événements couvre les couches supplémentaires d'investigation. Pour la détection des attaques Azure AD, consultez notre article dédié sur la détection des attaques Microsoft 365 via Azure AD.

Intégration Sentinel avec l'architecture Zero Trust Microsoft 365

Microsoft Sentinel ne doit pas être un outil d'investigation isolé — il doit être le cerveau central de votre architecture Zero Trust Microsoft 365. Les alertes Sentinel alimentent les policies Conditional Access via les risques utilisateur Identity Protection ; les incidents Sentinel déclenchent des playbooks Logic Apps qui bloquent automatiquement les comptes ou forcent une ré-authentification renforcée. Cette intégration crée une boucle de rétroaction défensive : chaque anomalie détectée par KQL peut générer une restriction d'accès en temps quasi-réel, sans intervention manuelle.

Sur les tenants M365 E5, la combinaison Sentinel + Conditional Access basé sur les risques + Defender XDR offre le meilleur rapport protection/friction pour les utilisateurs. L'investissement en licences E5 ne se rentabilise que si vous exploitez réellement les capacités de corrélation et d'automatisation — avoir les données dans Sentinel sans règles analytiques actives revient à acheter un système d'alarme et ne jamais le brancher.

Pour la mise en oeuvre de l'architecture Zero Trust M365 complète, consultez notre article sur l'implémentation Zero Trust Microsoft 365 et notre guide sur les politiques Intune pour la conformité Zero Trust. Pour les équipes qui souhaitent automatiser l'ensemble du cycle d'audit, notre article sur le threat hunting Microsoft 365 avec Microsoft Sentinel couvre les techniques avancées au-delà des règles analytiques standards.

La page produit Microsoft Sentinel pour évaluer les options de licences et les fonctionnalités : Microsoft Sentinel — Azure SIEM et SOAR.

FAQ — Audit Microsoft 365 et corrélation des journaux dans Sentinel

Comment connecter le Unified Audit Log de Microsoft 365 à Microsoft Sentinel ?

Via le connecteur natif Microsoft 365 Defender dans Microsoft Sentinel. Depuis le portail Sentinel, accédez à Content Hub, installez la solution Microsoft 365 Defender, puis allez dans Data Connectors et activez le connecteur Microsoft 365 Defender. Il faut être titulaire du rôle Security Administrator ou Global Administrator sur le tenant M365, et avoir le rôle Contributor sur le workspace Log Analytics cible. Une fois connecté, la table OfficeActivity se remplit avec le contenu du UAL dans un délai de quelques minutes à une heure selon le volume d'activité du tenant.

Quelle est la rétention des logs dans Microsoft Sentinel ?

La rétention dans Microsoft Sentinel est indépendante de la rétention native M365. Elle dépend de votre configuration Log Analytics : par défaut, les tables interactives conservent les données 90 jours (inclus dans le prix d'ingestion), avec extension possible jusqu'à 2 ans. Au-delà, les données peuvent être archivées dans Azure Data Lake Storage Gen2 via les Archiving Policies pour une conservation long terme à faible coût. Pour les enquêtes judiciaires ou les obligations de conformité, configurez votre politique de rétention dès le déploiement — vous ne pouvez pas récupérer des logs que vous n'avez pas conservés.

Comment créer une règle analytique Sentinel depuis zéro ?

Dans Microsoft Sentinel, naviguez vers Analytics → Create → Scheduled query rule. L'assistant guide en 5 étapes : nom et description avec mapping MITRE ATT&CK, requête KQL et fenêtre temporelle, configuration des alertes (seuil et regroupement par entité utilisateur ou IP), automated response avec sélection des playbooks Logic Apps à déclencher, puis review et activation. Testez toujours votre requête KQL en mode simulation avant activation — utilisez le bouton "View query results" pour voir ce que la règle aurait détecté sur les dernières 24 à 48 heures.

Qu'est-ce qu'une attaque de vol de token OAuth dans Microsoft 365 ?

Un vol de token OAuth (Token Theft) consiste à dérober un token d'accès ou de rafraîchissement valide depuis le poste de la victime pour l'utiliser sans connaître son mot de passe ni passer le MFA. Les vecteurs courants sont les infostealers (malware qui extraient les tokens du cache du navigateur ou des applications Microsoft Office), les attaques AitM via des proxies de phishing comme Evilginx qui interceptent le token après authentification MFA réussie, et l'injection de session. Le signal de détection principal est l'impossible travel dans SigninLogs : le même compte utilisé depuis deux pays géographiquement impossibles dans un intervalle court. La parade : Conditional Access avec évaluation de la conformité du device (seuls les devices managés Intune peuvent générer des tokens valides) et la fonctionnalité Token Protection qui lie cryptographiquement le token au device d'origine.