Een medewerker opent een phishingmail, meldt zich aan op een nagemaakte Microsoft 365 pagina en merkt verder niets. Achter de schermen wordt het account gebruikt. Kort daarna komen er verdachte aanmeldingen en pogingen om via SMB bestanden op andere systemen te benaderen. Het SOC krijgt meerdere meldingen. De interessante vraag is niet alleen of je die meldingen ziet, maar of je de aanvaller kunt tegenhouden voordat de aanval zich verspreidt.

Ik zie bij klanten dat detectie vaak goed geregeld is, maar de stap van incident naar aantoonbare containment minder volwassen is. Iemand ziet een riskante aanmelding, een ander controleert een endpoint en pas daarna denkt men aan laterale beweging. Microsoft Defender XDR kan die signalen op incidentniveau verbinden en onder voorwaarden zelf reageren. In deze blog laat ik zien hoe je de keten onderzoekt, welke nieuwe functionaliteit uit 2026 relevant is en waar de beperkingen zitten.

Het scenario hieronder is een fictieve, technisch realistische reconstructie van bekende aanvalspatronen. Het gaat niet om een geverifieerd incident bij een specifieke klant. Tijden, hosts en accounts zijn labgegevens. Ze zijn gekozen om de analyse reproduceerbaar te maken zonder misbruikstappen te beschrijven.

Waarom dit juist in 2026 relevant is

Automatische containment bestaat al langer, maar de controleerbaarheid ervan heeft een nieuwe stap gekregen. Microsoft beschrijft DisruptionAndResponseEvents sinds juni 2026 als General availability in de Microsoft Defender XDR release notes. De tabel laat zien welk verkeer is geblokkeerd en welke endpoint policies zijn toegepast. Dat is precies de informatie die een SOC nodig heeft om te bepalen of de aanval echt gestopt is. [1][2]

Daarnaast heeft Microsoft in mei 2026 automatische device isolation toegevoegd als Public preview. Defender kan in ondersteunde scenario’s een gecompromitteerd, beheerd werkstation tijdelijk isoleren wanneer de incidentanalyse met hoge zekerheid aangeeft dat het als actieve uitvalsbasis dient. Dat is niet hetzelfde als de al bestaande Contain device actie. Zie die preview daarom als testkandidaat en niet als functie waarop je productieproces zonder meer moet vertrouwen. [1][3]

Ook de Activities weergave van incidenten krijgt meer context over attack disruption en predictive shielding. De Policy status kolom staat volgens Microsoft nog op Preview. Productbeschikbaarheid en interfaces kunnen per tenant afwijken. Controleer de release status altijd opnieuw voordat je een ontwerp definitief maakt. [1][4]

Techniek	Stand oktober 2026	Relevantie voor dit scenario
Automatic attack disruption	Beschikbaar; afhankelijk van licenties en dekking	Gecompromitteerde assets beperken via XDR correlatie
DisruptionAndResponseEvents	GA volgens release notes juni 2026	Controle van daadwerkelijke blokkades op endpoints
Automatische device isolation	Public preview	Tijdelijke isolatie van ondersteunde werkstations
Activities / Policy status	Preview	Zicht op actieve en ingetrokken policies
Predictive shielding	Scenarioafhankelijk; controleer per tenant	Preventieve hardening, onder andere GPO en Safe Boot

Het aanvalsscenario: één account, meerdere signalen

Stel je een organisatie voor met Microsoft 365 E5, Windows 11 werkstations, Exchange Online, een hybride Active Directory en Microsoft Defender voor Endpoint op alle beheerde devices. De identiteit van medewerker noor.vandijk@contoso.example is gesynchroniseerd naar Microsoft Entra ID. Fileserver FS-01 bevat afdelingsdocumenten en staat achter standaard Windows toegangscontrole. Het SOC werkt vanuit security.microsoft.com.

Om 09:14 krijgt Noor een e-mail met een link naar een vermeend document. Een paar minuten later registreert Safe Links een klik en Entra ID ziet daarna een afwijkende aanmeldcontext. Een klik op zichzelf bewijst geen accountovername, en een afwijkend IP adres is nog geen bewijs van tokenmisbruik. Het SOC moet de vervolghandelingen en sessiecontext controleren. In de reconstructie gebruiken we vervolgens een compromised endpoint, WKST-042, waarop dezelfde accountcontext bij verdachte SMB verbindingspogingen terugkomt.

Om 09:36 ziet Defender for Endpoint netwerk- en authenticatieactiviteit tussen WKST-042 en FS-01. Het gedrag kan onderdeel zijn van legitiem beheer, maar in combinatie met identity signalen, nieuwe processen en andere alerts neemt de verdenking toe. In deze labcasus bouwt Defender XDR een incident op. Als het model voldoende zekerheid bereikt en alle voorwaarden kloppen, kan automatic attack disruption een Contain user of Contain device actie toepassen. Dat is geen gegarandeerde uitkomst van elk phishingincident. [3]

Een paar minuten later proberen gecompromitteerde credentials nog een SMB resource te bereiken. Op endpoints waar de containment policy actief is, kan het verkeer worden geblokkeerd. In DisruptionAndResponseEvents zoek je dan naar gebeurtenissen zoals ContainedUserLogonBlocked, ContainedUserSmbFileOpenBlocked of ContainedUserSmbSessionStopped. Die afzonderlijke event types staan expliciet in het Microsoft schema. [2]

Tijd, fictief	Waar kijk je	Te beoordelen observatie
09:14	Defender for Office 365	Aflevering phishingmail en URL
09:18	UrlClickEvents	Klikcontext en Safe Links verdict
09:25	Entra ID sign-ins	Account, IP, device compliance, risico
09:36	Defender for Endpoint	SMB en endpointgedrag richting FS-01
09:40	Defender XDR incident	Correlatie, tags, response acties
09:42	DisruptionAndResponseEvents	Blocked, Prevented en PolicyUpdated

Wat Defender XDR precies doet

Automatic attack disruption kijkt niet alleen naar losse indicators of compromise. Microsoft combineert signalen van e-mail, identity, apparaten en cloudapplicaties tot een incident. Daarna beoordeelt het systeem welke assets door de aanvaller worden gebruikt en kan het de bedreiging op die assets beperken. Deze correlatie op incidentniveau is het verschil met een simpele detectieregel die bijvoorbeeld elk verdacht IP adres blokkeert. [3]

Voor ons voorbeeld zijn vooral Contain user, Contain device en eventueel Disable user relevant. Contain user gebruikt Defender for Endpoint om communicatie van een gecompromitteerde gebruiker op onboarded devices te beperken. Contain device beperkt communicatie van een verdacht apparaat door beleidsregels op andere onboarded devices toe te passen. Disable user gebruikt de identity integratie om verdere toegang te blokkeren. Die acties zijn niet uitwisselbaar en ze kunnen verschillende operationele gevolgen hebben. [3]

Isolate device is weer iets anders. Hierbij wordt het getroffen werkstation zelf grotendeels van het netwerk geïsoleerd terwijl beveiligingsconnectiviteit behouden blijft. De automatische variant is op dit moment een preview en beperkt tot ondersteunde, beheerde eindgebruikerswerkstations. Zorg dus dat de servicedesk weet wat een containment label betekent en welke uitzonderingen voor kritieke systemen gelden. [4]

Predictive shielding kijkt nog een stap vooruit. Afhankelijk van het aanvalspatroon kan Defender bijvoorbeeld GPO abuse of Safe Mode tampering helpen blokkeren en preventief accounts beperken. Verwar dit niet met een universele blokkade tegen ransomware. Het is een verzameling contextgevoelige beschermingsacties; welke acties je ziet hangt af van ondersteunde scenario’s en de werkelijke detectorhit. [3]

Eerst controleren of je tenant klaar is

1. Controleer licenties en onboarding

Een Microsoft 365 E5 demo tenant is een goed startpunt. Controleer alsnog of de juiste workloads actief zijn. Alleen een licentie hebben is niet voldoende. Defender for Endpoint moet op relevante workstations zijn onboarded, Defender for Office 365 moet Exchange Online gegevens leveren en Defender for Identity moet voor on-premises identity acties bruikbare dekking hebben. Microsoft stelt dat de breedte van de uitgerolde producten de dekking voor detectie en response bepaalt. [4]

Begin bij de device inventory in Microsoft Defender portal. Controleer of WKST-042 en andere endpoints sensordata sturen, of hun health status goed is en of Device discovery bij gebruik van Contain device op Standard discovery staat. Neem daarna de identity coverage door. Als domain controllers geen juiste auditing hebben of Defender for Identity niet correct is ingericht, verwacht dan geen volledige on-premises identity response. [4]

2. Controleer automation en de Sense client

Ga in het Microsoft Defender portal naar System, Settings, Endpoints, Device groups, onder Permissions. Beoordeel daar Remediation level per device group. Microsoft beveelt Full, remediate threats automatically aan. Ook Semi kan attack disruption triggeren zonder handmatige goedkeuring. No automated response sluit bepaalde groepen uit van containment, maar gebruik dat heel gericht. Check kritieke bedrijfssystemen apart. [4]

Voor Contain user noemt Microsoft minimaal Sense clientversie 10.8470. De actuele versie check je op een testwerkstation met PowerShell. Dit controleert uitsluitend een lokale registrywaarde en wijzigt niets aan het systeem.

Get-ItemProperty -Path ‘Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status’ -Name ‘MsSenseDllVersion’ | Select-Object MsSenseDllVersion

Een goed sensornummer op één device bewijst niet dat het gehele netwerk klaar is. Maak daarom in je operationele inventaris een overzicht van onboarded devices, sensorversies en device groups die geen automatische acties toestaan. Dit klinkt klein, maar het heeft direct impact op je SOC proces.

3. Controleer de overige bronnen

Voor Microsoft Defender for Cloud Apps adviseert Microsoft de Microsoft 365 connector goed in te richten en ook Microsoft Entra ID apps mee te nemen. Voor Defender for Office 365 moeten mailboxes in Exchange Online staan en zijn relevante mailbox audit events nodig, waaronder MailItemsAccessed en UpdateInboxRules. Ontbrekende auditdekking leidt tot gaten in je verhaal. [4]

Controleer ten slotte RBAC voor SOC analisten. De persoon die een incident leest moet niet automatisch het recht hebben om accounts vrij te geven. Leg vast wie containment mag terugdraaien, wie de functionele eigenaar informeert en hoe je een fout-positief beoordeelt. Geef serviceaccounts, domeincontrollers en kritieke productieassets geen ondoordachte uitzonderingen. [3][4]

Praktisch onderzoek in Advanced Hunting

Stap 1. Ga van een phishingklik naar het originele bericht

Open Microsoft Defender portal, Hunting, Advanced hunting. De volgende query begint bij Safe Links klikken met een phishingverdict of een expliciete click-through. Daarna koppelt hij via NetworkMessageId de e-mailcontext uit EmailEvents. Een link is alleen geschikt als join sleutel bij ondersteunde e-mailscenario’s. Microsoft documenteert dat e-mails vanuit Drafts en Sent niet altijd dezelfde correlatie toelaten. [5][6]

let clicks = UrlClickEvents
| where Timestamp > ago(7d)
| where Workload == “Email”
| where ThreatTypes has “Phish” or IsClickedThrough == true
| project ClickTime=Timestamp, AccountUpn, NetworkMessageId,
          ClickedUrl=Url, ClickVerdict=ThreatTypes, IsClickedThrough;
clicks
| join kind=leftouter (
    EmailEvents
    | where Timestamp > ago(7d)
    | project NetworkMessageId, Subject, SenderFromAddress,
              RecipientEmailAddress, DeliveryAction, OriginalThreatTypes
) on NetworkMessageId
| project ClickTime, AccountUpn, Subject, SenderFromAddress,
          RecipientEmailAddress, ClickedUrl, ClickVerdict,
          IsClickedThrough, DeliveryAction, OriginalThreatTypes
| order by ClickTime desc

Bekijk niet alleen of de klik succesvol was. Leg de oorspronkelijke afleveractie, post-delivery acties en het daadwerkelijke risico naast elkaar. Een verdict verandert soms na aflevering. Daarvoor zijn DeliveryAction en OriginalThreatTypes interessant. Een URL die als phish is herkend, is niet automatisch bewijs dat credentials of tokens zijn buitgemaakt. Combineer daarom met identity en endpointcontext.

Stap 2. Bekijk aanmeldingen na de klik

Met een afzonderlijke query kun je verdacht gedrag rondom de gebruiker beoordelen. Gebruik de nieuwe naam EntraIdSignInEvents. Microsoft heeft de vervanging van AADSignInEventsBeta op 19 oktober 2026 aangekondigd. De tabel vereist Microsoft Entra ID P2 en de dataset kan per tenant verschillen. [7]

let account = “noor.vandijk@contoso.example”;
EntraIdSignInEvents
| where Timestamp > ago(7d)
| where AccountUpn =~ account
| project Timestamp, AccountUpn, IPAddress, Country,
          DeviceName, IsManaged, IsCompliant,
          RiskLevelDuringSignIn, RiskState, ErrorCode,
          Application, SessionId, UniqueTokenId
| order by Timestamp desc

Let op combinaties, niet op één veld. Een vreemd land kan verklaarbaar zijn door VPN en een unmanaged device is niet per definitie vijandig. Kijk naar afwijkingen in device compliance, session context, authenticatie, toegang tot resources en wijzigingen aan het account. Controleer zo nodig ook de sign-in logs in het Microsoft Entra admin center, Entra ID, Monitoring and health, Sign-in logs.

Stap 3. Bekijk of Defender werkelijk iets tegenhield

Dit is de nieuwe stap die ik belangrijk vind. Een alert kan verdwenen zijn terwijl de verdachte account nog probeert aan te melden op andere hosts. De tabel DisruptionAndResponseEvents biedt zicht op de resultaten van endpointcontroles. Je kunt ermee aantonen dat een SMB poging werd geblokkeerd, een RDP sessie is beëindigd of een policy op een client terechtkwam. [2]

DisruptionAndResponseEvents
| where Timestamp > ago(7d)
| where ReportType in (“Blocked”, “Prevented”, “PolicyUpdated”)
| project Timestamp, ActionType, ReportType, PolicyName,
          IsPolicyOn, SourceUserName, SourceDeviceName,
          TargetDeviceName, Service, SourceIpAddress,
          DeviceName, DataSources
| order by Timestamp desc

Lees ReportType zorgvuldig. Prevented betekent dat een actie volledig is tegengehouden voordat deze kon worden uitgevoerd. Blocked betekent dat een bestaande verbinding of sessie gedwongen werd beëindigd. PolicyUpdated toont een policyupdate, maar bewijst niet dat al het verdachte verkeer op dat moment is verdwenen. Ook IsPolicyOn beschrijft alleen de status op het moment van het event. [2]

Voor ons scenario wil ik vooral zien vanaf welke bronhost SMB en logon pogingen worden geblokkeerd. Gebruik de volgende aggregatie voor een snelle SOC triage, met het beleid en de aangevallen host als context. Ze is niet bedoeld als score voor de totale effectiviteit van de bescherming.

DisruptionAndResponseEvents
| where Timestamp > ago(7d)
| where ActionType in (
    “ContainedUserLogonBlocked”,
    “ContainedUserSmbFileOpenBlocked”,
    “ContainedUserSmbSessionStopped”,
    “ContainedUserRemoteDesktopSessionDisconnected”)
| summarize BlockedEvents=count(),
            FirstSeen=min(Timestamp), LastSeen=max(Timestamp),
            Actions=make_set(ActionType, 10),
            Services=make_set(Service, 10)
    by SourceUserName, SourceDeviceName, TargetDeviceName, PolicyName
| order by BlockedEvents desc

Een stijging in BlockedEvents na containment kan betekenen dat een aanvaller blijft proberen het netwerk te benaderen terwijl de policy werkt. Het is geen bewijs dat elk aanvalspad is afgedekt. Vergelijk de resultaten met endpointtelemetrie, identity logs en de actuele incidentstatus. De tabel toont niet de uitvoering van acties als Contain user of Disable user, maar de gevolgen van Defender for Endpoint controles. Voor de volledige historie van uitgevoerde acties moet je het Action center gebruiken. [2]

Stap 4. Filter de gebeurtenissen van predictive shielding

Dezelfde tabel bevat ook signalen die bij predictive shielding horen. De onderstaande query helpt als je wilt zien of beleid rond Safe Boot of Group Policy werd toegepast. Een resultaat zonder preventie-events is geen bewijs dat er geen aanval is; het vertelt alleen wat dit datatype heeft vastgelegd.

DisruptionAndResponseEvents
| where Timestamp > ago(14d)
| where ActionType in (
    “SafeBootBlocked”,
    “SafeBootGuardPolicyApplied”,
    “GroupPolicyAccessBlocked”,
    “GroupPolicyHardeningPolicyApplied”)
| project Timestamp, DeviceName, SourceDeviceName,
          ActionType, ReportType, PolicyName, IsPolicyOn
| order by Timestamp desc

Van query naar incidentbesluit

In een echt SOC wil je dat analisten vanuit de resultaten naar het incident kunnen teruggaan. Ga naar Incidents and alerts, Incidents. Zoek de incidenten met het label Attack Disruption. Open de incidentpagina en controleer de gele banner, de getroffen assets en de incidentgraph. Bij een ondersteunde tenant kun je op het tabblad Activities filteren op Provider, Attack disruption. De Policy status weergave is nog Preview. [3]

Ga vervolgens naar Actions and submissions, Action center, History. Hier controleer je welke automatische of handmatige acties daadwerkelijk zijn uitgevoerd en of er een Undo optie beschikbaar is. Bewaar het tijdstip, de actor en de reden van vrijgave in je ticket. Dat is belangrijker dan alleen een screenshot waarop het woord contained staat. [8]

Een bruikbaar beslismoment is: blijven er na containment pogingen zichtbaar vanaf hetzelfde account of device, zijn ze tegengehouden en bestaan er nog paden buiten onboarded endpoints? Als een kritieke fileserver niet is onboarded, kan een endpoint containment policy op die server geen bescherming afdwingen. Als een account toegang had tot SaaS bronnen, moet je daarnaast cloudtoegang, sessies en mailboxregels onderzoeken. Het SOC moet de aanvalsketen volledig beoordelen.

Bewijsvraag	Waar bewijs ophalen	Operationele actie
Wat startte het incident?	Incident story, EmailEvents, UrlClickEvents	Zet initiële tijdlijn vast
Welke identiteit is getroffen?	Entra sign-ins, identity alerts	Controleer sessies en bevoegdheden
Wat deed het endpoint?	Device timeline, proces- en netwerkgebeurtenissen	Scope laterale beweging
Wat heeft Defender uitgevoerd?	Action center, History	Audit en undo procedure beoordelen
Wat is aantoonbaar geblokkeerd?	DisruptionAndResponseEvents	Prevented en Blocked apart vastleggen
Is herstel verantwoord?	Nieuwe sign-ins, endpoint health, validatie eigenaar	Pas dan containment opheffen

Wat je niet moet doen bij herstel

Een veelvoorkomende fout is direct op Undo klikken zodra de gebruiker zijn laptop weer nodig heeft. Je hebt dan wel de symptomen verminderd, maar mogelijk niet de oorzaak weggenomen. Controleer of het account en het device opnieuw als betrouwbaar kunnen worden behandeld. Bij identity compromise horen onder andere sessie-intrekking waar van toepassing, accountherstel, wijziging van ongewenste mailboxregels, beoordeling van MFA methoden en onderzoek naar eventuele privilege escalation.

Bij een verdachte workstation kijk je naar de volledige process chain, persistence, verdachte scheduled tasks, netwerkverbindingen en device health. Herstel een device pas nadat de incident responder het heeft vrijgegeven. Denk ook aan de functional impact: een ingeperkt account kan niet meer normaal naar shares verbinden en gebruikers kunnen onverwachte foutmeldingen zien. Stem het terugdraaien af met de eigenaar en servicedesk.

Een andere fout is een KQL query als enige waarheid behandelen. Advanced Hunting is afhankelijk van datadekking, ingestietijden, licenties en bewaartermijnen. Het ontbreken van resultaten is geen bewijs dat een aanval niet heeft plaatsgevonden. Controleer bronstatus, tijdvenster, query filters, tijdzones en ondersteuningsstatus van de workload voordat je conclusies trekt.

Veelgemaakte fouten in de praktijk

Contain user verwarren met een volledige cloudblokkade

Contain user is in deze context endpointgerichte containment. Het helpt laterale beweging beperken via onboarded endpoints. Voor cloudtoegang, tokens en accounts zijn andere response acties en identity controles nodig. Denk dus in aanvalspaden en niet in een enkel knopje.

De preview van automatische device isolation als GA verkopen

De introductie in mei 2026 betekent niet dat alle tenants deze optie al als stabiele productievoorziening hebben. Controleer preview enrollment, device scope, uitzonderingen en service desk procedures. Scheid in documentatie duidelijk de bestaande containmenttechnieken van de preview automatische isolatie.

Beleidstoepassing verwarren met bewezen blokkade

PolicyUpdated is een nuttig signaal, maar wil je aantonen dat een SMB poging daadwerkelijk gestopt werd, dan zoek je naar geschikte blocked of prevented events. Koppel deze aan bron, doel en tijd. Gebruik het Action center om de daadwerkelijke response actie te bevestigen. [2]

Vergeten wie de policies weer uitschakelt

Zonder runbook blijven systemen soms langer beperkt dan nodig of worden ze juist te snel vrijgegeven. Leg vast wie eigenaar is van de actie, wie de zakelijke impact afweegt en wie na containment een nieuwe risicoanalyse uitvoert.

Zo test je dit veilig in een E5 demo tenant

Je hebt geen ransomware of misbruik van credentials nodig om dit proces te valideren. Gebruik een schoon Windows 11 testdevice, een testgebruiker zonder rechten op productieassets en vooraf gecontroleerde labdata. Controleer de aanwezigheid van de vereiste tabellen, auditlogboeken, portalrollen, sensorversies en device groups. Zet een testincident op vanuit beschikbare simulatie- of evaluatiemogelijkheden, zonder echte phishing naar medewerkers of ongeautoriseerde laterale beweging te genereren.

Test vooral het SOC runbook. Kan een analist in minder dan enkele minuten het incident vinden, relevante device en identity gegevens verzamelen en onderscheid maken tussen een uitgevoerde actie en een geblokkeerde vervolgactie? Kan dezelfde analist de juiste eigenaar waarschuwen? Kun je na afloop reconstrueren waarom containment werd geactiveerd en wie een vrijgave heeft geautoriseerd? Dat is een betere toets dan alleen kijken of er een Defender alert verschijnt.

Let op dat een simulatie niet vanzelf een automatic attack disruption trigger oplevert. De beschermingslogica vereist specifieke attack patterns en hoge confidence. Je kunt de benodigde detectiedekking en query’s dus afzonderlijk valideren, terwijl je live disruptiegedrag pas beoordeelt wanneer zich een passend test- of productie-incident voordoet. Gebruik geen onveilige aanvalsstappen om een model tot reactie te dwingen.

Mijn advies voor SOC teams

Begin niet met de previewfeatures, maar met operationele basisdekking. Zorg voor correcte onboarding, identiteitstelemetrie, juiste automation levels en een eigenaar voor het Action center. Daarna kun je DisruptionAndResponseEvents gebruiken om dashboards en hunts te bouwen rond geblokkeerde logons, SMB toegang en policy changes. Reserveer een aparte change en evaluatie voor automatische device isolation, inclusief uitsluitingen voor bedrijfskritische systemen.

Maak ook je incidentregistratie strakker. Leg niet alleen vast dat Defender XDR een aanval heeft onderbroken, maar welke entiteit getroffen was, welke acties zijn uitgevoerd, welk verkeer daarna daadwerkelijk is geblokkeerd, welke paden nog open stonden en hoe je herstel hebt gevalideerd. Zo bouw je bewijs op dat technisch klopt en voor een CISO ook uit te leggen is.

Mijn advies is om de eerste dertig dagen wekelijks vijf containmentincidenten of relevante testcases te reviewen. Kijk naar ontbrekende sensors, vals-positieve interpretatie van policy events en te late vrijgave. Daarmee verbeter je de meetbaarheid zonder op voorhand aan te nemen dat de machine altijd gelijk heeft.

Checklist voor je implementatie

• Defender for Endpoint is onboarded op de relevante werkstations en de devices melden health en events.
• De Sense client voldoet aan de minimumversie voor Contain user en device groups hebben bewuste automation levels.
• Defender for Identity heeft bruikbare sensor- en auditdekking op domain controllers, waar nodig.
• Exchange Online auditing en Defender for Office 365 zijn ingericht voor e-mailcorrelatie.
• De Microsoft 365 connector in Defender for Cloud Apps is gecontroleerd, inclusief Entra ID apps waar vereist.
• SOC analisten weten waar Incidents, Advanced Hunting en Action center staan.
• KQL queries voor phishingcontext, sign-ins en disruption events zijn getest op beschikbare tabellen.
• Previewfeatures staan in een apart besluitdocument met scope, risico’s en rollback.
• Een runbook beschrijft het vrijgeven van accounts en apparaten na forensische beoordeling.
• De evaluatie rapporteert apart over uitgevoerde acties, geblokkeerde vervolgacties en resterende risico’s.

Conclusie

De sterkste kant van Microsoft Defender XDR is niet dat het veel alerts maakt. Het is dat identity, e-mail en endpoint signalen bij elkaar komen, waarna het platform in ondersteunde scenario’s automatisch kan ingrijpen. In ons voorbeeld begint het bij een verdachte mail en eindigt het bij SMB blokkades die je kunt onderzoeken. Daarmee verschuift je SOC van alleen signaleren naar gecontroleerd beperken en aantoonbaar herstellen.

De nieuwe DisruptionAndResponseEvents tabel uit 2026 maakt de uitgevoerde blokkades veel concreter. Tegelijk moet je de grenzen kennen. De tabel is geen vervanging voor het Action center, automatic device isolation is nog preview en een goede query repareert geen ontbrekende dekking. Wie dat onderscheid begrijpt, kan Defender XDR beter inzetten en uitleggen waarom een incident onder controle is.

Volg ITCowboys voor de volgende technische deep dive. In de komende blogs pak ik meer Microsoft Security, XDR, Sentinel, Identity en Purview onderwerpen op vanuit de praktijk.