Radioactive Directory

RC4 Kerberos Enforcement Loses Its Rollback — CVE-2026-20833

The last phase of Microsoft's RC4 removal has landed. Since the January 2026 cumulative updates, RC4 has not been one of the assumed Kerberos encryption types on a domain controller, with auditing added to surface accounts relying on it. April 2026 turned that into enforcement, blocking RC4 issued through assumed encryption types but leaving a rollback to audit mode. The July 2026 updates removed the rollback. If a service account still needs RC4 and you never configured for it explicitly, it is already failing, and there is no longer a switch to buy time with.

Explicit configuration is still honored: DefaultDomainSupportedEncTypes on the KDCs, or msDS-SupportedEncryptionTypes on the account with the RC4 bit set. RC4 is not being removed from Windows, only from the silent fallback path. Note the knock-on for offense as well as operations, since RC4 service tickets are what made Kerberoasting cheap. Full enforcement timeline here.

CVE-2026-25177 — "KerberLoss": Unicode SPN Collisions Enable DoS, SPN-Jacking, and Silent Kerberos→NTLM Downgrade (CVSS 8.8)

Microsoft's March 2026 Patch Tuesday (10 March) fixed a high-severity AD DS vulnerability disclosed by Semperis researcher Shai Laron and named KerberLoss. AD's LDAP server fails to normalise invisible Unicode characters when enforcing SPN and UPN uniqueness. Of the 385 such characters Semperis tested, only 106 are filterable via LDAP; the other 279 are treated as whitespace or ignored outright by the DC during string comparison. They are ignored on lookup but accepted on write, so an attacker with WriteSPN on any account they control can register an SPN that collides with a legitimate service while passing the duplicate-name check.

Three distinct outcomes fall out of that primitive:
1. Denial of service. Register a colliding SPN for a HOST-mapped service (e.g. cifs/SERVERB with an embedded invisible character) on an account you own. The KDC starts encrypting service tickets with your account's key, and the real server can no longer decrypt them — clients get KRB_AP_ERR_MODIFIED and the service is effectively offline.
2. SPN-jacking. The same collision bypasses SPN alias uniqueness without needing WriteSPN on the intermediate service, opening S4U2Self abuse against constrained-delegation hosts and compromise of delegation-enabled systems.
3. Kerberos→NTLM downgrade. Create an exact duplicate explicit SPN and the DC returns KDC_ERR_S_PRINCIPAL_UNKNOWN, forcing clients forest-wide to fall back to NTLM. Access keeps working, so nobody notices — but the authentication posture has been silently degraded to a relayable protocol.

Network-reachable, low complexity, no user interaction. Microsoft rates exploitation as "less likely" and it is not in the CISA KEV catalog, but the blast radius is wide. Patch DCs, restrict WriteSPN via least privilege, and hunt Event ID 5136 for conflicting SPN additions. Note that KerberLoss and ResetNightmare came out of the same Semperis research and were patched a month apart — one patch does not cover both.

Microsoft Announces 3-Phase Plan to Kill NTLM — Kerberos Migration Roadmap is Official

Microsoft has formally laid out a three-phase roadmap to deprecate NTLM across Windows. Phase 1 (available now) introduces enhanced NTLM auditing to identify where NTLM is still in use. Phase 2 (expected H2 2026) tackles common migration blockers with IAKerb and a local Key Distribution Center (KDC). Phase 3 will disable NTLM by default in the next Windows Server and client releases, requiring explicit re-enablement via policy. Worth noting: Windows Server 2025 and Windows 11 24H2 already remove NTLMv1, which is a real win, but only on those builds — Server 2019 and 2022, Windows 10 and Windows 11 up to 23H2 still ship it and still accept it unless you hardened LmCompatibilityLevel yourself. Even on the newest builds, remnants survive in SSO paths such as MS-CHAPv2 on domain-joined machines. Microsoft is closing that too: the BlockNTLMv1SSO default flips from Audit to Enforce in October 2026 on any machine where the key has not been set manually, so if you have been relying on audit mode to keep a legacy dependency alive, set the key deliberately before it flips under you. NTLMv2 is a different story entirely — it's deeply embedded in enterprise environments with far more dependencies, and actually removing it will be significantly harder. Phase 3 hinges on the "next major release," which for most orgs means a 5-10 year adoption horizon at best. The auditing in Phase 1 is genuinely useful, but don't hold your breath on NTLM disappearing anytime soon.

January Patch Tuesday Breaks Shadow Credentials — Tooling Already Updated

Microsoft's January 2026 cumulative update (KB5073723 for Server 2019, KB5073379 for Server 2025) introduced changes that broke Shadow Credentials attacks. The security community quickly diffed the patch and identified the changes. RedTeamPentesting has already updated their keycred tool (v1.2.1 at the time; v1.2.2 followed in July 2026) to work with the new requirements.