TL;DR: Active Directory Unicode edge cases can let non-privileged users create confusing lookalike objects, bypass SPN and UPN uniqueness checks, and escalate to domain-wide impact, according to Semperis research. The result is a governance failure, not just a parsing bug: identity systems must validate what humans can see and what controllers will actually accept.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Semperis's research: Invisible Unicode characters in Active Directory can defeat uniqueness checks and create lookalike identities that change authorization outcomes.
Why it matters: It matters because identity teams have to govern what directory services accept, not just what administrators can visually verify, or low-privilege changes can become domain-wide compromise paths.
Context
Active Directory identity integrity depends on more than user-facing consoles. If the directory can accept visually indistinguishable objects, then uniqueness checks, operator review, and downstream authorization decisions can all diverge from what the domain controller actually stores and resolves.
Semperis shows two distinct outcomes from that gap: a denial-of-service path through conflicting service principal names and a full domain takeover path through a forged user principal name. The common failure is that directory semantics, not just admin permissions, decide whether a low-privilege change becomes a high-impact identity event.
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 conflicting SPNs create such a serious Kerberos risk?
A: A conflicting SPN changes which account Kerberos treats as the owner of a service. If the ticket is encrypted with the wrong account key, service access fails, and if the collision is exploitable in a delegation flow, the attacker can steer ticket issuance. That is why SPN writes must be treated as privileged identity events, not routine admin changes.
Q: How can security teams tell if Unicode abuse is hiding in Active Directory?
A: Look for duplicate-looking objects, unexpected hidden characters in attribute values, and SPN or UPN changes that do not match normal delegation or onboarding patterns. On domain controllers, event ID 5136 is a key signal because it records directory object modifications. The strongest indicator is a naming change that appears harmless in the GUI but changes account resolution.
Q: Should organisations rely on visual review to catch directory identity abuse?
A: No. Visual review is useful for triage, but it is not enough when the directory can store values that render ambiguously or are ignored by different components. Organisations need attribute-level validation, least-privilege write access, and audit telemetry because the attack succeeds through directory semantics, not just through user deception.
Technical breakdown
How invisible Unicode breaks directory uniqueness checks
Active Directory does not treat every Unicode character consistently. Some invisible characters are preserved in object attributes, some are ignored during LDAP filtering, and others are interpreted as whitespace or display artefacts. That means a name can look identical in the GUI while remaining distinct, or can resolve differently depending on how the domain controller parses the value. Once that happens, the directory’s notion of uniqueness no longer matches what administrators think they created. The technical problem is not only hidden characters, but inconsistent normalization between client tools, LDAP filters, and server-side comparison logic.
Practical implication: validate directory attribute handling at the server boundary, not just in admin tools.
Why SPN alias collisions can redirect Kerberos traffic
Service Principal Names tell Kerberos which account owns the encryption key for a service. If an attacker can write a conflicting SPN that survives uniqueness checks, the Key Distribution Center may issue tickets encrypted for the wrong account. In the article’s DoS scenario, that causes authentication failures because the target service cannot decrypt the ticket. In the more serious scenario, conflicting SPN ownership lets the attacker shape ticket issuance during delegation flows and obtain a ticket that decrypts under the attacker-controlled object. The issue is not Kerberos itself, but identity binding failure at SPN resolution.
Practical implication: treat SPN writes as high-risk identity changes and audit any conflicting SPN additions immediately.
How a writable UPN becomes a domain takeover path
A User Principal Name is not just a label. In Active Directory, it can influence how the domain controller resolves the target account during authentication and password reset workflows. If a low-privileged principal can set a UPN that matches another account’s SamAccountName, the controller may bind the reset or authentication step to the wrong identity. In ResetNightmare, that allowed the attacker to obtain a ticket for the real privileged user after only a writable-object primitive. The lesson is that identity attributes used for lookup and identity proofing must be governed as authentication inputs, not treated as cosmetic profile data.
Practical implication: protect writable UPN and related lookup attributes with least privilege and change monitoring.
Threat narrative
Attacker objective: The attacker wants to control identity resolution in Active Directory so that a low-privilege write operation becomes domain administration or service disruption.
- Entry begins with a low-privileged principal who can write object attributes on users or computers in Active Directory.
- Credential or ticket access follows when the attacker adds an invisible Unicode character that bypasses SPN or UPN uniqueness checks and changes how the domain controller resolves the identity.
- Escalation occurs when Kerberos or password-reset logic binds the request to the attacker-influenced object instead of the intended target account.
- Impact is domain-wide control, denial of service against services mapped by SPN, or direct Domain Admin compromise through ResetNightmare.
Breaches seen in the wild
- Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.
- Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Directory identity is only as strong as the comparison rules behind it: If a controller and an administrator do not evaluate names the same way, then uniqueness checks become a cosmetic control rather than a security control. Active Directory’s Unicode edge cases show that identity integrity can fail even when permissions look intact. The implication is that directory governance must include parser behaviour, not only access policy.
SPN and UPN are not metadata, they are authorization inputs: This research shows that values often treated as directory labels can determine which account Kerberos and password-reset logic trust. Once a writable attribute can impersonate another identity at lookup time, least privilege loses its meaning because the attacker does not need elevated rights, only a crafted string. Practitioners should treat identity attributes as security-critical state.
Unicode normalization is a control plane issue, not a presentation issue: The weakness here is not that objects look confusing in a console, but that the directory accepts values that humans cannot reliably distinguish. That breaks review, correlation, and incident triage at the same time. The result is an identity blast radius that starts with a single attribute write and ends in domain-level compromise.
Privilege boundaries fail when object identity can be forged through naming collisions: KerberLoss and ResetNightmare illustrate a broken assumption that identity lookup is stable and unambiguous. It is not, when invisible characters can change how the DC binds an object. Identity teams should read this as a governance failure in attribute validation and a reminder that directory semantics are part of the attack surface.
Named concept: identity comparison mismatch: This article exposes the gap between what administrators see and what domain controllers accept as equivalent or unique. That mismatch is the root failure that allows SPN collision, lookalike objects, and UPN hijacking to exist in the same directory. For practitioners, the control question is whether the directory enforces the same identity rule at every resolution point.
What this signals
Identity comparison mismatch: Active Directory shows why review controls fail when the directory’s comparison logic can diverge from human perception. Once that happens, the programme has to treat SPN and UPN writes as security events, not administrative housekeeping.
The governance lesson extends beyond one bug. Any identity platform that allows ambiguous attribute values creates an opportunity for low-privilege changes to reshape authentication decisions, so lifecycle controls and change monitoring need to be tied directly to directory semantics.
For practitioners
- Harden attribute write permissions Restrict who can modify SPN, UPN, and other lookup-sensitive attributes on user and computer objects, especially where generic write rights exist on delegated OU structures.
- Audit for invisible character abuse Scan Active Directory objects for hidden Unicode characters, duplicate-looking names, and conflicting SPN or UPN values that could alter directory resolution.
- Monitor directory modifications at the DC Enable SACLs and review Security event ID 5136 for SPN and UPN changes that collide with existing identities or introduce non-default naming patterns.
- Patch domain controllers and verify fixes Apply the relevant Microsoft updates to all domain controllers and then retest whether uniqueness checks still block conflicting SPN and UPN values.
- Revisit delegated administration models Review delegated write permissions across users and computer objects so that no low-privilege role can turn a naming attribute into an authentication primitive.
Key takeaways
- Invisible Unicode handling in Active Directory creates a genuine identity integrity problem because controllers, operators, and LDAP filters can disagree on what a name means.
- The article ties that weakness to both service disruption and full domain compromise, showing that naming collisions can change authentication outcomes at the directory layer.
- The limiting control is tighter write access and stronger validation on lookup-sensitive attributes such as SPN and UPN, backed by patching and directory change monitoring.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Unicode confusion changes how AD authenticates and resolves principals. |
| NHI-05 — Overprivileged NHI | Writable SPN and UPN attributes become escalation paths when permissions are too broad. | |
| Recommendation — Validate identity inputs so ambiguous directory values cannot alter authentication outcomes. Tighten write rights on SPN and UPN attributes to limit privilege escalation paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | This article centers on who can change authoritative identity attributes. |
| Recommendation — Review entitlements on directory attributes and remove unnecessary write permissions. | ||
| MITRE ATT&CK | TA0006;TA0004 — Credential Access; Privilege Escalation | The attack abuses identity attribute writes to gain higher-privilege access. |
| Recommendation — Map SPN and UPN abuse to credential access and privilege escalation detection coverage. | ||
| CIS Controls v8 | CIS-5 — Account Management | Directory accounts and their writable attributes are the core governance surface here. |
| Recommendation — Apply account management controls to review and restrict high-risk directory attribute changes. | ||
Key terms
- Identity Comparison: Identity comparison checks whether two names point to the same object in memory, not whether they have the same value. In Python, this is done with is. It can appear to work for interned strings or cached integers, but it is not a safe substitute for equality testing.
- ServicePrincipalName: ServicePrincipalName is an Active Directory attribute that identifies the service or application associated with an account. In practice, it helps security teams locate service accounts during discovery and validate whether an account is still tied to a legitimate workload, which supports inventory and governance efforts.
- User Principal Name: A logon attribute that helps identify a user during authentication and lookup. If a UPN can be set to mimic another account’s identity, the directory may bind trust to the wrong principal, especially where uniqueness and normalization are weak.
- Unicode Normalization: Unicode normalization is the process of converting text into a consistent encoded form so that visually similar strings compare predictably. Security teams care about it because different normalisation rules across proxies, applications, and filters can create bypasses, inconsistencies, and hard-to-detect abuse paths.
Deepen your knowledge
NHI governance, identity lifecycle management, and workload identity security 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 or NHI governance programme, it is worth exploring.
Published by the NHIMG editorial team on August 11, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org