Microsoft Defender for Identity - Simply Explained

What happens when an attacker steals a legitimate password instead of breaking in through a firewall? I'm your host, Mirko Peters, and today we're talking about Microsoft Defender for Identity. Most security tools focus on the perimeter. They watch for malware, suspicious files, unusual network traffic, but identity attacks skip all of that entirely. An attacker with a stolen password doesn't need to break in. They just log in, and from the outside everything looks normal. By the end of this episode, you'll understand what Microsoft Defender for Identity actually is, why it exists, and how it watches for threats that traditional security tools completely miss. Let's start with why identity security has become the new battleground. The identity security problem. 20 years ago, securing a network meant locking down the building, you set up a firewall, ran antivirus on every machine, and advised everyone to use strong passwords. That worked pretty well back then because attackers had to break through your defences to get in. They needed to find a vulnerability, exploit it, and then move around inside your network. The perimeter was the wall and the wall was strong, but here's the thing. That approach doesn't work anymore. Attackers don't break in, they just log in, they scoop up a legitimate password through phishing, a data breach, or a simple guess, and then stroll right through the front door. Compromised credentials are now behind 79% of ransomware attacks. That's not a niche problem. That's the main way attackers get in. And the numbers are serious. 70% of organizations experienced at least one identity-related security breach in 2025. The average recovery cost, 1.64 million, that's not just the ransom payment. It's downtime, forensic investigation, legal fees, regulatory fines, and reputational damage. For mid-sized organizations, the median cost is still $750,000. So this isn't a theoretical risk. It's happening everywhere. Here's the core problem. Traditional security tools watch for malware, suspicious files, and unusual network connections. But they don't understand user behavior. They don't know if a login is normal or suspicious. An attacker with a stolen password looks exactly like a legitimate user. The same username, the same password, the same authentication process. The only difference is intent. And unless you're watching for abnormal patterns of behavior, you won't see it until it's too late. This is the gap that Defender for Identity was built to fill. It watches the watches. It monitors your identity infrastructure, learns what normal looks like for each user and device, and flags anything that doesn't fit. It's not looking for malware. It's looking for behavior that doesn't make sense. So what exactly is Defender for Identity? And how does it work? What is Defender for Identity? Here's the simplest definition. Microsoft Defender for Identity is a cloud-based security tool that watches your on-premises active directory for identity-based attacks. Notice I didn't say "entry" that's a common point of confusion. Defender for Identity focuses on your on-premises identity infrastructure, including domain controllers, active directory, and ADFS servers. This is the stuff that lives in your own data center or on your own servers. It's not a cloud-only solution. Now, how does it work? It uses behavioral analytics. It learns what's normal for each user and each device, and then it flags anything unusual. Think of it like a security guard who knows every employee's routine. They know who comes in at 8am, who works late, and who accesses the server room. When someone shows up at 3am trying to open the server room door, the guard notices immediately. That's exactly what Defender for Identity does, but for your digital environment. Let's clear up what this tool is not. It's not antivirus. It's not a firewall. It's not a patch management solution. It's identity-threat detection, a completely different category. It's not looking for malicious files. It's looking for malicious behavior. And that distinction matters because the most dangerous attacks today don't use malware at all. They use legitimate credentials. Defender for Identity sits inside Microsoft Defender XDR, which is Microsoft's extended detection and response platform. In practice, that means it shares signals with Defender for Endpoint, Defender for Office 365, and Microsoft Sentinel. So when Defender for Identity detects a suspicious login on a domain controller, it can cross-reference that with a phishing email detected by Defender for Office 365, or a suspicious process on a user's laptop detected by Defender for Endpoint. The real value isn't any single alert. It's how these tools work together to tell the full story of an attack. A single alert might look like a false positive, but when you see the whole picture, including the phishing email, the compromised credentials and the lateral movement, you know exactly what happened. Let's open the hood and look at how it actually detects threats. How it works, sensors and behavioral analytics. Defender for Identity uses lightweight sensors installed on your domain controllers. That's the key piece of the puzzle. Without the sensor, nothing happens. The sensor captures the data and is designed to be as unobtrusive as possible, running quietly in the background, reading network traffic and Windows events without slowing down your domain controller. Think of these sensors as the eyes and ears of the system. They capture three main types of information, network traffic to see authentication requests, flowing between machines, Windows events to see what's happening at the operating system level, and authentication activity to see who's logging in from where and when. All of that data gets sent to the Defender for Identity Cloud Service for Analysis. The sensor doesn't do the heavy lifting itself, it just collects and forwards. Once the data reaches the cloud, the real work begins. The Cloud Service builds a baseline profile for every single user in your environment. It learns their typical login times, which workstations they usually use, and what resources they normally access. This is the behavioral analytics part. The system doesn't come with pre-configured rules about what's normal. It learns from your actual environment, and that's important because normal looks different for every organization, when something deviates from that baseline, and alert fires. For example, a user who always logs in from 9 a.m. to 5 p.m. suddenly authenticates at 3 a.m. from a workstation they've never used before. That's a deviation. The system flags it. It doesn't assume it's malicious right away, but it raises the alert so your security team can investigate. What kinds of attacks does it actually detect? The list is long, but here are the big ones. Pass the hash attacks, where an attacker steals a password hash and uses it to authenticate. Kerberoasting, where an attacker requests service tickets for privileged accounts and cracks them offline. Golden ticket usage, where an attacker forges a Kerberoast ticket to gain domain-wide access. DC sync attacks, where an attacker pretends to be a domain controller and requests password hashes. And lateral movement, where an attacker uses one compromised account to hop from machine to machine. Each detection is mapped to the Miter attack framework, which is the industry standard for describing attack techniques. So when defender for identity flags something, it doesn't just say suspicious activity. It says, "This is a pass the hash attack, mapped to technique T-Fun Feen 50 on 0.0.2." That gives your security team immediate context about what they're dealing with and how to respond. Here's the real difference. It doesn't just tell you something happened, it shows you the attack timeline. It traces how the attacker moved from point A to point B. So instead of a single alert that says, "Suspicious login," you get a full story. The initial compromise, the lateral movement, the privilege escalation and the domain dominance all connected in a single timeline. That's the difference between a tool that alerts you and a tool that helps you understand. Let's walk through the stages of an attack and see where defender for identity catches each one. The attack lifecycle it catches. So attackers follow a predictable pattern. It's not random at all. They go through stages, and each stage has a specific goal. The stages are reconnaissance, compromised credentials, lateral movement, and domain dominance. Once you understand these stages, you'll see exactly where defender for identity fits in. But what does that actually look like? Let's start with reconnaissance. The attacker has no access yet. They're just looking around, scanning your network, searching for accounts, groups, and trust relationships. They're trying to figure out who the administrators are, which accounts have elevated privileges and how the domain is structured. They often use tools like Bloodhound to map out the environment. Defender for identity spots this by watching for suspicious LDP queries or enumeration attempts. An alert fires when someone starts querying for all domain admin accounts from a workstation that's never done that before. The attacker hasn't done anything harmful yet, but you know they're looking. Next up is compromised credentials. The attacker has found a way to get a password through phishing, a data breach, or buying it on the dark web. Now they have a legitimate username and password. Defender for identity flags, unusual logins at this stage. Unusual logins include a user signing in from a new location at 3am, or suddenly accessing hundreds of files instead of their usual five. These are behavioral deviations that don't require malware detection. They just require understanding what normal looks like. Then comes lateral movement. The attacker has a foothold, but it's probably not a privileged account yet. They need to move across your network to reach high-value targets. They use techniques like Pass the hash, Pass the ticket, and overpass the hash to hop from machine to machine. Each hop looks like a legitimate authentication, but the pattern is suspicious. Defender for identity detects this by watching for authentication anomalies. If a user account authenticates from three different workstations in five minutes, that's not normal human behavior. That's an attacker moving laterally. Finally, domain dominance. What you see, alerts, incidents, and taking action, open the Microsoft Defender Portal at Security, Microsoft.com and navigate to identities. That's your command center. The first thing you'll see is the dashboard, which gives you a quick overview of everything happening in your identity environment. How many users are being monitored, how many active alerts are open, and the health status of your sensors. It's designed to give you a snapshot in seconds, not minutes. There's also a score on that dashboard called the Identity Security Score. It's a zero to 100 number that shows how well you're protecting your identity infrastructure. This isn't a theoretical metric. It's based on actual configurations and recommendations. If you have domain controllers without sensors, your score drops. If you have users without multi-factor authentication, your score drops. Fix those issues, and your score goes up. It's a concrete way to track your security posture over time. Now, let's talk about alerts. Alerts are generated by detection rules. Pre-configured conditions that define what suspicious behavior looks like. Based on years of threat research, Microsoft has built hundreds of these rules. When a user logs in from an unusual location, that's a detection rule. When someone tries a DC sync attack, that's a detection rule. When an attacker uses a golden ticket, that's a detection rule. The system is constantly comparing what's happening in your environment against these rules. But here's the thing, multiple alerts can combine into a single incident. That's important because attackers don't do one suspicious thing. They do many things in sequence. A single alert might look like a false positive, but when you see the full incident, the reconnaissance, the credential compromise, the lateral movement, the domain dominance, you know exactly what happened. The incident is the story. The alerts are just individual sentences. Each incident includes an attack graph. This is a visual map of how the attacker moved through your environment. It shows you the starting point, every hop along the way, and the final destination. You can see which accounts were compromised, which machines were accessed, and which techniques were used. It's like watching a security camera replay of the entire attack, but in diagram form, and you can take action directly from the portal. If you identify a compromised user account, you don't need to log into your domain controller to disable it. You can do it right from the Defender portal, disable the account, force a password reset, request a sign in attempt, the sensor communicates back to your on-premises active directory, and makes the change instantly. That's the power of having the sensor on your domain controller. It's not just listening, it can act. You can also configure email notifications. When a critical alert fires, your security team gets an email instantly. They don't have to monitor the dashboard 24/7, the system alerts them. And because the alerts are mapped to the Miter ATTANK framework, they know exactly what kind of attack they're dealing with before they even open the portal. Beyond the basics, there are a few advanced features worth knowing about. Honeypots, tagging, and exclusions. Let's talk about Honeypots accounts. These are also called Honey tokens, and they're exactly what they sound like. Fake user accounts, you create specifically to lure attackers. You give them a tempting name, like Exchange Admin or Domain Backup Service. You give them a high-privileged sounding group membership. But here's the catch. These accounts have no real use. Nobody should ever log into them. They're not used for any legitimate purpose. They just sit there waiting. If someone does log into a Honeypot account, you know immediately. Not because you set up custom monitoring, not because you wrote a complex detection rule, because Defender for Identity knows that account should never be used. The moment someone authenticates with it, an alert fires. And you know exactly what happened. An attacker found your decoy account and tried to use it. That's not a false positive. That's a confirmed intrusion attempt. You can set these up in the Defender portal under settings identities honey tokens. It takes about 30 seconds. Entity tagging is another feature. You can mark specific users, devices or groups as sensitive for extra monitoring. Think about what that means. If you tag a Domain Admin account as sensitive, Defender for Identity watches every single action that account takes more closely. Any deviation from normal behavior gets flagged with higher priority. Any lateral movement involving that account gets escalated, it's like putting a GPS tracker on your most valuable assets. And then there are exclusion rules, sometimes legitimate security tools or admin processes trigger false alarms. Your vulnerability scanner might authenticate against every machine in the network. That looks suspicious. Your backup software might access domain controllers at unusual hours. That also looks suspicious. You can exclude specific IP addresses, devices or users from certain detection rules so those false positives don't clutter your alert queue. Global exclusion apply to all detection rules. Per-rule exclusions are more targeted. The goal is the same. Reduce noise so your security team focuses on real threats. Defender for Identity doesn't work alone. Let's see how it fits into the bigger picture. How it fits in Microsoft's security ecosystem. So how does Defender for Identity fit into Microsoft's bigger security picture? Think of it as one piece of the Defender XDR puzzle. On its own, each tool is useful, but the real power comes when they work together. Defender for endpoint guards your devices. It checks every laptop and server for malware and suspicious network activity. Defender for Office 365 protects your email and collaboration tools, catching phishing attempts and malicious attachments. And Defender for Identity, it watches over your user accounts, looking for stolen credentials, lateral movement and domain dominance. On their own, each tool is useful, but here's the thing. Together, they share signals and connect the dots. Imagine a suspicious login on a domain controller. That same login could be linked to a phishing email that Defender for Office 365 already caught. The attacker compromises the mailbox and is now trying to move laterally. Defender for Identity sees the login, Defender for Office 365 sees the email and the Microsoft Defender XDR platform creates a single incident. That's the difference between isolated alerts and a complete attack story. It also integrates with Microsoft Sentinel, which is Microsoft's cloud native CM. That's where you go for advanced hunting and custom detections. You can write custocheries that search across all your defender data, Identity, endpoint, email, cloud apps, and find patterns that automated rules don't always catch. And it works alongside Microsoft EntraID Protection. Here's the distinction. EntraID Protection handles cloud-based sign-in risks like risky sign-ins from anonymous IP addresses or a typical travel. Defender for Identity handles on-premises threats like watching your domain controllers, active directory and ADFS servers. Microsoft recommends using both for defense and depth in hybrid environments. The magic isn't any single product. It's how they all talk to each other. Let's wrap up with what you should do next. Here's the takeaway. Defender for Identity fills a gap that traditional security tools leave open. It watches for Identity-based attacks using stolen credentials. It catches attackers who don't break in. They log in. And it's not complicated. Sensors on your domain controllers plus behavioral analytics in the cloud equals real-time threat detection. The simplest next step? Check if your domain controllers are running Windows Server 2019 or above. If they are, you can activate the new sensor from the Defender portal today. There's no download, no installation, just a few clicks. Subscribe on your favorite podcast platform and share this with someone who's starting their Identity Security journey. And click here for our next episode on Microsoft, Enter ID Protection, the Cloud Side Companion to Defender for Identity.