Cinq requêtes KQL utiles sur les journaux de connexion et d'audit Entra ID
Les journaux Entra ID contiennent l'essentiel des signaux utiles pour détecter une compromission d'identité. Encore faut-il les conserver assez longtemps et savoir les interroger. Voici les requêtes que nous utilisons le plus souvent en audit, à adapter à votre contexte.
Prérequis : envoyer les journaux au bon endroit
La rétention des journaux dans le portail Entra est courte et dépend de la licence ; vérifiez les durées actuelles dans la documentation Microsoft. Pour interroger un historique utile, il faut configurer des paramètres de diagnostic qui exportent les journaux vers un espace de travail Log Analytics, éventuellement associé à Microsoft Sentinel.
Les tables les plus utiles sont SigninLogs (connexions interactives), AADNonInteractiveUserSignInLogs (connexions non interactives, par jeton d'actualisation notamment), AADServicePrincipalSignInLogs (connexions des applications) et AuditLogs (modifications de l'annuaire). Les connexions non interactives sont volumineuses, mais les ignorer revient à ignorer une grande partie de l'activité des jetons volés.
1. Authentification héritée
Les protocoles hérités ne supportent pas la MFA. Avant de les bloquer, et pour vérifier que le blocage est effectif, listez qui les utilise encore :
SigninLogs | where TimeGenerated > ago(30d) | where ClientAppUsed !in ("Browser", "Mobile Apps and Desktop clients") | summarize Tentatives = count() by UserPrincipalName, ClientAppUsed, ResultType
Un résultat non vide après la mise en place du blocage mérite une analyse : une tentative refusée est normale, une connexion réussie ne l'est pas.
2. Échecs MFA répétés
Un attaquant qui connaît le mot de passe se heurte à la MFA. Des échecs répétés, en particulier des refus de notification, peuvent signaler une tentative de fatigue MFA :
SigninLogs | where TimeGenerated > ago(7d) | where ResultType == "500121" | summarize Echecs = count() by UserPrincipalName, bin(TimeGenerated, 1h) | where Echecs > 5
Le seuil est à ajuster à votre population. Un utilisateur concerné doit être contacté : son mot de passe est probablement connu d'un tiers.
3. Pulvérisation de mots de passe
La signature classique : une même adresse IP qui échoue sur de nombreux comptes différents avec l'erreur 50126 (identifiants invalides).
SigninLogs | where TimeGenerated > ago(1d) | where ResultType == "50126" | summarize Comptes = dcount(UserPrincipalName), Echecs = count() by IPAddress | where Comptes > 10 | order by Comptes desc
Type des colonnes. Dans SigninLogs, ResultType est une chaîne de caractères : comparez-la à "50126" et non à 50126. Une requête qui ne renvoie rien n'est pas toujours une bonne nouvelle.
4. Nouveaux consentements d'applications
Le consentement illicite est un moyen discret d'obtenir un accès durable aux données. Chaque consentement doit être connu :
AuditLogs | where TimeGenerated > ago(30d) | where OperationName == "Consent to application" | extend Initiateur = tostring(InitiatedBy.user.userPrincipalName), Application = tostring(TargetResources[0].displayName) | project TimeGenerated, Initiateur, Application, Result
Complétez par l'opération Add app role assignment to service principal, qui trace l'octroi d'autorisations d'application.
5. Modifications de rôles privilégiés
Toute attribution de rôle hors processus est un signal fort :
AuditLogs | where TimeGenerated > ago(30d) | where Category == "RoleManagement" | where OperationName has "member to role" | extend Cible = tostring(TargetResources[0].userPrincipalName), Initiateur = tostring(InitiatedBy.user.userPrincipalName) | project TimeGenerated, OperationName, Initiateur, Cible
Les opérations PIM portent des libellés spécifiques ; filtrer sur la catégorie plutôt que sur un libellé exact évite d'en manquer. Croisez le résultat avec vos demandes de changement.
Ce qu'un audit vérifie
- L'export des journaux de connexion, y compris non interactifs et d'applications, et des journaux d'audit.
- La durée de rétention effective dans l'espace de travail.
- L'existence de règles d'alerte sur les consentements, les rôles et les schémas d'attaque courants.
- Le traitement des alertes : qui les reçoit et dans quel délai.
- La protection de l'espace de travail lui-même contre la suppression ou la modification des données.