Threat Hunting: Wat het is en hoe het werkt

Threat hunting is de praktijk van proactief zoeken door netwerken en endpoints naar aanvallers die je bestaande detecties al hebben omzeild. Het begint met een eenvoudige, oncomfortabele aanname: er kan al iets slechts binnen zijn, en geen alert is ervoor afgegaan. In plaats van te wachten tot een SIEM-regel activeert, stelt een jager een hypothese op en gaat op zoek naar bewijs om deze te bevestigen of te verwerpen.

Waarom detectie alleen niet genoeg is

Signatuur-gebaseerde en regel-gebaseerde detectie vangt bekende patronen. Aanvallers die living-off-the-land binaries (LOLBins), geldige inloggegevens, of langzame, lage-volume technieken gebruiken, kunnen onder deze drempels blijven gedurende weken. Threat hunting vult die leemte in door een mens actief de data in twijfel te trekken: maakt deze PowerShell-aanroep vanuit een finance-werkstation om 2 uur 's nachts zin? Waarom maakt svchost.exe een uitgaande verbinding met een IP-adres zonder reverse DNS?

Dit is geen incident response. IR begint nadat je weet dat er iets gebeurd is. Hunting begint als je het nog niet weet, en het doel is dat uit te vinden voordat een groter incident de vraag afdwingt.

De drie veel voorkomende startpunten

De meeste hunts beginnen vanuit een van drie hoeken:

• Intelligence-driven: een nieuw bedreigingsrapport beschrijft een TTP (bijvoorbeeld misbruik van een geplande taak voor persistentie), en je controleert of het in je omgeving aanwezig is.
• Situational awareness: je kijkt wat werkelijk ongebruikelijk is voor je organisatie — een serviceaccount dat zich aanmeldt vanuit een land waar het nog nooit is geweest, of een piek in SMB-verkeer tussen werkstations die normaal alleen met servers communiceren.
• Analytics-driven: je bouwt een basislijn van normaal gedrag (procestrees, inlogtijden, DNS-queryvolume) en zoekt naar statistische uitschieters ertegenaan.

MITRE ATT&CK is de referentie die de meeste teams gebruiken om hypothesen in te structureren. In plaats van "zoek naar malware", kies je een techniek als T1053 (Scheduled Task/Job) en vraag je jezelf af: hoe zou dat eruitzien in onze Windows Event Logs of EDR-telemetrie, en kan ik er nu naar query's op uitvoeren?

Hoe de werkelijke workflow eruitziet

Een hunt volgt doorgaans deze lus:

1. Stel een specifieke, testbare hypothese op (niet "controleer op inbreuken" maar "controleer op nieuwe geplande taken die buiten patchvensters zijn gemaakt in de laatste 30 dagen").
2. Identificeer de benodigde gegevensbronnen — Sysmon Event ID 1 voor procesverwezenlijking, Windows Security Event ID 4698 voor geplande taakverwezenlijking, EDR-procestrees, of Zeek conn logs voor netwerkcontext.
3. Query en draai. In de praktijk betekent dit KQL schrijven in Microsoft Sentinel, SPL in Splunk, of ruwe query's tegen een Elastic index.
4. Triage resultaten — de meeste zijn false positives of goedaardige admin-activiteiten, en de taak is die ruis te reduceren tot wat werkelijk anomaal is.
5. Documenteer bevindingen, of het nu een bevestigde inbreuk is, een detectiegat, of gewoon een