(Or, How Your Domain Controller Became the World’s Best Surveillance Camera (And Nobody Told the Attacker))
Last time, we introduced our grizzled PI properly. We talked about what he watches, how he thinks, where he fits in the ecosystem, and why hybrid environments need him in the basement whether they know it or not.
Today, he works a case.
We’re going to walk through a realistic credential-based attack – the kind that happens in real environments, against real organizations, on perfectly ordinary Tuesday nights – and watch MDI catch it. Step by step. Alert by alert. We’ll talk about what the analyst sees, what the portal surfaces, and where the PI picks up the scent.
And then – because this is where most content chickens out – we’re going to talk about where he doesn’t catch it cleanly. The gaps. The blind spots. The places where you need to be paying attention even when the alerts aren’t firing.
Ready? Let’s open the case file.
Setting the Scene
Before we start, a quick note on what we’re not covering: how the attacker got in. That’s a different story – phishing, credential stuffing, a compromised vendor account, a reused password from a breach database. The initial access vector matters, but it’s not MDI’s territory. MDI’s territory starts the moment an attacker has a foothold and starts moving.
Our attacker – let’s call him Kevin, because every organization has a Kevin-shaped problem somewhere – has compromised a low-privilege domain account. Maybe it’s a helpdesk user. Maybe it’s a service account with a password that hasn’t been changed since the Obama administration. Either way, Kevin is in. He’s got credentials. He’s authenticated to the domain.
And he has no idea the PI is already watching.
Stage 1 – Reconnaissance: Kevin Gets His Bearings
The first thing any competent attacker does after getting a foothold is look around. They want to know the layout – what’s in the environment, who the privileged accounts are, which systems are domain controllers, what the trust relationships look like. In Active Directory, this is called reconnaissance, and it generates a very specific kind of noise.
Kevin fires up a tool. Maybe it’s BloodHound – the open-source AD mapping tool that’s become standard equipment for attackers and red teamers alike. Maybe it’s a PowerShell script doing LDAP queries against the directory. Maybe it’s something simpler. Whatever it is, it starts pulling data – enumerating users, groups, computers, permissions, paths to Domain Admin.
What MDI sees:
MDI is watching every LDAP query that crosses the domain controller. It knows what normal looks like for every account in the environment – which accounts query the directory, how often, and what they’re asking for. A helpdesk account that suddenly issues hundreds of LDAP queries enumerating every user, group, and computer object in the directory is not normal. Not even a little.
MDI fires an alert: Reconnaissance using LDAP queries. It identifies the source account, the source machine, the volume of queries, and the timeframe. It maps this against the account’s historical baseline – Kevin’s compromised helpdesk account has never done anything like this before.
The PI has made Kevin immediately. Kevin doesn’t know this yet. Kevin is feeling pretty good about himself.
Stage 2 – Kerberoasting: Kevin Goes Fishing for Service Accounts
Kevin reviews his BloodHound output. He’s looking for service accounts – accounts with Service Principal Names (SPNs) set, which means they’re running services and are eligible for Kerberos service ticket requests. Service accounts are attractive targets because they often have elevated privileges, they’re frequently overlooked in password hygiene programs, and their passwords are sometimes… let’s say vintage.
Kevin requests Kerberos service tickets for every SPN-enabled account he can find. He’s not trying to use those tickets right now – he’s going to take them offline and crack them. If any of those service accounts have weak passwords, he’ll have plaintext credentials in minutes. This is Kerberoasting, and it’s one of the most common techniques in real-world AD attacks.
What MDI sees:
MDI tracks Kerberos ticket requests across the environment. It knows which accounts get their service tickets requested regularly as part of normal operations, and which ones are sitting quietly. When Kevin requests tickets for a dozen service accounts in rapid succession – accounts that haven’t had their tickets requested in weeks or months – that’s an anomaly. A significant one.
MDI fires an alert: Suspected Kerberos SPN enumeration. The alert identifies the requesting account, the accounts being targeted, the volume and velocity of requests, and flags the behavior as consistent with Kerberoasting reconnaissance.
Now, MDI can’t tell Kevin’s password cracking is going to succeed – that happens offline, away from the domain controller’s eyes. This is one of the gaps we’ll come back to. But it’s flagged the behavior. The PI has noted that someone is pulling files from the cabinet labeled “Service Account Credentials” and taking them outside.
Stage 3 – Lateral Movement: Kevin Goes Exploring
Let’s say Kevin got lucky. One of those service accounts had a password that cracked in four minutes. It’s a SQL service account – not Domain Admin, but it has local admin rights on several servers. Kevin has new credentials and a new set of doors to try.
He starts moving. Using Pass-the-Hash – a technique that lets him authenticate using the credential hash rather than the plaintext password – Kevin begins authenticating to systems he’s identified as interesting. A file server here. A backup server there. He’s looking for more credentials, more access, a path upward.
What MDI sees:
This is where MDI’s behavioral baseline work really pays off. The SQL service account Kevin is using has a history – it authenticates to specific systems, at specific times, in specific ways. It does not, under any normal circumstances, authenticate to fourteen different servers in twenty minutes using NTLM from a workstation it’s never touched.
MDI fires multiple alerts here:
Suspected identity theft using Pass-the-Hash attack – MDI detects the anomalous NTLM authentication pattern, the mismatch between the account’s normal authentication behavior and what’s happening now, and the source machine (Kevin’s initial foothold workstation) making authentications that don’t fit the account’s profile.
Lateral movement using remote execution – as Kevin uses his access to run commands on remote systems, MDI flags the remote execution attempts, correlating them with the authentication anomalies already detected.
At this point, if your Sentinel or XDR automation is configured correctly, a playbook should be firing. The PI has radioed upstairs. Security Camera Guy is paying attention. The bouncer is getting nervous.
The question is whether anyone is watching the board.
Stage 4 – Privilege Escalation: Kevin Gets Ambitious
Kevin has been exploring. He’s found something interesting on one of the servers he’s accessed – cached credentials for an account with significantly higher privileges. Maybe a Domain Admin who logged into that server for routine maintenance and whose credentials are sitting in memory. Kevin extracts them.
Now he’s playing for keeps.
With Domain Admin credentials – or something close to it – Kevin has options. He could create a backdoor account. He could modify group policies. He could run a DCSync attack, replicating all the credential hashes in the directory and taking them offline. Or – if he’s feeling theatrical – he could deploy Skeleton Key malware, patching the domain controller’s LSASS process to accept a master password for any account in the domain.
Kevin goes for DCSync. He pretends to be a domain controller and requests replication of the AD database. It’s quiet, it’s fast, and if successful, he walks away with every credential hash in the environment.
What MDI sees:
DCSync is one of MDI’s strongest detection areas. MDI watches replication traffic between domain controllers very carefully. When a non-domain-controller account – even one with Domain Admin privileges – starts issuing directory replication requests, that is immediately and specifically flagged.
MDI fires an alert: Suspected DCSync attack (replication of directory services). This is a high-severity alert. It identifies the account making the replication request, the source machine, the specific replication calls being made, and flags it explicitly as a credential harvesting technique.
If the Skeleton Key path had been taken instead, MDI would have caught that too – it monitors domain controller process behavior and detects the specific memory modification pattern that Skeleton Key uses. The PI knows what a lockpick sounds like.
The Full Picture: What the Incident Looks Like in XDR
Here’s where the integration story from Post 1 pays off in practice.
In Defender XDR, all of these alerts – the LDAP reconnaissance, the Kerberoasting, the Pass-the-Hash lateral movement, the DCSync attempt – don’t appear as five separate alerts requiring five separate investigations. XDR correlates them into a single incident. One unified timeline. One attack story, told from beginning to end.
That timeline tells you: this started with a compromised helpdesk account doing LDAP reconnaissance at 11:47 PM. It moved to Kerberoasting at 11:52. The service account’s credentials were used for lateral movement starting at 12:14 AM. DCSync was attempted at 1:03 AM.
You can see the whole story. You know exactly which accounts are involved, which machines were touched, and what the attacker was trying to accomplish. That’s not just detection – that’s investigation, handed to you mostly pre-assembled.
Now compare that to what you’d have without MDI: some NTLM authentication events in your SIEM, maybe a Defender for Endpoint alert on the lateral movement if you caught it at the endpoint level, and a DCSync attempt that might have appeared as a routine replication event if nobody was specifically watching for it. A collection of puzzle pieces with no picture on the box.
MDI is the picture on the box.
Now For the Part Nobody Else Writes: The Gaps
MDI is excellent. It is not magic. Here’s where it doesn’t catch things cleanly – and what you do about it.
The offline gap. When Kevin took those Kerberos service tickets offline to crack them, MDI couldn’t follow him there. It flagged the ticket requests. It cannot tell you whether the cracking succeeded. If Kevin’s service account had a strong password, MDI’s Kerberoasting alert was the end of that thread. If it was weak, the next thing MDI sees is the successful authentication – by which point Kevin already has what he wanted. The mitigation here isn’t MDI tuning – it’s fixing your service account password hygiene and monitoring for Managed Service Accounts wherever possible.
The living-off-the-land gap. MDI is excellent at detecting known attack tools and techniques. It’s less reliable when an attacker is using only built-in Windows tools – WMI, PowerShell, native AD administration commands – in ways that superficially resemble legitimate administrative activity. A sufficiently patient attacker who moves slowly and mimics normal admin behavior can generate less obvious signals. This is where your Defender for Endpoint behavioral detection and your Sentinel hunting queries need to pick up the slack.
The initial access gap. As mentioned up front – MDI doesn’t cover how Kevin got in. Phishing, credential stuffing, a compromised vendor – that’s Defender for Office 365, Entra ID Protection, and Conditional Access territory. MDI picks up the story once Kevin has AD access. Make sure the earlier chapters of that story are also being watched.
The tuning gap. Out of the box, MDI generates a learning period before it starts firing behavioral alerts – typically around 30 days for a new deployment, while it establishes baselines. During that period, some detections are limited. Plan your deployment timing accordingly, and don’t panic at the volume of alerts in the first few weeks. Tuning the alert thresholds and exclusions for legitimate administrative activity in your environment is real work that needs real attention. We’ll cover that in a future post.
The coverage gap. MDI sensors need to be on your domain controllers. All of them. Every DC that doesn’t have an MDI sensor is a blind spot – an attacker who knows your environment well enough can potentially route authentication through a DC without a sensor. Audit your sensor deployment regularly. It sounds obvious. It gets overlooked more than it should.
What This Means for Your Environment
Kevin had a bad night. Not because the attack was unsophisticated – it wasn’t. Kerberoasting, Pass-the-Hash, and DCSync are real techniques used in real attacks against real organizations right now. Kevin had a bad night because every move he made was watched, logged, correlated, and surfaced in a unified incident that told the whole story.
That’s what a properly deployed MDI gives you in a hybrid environment. Not perfect coverage – nothing gives you that. But coverage of the specific techniques that attackers use against AD, in the places where those techniques actually happen, correlated with the rest of your security stack into something an analyst can actually work with.
The PI worked the case. He got the timeline. He named the accounts, the machines, the techniques, and the sequence. He handed the case file upstairs with a neat bow on it.
What happens next is up to you – and we’ll talk about automation, response playbooks, and how to make sure the right things happen automatically when the PI calls it in. That’s a future post.
For now: if you’ve got MDI deployed, go look at your incidents view. Look at what’s correlating. Look at what your service accounts are doing. Look at whether your sensors are on every domain controller.
And if you don’t have MDI deployed yet, well… The PI’s been waiting in the basement. Time to introduce yourself.
Got questions about MDI alert tuning, sensor deployment, or what a DCSync alert actually looks like in your environment? Drop them in the comments – always happy to dig into specifics.
Xenodyne Technologies 
Leave a comment