Unicode identity confusion in Active Directory enables Domain Admin

At a glance

What this is: This research shows that hidden or unfilterable Unicode characters in Active Directory can bypass uniqueness checks, create lookalike identities, and enable privilege escalation or service disruption.

Why it matters: It matters because IAM teams often assume directory naming controls are sufficient, but DC-side parsing differences can break trust in identity records and undermine access governance.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Semperis' analysis of KerberLoss and ResetNightmare in Active Directory

Context

Active Directory identity governance depends on the directory and the domain controller agreeing on what a name means. When that agreement breaks, attackers can create objects that look legitimate to administrators but resolve differently to the KDC and LDAP processing path, which turns naming into an access-control problem.

This is a human IAM issue as much as a directory-hardening issue, because admins, help desks, and recertification workflows all rely on the integrity of displayed identity attributes. If object uniqueness, SPN mapping, or UPN validation can be confused, then the control plane stops matching what operators believe they are approving.

The research focuses on two Active Directory privilege escalation paths, KerberLoss and ResetNightmare, both of which abuse identity confusion rather than password theft. That makes the starting position unusual in mechanism, but familiar in governance failure: trust in directory naming outpaced the controls that actually enforce it.

Key questions

Q: What breaks when hidden Unicode is allowed in Active Directory object names?

A: It breaks the assumption that displayed names and directory-resolved identities are the same thing. If a user can create lookalike SPNs or UPNs, uniqueness checks and operator review no longer guarantee that the right account will receive Kerberos tickets or authentication mappings. That can lead to impersonation, service disruption, or privilege escalation.

Q: Why do SPN and UPN collisions create such a high-risk identity control failure?

A: Because both attributes participate directly in how Active Directory resolves who or what an identity is. If a collision is accepted, the directory may issue tickets or map authentication to the wrong object even though administrators believe the value is unique. That turns a simple write permission into a domain-level security concern.

Q: How can security teams tell whether directory naming controls are actually working?

A: Look for two signals: whether the DC resolves the same object that administrators see, and whether object-modification logs show unexpected SPN or UPN changes. If display, lookup, and ticket issuance disagree, the control is failing even if the console appears clean.

Q: Who is accountable when a writable SPN or UPN enables domain compromise?

A: Accountability sits with the team that granted the write permission and with the control owners who failed to constrain or monitor it. In a regulated environment, that usually means identity engineering, directory administration, and security operations all need a documented ownership chain for high-risk attribute changes.

Technical breakdown

How Unicode confusion breaks Active Directory uniqueness checks

Active Directory does not treat every Unicode character consistently across console display, LDAP filtering, and server-side object handling. Some characters render invisibly, some are normalised away, and some are treated as whitespace or ignored altogether. That means two strings can look identical to an operator while being handled differently by the directory service. In practice, this creates a split between visual identity and effective identity, which is dangerous whenever names are used as a control input for account creation or lookup.

Practical implication: validate object names against the same server-side rules DCs apply, not just what the admin console displays.

SPN uniqueness, lookup precedence, and KerberLoss

Service Principal Names determine which account receives a Kerberos service ticket. If an attacker can write an SPN containing an unfilterable Unicode character, the SPN can bypass alias uniqueness checks while still appearing legitimate in administrative tools. The KDC may then resolve requests to the attacker-controlled object, especially when explicit SPN precedence and LDAP lookup behavior diverge. That creates a path to service denial or ticket misdirection without needing admin control of the target service itself.

Practical implication: audit SPN changes with SACLs and alert on any non-default principal gaining SPN write capability.

UPN collisions and ResetNightmare escalation

User Principal Names are meant to map a user to a stable sign-in identity, but ResetNightmare shows what happens when write access to a UPN is enough to impersonate another account's SamAccountName. If the target password age and object permissions align, a low-privileged user can set a colliding UPN and trigger authentication downgrade or outright privilege escalation. This is a directory trust failure, not a password strength issue, because the system accepts an identity assertion that should never have been considered authoritative.

Practical implication: restrict generic write permissions on user objects and monitor UPN changes against existing account names.

Threat narrative

Attacker objective: The attacker aims to confuse directory identity resolution so that privileged tickets or account mappings resolve in their favor.

1. Entry occurs when a low-privileged user gains generic write access over a user or computer object, or when a delegated permission allows SPN or UPN modification.
2. Escalation occurs when the attacker inserts hidden Unicode into SPN or UPN values to bypass uniqueness enforcement and cause the directory to resolve the wrong identity.
3. Impact occurs when Kerberos tickets are issued to the attacker-controlled object, producing service disruption, authentication downgrade, or full Domain Admin compromise.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity confusion is a governance failure, not a parsing edge case. Active Directory naming controls are often treated as a hygiene problem, but this research shows they are part of the authorization boundary. When the directory accepts objects that look identical but resolve differently, the control that failed is the assumption that visible names are authoritative. Practitioners should treat naming validation as a security control with direct access consequences.

Directory uniqueness checks do not equal identity integrity. The article demonstrates that SPN and UPN uniqueness logic can be bypassed while administrative tooling still shows a plausible object. That means recertification, change approval, and privileged access workflows can all be fooled by a record that appears normal but behaves differently under LDAP and Kerberos. The implication is that identity governance must validate the resolution path, not just the attribute value.

Kerberos attack paths can start with object write rights, not credential theft. The most dangerous part of KerberLoss and ResetNightmare is that the attacker does not need to steal a password or bypass MFA. They only need a permission set that seems narrow on paper but is powerful in practice, such as write access to SPN or UPN fields. That is a reminder that identity risk is often embedded in object-level delegation.

This is a domain-admin problem created by weak object governance. The research shows that a low-privileged user can pivot from a single writable attribute to broad domain compromise when object permissions are too open and uniqueness validation is incomplete. That makes least privilege and delegated administration central to directory resilience, not optional hardening. Teams should re-evaluate every write path that can alter identity-resolving attributes.

Hidden Unicode is a named concept worth tracking as identity masquerade debt. These characters create a gap between what operators see and what the DC enforces, which accumulates technical and governance debt over time. The more approval, lookup, and troubleshooting workflows depend on human-readable names, the larger that debt becomes. Practitioners should assume any invisible-character allowance is a latent impersonation surface.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For identity teams working through attribute-risk governance, Ultimate Guide to NHIs , Key Challenges and Risks is the natural next reference.

What this signals

Unicode-driven identity ambiguity should be treated as a directory governance smell, not a rare exploit pattern. Where naming, lookup, and ticket issuance do not agree, the programme has already lost the ability to prove identity integrity. Teams should align directory hardening with privileged attribute governance, because writable fields that resolve identities are effectively access-control inputs.

Identity programmes that still rely on human-readable uniqueness alone will miss this class of failure. The practical test is whether change control, audit, and detection operate on the same resolution rules as the DC. If they do not, then lookalike object creation becomes a policy bypass, not just a nuisance for admins.

The right next step is to tie directory object governance to privileged access review and change-detection workflows, using the same discipline applied to service account and secrets oversight. If your programme already maps to the Ultimate Guide to NHIs, extend that model to high-risk identity attributes that can change how the directory resolves authority.

For practitioners

• Audit writable identity attributes Review who can change SPNs, UPNs, and other identity-resolving attributes across user and computer objects. Remove generic write permissions, especially where delegation was granted for convenience rather than a documented operational need.
• Detect hidden-character abuse in directory objects Use directory service auditing and object-modification logging to flag unusual Unicode values, duplicate-looking names, and collision attempts that affect SPN or UPN resolution. Security event ID 5136 on domain controllers is especially useful when paired with change baselines.
• Validate the server-side resolution path Test how DCs handle object names, SPNs, and UPNs under the same lookup conditions used in production rather than relying on console display or client-side parsing. Any mismatch between visual identity and resolved identity should be treated as a control failure.

Key takeaways

• Hidden Unicode in Active Directory turns naming into an access-control problem because visually identical objects can resolve differently at the directory layer.
• KerberLoss and ResetNightmare show that low-privilege write access to SPN or UPN fields can be enough to trigger service disruption or full domain compromise.
• The control that matters most is not cosmetic validation but strict governance over writable identity attributes, backed by change detection on domain controllers.

Key terms

• Lookalike Identity Object: A directory object that appears identical to a legitimate identity in administrative tools but resolves differently to the underlying authentication system. In Active Directory, this can happen when invisible characters or collision-prone attributes are accepted, creating a mismatch between human review and machine enforcement.
• Service Principal Name Collision: A condition where two objects contend for the same SPN or a confusable variant of it. Because Kerberos relies on SPNs to resolve which account owns a service key, a collision can misdirect tickets, break service access, or enable privilege escalation if write rights are too broad.
• User Principal Name Collision: A conflict where a UPN is set to mimic or overlap another account identity, causing authentication and lookup ambiguity. In governance terms, it is a high-risk attribute change because it can convert a simple write permission into an impersonation path or a domain compromise route.
• Identity Masquerade Debt: The cumulative risk created when identity systems permit objects or attributes that look authoritative to humans but are not reliably unique to the directory. Over time, that gap increases the chance of mistaken approval, incorrect ticket issuance, and unnoticed privilege abuse.

What's in the full report

Semperis' full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step reproduction of KerberLoss and ResetNightmare in a lab environment
• LDAP filtering behaviour across 385 invisible Unicode characters and the exact character classes that work or fail
• Detection examples using Directory Services Protector and Security event ID 5136
• Patch timeline and disclosure chronology for CVE-2026-25177 and CVE-2026-27912

👉 Semperis' full post covers the attack chain, detection logic, and patch guidance in detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.