Kerberos attacks are usually explained through stolen tickets, cracked service-account passwords, or forged credentials. KerberLoss and ResetNightmare are more uncomfortable: they target the directory logic that decides which identity owns a service and what a password reset is allowed to mean.

Semperis researcher Shai Laron presented the two vulnerabilities at Black Hat USA 2026. Microsoft patched CVE-2026-25177 in March and CVE-2026-27912 in April. The public technical discussion makes the operational lesson timely now: low-privileged directory write paths can have authentication consequences far beyond the object being edited.

TL;DR

  • Patch domain controllers for CVE-2026-25177 and CVE-2026-27912.
  • Audit delegated permissions that allow users or service principals to modify SPNs or reset passwords.
  • Detect abnormal servicePrincipalName changes and unexpected Kerberos-to-NTLM fallback.
  • Treat identity configuration as executable security logic, not harmless metadata.

KerberLoss: Break the Name-to-Service Decision

Kerberos uses a service principal name (SPN) to associate a service instance with an account. Active Directory is expected to enforce uniqueness: if two objects claim the same service identity, authentication becomes ambiguous and unsafe.

CVE-2026-25177, called KerberLoss by the researcher, concerns how Active Directory validates names during SPN uniqueness checks. Under the required permissions, crafted name handling can interfere with that protection. The resulting impact can include service disruption, service identity manipulation, and authentication falling back from Kerberos to NTLM.

That downgrade matters because NTLM has different trust properties and remains exposed to relay attacks in many environments. KerberLoss does not automatically relay credentials, but it can help create the condition in which clients stop using the stronger protocol defenders expected.

ResetNightmare: Password Reset Is Not a Small Permission

CVE-2026-27912 affects Windows Kerberos authorization. Semperis describes ResetNightmare as a logic flaw through which a low-privileged user with the necessary directory conditions can target accounts, including privileged ones, and build a path toward domain takeover.

The exact exploit chain has prerequisites; an ordinary account does not become Domain Admin merely by existing. The defensive mistake is focusing only on direct group membership while overlooking delegated reset rights, object-control permissions, and identity workflows that can change who is able to authenticate as whom.

🔴 RED TEAM — Abuse the Directory’s Own Rules

Low-privileged domain foothold
        ↓
Discover delegated SPN or password-reset permissions
        ↓
Exploit vulnerable name or authorization logic
        ↓
Disrupt Kerberos, redirect service identity, or alter account access
        ↓
Use NTLM fallback or privileged account control for lateral movement

This path is attractive because many steps resemble administration. LDAP modifications, service-account maintenance, and password resets are normal events. The attack is visible when defenders can distinguish the right administrator changing the right object during the right window from everything else.

🔵 BLUE TEAM — Patch the Domain Controllers First

Apply Microsoft’s March 2026 fixes for CVE-2026-25177 and April 2026 fixes for CVE-2026-27912 to every domain controller. Mixed patch levels are risky because clients do not promise to select the safest controller for every operation.

Unsupported domain controllers need a migration or an explicitly evaluated extended-support strategy. A third-party micropatch can reduce risk in constrained legacy environments, but it should not become a permanent substitute for a supported identity platform.

Audit Dangerous Delegation

Review who can:

  • write or modify servicePrincipalName attributes;
  • reset passwords on users, computers, and service accounts;
  • change ownership, discretionary ACLs, or group membership on identity objects;
  • create computer accounts or modify accounts used by critical services;
  • administer organizational units containing privileged or tier-zero identities.

Remove inherited or historical delegations that no current workflow requires. Test the business process after tightening permissions; identity outages have a way of restoring dangerous rights in a hurry.

Detect Changes and Downgrades

Enable and centralize directory-service-change auditing. Windows Event ID 5136 can record object attribute modifications when the appropriate audit policy and SACLs are configured. Correlate SPN changes with the actor, target distinguished name, originating host, change ticket, and subsequent authentication behavior.

Also investigate:

  • bursts of SPN additions, deletions, or near-duplicate values;
  • password resets on privileged or rarely changed accounts;
  • Event ID 4742 changes to computer accounts and relevant user-account events;
  • Kerberos failures followed by NTLM authentication to the same service;
  • NTLM activity from systems that normally use Kerberos exclusively;
  • service outages immediately following directory modifications.

Do not alert on every 5136 event without context. Directory synchronization and legitimate administration can generate volume. Focus on protected objects, sensitive attributes, unusual actors, and changes outside approved windows.

What to Do Today

  1. Verify March and April 2026 security updates on all domain controllers.
  2. Enumerate principals with SPN-write and password-reset permissions.
  3. Remove stale delegation and tier privileged identities separately.
  4. Alert on suspicious SPN changes and Kerberos-to-NTLM fallback.
  5. Test whether critical services can operate with NTLM restricted or disabled.

Kerberos is not secured only by protecting krbtgt. The directory attributes and permissions feeding the protocol are part of the authentication boundary too.

Sources