Introduction à Microsoft Sentinel KQL
La plupart des organisations font de la détection « réactive » : une alerte se déclenche, on enquête, on corrige. La chasse aux menaces (threat hunting) change la logique : on formule des hypothèses, on explore les données, on cherche des signaux faibles à grande échelle — à l’âge où les attaquants automatisent tout.
Microsoft Sentinel est particulièrement adapté à cet exercice, à condition de maîtriser un minimum de KQL (Kusto Query Language). Le but de cet article n’est pas de vous noyer dans la syntaxe : on va vous donner une méthode, des commandes clés et des requêtes « réutilisables » pour chasser efficacement dans les logs.
Ce que vous allez apprendre dans ce guide
- Comprendre le rôle de la chasse aux menaces dans Sentinel
- Savoir où chercher : tables, périodes, champs utiles
- Maîtriser les commandes KQL essentielles (search, where, project, summarize, join, parse, mv-expand)
- Construire des requêtes de hunting pour repérer des comportements avancés
- Analyser et interpréter les résultats pour passer à l’étape « investigation »
Threat hunting vs détection vs investigation (en 30 secondes)
- Détection : règles/analytique à partir d’événements connus (alertes).
- Investigation : on suit une alerte et on reconstitue une chaîne d’événements.
- Threat hunting : on part d’une hypothèse (ex. : « mouvement latéral discret ») et on explore les données pour trouver des traces.
Prérequis (pour que la chasse soit utile)
Avant d’écrire des requêtes, assurez-vous que vous avez :
- Des connecteurs activés (Microsoft 365, Azure, Defender, Windows, etc.)
- Une rétention cohérente (sinon vous chassez sur 7 jours et vous ratez le signal)
- Une convention de noms et de tags (workspaces, tables, comptes VIP)
- Un objectif clair : « réduire le temps de détection », « détecter l’exfiltration », etc.
Module SC-200 à étendre (ce qu’on va couvrir)
Le module « Créer des requêtes pour Microsoft Sentinel avec KQL » vise notamment à :
- Construire des instructions KQL pour Microsoft Sentinel
- Analyser les résultats d’une requête
- Générer des requêtes multi-tables
- Utiliser les données Sentinel via KQL
1) Où chasser : comprendre les tables et le « datastore »
Dans Sentinel, vos données sont stockées dans Log Analytics sous forme de tables. Chaque connecteur alimente une ou plusieurs tables.
Comment découvrir les tables disponibles
Commencez par explorer l’écosystème de données :
- Recherche globale :
search "keyword"
- Filtre rapide sur une période :
| where TimeGenerated > ago(24h)
- Projeter seulement les champs utiles :
| project TimeGenerated, Computer, Account, IPAddress, OperationName
2) Les commandes KQL indispensables (le « kit » du hunter)
| where Account contains "admin"| where IPAddress startswith "10."
project (sélectionner les colonnes)
| project TimeGenerated, Account, IPAddress, ActionType
extend (créer un champ)
| extend Hour = datetime_part("hour", TimeGenerated)
summarize (agréger)
| summarize count() by Account| summarize dcount(IPAddress) by Account
order by et take
| order by TimeGenerated desc| take 50
join (corréler)
| join kind=inner (...) on DeviceId
parse / extract (extraire)
- Utile pour des champs semi-structurés.
mv-expand (exploser des tableaux)
- Utile quand un champ contient une liste (ex. : IPs, URLs).
3) Patterns de requêtes « hunting » (prêts à copier)
Les exemples ci-dessous sont des patterns. Adaptez les tables selon vos connecteurs (Defender, Azure AD/Entra, M365, etc.).
A) Détecter une authentification anormale (impossible travel / pays inattendu)
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| summarize Countries = make_set(LocationDetails.countryOrRegion) by UserPrincipalName
| where array_length(Countries) > 1B) Compter les échecs MFA / sign-in (bruit vs signal)
SigninLogs
| where TimeGenerated > ago(24h)
| summarize Failures = countif(ResultType != 0), Success = countif(ResultType == 0) by UserPrincipalName
| where Failures > 10 and Success > 0
| order by Failures desc
C) Recherche large (quand vous n’avez qu’un indice)
search "rundll32"
| where TimeGenerated > ago(7d)
| take 200
D) Repérer des exécutions PowerShell suspectes (exemple)
DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any ("-enc", "IEX", "DownloadString", "FromBase64String")
| project TimeGenerated, DeviceName, AccountName, ProcessCommandLine
| order by TimeGenerated desc
E) Corréler un utilisateur + un appareil (join)
let suspiciousUsers = SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| summarize by UserPrincipalName;
DeviceLogonEvents
| where TimeGenerated > ago(24h)
| join kind=inner suspiciousUsers on $left.AccountUpn == $right.UserPrincipalName
| project TimeGenerated, DeviceName, AccountUpn, LogonType4) Comment analyser les résultats (sans se tromper)
Évitez les faux positifs classiques:
- Les comptes de service et comptes d’automatisation
- Les sauts de VPN / proxys (même utilisateur, IP différente)
- Les scans internes (outils de sécurité)
Passez de « liste » à « histoire »:
Un bon résultat de hunting doit permettre de raconter :
- Qui ? (compte)
- Quoi ? (action)
- Où ? (appareil, IP, pays)
- Quand ? (timeline)
- Et ensuite ? (impact potentiel)
Liens externes (références utiles)
Vos prochaines étapes
- Choisissez une hypothèse de chasse (ex. : exécution PowerShell encodée).
- Exécutez la requête sur 24h, puis 7 jours.
- Ajoutez 1 corrélation (join) pour enrichir le contexte.
- Transformez votre requête en règle / workbook / hunting query réutilisable.
Parcours de certification & formations recommandées (options pratiques)
FAQ (questions fréquentes)
Est-ce que je dois être développeur pour utiliser KQL ?
Non. KQL est conçu pour l’analyse de logs. Avec quelques commandes (where, project, summarize), vous pouvez déjà produire des résultats utiles.
Quelle est la différence entre une hunting query et une règle d’analyse ?
Une hunting query est exploratoire (hypothèse, recherche). Une règle d’analyse génère des alertes automatiquement.
Quelles tables dois-je utiliser en priorité ?
Commencez par les tables liées à vos connecteurs principaux (SigninLogs, AuditLogs, DeviceProcessEvents, DeviceNetworkEvents, etc.).
Comment réduire les faux positifs ?
Créez des listes d’exceptions (comptes de service, IPs VPN), ajoutez du contexte (join), et utilisez des seuils (summarize) adaptés à votre environnement.
