Defender for Identity: Detecting Lateral Movement in Hybrid Environments

In a hybrid Active Directory environment I supported, the incident started with a service account nobody had flagged as privileged. The attacker compromised it, and the existing trust relationships between domains did the rest of the work. What began as one compromised account in one domain became a multi-domain, multi-forest compromise, because nothing was watching the paths between them.

That's the part of a breach most organizations understand least. Moving around once you're in is where the damage compounds, and it's the phase where hybrid environments have the weakest visibility.

The data backs this up. Mandiant's M-Trends 2026 report puts global median dwell time at 14 days, up from 11 the year before. Organizations that catch an intrusion internally do it in about 9 days. Organizations that find out from someone else average 25 days. That 16-day gap is the window where an attacker goes from one compromised account to domain admin, or in a hybrid environment with unaudited trusts, to domain admin in more than one domain. Verizon's 2026 Data Breach Investigations Report found credential abuse touching 39% of breaches and named it the primary method attackers use to move laterally, escalate privileges, and monetize access once they're inside.

What lateral movement actually looks like in hybrid AD

Lateral movement is a set of ways an attacker turns "I have one set of credentials" into "I have access to systems I was never supposed to touch."

The common ones in a hybrid Active Directory environment:

• Pass-the-Hash: reusing a captured password hash to authenticate as another account without ever knowing the plaintext password.

• Pass-the-Ticket: stealing a Kerberos ticket and replaying it to impersonate the account it belongs to.

• Kerberoasting: requesting service tickets for accounts with service principal names, then cracking them offline to recover service account passwords.

• Golden ticket and RBCD abuse: forging Kerberos tickets or manipulating resource-based constrained delegation attributes to grant an attacker-controlled account impersonation rights it was never assigned.

• Cross-domain and cross-forest movement via trust relationships: the technique behind the incident above. It doesn't require a new exploit. It requires an existing trust path nobody audited, and a privileged account sitting on the wrong side of it.

That last one is the one architects underweight most. Trust relationships are configuration, not code, so they don't show up on a vulnerability scan. They show up when someone maps them, and most organizations don't.

"Understanding the Lateral Movement Attack Chain: A detailed progression from initial account compromise through reconnaissance, lateral movement, and privilege escalation to full domain dominance and cross-domain trust traversal, highlighting the increasing impact."

How Microsoft Defender for Identity (MDI) detects it

Defender for Identity's sensors sit directly on the infrastructure that lateral movement has to pass through. As of the May 2026 sensor v3.x release, sensors deployed on domain controllers support every identity role running on that server, including Microsoft Entra Connect, AD FS, and AD CS roles. Microsoft's recommended coverage is every domain controller, including read-only domain controllers, plus every AD FS, AD CS, and Entra Connect server in the environment. Partial sensor coverage means partial visibility, and lateral movement only needs one uncovered hop to go unseen.

On top of that sensor coverage, three capabilities matter most for catching lateral movement specifically:

• Behavioral baselining. Defender for Identity learns what normal authentication looks like for each account, including which systems it typically touches and which domains it typically authenticates against. A service account that has never authenticated outside its home domain suddenly authenticating into a second forest is exactly the kind of anomaly this is built to catch.

• Honeytoken accounts. These are dormant accounts with no legitimate activity tied to them. Any authentication attempt against one is inherently suspicious, and Defender for Identity can detect honeytoken use across the lateral movement techniques attackers actually rely on, including remote execution, SMB sessions, and RDP sessions.

• Named lateral movement alerts. Defender for Identity ships specific, current detections for the techniques above: Suspected pass-the-ticket attack (generally available), Possible golden ticket attack, Possible Kerberoasting attack using a stealthy LDAP search, Suspicious NTLM authentication, and Suspicious resource-based constrained delegation (RBCD) attribute change and authentication. Each alert maps to a specific technique, which matters when you're validating that your detection coverage actually matches your threat model instead of assuming it does.

Incident ID 4 from Microsoft Defender: Medium priority alert for lateral movement using remote logon, with attempts blocked across multiple devices. The investigation highlights notable MITRE tactics and techniques, including remote services and valid account exploitation.

What changed: the path map you used to rely on is gone

If you built your mental model of Defender for Identity around the old visual lateral movement path map, that model is out of date. Microsoft retired the SAM-R-based collection that powered those automated maps in May 2025. It wasn't replaced immediately.

As of April 2026, Defender for Identity customers with a Microsoft Sentinel Data Lake license get Identity Explorer, a preview capability that uses a hunting graph to visualize identity attack paths and exposure scenarios. It runs on predefined identity scenarios to surface lateral movement paths, privilege escalation routes, and credential-access risks. The underlying exposure data moved into a tool you have to query rather than a static picture that updated itself.

There's a second relevant addition from March 2026: the Domain investigation page, which shows Active Directory domain security details including trust relationships directly. That's the specific gap in the incident described above. Nobody had a page that surfaced which domains and forests trusted each other and why. Now there is one.

Microsoft Defender dashboard displaying Identity Security settings with a highlighted honeypot account, "Super Admin," used to detect unauthorized access attempts.

Correlation into Defender XDR

An isolated lateral movement alert tells you something happened on one system. Correlated into a Defender XDR unified incident alongside Defender for Endpoint and Defender for Cloud Apps signals, it tells you the scope: which endpoints were touched, which cloud apps the compromised identity accessed, and how the timeline connects across all of it. In a multi-domain or multi-forest scenario, that correlated view is the difference between investigating one incident and investigating what looks like several unrelated ones until someone notices the same account behind all of them.

The business case

Here's the mechanism, stated plainly: every day lateral movement goes undetected adds systems, domains, and forests to the remediation and audit scope. Detection speed determines how much there is to respond to.

On the engagement referenced above, the extended detection window turned a single compromised service account into a cross-forest incident. Business impact from the resulting operational disruption landed at roughly $1 million, and full mitigation took 8 to 10 months. That scope was a function of how long the lateral movement phase went unnoticed, in an environment where the trust relationships that made the spread possible had never been mapped or monitored.

Tie that back to the Verizon figure: credential abuse touches 39% of breaches, and once an attacker has working credentials, lateral movement is usually the easy part, which is exactly why detection during the hop matters more than prevention at the perimeter. Perimeter controls stop the attacker who doesn't get in. They do nothing for the attacker who already did.

What good looks like

A practical checklist for architects and engineers validating lateral movement detection in a hybrid environment:

• Full sensor coverage. Every domain controller, including RODCs, plus every AD FS, AD CS, and Entra Connect server. Confirm coverage on the Sensors page rather than assuming it.

• Honeytoken accounts reviewed on a regular identity hygiene cadence, not just deployed once and forgotten.

• Sensitive-account and service-account tagging done accurately. Run the "Identify service accounts in privileged groups" posture assessment specifically. It's built to catch exactly the kind of unflagged privileged service account that started the incident above.

• Trust relationships audited on purpose, using the Domain investigation page.

• Detection validated against named techniques. Test for pass-the-ticket, golden ticket, Kerberoasting, and RBCD abuse specifically, and confirm the corresponding alerts fire.

• MDI alerts wired into Microsoft Sentinel and Defender XDR correlation rules, so a lateral movement alert becomes part of a unified incident automatically.

The Identity Security dashboard highlights a perfect coverage score, with all domain controllers and servers onboarded. However, it shows a critical alert indicating three sensors are not healthy, requiring attention.

Lateral Movement Detection: An overview of security techniques and their corresponding detection and response signals, highlighting methods such as Pass-the-Hash, Pass-the-Ticket, and more, along with their associated MDI detections and XDR signals using Defender for Endpoint and Cloud Apps.

Closing thought

Lateral movement is the last phase of a breach where the cost is still contained. Catch it there, and you're remediating one account. Miss it, and you're remediating a forest, for the better part of a year.

Is Your Defender for Identity Deployment Validated, or Just Installed?

Cloud Harbor Consulting partners with security architects and engineering teams to turn a Defender for Identity deployment that stalled at sensor installation into a validated detection program, with sensor coverage, trust relationship mapping, and technique-specific alerting confirmed in the right order. Schedule a conversation to walk your hybrid AD environment against this validation checklist and pinpoint where an untagged privileged service account, an unaudited domain trust relationship, or detection coverage that has never been tested against pass-the-ticket, golden ticket, and RBCD techniques is leaving your identity estate exposed.

Contact Us