Microsoft Defender XDR Advanced Hunting: KQL Queries voor Threat Hunting

Graph API Response

Microsoft Defender XDR Advanced Hunting is een van de krachtigste hulpmiddelen voor moderne security operations teams. Waar klassieke detectie vooral leunt op vooraf gedefinieerde regels en signatures, geeft Advanced Hunting je toegang tot ruwe telemetrie zodat je zelf gericht onderzoek kunt doen. Met de Kusto Query Language (KQL) kun je patronen herkennen die (nog) niet in een standaardregel of productupdate zijn vastgelegd. Dat maakt het instrument bij uitstek geschikt voor organisaties die willen werken volgens een zero‑trustbenadering en de Nederlandse Baseline voor Veilige Cloud (NBVC), BIO en NIS2 serieus toepassen.

In de praktijk betekent dit dat je als analist of security architect niet langer hoeft te wachten tot een product een kant‑en‑klare alert genereert. Je kunt zelfstandig hypotheses opstellen – bijvoorbeeld over mogelijk misbruik van beheerdersaccounts, ongebruikelijke datastromen of command‑line tooling – en deze direct toetsen op maximaal dertig dagen aan rijke Defender‑telemetrie. Denk aan procesinformatie van werkstations en servers, e‑mailgegevens, aanmeldlogs, identity‑events en signalen uit Defender for Cloud Apps. Door deze bronnen in één query samen te brengen, ontstaat een integraal beeld van wat er in de tenant en het hybride landschap gebeurt.

Dit artikel richt zich op security professionals binnen de Nederlandse (semi)overheid die Microsoft Defender XDR al hebben ingericht, maar de stap willen zetten van reactief reageren op meldingen naar gestructureerde threat hunting. In plaats van een droge lijst met losse KQL‑snippets, bouwen we een verhaal op rond concrete jachtvragen. Per hoofdstuk leggen we uit hoe je de data leest, welke risico’s je adresseert en hoe je de resultaten vertaalt naar structurele verbeteringen in processen, configuraties en governance. De voorbeeldqueries die in de codeblokken zijn opgenomen, kun je direct in de Advanced Hunting‑interface gebruiken of als basis nemen voor eigen varianten.

Hoewel de interface grotendeels Engelstalig is en veel terminologie uit de internationale securitygemeenschap afkomstig is, blijft de insteek van dit artikel volledig Nederlandstalig en toegespitst op de context van overheidsorganisaties. We verbinden de technische mogelijkheden van Advanced Hunting aan eisen uit de BIO, toezicht door de overheid en de noodzaak om aantoonbaar grip te houden op identiteiten, apparaten, data en logging. Aan het einde heb je niet alleen een reeks bruikbare queries, maar vooral een logische denk- en werkstructuur waarmee je als team stapsgewijs volwassen threat hunting kunt opbouwen.

Wat je leert

Dit artikel leert je threat hunting met Microsoft Defender XDR Advanced Hunting. Je krijgt 15 direct bruikbare KQL queries voor het detecteren van PowerShell abuse, credential dumping, lateral movement, phishing en persistence mechanisms. Inclusief best practices voor query optimization en detection rule development.

Pro tip

Gebruik case-insensitive operators in je queries! where FileName == "powershell.exe" mist "PowerShell.exe" en "POWERSHELL.EXE". Gebruik in plaats daarvan where FileName =~ "powershell.exe" of where FileName in~ ("powershell.exe", "pwsh.exe"). Dit voorkomt dat je threats mist door capitalization differences!

Wat is Advanced Hunting?

Advanced Hunting in Microsoft Defender XDR is in de kern een query‑gedreven onderzoeksomgeving bovenop de enorme hoeveelheid telemetrie die Microsoft 365 en Azure dagelijks verzamelen. Waar traditionele dashboards vooral samenvattingen, grafieken en vooraf gedefinieerde rapporten tonen, biedt Advanced Hunting directe toegang tot de onderliggende records. Elke processtart, aanmeldpoging, e‑mailaflevering of cloudapplicatie‑actie wordt vastgelegd in tabellen die je met Kusto Query Language (KQL) kunt doorzoeken. Omdat deze data tot dertig dagen terug beschikbaar zijn, kun je niet alleen naar de actuele situatie kijken, maar ook reconstructies maken van gebeurtenissen die zich in de afgelopen weken hebben afgespeeld.

De kracht van Advanced Hunting zit in de combinatie van verschillende datastromen. Vanuit Defender for Endpoint ontvang je bijvoorbeeld gedetailleerde informatie over processen, command‑lines, bestanden en registry‑aanpassingen op werkstations en servers. Defender for Office 365 draagt gegevens aan over verzonden en ontvangen e‑mails, URL‑kliks en bijlagenanalyse. Defender for Identity geeft zicht op verdachte aanmeldingen en protocolmisbruik richting domeincontrollers. Defender for Cloud Apps voegt daar activiteiten in SaaS‑applicaties aan toe, terwijl Entra ID (voorheen Azure AD) cruciale sign‑inlogs, risk‑events en auditberichten levert. Door deze datasets in één query samen te brengen, kun je complete aanvalsketens over identiteiten, apparaten, e‑mail en cloud‑apps heen analyseren.

Voor organisaties in de publieke sector is dit bijzonder waardevol. De Nederlandse Baseline voor Veilige Cloud en de BIO leggen nadruk op aantoonbare controle over toegangsbeheer, logging en incidentrespons. Advanced Hunting helpt om die eisen in de praktijk vorm te geven. Je kunt onderzoeken of privileged accounts zich gedragen zoals bedoeld, of er apparaten zijn die afwijken van het beoogde hardeningsniveau, of bepaalde mailboxen opvallend vaak verdachte links ontvangen. In plaats van alleen te vertrouwen op generieke ‘high’, ‘medium’ of ‘low’ alerts, kun je zelf gericht hypotheses formuleren en toetsen. Dat sluit nauw aan op een zero‑trustarchitectuur waarin je niets als vanzelfsprekend vertrouwt.

Het werken met Advanced Hunting vraagt wel een andere mindset dan het beoordelen van klassieke alerts. Je begint niet met een vooraf gegeven conclusie, maar met een veronderstelling over mogelijk risico: bijvoorbeeld dat een aanvaller geprobeerd zou kunnen hebben om via PowerShell aanvullende tooling te downloaden, of dat een bepaald serviceaccount op ongebruikelijke tijden wordt gebruikt. Vanuit die hypothese zoek je naar concrete sporen in de data. Je leert stap voor stap welke tabellen relevant zijn, hoe velden heten en hoe je met KQL filters, joins en aggregaties opbouwt. Naarmate je meer ervaring opdoet, ontwikkel je een eigen bibliotheek met queries die passen bij de processen, systemen en dreigingsbeelden van jouw organisatie.

Binnen een Security Operations Center kun je Advanced Hunting inzetten in verschillende scenario’s. Analisten gebruiken het tijdens triage om snel extra context bij alerts te verzamelen. Threat hunters gebruiken het om zonder voorafgaande melding op zoek te gaan naar afwijkend gedrag of bekende tactieken van dreigingsactoren. Forensische specialisten reconstrueren een incident door chronologisch te analyseren welke processen, aanmeldingen en netwerkverbindingen plaatsvonden. Compliance‑ of auditteams benutten dezelfde data om aan te tonen dat logging volledig is, dat gevoeligere acties extra worden bewaakt en dat maatregelen uit de BIO ook daadwerkelijk operationeel zijn. Zo vormt Advanced Hunting niet alleen een technisch hulpmiddel, maar een fundamentele bouwsteen van governance, risk en compliance binnen de overheid.

Samengevat: Advanced Hunting is geen losstaande feature, maar het analytische hart van Defender XDR. Door de rijke telemetrie, de flexibele querytaal en de nauwe koppeling met andere Microsoft‑beveiligingsdiensten krijg je als organisatie de mogelijkheid om gericht te onderzoeken waar je verdediging sterk is en waar nog zwakke plekken zitten. De rest van dit artikel laat zien hoe je die mogelijkheden vertaalt naar concrete queries en werkafspraken die dagelijks bruikbaar zijn voor het SOC‑team.

Basis KQL Queries

Om effectief met Advanced Hunting te werken, is het belangrijk dat je een aantal basispatronen in Kusto Query Language goed begrijpt. KQL is een leesbare, declaratieve querytaal: je beschrijft wat je wilt zien, niet stap voor stap hoe het systeem dat moet ophalen. Voor securitydoeleinden komt het vrijwel altijd neer op drie vragen: uit welke tabel wil je lezen, welke records zijn interessant en welke velden heb je nodig om een oordeel te vormen. Als je die structuur consequent toepast, blijft een query ook bij complexere jachtvragen overzichtelijk en onderhoudbaar.

Een goede start is het zoeken naar recente processtarts op endpoints, omdat aanvallers vrijwel altijd code moeten uitvoeren om verder te komen. In Defender XDR worden die gebeurtenissen geregistreerd in de tabel DeviceProcessEvents. Door in eerste instantie alleen te filteren op een tijdsvenster – bijvoorbeeld de afgelopen vierentwintig uur – krijg je een gevoel voor het volume in jouw omgeving. Vervolgens kun je die ruwe stroom beperken tot processen die je echt verdacht vindt, zoals PowerShell, command‑line interpreters of scriptingomgevingen die vaak voor living‑off‑the‑land‑technieken worden misbruikt. Het is daarbij verstandig om direct case‑insensitieve vergelijkingen te gebruiken, omdat bestandsnamen in logs niet altijd in een vaste schrijfwijze voorkomen.

De voorbeeldquery in het onderstaande codeblok laat zien hoe je dat op een gestructureerde manier kunt doen. Eerst selecteer je de DeviceProcessEvents‑tabel en beperk je de resultaten tot processen die in de afgelopen vierentwintig uur zijn gestart. Vervolgens filter je op bestandsnamen die overeenkomen met PowerShell, zowel de klassieke powershell.exe als de modernere pwsh.exe. Daarna zoek je in de command‑line naar patronen die vaak horen bij misbruik, zoals het gebruik van de parameter om commando’s te encoderen of expliciet de uitvoering van scriptsigningen te omzeilen. Tot slot projecteer je alleen de velden die nodig zijn voor triage: tijdstip, apparaatnaam, account en de volledige command‑line.

Voor teams in de Nederlandse publieke sector is het nuttig om deze basisquery te koppelen aan de eigen hardeningstandaarden. Als in beleid is vastgelegd dat PowerShell alleen voor beheertaken op specifieke beheerwerkplekken mag worden gebruikt, kun je de query uitbreiden met een filter dat alleen niet‑beheerend gebruik toont, of juist alle apparaten buiten een bepaalde groep uitlicht. Op die manier wordt de uitkomst direct bruikbaar voor opvolging: je ziet welke accounts en systemen beleid overtreden en kunt gericht onderzoeken of dit verklaarbaar beheerwerk is of dat er sprake kan zijn van misbruik.

Een ander belangrijk basisprincipe is het beperken van het aantal kolommen en records dat je ophaalt. Door al vroeg in de query te filteren op tijd, apparaat of account, voorkom je dat de uitvoering onnodig zwaar wordt en de interface traag reageert. Ook helpt het om tijdens het ontwikkelen van een query tijdelijk met een kleiner tijdsvenster te werken, bijvoorbeeld één of twee uur, zodat je sneller kunt itereren. Als de logica eenmaal klopt, kun je de periode vergroten om te kijken of het patroon ook in de afgelopen dagen zichtbaar is. Zo bouw je stap voor stap een set basisqueries op die zowel technisch efficiënt als inhoudelijk relevant zijn voor jouw organisatie.

kql
DeviceProcessEvents | where Timestamp > ago(24h) | where FileName =~ "powershell.exe" or FileName =~ "pwsh.exe" | where ProcessCommandLine contains "-enc" or ProcessCommandLine contains "-exec bypass" | project Timestamp, DeviceName, AccountName, ProcessCommandLine | order by Timestamp desc

Queries voor Suspicious Activities

Zodra je de basis onder de knie hebt, wordt het interessanter om te jagen op concrete aanvalstechnieken. Een terugkerend thema in vrijwel alle ernstige incidenten is misbruik van inloggegevens. Aanvallers proberen zo snel mogelijk van een initiële foothold naar hogere rechten te escaleren, zodat zij zich lateraal kunnen verplaatsen en kritieke systemen kunnen bereiken. In Windows‑omgevingen is credential dumping met hulpmiddelen zoals Mimikatz een bekende tactiek. Hoewel professionele aanvallers hun tooling regelmatig aanpassen, laten zij in de praktijk vaak herkenbare sporen achter in procesnamen, command‑lines en netwerkgedrag.

Met Advanced Hunting kun je zulke patronen expliciet in de data opzoeken. Een goed vertrekpunt is opnieuw de tabel DeviceProcessEvents, waarin je zoekt naar processen die woorden bevatten die typisch zijn voor Mimikatz‑commando’s of modules. Termen als ‘sekurlsa’, ‘lsadump’ en ‘kerberos’ komen in normale productiesoftware zelden voor in command‑lines, maar zijn juist karakteristiek voor tooling die wachtwoorden en tickets probeert uit te lezen uit het geheugen van het systeem. Door daarnaast te kijken naar bekende bestandsnamen en, waar beschikbaar, hashwaarden die in threat intelligence feeds als verdacht zijn aangemerkt, vergroot je de kans dat je daadwerkelijke misbruik signaleert in plaats van alleen lab‑experimenten of testomgevingen.

In het bijbehorende codeblok wordt die aanpak gecombineerd met informatie over netwerkverkeer. De query start met het selecteren van recente procesgebeurtenissen, filtert op verdachte command‑line patronen en bestandsnamen en maakt vervolgens een join met DeviceNetworkEvents op basis van het apparaat. Op die manier kun je zien of een mogelijk malafide proces direct netwerkverbindingen opzet, bijvoorbeeld via SMB naar andere systemen in het domein. Dat helpt om sneller te bepalen of je met een geïsoleerde test te maken hebt of dat er werkelijk een poging tot laterale beweging en verdere compromittering gaande is.

Belangrijk is dat je na het draaien van zo’n query altijd een analytische vertaalslag maakt naar jouw eigen omgeving. Niet elk script dat ‘sekurlsa’ in de command‑line bevat, is automatisch kwaadwillend; sommige security‑teams gebruiken vergelijkbare tooling in hun eigen pentests of purple‑team‑oefeningen. Documenteer daarom per query welke false positives je verwacht, welke accounts of apparaten structureel kunnen worden uitgesloten en hoe je de resultaten wilt triëren. Door die kennis vast te leggen in playbooks en in de beschrijving van de query, zorg je ervoor dat collega’s op dezelfde manier naar de uitkomsten kijken en dat je als team consistent leert van eerdere casussen.

Voor organisaties die NBVC en BIO volgen, is het daarnaast relevant om de uitkomsten te koppelen aan beheersmaatregelen rond privileged access management. Als je via Advanced Hunting bijvoorbeeld herhaaldelijk ziet dat dezelfde beheeraccounts op ongebruikelijke tijden op productieservers inloggen, is dat een signaal om kritisch naar je PIM‑inrichting, logging en alertering te kijken. Door technische bevindingen uit KQL‑queries te verbinden met governance‑maatregelen, versterk je zowel je operationele weerbaarheid als je aantoonbaarheid richting toezichthouders en auditors.

Na verloop van tijd ontstaat er een verzameling queries voor verschillende vormen van misbruik, zoals password spraying, brute‑forceaanvallen, misuse van serviceaccounts of verdachte interacties met directory‑services. Door die verzameling te koppelen aan bekende aanvalsketens, bijvoorbeeld op basis van MITRE ATT&CK, kun je per tactiek beoordelen hoe volwassen je detectie is. Zo wordt hunting op ‘suspicious activities’ niet alleen een incidentele exercitie, maar een structureel middel om je detectielandschap te spiegelen aan de risico’s die horen bij jouw digitale kroonjuwelen.

kql
DeviceProcessEvents | where Timestamp > ago(7d) | where ProcessCommandLine has_any ("sekurlsa", "lsadump", "kerberos", "privilege::debug") or FileName in~ ("mimikatz.exe", "mimilib.dll") or SHA1 in ("<known-mimikatz-hashes>") | join kind=leftouter ( DeviceNetworkEvents | where RemotePort == 445 // SMB lateral movement ) on DeviceId | project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, RemoteIP | order by Timestamp desc

Email Threat Queries

E‑mail blijft een van de belangrijkste aanvalskanalen voor organisaties in de publieke sector. Ondanks de inzet van moderne filtering, sandboxing en AI‑gebaseerde risicobeoordeling glippen er nog steeds phishingmails en kwaadwillende links door de verdediging. Advanced Hunting maakt het mogelijk om gericht in de Defender for Office 365‑data te zoeken naar verdachte combinaties van afzenders, onderwerpen, bestemmingen en gebruikersgedrag. Daarmee kun je niet alleen afzonderlijke incidenten analyseren, maar ook patronen ontdekken in campagnes die specifiek op jouw organisatie of keten zijn gericht.

Een krachtige benadering is om e‑mailgegevens te combineren met klikgedrag. De tabel EmailEvents bevat per bericht onder meer informatie over de richting (inbound of outbound), de afzender, de ontvangers, classificaties door Defender en het uiteindelijke aflever‑ of blokkeringsresultaat. EmailUrlInfo voegt daar per bericht de URL’s aan toe die in de inhoud of bijlagen zijn aangetroffen. UrlClickEvents registreert vervolgens wie op welke link heeft geklikt en of die klik is toegestaan of geblokkeerd. Door deze tabellen in één query te koppelen, ontstaat een gedetailleerd beeld van welke verdachte links daadwerkelijk door gebruikers zijn aangeklikt en mogelijk tot verdere compromittering hebben geleid.

In de voorbeeldquery wordt eerst gefilterd op inkomende e‑mailberichten met een classificatie die wijst op phishing of malware. Daarna worden die berichten gekoppeld aan de URL‑informatie, waarbij expliciet wordt uitgesloten dat de links verwijzen naar bekende betrouwbare domeinen van de leverancier zelf. Dit is slechts een eenvoudige illustratie; in een echte omgeving kun je deze whitelist uitbreiden met jouw eigen overheidsdomeinen en vertrouwde dienstverleners. Vervolgens wordt de set verrijkt met klikgebeurtenissen, zodat je alleen berichten overhoudt waarbij verdachte links daadwerkelijk zijn geopend. Dat levert een zeer relevante lijst op voor opvolging door het SOC of het security‑awarenessteam.

Voor de Nederlandse overheid is het van belang om zulke analyses te koppelen aan bredere programma’s voor bewustwording en ketensamenwerking. Wanneer je via Advanced Hunting ziet dat bepaalde afdelingen, functies of ketenpartners disproportioneel vaak op verdachte links klikken, kun je samen met HR en communicatie gerichte trainingen of simulaties organiseren. Ook kun je – binnen de kaders van AVG en Woo – aantonen dat je inspanningen rond phishingbestrijding structureel zijn onderbouwd en gemonitord. De uitkomsten van deze queries vormen daarmee niet alleen input voor operationele mitigatie, maar ook voor beleidsbeslissingen en rapportages aan bestuurders en toezichthouders.

Een laatste aspect is de koppeling met andere Defender‑signalen. Kliks op verdachte links leiden idealiter tot aanvullende monitoring op endpoints en identiteiten. Door e‑mailqueries te combineren met DeviceProcessEvents, IdentityLogonEvents of Defender for Cloud Apps‑data, kun je onderzoeken of een gebruiker na het klikken op een link bijvoorbeeld ongebruikelijke aanmeldpogingen doet, scripts downloadt of bestanden naar externe cloudopslag stuurt. Zo groeit een ogenschijnlijk eenvoudige phishingalert uit tot een volledige ketenanalyse, waarin je niet alleen het initiële risico beoordeelt, maar ook de vervolgstappen van een mogelijke aanvaller zichtbaar maakt.

Door resultaten structureel te analyseren over langere perioden, bijvoorbeeld per kwartaal, kun je bovendien inzicht krijgen in de effectiviteit van je bewustwordingsprogramma’s en technische maatregelen. Een dalende trend in het aantal klikken op verdachte links na nieuwe trainingen of na de introductie van aanvullende technische controls geeft aan dat je interventies daadwerkelijk effect hebben. Daarmee wordt Advanced Hunting ook een instrument voor continue verbetering: niet alleen om incidenten te vinden, maar ook om te meten of beleidskeuzes rond e‑mailbeveiliging en security‑cultuur in de praktijk werken.

kql
EmailEvents | where Timestamp > ago(7d) | where EmailDirection == "Inbound" | where ThreatTypes has_any ("Phish", "Malware") | join kind=inner ( EmailUrlInfo | where Url !has "microsoft.com" and Url !has "office.com" ) on NetworkMessageId | join kind=inner ( UrlClickEvents | where ActionType == "ClickAllowed" ) on NetworkMessageId | project Timestamp, RecipientEmailAddress, SenderFromAddress, Subject, Url, UrlLocation | order by Timestamp desc

Lateral Movement Detection

Zodra een aanvaller een eerste systeem in de omgeving heeft gecompromitteerd, verschuift de focus vrijwel altijd naar laterale beweging. Het doel is dan om vanaf die eerste foothold andere apparaten, servers of cloudresources te bereiken die meer waardevolle data of hogere rechten bevatten. Voor organisaties die werken met Active Directory en hybride identiteitsoplossingen vormt dit een aanzienlijk risico: één zwak systeem met hergebruikte credentials kan de deur openen naar een groot deel van het netwerk. Advanced Hunting helpt om patronen te detecteren die wijzen op dit type misbruik, nog voordat alle traditionele detectieregels aanslaan.

Een veelbesproken techniek is pass‑the‑hash, waarbij in plaats van het oorspronkelijke wachtwoord een gehashte variant wordt hergebruikt om op andere systemen te authenticeren. In de telemetrie zie je zo’n aanval zelden letterlijk terug als ‘pass‑the‑hash’, maar wel via afwijkend aanmeldgedrag. De query in het codeblok hieronder toont een aanpak waarbij je in DeviceLogonEvents zoekt naar accounts die zich in een relatief korte periode aanmelden op veel verschillende apparaten. Door in eerste instantie te filteren op logontypen die typisch zijn voor netwerk‑ of RDP‑toegang en machineaccounts uit te sluiten, focus je op interactief menselijk gebruik. Vervolgens aggregeer je per account hoeveel verschillende apparaten in beeld komen en over welke periode die activiteit zich uitstrekt.

Wanneer een normaal medewerkeraccount zich plotseling op tien verschillende servers verspreid over de organisatie aanmeldt, is dat een signaal om verder te kijken. Natuurlijk zijn er legitieme scenario’s, zoals servicedesks of beheerders die via tooling op meerdere systemen inloggen, maar ook die patronen kun je meestal vooraf definiëren en desnoods expliciet uitsluiten in je query. Door drempelwaarden, uitzonderingen en bekende serviceaccounts te documenteren en te onderhouden, voorkom je dat je team verdrinkt in false positives en blijft de focus liggen op werkelijk afwijkende patronen.

Binnen de context van de Nederlandse Baseline voor Veilige Cloud en de BIO sluit deze vorm van hunting nauw aan bij maatregelen rond autorisatiebeheer, logging en netwerksegmentatie. Door laterale beweging vroegtijdig te detecteren, kun je voorkomen dat een aanvaller domeinbrede rechten vergaart of toegang krijgt tot systemen met bijzondere persoonsgegevens, vitale processen of staatsgeheime informatie. De resultaten van deze queries kunnen direct input leveren voor verbeteringen in Conditional Access‑beleid, network segmentation, de inrichting van privileged access workstations en de inzet van jump servers.

Een belangrijk leereffect van dit soort analyses is dat je zicht krijgt op feitelijk geobserveerd gedrag, niet alleen op papieren ontwerpen. Veel organisaties gaan ervan uit dat beheeraccounts uitsluitend vanaf beveiligde beheerwerkplekken inloggen, maar Advanced Hunting‑data laten regelmatig zien dat uitzonderingen zijn ingeslopen of dat tijdelijke oplossingen structureel zijn geworden. Door die bevindingen terug te koppelen naar architectuur- en governance‑overleggen, zorg je dat technische inzichten uit het SOC leiden tot blijvende verbeteringen in het ontwerp en de beheersprocessen.

Door laterale‑bewegingsqueries op te nemen in periodieke rapportages aan CISO, CIO en lijnmanagement ontstaat bovendien een gesprek over de feitelijke effectiviteit van netwerksegmentatie en identity‑governance. Wanneer maand na maand dezelfde patronen terugkeren, is dat een aanwijzing dat structurele maatregelen nodig zijn in plaats van alleen incidentgerichte opvolging. Zo wordt lateral‑movement‑hunting een thermometer voor de volwassenheid van je toegangsmodel en niet slechts een technische exercitie in het SOC.

kql
DeviceLogonEvents | where Timestamp > ago(1d) | where LogonType in ("Network", "RemoteInteractive") | where AccountName !endswith "$" // Exclude machine accounts | summarize DistinctDevices = dcount(DeviceName), Devices = make_set(DeviceName), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by AccountName, LogonType | where DistinctDevices > 5 // Same account logging into 5+ devices | order by DistinctDevices desc

Persistence Detection Queries

Naast initiële toegang en laterale beweging is persistente verankering een kernonderdeel van bijna elke gerichte aanval. Een aanvaller die slechts kortstondig toegang heeft, loopt het risico dat een herstart, patch of wachtwoordwijziging de deur weer sluit. Daarom zoeken dreigingsactoren naar manieren om zichzelf opnieuw te laten uitvoeren bij systeemstart, gebruikersaanmelding of volgens een tijdschema. In Windows‑omgevingen zijn scheduled tasks, services, registry‑runkeys en aanpassingen in opstartlocaties bekende persistente mechanismen. Advanced Hunting biedt voldoende detail om dergelijke wijzigingen gericht op te sporen en te koppelen aan de accounts en processen die ze hebben aangebracht.

Een praktische instap is het monitoren van nieuwe scheduled tasks. De query in het onderstaande codeblok richt zich op processen die schtasks.exe aanroepen met de parameter om een taak aan te maken. Door bekende, door Microsoft geleverde taken uit te sluiten en aanvullende filters toe te passen op command‑lines die scripts uit tijdelijke mappen, publieke folders of profielmappen starten, kun je verdachte patronen isoleren. De query extraheert daarnaast de taaknaam en de geconfigureerde actie, zodat je snel kunt beoordelen of een aangemaakte taak past bij legitiem beheer of dat er sprake kan zijn van een poging tot persistente toegang.

Voor organisaties in de publieke sector is het belangrijk om deze technische detecties te verbinden met het formele wijzigings- en releaseproces. Als jouw organisatie bijvoorbeeld voorschrijft dat geautomatiseerde taken via een gecentraliseerd configuratieplatform of een changeproces worden uitgerold, dan horen individuele beheerders geen handmatige scheduled tasks op productiesystemen aan te maken. Door resultaten uit Advanced Hunting naast change‑registraties te leggen, ontdek je ‘schaduwautomatisering’ en kun je bijsturen. Dat past bij de governance‑eisen uit de BIO, waarin controle op wijzigingen, functiescheiding en herleidbaarheid van handelingen expliciet worden genoemd.

Persistente mechanismen beperken zich bovendien niet tot Windows‑taken alleen. In Defender‑telemetrie kun je ook zoeken naar installatie en configuratie van services, aanpassingen in autostart‑locaties, scripts die in logon‑scripts worden geïnjecteerd en tooling die misbruik maakt van vertrouwde applicaties om code uit te voeren. Hoewel niet elk patroon standaard in één kant‑en‑klare query te vangen is, kun je met Advanced Hunting stapsgewijs specifieke scenario’s modelleren die passen bij jouw omgeving. Denk aan een query die nieuwe services identificeert waarvan de binairen in niet‑standaard paden staan, of processen die bij elke gebruikersaanmelding worden gestart vanuit mappen waar normaal geen uitvoerbare bestanden horen te staan.

Door jacht op persistente mechanismen op te nemen in een regelmatig hunting‑ritme, bijvoorbeeld wekelijks of maandelijks, verminder je de kans dat een aanvaller langdurig onopgemerkt in je omgeving aanwezig is. Tegelijkertijd bouw je kennis op over hoe legitiem beheer in de praktijk plaatsvindt, wat weer input is voor het aanscherpen van beleid, autorisaties en technische configuraties. Zo ontstaat een feedbacklus waarin Advanced Hunting niet alleen incidenten helpt opsporen, maar ook de structurele kwaliteit van je security‑architectuur verhoogt.

In veel organisaties blijkt uit dit soort analyses dat documentatie over persistente taken en services niet altijd overeenkomt met de werkelijkheid. Door de resultaten van je queries terug te leggen bij systeembeheerders, applicatie‑eigenaren en change‑coördinatoren ontstaat een dialoog over welke taken echt noodzakelijk zijn en welke kunnen worden uitgefaseerd of geautomatiseerd via centrale tooling. Dit draagt niet alleen bij aan minder aanvalsoppervlak, maar ook aan een beter beheersbare omgeving waarin onverwachte wijzigingen sneller worden opgemerkt en onderzocht.

kql
DeviceProcessEvents | where Timestamp > ago(7d) | where FileName =~ "schtasks.exe" | where ProcessCommandLine has "/create" | where ProcessCommandLine !has "Microsoft" | extend TaskName = extract(@"/tn\s+([^\s]+)", 1, ProcessCommandLine) | extend TaskAction = extract(@"/tr\s+([^/]+)", 1, ProcessCommandLine) | project Timestamp, DeviceName, AccountName, TaskName, TaskAction, ProcessCommandLine | order by Timestamp desc

Advanced Threat Patterns

Naarmate aanvallers beter worden in het ontwijken van klassieke detectiemechanismen, maken zij steeds vaker gebruik van zogenaamde living‑off‑the‑land‑technieken. In plaats van eigen malware naar een systeem te uploaden, benutten zij bestaande, legitieme Windows‑onderdelen en beheerhulpmiddelen om commando’s uit te voeren, bestanden te downloaden of code te laden. Voorbeelden daarvan zijn certutil.exe, bitsadmin.exe, mshta.exe en regsvr32.exe, maar in de praktijk is de lijst veel langer en verschilt deze per organisatie. Omdat deze binaries ook in reguliere beheersscenario’s worden gebruikt, is puur op basis van de procesnaam vaak moeilijk te zien of er sprake is van misbruik.

Advanced Hunting biedt de mogelijkheid om die scheidslijn scherper te maken door procesinformatie te combineren met context over bestandslocaties, command‑lines en vervolgacties. In de voorbeeldquery wordt eerst een dynamische lijst gedefinieerd met veelvoorkomende LOLBins. Vervolgens worden alle processen geselecteerd waarin de bestandsnaam overeenkomt met een van de elementen uit die lijst. Door daarna te filteren op command‑lines die wijzen op netwerkcommunicatie of het downloaden van content, verklein je het aantal resultaten al aanzienlijk. De query maakt vervolgens een koppeling met DeviceFileEvents om te achterhalen of het verdachte proces nieuwe bestanden heeft aangemaakt in locaties die vaak door aanvallers worden gebruikt, zoals tijdelijke mappen of profielen van gebruikers.

Het doel is niet om elk gebruik van deze binaries te blokkeren, maar om patronen te herkennen die niet passen bij reguliere beheersactiviteiten. In een goed ingerichte omgeving kun je bijvoorbeeld verwachten dat bepaalde beheerhulpmiddelen alleen vanaf specifieke jump servers of beheerwerkplekken worden gestart. Door die kennis terug te laten komen in je query – bijvoorbeeld via een filter op bekende beheerdevice‑namen of security‑groepen – richt je je hunting op afwijkingen ten opzichte van het beoogde ontwerp. Dat sluit aan bij het zero‑trustprincipe waarin niet alleen identiteiten, maar ook apparaten en workloads expliciet worden gevalideerd.

De inzichten uit dit soort advanced patterns zijn bovendien waardevol voor zowel technische als bestuurlijke besluitvorming. Als je regelmatig ziet dat bepaalde binaries op ongebruikelijke plekken worden ingezet, is dat een signaal om te onderzoeken of hardeningrichtlijnen moeten worden aangescherpt, bijvoorbeeld door AppLocker, Defender Application Control of Intune‑configuratieprofielen strenger in te stellen. Tegelijkertijd kun je de resultaten gebruiken om bewustwording te vergroten bij beheerders en developers, zodat zij begrijpen waarom het gebruik van generieke tools in productieomgevingen risico’s oplevert. In rapportages richting CISO’s en bestuurders helpt het om te laten zien dat je niet alleen op bekende malware vertrouwt, maar actief jaagt op misbruik van legitieme functionaliteit.

Door deze geavanceerde patronen onderdeel te maken van je vaste hunting‑set, creëer je een verdedigingslaag die moeilijker te omzeilen is voor aanvallers. Zelfs als zij nieuwe binaries of scripts inzetten, zullen zij in veel gevallen alsnog afwijkende logon‑patronen, bestandslocaties of datastromen genereren die met Advanced Hunting zichtbaar worden. Het is juist de combinatie van verschillende signalen – proces, bestand, netwerk, identiteit – die ervoor zorgt dat je als organisatie tijdig kunt ingrijpen voordat een incident uitgroeit tot een grootschalige verstoring van dienstverlening.

Daarnaast helpt het om de inzichten uit deze advanced patterns te koppelen aan concrete architectuurkeuzes, zoals het minimaliseren van beheerrechten op werkstations, het scheiden van beheer- en kantooromgevingen en het standaardiseren van beheertooling. Wanneer je uit analyses afleidt dat bepaalde LOLBins structureel nodig zijn voor legitiem beheer, kun je daar expliciete regels en uitzonderingen voor vastleggen. Daarmee maak je voor auditors en toezichthouders inzichtelijk waarom bepaalde binaries wel zijn toegestaan, onder welke voorwaarden dat gebeurt en hoe je afwijkend gebruik actief monitort met Advanced Hunting.

kql
let LOLBins = dynamic(["certutil.exe", "bitsadmin.exe", "mshta.exe", "regsvr32.exe"]); DeviceProcessEvents | where Timestamp > ago(7d) | where FileName in~ (LOLBins) | where ProcessCommandLine has_any ("http", "download", "exec", "script") | join kind=leftouter ( DeviceFileEvents | where ActionType == "FileCreated" | where FolderPath has_any ("\\temp\\", "\\appdata\\", "\\public\\") ) on DeviceId, InitiatingProcessId | project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, CreatedFile=FileName1, CreatedFilePath=FolderPath | order by Timestamp desc

Best Practices voor Threat Hunting

Effectieve threat hunting vraagt om meer dan een verzameling losse queries; het draait om een gestructureerde werkwijze die hypotheses, tooling, documentatie en governance met elkaar verbindt. Een goed vertrekpunt is altijd een duidelijke onderzoeksvraag. In plaats van willekeurig tabellen te doorzoeken, formuleer je expliciet welk risico je wilt toetsen. Dat kan gaan over ongeautoriseerde administratoractiviteit buiten kantoortijden, signalen van credential dumping op domeincontrollers of aanwijzingen dat data wordt geëxfiltreerd naar onbekende cloudopslag. Door die vraag vooraf met het team te delen, voorkom je dat iedereen met een eigen interpretatie aan de slag gaat en kun je de uitkomsten later beter vertalen naar concrete verbetermaatregelen.

Bij het opstellen van queries loont het om vanaf het begin op performance en leesbaarheid te letten. Geoptimaliseerde queries filteren zo vroeg mogelijk in de pipeline, bij voorkeur direct na het selecteren van de tabel, zodat alleen relevante gebeurtenissen overblijven voordat je complexe bewerkingen uitvoert. Eerst een tijdvenster en enkel de noodzakelijke apparaten of accounts selecteren, daarna pas join‑operaties of aggregaties toepassen, helpt om de belasting op het platform beperkt te houden. Ook het terugbrengen van het aantal kolommen via project maakt een merkbaar verschil en zorgt ervoor dat analisten sneller overzicht houden tijdens triage.

Zodra een query herhaaldelijk interessante signalen oplevert, is het verstandig om te bekijken of je deze kunt verheffen tot een structurele detectie. In Defender XDR kun je Advanced Hunting‑queries namelijk omzetten naar Custom Detection Rules die periodiek draaien en bij een match automatisch een alert genereren. Dat betekent dat een succesvol hunting‑experiment doorstroomt naar de dagelijkse operatie van het SOC, zonder dat een analist de query telkens handmatig hoeft uit te voeren. Bij het configureren van zo’n regel denk je niet alleen na over de technische logica, maar ook over de ernstindeling, de toegewezen responsprocedures en de wijze waarop je valse positieven monitort.

Documentatie vormt de ruggengraat van volwassen hunting. Een querybibliotheek waarin per item de bedoeling, verwachte false‑positiveratio, triage‑instructies en koppelingen met MITRE ATT&CK‑tactieken zijn vastgelegd, maakt het mogelijk om kennis te delen over teams en generaties medewerkers heen. Binnen de context van de Nederlandse overheid helpt dit bovendien om richting auditors en toezichthouders aan te tonen dat detecties niet willekeurig tot stand komen, maar zijn ingebed in een methodische aanpak. Door per query te beschrijven welke controls uit de NBVC of BIO worden geraakt, leg je direct de link tussen technische observaties en formele beheersmaatregelen.

Tot slot is het zinvol om threat hunting als terugkerend ritme in te richten in plaats van een ad‑hocactiviteit bij grote incidenten. Veel organisaties kiezen voor een wekelijks moment waarop analisten recente alerts en trends doorlopen en gericht zoeken naar onbekende patronen. Daarnaast kan maandelijks of per kwartaal een diepgaande sessie plaatsvinden rond een specifiek onderwerp, zoals ransomware‑tactieken, identiteitsmisbruik of supply‑chainrisico’s. Door deze sessies te koppelen aan duidelijke doelen, zoals het opleveren van een nieuwe detectieregel of het aanscherpen van een runbook, wordt hunting een herkenbaar onderdeel van de beveiligingscyclus en niet slechts een experimentele nevenactiviteit.

Een volwassen aanpak betekent ook dat je de rol van threat hunting expliciet positioneert in je governance‑structuur. Door in beleid en architectuurdocumenten vast te leggen hoe hunting bijdraagt aan risicobeheersing, welke rapportagelijnen bestaan en hoe bevindingen worden opgevolgd, voorkom je dat inspanningen afhankelijk zijn van enkele enthousiaste specialisten. Zo ontstaat een duurzaam model waarin Advanced Hunting niet alleen een technisch hulpmiddel is, maar een vaste pijler onder de continuïteit, weerbaarheid en aantoonbaarheid van je cloud‑ en Microsoft 365‑omgeving.

Veelgemaakte Fouten

Bij het inzetten van Advanced Hunting ziet men in de praktijk steeds dezelfde valkuilen terugkeren. De eerste is het schrijven van veel te brede queries. Een ogenschijnlijk onschuldige instructie zoals DeviceEvents | where Timestamp > ago(30d) kan in een grotere omgeving miljoenen records opleveren, met lange wachttijden en time‑outs tot gevolg. Analisten verliezen daardoor snel het overzicht en zijn geneigd om de tool als traag of onbetrouwbaar te ervaren. De kern van het probleem is dat er geen duidelijke focus is aangebracht voordat de query wordt uitgevoerd. Door al in de eerste regels tijdsvenster, type gebeurtenis en relevante apparaatgroepen te beperken, houd je de dataset beheersbaar en blijft de responstijd acceptabel.

Een tweede veelvoorkomende fout is onvoldoende aandacht voor de manier waarop strings worden vergeleken. Wie gewend is aan klassieke programmeertalen, schrijft al snel expressies met exacte, hoofdlettergevoelige vergelijkingen. In logdata komt dezelfde bestandsnaam echter in uiteenlopende schrijfwijzen voor, afhankelijk van het bronproces of de component die de gebeurtenis heeft geregistreerd. Een query die strikt zoekt naar powershell.exe zal daarom varianten met andere hoofdlettergebruik eenvoudig missen. Door bewust gebruik te maken van de case‑insensitieve operatoren in KQL voorkom je dat je relevante signalen over het hoofd ziet. In de voorbeeldquery in het codeblok hieronder wordt dat verschil geïllustreerd en zie je hoe je een vergelijking robuuster maakt zonder aan precisie in te boeten.

Een derde valkuil is het negeren van false positives. Elke huntingquery levert in de praktijk een mix op van daadwerkelijk verdacht gedrag, grijze gevallen en geheel legitieme activiteiten. Als je die nuance niet vastlegt, beland je al snel in een situatie waarin analisten bij elke uitvoering opnieuw moeten uitzoeken welke resultaten relevant zijn. Beter is het om expliciet te documenteren welke accounts, apparaten of scenario’s structureel een verklaring hebben en deze waar mogelijk al in de query uit te filteren. Serviceaccounts voor back‑ups, monitoring of geautomatiseerde deploymentprocessen kunnen bijvoorbeeld in een aparte lijst worden opgenomen die je in de where‑clausule uitsluit. Op die manier verschuift de aandacht naar de overblijvende, minder verklaarbare gebeurtenissen.

Tot slot is er de neiging om queries eenmalig te schrijven en daarna jarenlang onaangeroerd te laten. In een dynamische cloudomgeving veranderen diensten, configuraties en dreigingsbeelden echter continu. Wat vandaag een zinnige filter is, kan volgend jaar leiden tot blinde vlekken of juist onnodige uitsluitingen. Door periodiek – bijvoorbeeld elk kwartaal – een review te doen van de belangrijkste queries en detectieregels, houd je de logica in lijn met de actuele architectuur, nieuwe beveiligingsmaatregelen en gewijzigde wettelijke eisen. Binnen de context van de Nederlandse overheid betekent dit dat je huntingaanpak meegroeit met aanpassingen in NBVC, BIO‑normen en NIS2‑implementatie. Zo zorg je ervoor dat Advanced Hunting geen eenmalige exercitie blijft, maar een levend instrument dat de werkelijkheid van jouw organisatie blijft reflecteren.

Teams die deze fouten expliciet maken in hun documentatie en onboarding voor nieuwe analisten, merken vaak dat de leercurve aanzienlijk wordt verkort. Door voorbeelden van mislukte queries, performanceproblemen en gemiste signalen te delen in interne kennissessies, ontstaat een cultuur waarin men openlijk spreekt over wat niet goed ging en hoe dat is opgelost. Dat sluit aan bij de bredere ambitie van de Nederlandse Baseline voor Veilige Cloud om van incidenten en bijna‑incidenten te leren en die lessen te verankeren in processen, tooling en governance.

Microsoft Defender XDR Advanced Hunting is een essentieel tool voor moderne security teams. Met de queries in dit artikel heb je een solide basis om te starten met proactieve threat hunting. Begin met de basis queries, experimenteer, en bouw langzaam je query library op.

Vergeet niet: threat hunting is een skill die je ontwikkelt door te doen. Start vandaag nog met één query per week, en binnen enkele maanden ben je een KQL expert!

Bekijk onze Defender XDR artikelen voor meer security automation
Bekijk artikelen →
Defender XDR KQL Threat Hunting Advanced Hunting SOC