TL;DR Cayosoft Guardian helps identity and security teams see how permissions, delegation, drift, and recovery dependencies connect across Active Directory and Microsoft Entra ID, so they can find identity attack paths before attackers do and recover with confidence when identity is targeted.
When I present this at BSides, there is one line where the room usually gets quiet:
One side is living a delusion.
I pause because everyone knows the two sides are defenders and attackers. The uncomfortable part is deciding which side sees the environment more clearly.
I have been on both sides of that room. I have been the defender who was sure the environment was locked down, and I have been the one who found the thing that quietly proved otherwise. What I have learned is that identity almost never fails the way we expect it to. It fails in the space between decisions that all made sense at the time. The problem is not that defenders are careless. The problem is that attackers treat identity as a path, while defenders too often treat it as a checklist. That is why these paths keep working.
Attackers do not create identity attack paths. They inherit them.
Identity attack paths are the routes attackers take through permissions, groups, roles, credentials, applications, certificates, and sync paths to get to something that matters. In Microsoft environments, those routes usually cross Active Directory, Entra ID, Microsoft 365, AD CS, service accounts, service principals, and hybrid identity.
But the important thing about attack paths is not their definition. It is their origin.
Every identity attack path starts as a legitimate business decision. A project needs access. A help desk team gets delegated rights. A service account gets more permission than anyone expected. An application gets write access because the business needed it yesterday. None of those decisions feel reckless in the moment.
The problem is that nobody goes back. Small decisions accumulate, and attack paths exist whether attackers are present or not. The attacker does not create the path. The attacker finds the path that already exists.
That is the uncomfortable part. The risk is usually hiding in things that look normal: stale ACLs, nested groups, GPO edit rights, service principal credentials, app consent grants, Conditional Access exclusions, certificate templates, and synchronization permissions.
Why do Active Directory and Entra ID attack paths persist?
Identity attack paths persist because access rarely disappears when the original reason for it is gone. Nested groups stretch privilege beyond the team that requested it. ACLs grant WriteDACL, WriteOwner, GenericAll, or GenericWrite where nobody expects them. GPO edit rights become code execution. Service accounts keep SPNs and weak passwords long after the owner has moved on. Legacy access survives reorganizations, migrations, acquisitions, emergency changes, and cloud projects.
Why do defenders miss identity attack paths?
Most security programs still review identity in pieces: users, groups, computers, roles, policies, findings, and vulnerabilities. That work matters. Each piece needs ownership, hygiene, and control. The gap is that risk often sits between those pieces, not inside one object. A group may look approved. A role assignment may have an owner. A policy may exist. The route between them is what gets missed.
A help desk delegation looks fine because it was created for a ticket queue. A service account looks fine because an application still depends on it. A nested group looks fine because nobody remembers why it was added. A certificate template looks fine because it has existed for years without causing visible pain. A service principal looks fine because it was approved during a project and never revisited. Put them together and suddenly you have Tier 0 access, Global Administrator impact, or a recovery plan that fails when you need it most.
That is why these identity attack paths stay hidden until the incident. Nothing looks strange by itself. The danger is in how the pieces combine. A defender may ask whether an account is enabled or whether a delegation was approved. An attacker asks a different question: if I control this identity, what can I reach next?
Why are modern attacks identity-first?
Modern attacks are identity-first because identity is where control decisions are enforced. Attackers do not just want a foothold on one endpoint or access to one file share. They want the ability to authenticate, authorize, escalate, persist, and shape the recovery effort. In a Microsoft environment, that often means moving toward Active Directory, Entra ID, Microsoft 365, service principals, synchronization, and the systems administrators trust during containment.
Ransomware became more effective as operators learned to spend more time with identity. They enumerate who can reset passwords, who can edit policies, which accounts are excluded from controls, which applications have broad permissions, and which service accounts are trusted. The goal is not only encryption. It is leverage over the systems that decide who can get back in.
That is why identity compromise changes the recovery conversation. Files can be restored. Servers can be rebuilt. Endpoints can be reimaged. But if attackers still control identity, every future login is a question mark. You may bring systems back online, but you have not proved who still has control, which privileges are still valid, or whether the attacker’s path survived the rebuild.
Why does identity recovery fail to remove attackers?
Many organizations believe recovery resets the environment. Attackers do not.
Persistence can survive in places a basic restore does not validate: Golden Ticket and Golden SAML abuse, DCSync rights, AdminSDHolder manipulation, SIDHistory abuse, AD CS certificate abuse, shadow credentials, service principal credential injection, OAuth consent abuse, hybrid identity synchronization abuse, delegated rights, hidden ACLs, and stale trust relationships.
Restoring identity without validating privilege, trust, and persistence can bring the environment back online while preserving the attacker’s path back in.
What are toxic combinations in identity security?
Most teams can spot the obvious bad setting. The harder part is spotting the combination that turns several manageable issues into one serious path.
Unconstrained delegation, a service account with an SPN, delegated GPO rights, a stale SID, a vulnerable certificate template, an app registration with long-lived credentials, or a service principal with high-impact Graph permissions may each look manageable. Together, they become the identity attack path.
That is why identity teams need to evaluate combinations, not just isolated settings. Do not only ask whether an account is privileged. Ask what that account can influence, what trusts it inherits, and what recovery depends on it.
How do attackers think about identity?
Attackers think operationally. They compare what is documented against what can actually be enumerated. They look for drift, shortcuts, inherited rights, forgotten exceptions, and trusted systems that still accept old assumptions.
In Active Directory, attackers follow edges such as MemberOf, AdminTo, GenericAll, GenericWrite, WriteDACL, WriteOwner, AddMember, ForceChangePassword, GpLink, Owns, AllowedToDelegate, and CanRDP. In Entra ID, they follow role assignments, app ownership, service principal ownership, app role assignments, delegated and application permissions, consent grants, Conditional Access scope, PIM assignments, and privileged access group relationships.
Why do identity attack chains keep getting missed?
Identity attack chains often get missed because the evidence is distributed. Audit logs, directory changes, sign-in logs, Entra audit logs, Microsoft Graph activity, AD CS events, GPO history, endpoint signals, and identity protection alerts may all show part of the story. None of them, by themselves, explain the full route.
That creates a visibility gap. One tool shows a change. Another shows a sign-in. Another shows a policy edit. Another shows an application permission. Unless those signals are connected, the chain looks like normal administrative noise until it becomes impact.
One side is living a delusion. I will let you decide who.
How should identity teams reduce attack path risk?
Reducing identity attack path risk starts with seeing effective privilege across Active Directory, Entra ID, Microsoft 365, hybrid identity, applications, roles, certificates, policies, synchronization paths, and recovery dependencies. The goal is to understand who can influence control, where privilege has drifted, which combinations create reachability, and whether recovery would remove the access an attacker could depend on.
That means reviewing privilege as a system, not a spreadsheet. Teams should prioritize high-impact paths, validate Tier 0 dependencies, investigate drift, test recovery assumptions, and continuously revisit exceptions that were originally approved for valid reasons.
Final thought
The most dangerous permission in your environment may not be the oldest, broadest, or most obvious one. It may be the access granted yesterday that nobody logged, reviewed, or questioned.
That is why identity attack paths keep working. They survive in the space between business decisions, operational shortcuts, and assumptions nobody goes back to validate.
Attackers live in what we stop revisiting.
FAQs
An identity attack path is a chain of permissions, roles, credentials, applications, certificates, or synchronization dependencies that lets an attacker move from initial access to privileged control.
Active Directory attack paths remain dangerous because legacy delegation, nested groups, stale ACLs, service accounts, AD CS exposure, and Tier 0 dependencies can persist for years.
Entra ID attack paths often depend on app identities, token scope, OAuth consent, service principals, role assignments, Conditional Access exclusions, and Microsoft Graph permissions.
Privilege drift is the accumulation of access that was once justified but is no longer reviewed, needed, or understood.
Identity recovery fails when restoration does not remove attacker persistence, such as stolen credentials, certificates, delegated rights, service principal secrets, or hidden ACLs.
Security teams reduce identity attack path risk by mapping effective privilege, monitoring drift, reviewing delegation, hardening AD CS and service principals, and testing recovery.
Toxic combinations are identity conditions that look manageable alone but become dangerous when chained together.
Hybrid identity is harder to secure because risk can move between Active Directory, Entra ID, Microsoft 365, synchronization, applications, and recovery systems.
h2
text
h3
h3
hello
call out
h3
h2
hello
| hello | hello | hello |
| hello | hello | hello |
| hello | hello | hello |
| hello | hello | hello |
| hello | hello | hello |
| hello | hello | hello |
h2
hello
h3
hello
h3
hello
h3
hello
callout
h2
h3
callout
h3
Key Takeaways
See Cayosoft in Action
Cayosoft is recognized by Gartner as an ITDR solution provider and provides solutions that make identities more resilient to attacks and guarantee a fast forest recovery, if needed. Learn how Cayosoft Guardian facilitates granular change tracking, post-breach analysis, and long-term AD security improvements. Schedule a demo to see the capabilities in depth.