Notifications
Clear all
Topic starter
11/08/2026 3:13 pm
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.
NHIMG editorial — based on content published by Semperis: KerberLoss and ResetNightmare research on Active Directory Unicode abuse
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Audit writable identity attributes Review who can change SPNs, UPNs, and other identity-resolving attributes across user and computer objects.
- 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.
- 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.
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
👉 Read Semperis' analysis of KerberLoss and ResetNightmare in Active Directory →
Active Directory Unicode abuse: what identity teams need to fix?
Explore further
11/08/2026 3:27 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Unicode identity confusion in Active Directory enables Domain Admin
