(Or: How to Make Sure Kevin Has a Very Bad Night Even When You’re Asleep)
Kevin had a rough Post 2.
He got flagged at reconnaissance. He got flagged at Kerberoasting. He got flagged at lateral movement. He got flagged at DCSync. The PI was on him the whole time, building the case file, correlating the timeline, surfacing the full incident in Defender XDR with a neat bow on it.
And then – and here’s the part that should make you a little uncomfortable – the alerts sat there.
Not because the detection failed. The detection was perfect. But it was 1:17 AM on a Wednesday, and nobody was watching the board. The SOC analyst on call had seventeen other alerts in the queue. The incident was sitting in XDR, correctly identified, correctly correlated, correctly prioritized – and Kevin had another forty-five minutes to work before anyone touched it.
This is the gap that automation closes. And it’s the conversation most MDI content never gets around to having.
Detection Is Not Response
Let’s say this clearly, because it gets glossed over constantly: detection and response are not the same thing. A beautifully tuned MDI deployment that surfaces every attack technique Kevin throws at your environment is genuinely valuable – and completely insufficient on its own if nothing happens when the alerts fire.
The goal isn’t just to know Kevin was there. The goal is to make sure Kevin’s attack fails, his access gets cut, and your environment is protected – whether it’s 2 PM on a Tuesday with a full SOC watching the board, or 1 AM on a holiday weekend when the on-call analyst is juggling four other things.
That’s what this post is about. Three layers of automated response, how they work together, and – critically – the honest conversation about when not to automate, because nothing will erode trust in your security program faster than an automation that disabled the wrong account at the wrong time for the wrong reason.
Let’s build the response stack.
Layer 1 – XDR Automated Response: The Bouncer Gets a Radio
The first and most immediate layer of automated response lives in Defender XDR itself. When MDI fires a high-severity alert – your DCSync attempt, your Pass-the-Hash lateral movement, your Skeleton Key detection – XDR can take automatic response actions without waiting for a human to approve them.
The key actions available at this layer:
Disable user account. When a high-confidence, high-severity alert fires against a specific account, XDR can automatically disable that account in Active Directory. Kevin’s compromised service account? Gone. Not “flagged for review.” Not “alert sent to analyst.” Disabled. The access is cut at the source while the investigation is still spinning up.
Force password reset. For scenarios where disabling the account entirely is too disruptive – we’ll come back to this – XDR can force a password reset, invalidating whatever credentials Kevin has in hand and requiring the legitimate account owner to re-authenticate with a new password.
Isolate endpoint. When lateral movement is detected from a specific machine, Defender for Endpoint can isolate that machine from the network – cutting it off from everything except the Defender management channel – while the investigation proceeds. Kevin’s foothold machine goes dark.
These are the bouncer’s automatic responses. The PI radios down: “Compromised account, high confidence, DCSync attempt.” The bouncer doesn’t wait to be told what to do. He knows.
Setting up automated response in XDR:
In Defender XDR, go to Settings → Microsoft Defender XDR → Automated investigation and response. You’ll see automation levels ranging from “No automated response” to “Full – remediate threats automatically.” For MDI-sourced alerts on high-severity identity threats, Full automation on confirmed high-confidence detections is defensible – with the caveats we’ll discuss shortly.
The key setting to understand is the automation level per device group and identity – you can set different automation levels for different populations. Full automation for your standard user accounts. Semi-automation – where XDR takes the action but notifies an analyst first – for your privileged accounts and service accounts, where an automatic disable could have downstream consequences you need to be aware of.
Layer 2 – Conditional Access as Automated Enforcement: The Ecosystem Wakes Up
This is the layer that most organizations have the pieces for and aren’t fully using – and it’s arguably the most elegant part of the whole response stack.
Remember how we talked about MDI feeding risk signals into Entra ID Protection? And how Entra ID Protection feeds those risk scores into Conditional Access? This is where that plumbing pays off in a response context.
When MDI raises a high-risk alert against a user account, that risk elevation propagates to Entra ID Protection – often within minutes. And if your Conditional Access policies are configured correctly, that risk elevation automatically triggers a response at the access layer:
For medium-risk users: Require step-up MFA on next sign-in. Kevin’s compromised account can’t authenticate without a second factor that Kevin doesn’t have.
For high-risk users: Block access entirely until the risk is remediated, or require a password reset with MFA before access is restored. The account is effectively suspended from cloud resource access while the on-prem incident is being handled.
For risky sign-ins in real time: Conditional Access evaluates sign-in risk at authentication time – so even if MDI raises a risk signal during an active session, the next authentication attempt from that account hits a wall.
This is the bouncer and Security Camera Guy working in concert, automatically, without a human in the loop. The PI finds something. The risk score goes up. The bouncer gets the update and starts asking harder questions – or stops letting that account through the door entirely.
The thing I want to emphasize here: this layer is free if you’ve already got the pieces deployed. MDI, Entra ID Protection, and Conditional Access are all part of the Microsoft security stack you’re likely already paying for. The integration is built in. What it requires is configuration – policies that actually act on risk signals rather than just logging them.
If your Conditional Access policy for high-risk users is set to “Report only,” you have a very expensive notification system. Turn it on.
Layer 3 – Sentinel Playbooks: The Complex Stuff at Machine Speed
Layers 1 and 2 handle the immediate response – cut the access, block the authentication, isolate the machine. Layer 3 handles everything else: the notifications, the ticketing, the escalations, the multi-step workflows that need to happen in sequence and need to happen fast regardless of what time it is.
This is Microsoft Sentinel’s automation layer – Logic Apps-based playbooks triggered by Sentinel incidents or alerts. And when it’s built well, it’s the difference between “we contained the incident in forty minutes” and “we contained the incident in four.”
What a mature MDI response playbook looks like:
When a high-severity MDI incident hits Sentinel – let’s say our full Kevin scenario, the correlated incident with reconnaissance through DCSync – here’s what a well-built playbook does automatically, in sequence, without human intervention:
- Enriches the incident. Pulls additional context on the accounts and machines involved – when the account was created, what groups it belongs to, what its recent sign-in history looks like, whether it’s shown up in any previous incidents. Analyst walks in and the groundwork is already done.
- Notifies the right people. Posts a formatted incident summary to the SOC Teams channel or sends a PagerDuty alert to the on-call analyst. Not a generic “you have a new alert” ping – a structured summary with the account names, the attack chain, the severity, and a direct link to the XDR incident. Someone wakes up knowing exactly what they’re looking at.
- Opens a ticket. Creates an incident in your ITSM platform – ServiceNow, Jira, whatever you’re running – with the incident details pre-populated. No manual ticket creation at 1 AM. No information lost in translation between the alert and the ticket.
- Confirms or supplements the XDR response. If XDR has already disabled the account, the playbook logs that action in the ticket and notifies the account owner’s manager. If XDR is set to semi-automated for this account type, the playbook can present an approval workflow – one click to confirm the account disable – to the on-call analyst directly in Teams.
- Kicks off the investigation checklist. Posts a structured set of investigation steps to the incident channel – what to look at, what to confirm, what to rule out. Your junior analysts have a roadmap. Your senior analysts have a starting point that’s already half-complete.
Building this playbook isn’t a weekend project – a mature version takes real effort and iteration. But the bones of it are achievable with the built-in Sentinel playbook templates Microsoft provides, and each component you add compounds the value. Start with the notification. Add the ticketing. Layer in the enrichment. The automation doesn’t have to be perfect on day one to be dramatically better than nothing.
Now For the Honest Conversation: When NOT to Automate
Here it is. The part that gets skipped.
Full automation on high-severity alerts sounds great until you’ve experienced the 6 AM Monday call from an executive whose account was automatically disabled because they authenticated from an airport lounge in a city they’d never logged in from before. Or the service account that got auto-disabled because MDI flagged unusual behavior – and it turned out the “unusual behavior” was a legitimate, authorized infrastructure change that nobody thought to communicate to the security team first. Or the domain controller isolation that triggered during a Defender for Endpoint false positive and took a critical system offline during business hours.
These things happen. They happen to good security teams with good intentions and well-configured tools. And when they happen, the blowback isn’t just operational – it’s political. Leadership starts asking questions about whether the automation can be trusted. The “just turn it off” conversation starts. You spend more time defending the tool than using it.
So here’s the framework I’d recommend for thinking about automation levels:
Automate fully on:
- High-confidence, high-severity detections with low false-positive rates – DCSync, Skeleton Key, Golden Ticket attacks. These are not ambiguous. If MDI fires a confirmed DCSync alert, something real is happening. Automatic account disable is the right call.
- Endpoint isolation for confirmed lateral movement. The machine is a crime scene. Isolate it.
- Risk-based Conditional Access enforcement. Let the policy layer do its job – that’s what it’s designed for.
Automate with human-in-the-loop on:
- Privileged account actions. Automatically disabling a Global Admin or a critical service account can cascade into production outages. Semi-automated – take the recommended action, notify an analyst, require a one-click confirmation – is the right balance.
- Alerts that have historically generated false positives in your environment. Every environment is different. If a specific MDI detection type regularly fires on legitimate activity in your org, full automation on that detection is a liability until you’ve tuned it. Alert-and-notify while you work the tuning problem.
- Anything that touches regulated or validated systems. In GxP environments, automated changes to systems in scope for validation can have compliance implications. Know your boundaries before you automate across them.
Don’t automate (yet) on:
- New detections you haven’t validated in your environment. The 30-day learning period exists for a reason. Let MDI build its baselines, review the early alerts manually, understand what normal looks like in your specific environment before you let automation act on it.
- Low-confidence detections. MDI’s alert confidence levels exist for a reason. A low-confidence reconnaissance alert might be Kevin. It might also be your IT admin running an authorized AD audit. Automate on high confidence. Investigate on low.
The goal is a response stack that moves at machine speed on the things you’re certain about, and moves at human speed on the things that need judgment. Getting that balance right takes iteration – and it’s a moving target as your environment changes and your detection library matures.
Which brings us neatly to Post 4.
The Setup: Tuning, False Positives, and the Art of Making MDI Actually Livable
Because here’s the thing nobody tells you when you first deploy MDI: the first few weeks are loud.
Behavioral baselines are still forming. Exclusions for legitimate administrative activity haven’t been dialed in yet. Detections that are technically correct are firing on things your environment considers normal. Analysts are getting paged for events that turn out to be routine, and the credibility of the whole system is on the line.
This isn’t a MDI failure. This is MDI working exactly as designed – and it’s a phase every deployment goes through. The difference between organizations that come out the other side with a well-tuned, trusted detection system and organizations that quietly turn the alerts down to “low” and forget about them is whether they treat that initial noise as a problem to be solved or a reason to give up.
That’s the Post 4 story. How to tune MDI for your environment, how to build and manage exclusions properly without creating blind spots, how to evaluate false positive rates, and how to build analyst confidence in the system over time.
The PI is excellent at his job. But even the best PI needs to know which buildings to skip on his rounds – and which doors have already been checked.
We’ll get there.
Running Sentinel playbooks against MDI alerts? Built an automation that saved you or burned you? Drop it in the comments – always good to compare notes with people who’ve actually been through it.
Xenodyne Technologies 
Leave a comment