(Or, How Your On-Prem AD Has Been Lying to You (And He Already Knew))
We’ve built quite a cast of characters in this blog, haven’t we?
We’ve got the bouncer at the front door — Conditional Access, checking credentials and deciding who gets past the velvet rope. We’ve got Security Camera Guy upstairs, watching the monitors, eating his Subway sandwich, flagging anyone who looks at a door they shouldn’t. We’ve got the no-nonsense toolbox lady making sure nobody walks off with the chainsaw without signing for it. It’s a whole operation up there.
But there’s one character who hasn’t gotten his proper introduction yet.
He’s downstairs. He’s been down there the whole time, actually — working quietly in the basement, nosing through old filing cabinets, muttering to himself about service accounts, following footprints through hallways nobody else thinks to check. He used to be a detective. Good one, too. But the world changed, the cases got more complicated, and now he operates independently — a private investigator with a direct line to everyone upstairs and a very long memory.
His name is Microsoft Defender for Identity. And it’s past time we talked about what he actually does down there.
Wait — Didn’t We Already Meet Him?
Sort of. He got a cameo in the Risky Users post — a mention, a character sketch, a quick “and this guy watches the basement.” But that was the equivalent of a supporting actor credit. Today we’re talking about top billing.
Because here’s the thing: MDI is one of the most underutilized, underappreciated, and frankly under-explained products in the entire Microsoft security ecosystem. Organizations that have it deployed often aren’t getting half the value out of it. Organizations that don’t have it deployed often don’t fully understand what they’re missing. And the documentation — while technically complete — is the kind of thing that makes you want to pour yourself something and stare at the ceiling.
So let’s fix that. No documentation voice. No portal tour. Just a real explanation of what MDI is, what it watches, how it thinks, and why — if you’re running any kind of hybrid environment — it might be the most important product you’re not fully using.
So What IS Defender for Identity, Actually?
Microsoft Defender for Identity — MDI for short, formerly known as Azure Advanced Threat Protection, or Azure ATP, because Microsoft loves a good rebrand — is a cloud-based security solution that monitors your on-premises Active Directory environment for suspicious activity, threat indicators, and attacker behavior.
Note that phrase: on-premises Active Directory. This is the key distinction that a lot of people miss when they’re building out their Microsoft security stack. Entra ID Protection, Conditional Access, PIM — those are your cloud identity tools. They’re watching what happens in Azure, in Microsoft 365, in the cloud. They’re fantastic at what they do.
But most organizations — even the ones that have gone heavily cloud-first — still have on-prem AD. Legacy systems, domain-joined machines, service accounts running everything from your backup jobs to your line-of-business applications. On-prem AD is the boiler room of most hybrid environments. It keeps the lights on. It’s been running since before half your current employees were hired. And it is absolutely where attackers love to spend time once they’re inside your network, because it’s often where the crown jewels actually live — and where the monitoring is the thinnest.
MDI watches that environment. Specifically, it does this by deploying lightweight sensors directly on your domain controllers — not a standalone server, not a network tap, but a sensor right there on the DC, reading the event logs, analyzing the traffic, watching every authentication, every LDAP query, every Kerberos ticket request. It sees everything that crosses the domain controller.
That data gets shipped up to the Microsoft cloud, processed against a behavioral analytics engine and a library of known attack patterns, and surfaced as alerts — in the MDI portal, in Defender XDR, and in your SIEM if you’ve got one listening.
That’s the PI doing his rounds. Checking the logs. Noting the patterns. Watching the service corridors.
What Does He Actually Watch For?
This is where it gets interesting — and where MDI earns its keep.
Reconnaissance
Before an attacker makes a move, they look around. They want to know the layout of your environment — what accounts exist, what groups they belong to, which systems are domain controllers, what the trust relationships look like. In AD, this reconnaissance is often done through LDAP queries, DNS enumeration, and tools like BloodHound that map out the whole environment automatically.
MDI watches for this. Unusual LDAP queries. Accounts that suddenly start enumerating every user in the directory. DNS reconnaissance. Someone mapping your AD topology at 2 AM from a workstation that has no business doing so. The PI notices when someone new is walking the halls and writing things down.
Credential-Based Attacks
This is MDI’s bread and butter. Active Directory authentication is built on Kerberos and NTLM — protocols that were designed decades ago, in a very different threat environment, and that have well-known weaknesses that attackers actively exploit.
Kerberoasting? That’s when an attacker requests Kerberos service tickets for accounts with Service Principal Names set, takes those tickets offline, and cracks them to get the plaintext credentials. MDI sees the unusual service ticket requests. It knows which accounts get their tickets requested regularly and which ones suddenly light up on a Tuesday night from an account that’s never touched them before.
Pass-the-Hash and Pass-the-Ticket? These are attacks where an attacker captures credential hashes or Kerberos tickets from memory and uses them to authenticate without ever knowing the actual password. NTLM is particularly vulnerable here. MDI detects the anomalous NTLM usage patterns that these attacks generate — authentication attempts that don’t match the account’s normal behavior, ticket usage from unexpected sources, NTLM being used for resources that should be using Kerberos.
Brute force? The PI has a very low tolerance for someone standing at the door rattling the handle 400 times. MDI tracks failed authentication attempts and correlates them across your environment in ways that raw event logs don’t.
Lateral Movement
Here’s where MDI often catches things that nothing else does. Once an attacker has a foothold — even a low-privilege one — they move. They hop from system to system, gathering credentials, escalating privileges, working their way toward whatever they came for. This movement happens through AD. It generates authentication events, it touches domain controllers, it leaves fingerprints.
MDI watches those footprints. An account that normally authenticates to three systems suddenly authenticating to forty. Remote code execution techniques like pass-the-hash being used to move laterally. Accounts accessing resources they’ve never touched in their history. The PI doesn’t just watch the front door — he watches every door, and he has a very good memory for what normal looks like.
Privilege Escalation
The endgame in most AD attacks is Domain Admin. Or at least something close to it — an account with enough privilege to do real damage. MDI watches the paths attackers use to get there.
Skeleton Key malware — a technique that patches a domain controller’s LSASS process to accept a master password for any account — generates specific patterns that MDI detects. DCSync attacks, where an attacker replicates AD credentials by pretending to be a domain controller, are caught by MDI monitoring replication requests. Attempts to add accounts to privileged groups — Domain Admins, Enterprise Admins, the groups the no-nonsense toolbox lady keeps under lock and key — get flagged immediately.
Someone trying to sneak into Domain Admins at 2:03 AM? The PI is already on the phone.
Sensitive Account Monitoring
MDI specifically tracks your high-value accounts — the ones in privileged groups, the ones with access to sensitive resources, the service accounts running your critical infrastructure. It builds behavioral baselines for these accounts and raises alerts when their behavior deviates. Not just “this is suspicious” alerts — contextual alerts that tell you why it’s suspicious, what the account normally does, and what it’s doing differently right now.
Where Does He Fit in the Bigger Picture?
This is the part that makes MDI genuinely powerful rather than just another monitoring tool — it doesn’t work in isolation. It’s wired directly into the rest of the Microsoft security ecosystem.
MDI feeds its signals into Entra ID Protection, which means that what the PI finds in the basement directly informs the risk scores that Security Camera Guy is watching upstairs. A suspicious Kerberoasting attempt on-prem can raise the risk level of a user account in the cloud — which then triggers your Conditional Access policies, which means the bouncer at the front door suddenly gets a lot more skeptical about that account. The whole crew is talking to each other.
MDI surfaces in Defender XDR, which means your security team sees MDI alerts in the same place they see everything else — endpoint alerts, email threats, cloud app anomalies. XDR correlates MDI signals with signals from across the environment to build unified incident timelines. An attack that starts with a phishing email, moves to endpoint compromise, pivots to AD lateral movement, and escalates to Domain Admin — MDI is the piece that covers that middle-to-late stage. Without it, you’ve got a gap in your incident timeline right where attackers tend to do their most interesting work.
And MDI pipes into Sentinel if that’s your SIEM — which means your detection rules, your hunting queries, and your automation playbooks can all incorporate on-prem identity signals. The PI sends his case notes upstairs, and the whole team can act on them.
The One Thing Most People Get Wrong About MDI
They treat it as an on-prem tool.
MDI watches on-prem AD, yes. But the value of MDI is the bridge it builds between your on-prem environment and your cloud security posture. In a hybrid environment — which, let’s be honest, is most of us — attackers don’t think in terms of “cloud” and “on-prem.” They think in terms of “what can I reach from where I am.” They’ll use on-prem AD to get cloud credentials. They’ll use cloud access to pivot back on-prem. The attack surface doesn’t respect your architectural boundaries.
MDI is what gives you visibility into that hybrid attack surface. Not just “something weird happened in AD” — but “something weird happened in AD, here’s the account involved, here’s the cloud risk that’s now elevated as a result, here’s the full incident timeline, and here’s what we recommend you do about it.”
That’s not an on-prem tool. That’s your hybrid visibility layer.
What’s Coming Next
This is the introduction. The PI has officially gotten his close-up.
Next time, we’re going to walk through what a real credential-based attack actually looks like through MDI’s eyes — the specific alerts, the timeline, the detections, and the places where MDI catches something that nothing else would have. We’ll also talk honestly about the gaps — because no tool catches everything, and knowing where your blind spots are is half the battle.
The PI has been working the basement for a long time. He’s got case files.
Let’s open them.
Questions about MDI deployment, sensor configuration, or how to get it talking to the rest of your Defender stack? Drop them in the comments — happy to dig in.
Xenodyne Technologies 
Leave a comment