What happens when an attacker can use Kerberos tickets and directory permissions together inside Active Directory?

How Kerberos tickets and directory permissions combine into domain compromise

Kerberos tickets do not become dangerous on their own, and directory permissions do not become fatal on their own. The risk appears when an attacker can use one to amplify the other: stolen ticket material, weak delegation settings, or overly broad read and write rights can let an adversary move from one account to another, enumerate trusts, and turn a single foothold into administrative reach.

In active directory, that chain is especially powerful because tickets can carry authentication state across systems while directory permissions can expose the very objects an attacker needs to target next. If the attacker can read sensitive attributes, modify group membership, abuse delegation, or interact with privileged accounts and service objects, the environment can shift from contained access to domain-wide control.

Common escalation paths include harvesting hashes or tickets, requesting or replaying tickets where trust is weak, identifying privileged principals, and then using directory changes or token abuse to inherit higher rights. The practical result is not just more access, but access that looks legitimate enough to blend into normal administration activity.

Why this turns a local compromise into a lateral movement problem

The reason this matters is that Kerberos in Active Directory is built for seamless authentication, and directory permissions determine who can see, change, or impersonate which identities. When those controls are misaligned, the attacker can chain reconnaissance into privilege escalation without needing to break every target directly.

This is why The 52 NHI Breaches Report and the broader NHI literature are useful as analogues here: the same core failure pattern appears when reusable credentials, weak lifecycle hygiene, and privilege sprawl make trust relationships too easy to abuse. In Active Directory, the equivalent weakness is often a combination of durable tickets, stale delegated rights, and accounts that can still reach tier-zero assets long after they should have been reduced or removed.

Once the attacker can impersonate a more powerful principal, the problem becomes one of lateral movement and blast radius. Directory permissions then matter as much as the ticket itself, because they determine whether the attacker can enumerate targets, change objects, reset passwords, or pivot into management systems that were never meant to be reachable from the original compromise.

What defenders should verify before treating the issue as contained

Before assuming the incident is limited to one host or one account, verify whether the attacker touched ticket-granting activity, privileged group membership, delegation settings, or sensitive directory objects. A compromise that includes ticket abuse but no directory modification is serious; a compromise that includes both is usually a domain-control event until proven otherwise.

Pay special attention to service accounts, administrative groups, and any account that can alter permissions or reset credentials. If those objects were accessible, the attacker may not need to keep using the original access path once they have established a more durable identity foothold.

Also verify whether the same set of permissions would have allowed silent expansion without triggering obvious authentication failures. The most dangerous situations are the ones where the attacker never needs to brute force anything, because the ticket and the permission model already supply the path.

Risk and Threat Considerations

When Kerberos tickets and directory permissions are both weak, the risk is rapid privilege escalation with low noise. An attacker can use legitimate authentication material to move through the directory, harvest more credentials, and reach domain controllers, backup systems, or security tooling before defenders realise the original access path has already been expanded.

Failure mechanism: Stolen or misused tickets combine with over-broad directory rights to let an attacker authenticate as one identity while reshaping the directory or impersonating a more privileged one.

Impact: The compromise can progress from a single account to domain-admin level control, enabling mass access, ransomware deployment, or wider enterprise disruption.

Practitioner Guidance

What to prioritise: Treat the combination of ticket abuse and directory permission abuse as a single investigation scope, not two separate incidents. If the attacker had access to Kerberos material and writeable directory paths, assume privilege expansion is part of the timeline until disproven.

What to verify: Check whether privileged group membership, delegation configuration, and service account rights changed during the intrusion window. That evidence tells you whether the attacker merely authenticated or actually converted access into control.

Decision rule: If the exposed path can reach administrative identity or directory-management functions, prioritise containment and credential rotation before deeper forensic refinement. The key question is not whether the attacker used a ticket, but whether the ticket was enough to unlock durable rights.

Practitioner takeaway: In Active Directory, tickets are often the entry mechanism, but directory permissions determine whether the incident stays local or becomes a domain compromise.

Related resources from NHI Mgmt Group

• What happens when an attacker can change group membership or rewrite permissions in Active Directory?
• Why do legacy read permissions in Active Directory increase attacker reconnaissance risk?
• What happens when an attacker abuses IAM permissions inside a SaaS environment?
• What happens when an organisation cannot determine effective permissions in Active Directory?