KerberLoss: patch the DCs, then hunt the invisible ink

03 Affected

Every supported Windows Server version before the March 2026 updates: Server 2012 through Server 2025, all domain functional levels (it's a DC build-level fix, the functional level is irrelevant). MSRC frames the bug as covering UPNs as well as SPNs, so user accounts are in scope too, not just service accounts.

Fixed builds, per NVD's CPE data (cross-checked against the pyKerberloss README, which lists the same):

• Server 2012: 6.2.9200.25973
• Server 2012 R2: 6.3.9600.23074
• Server 2016: 10.0.14393.8957
• Server 2019: 10.0.17763.8511
• Server 2022: 10.0.20348.4893
• Server 2022 23H2: 10.0.25398.2207
• Server 2025: 10.0.26100.32522

The priority is every domain controller, then anywhere NTLM fallback would be juicy: file servers, certificate authorities, anything Tier-0.

04 Detection

Before we change anything, let's see what we're dealing with. One honest caveat up front, because the detection angle doing the rounds on social media is too narrow: hunting setspn.exe command lines only catches the version of this attack someone simulates with setspn. The public PoC writes SPNs over raw LDAP from Linux, which produces no process-creation telemetry on any Windows host at all, and the Semperis research used direct directory writes too. SPN writes are LDAP modify operations; the client tool is arbitrary. So treat the process-based rule below as one layer, and the directory-side signals as the durable ones.

First, are the DCs patched?

Get-ComputerInfo | Select-Object OsBuildNumber,OsUBR

The directory sweep, the single highest-value check (adapted from Forestall's writeup):

Get-ADObject -LDAPFilter '(servicePrincipalName=*)' -Properties servicePrincipalName |
  ForEach-Object { $_.servicePrincipalName } | Sort-Object -Unique |
  Where-Object { $_ -cmatch '[^ -~]' }

The near-duplicate hunt, which is the real tell (byte-identical duplicate SPNs are a common hygiene problem; raw-vs-normalised mismatches are this attack):

$invisible = [char]0x200B,[char]0x200C,[char]0x200D,[char]0x200E,[char]0x200F,[char]0x2060,[char]0xFEFF
Get-ADObject -LDAPFilter '(servicePrincipalName=*)' -Properties servicePrincipalName |
  ForEach-Object { $_.servicePrincipalName } |
  Group-Object { ($_.ToCharArray() | Where-Object { $invisible -notcontains $_ }) -join '' } |
  Where-Object Count -gt 1 | Select-Object Name,Count

Directory-change auditing, if you have it on (it is off by default, per TrustedSec's DACL-detections guide):

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5136} -MaxEvents 500 |
  Where-Object Message -match 'servicePrincipalName'

And the process-creation layer, for completeness. If you simulate the attack with PowerShell and setspn, you get two 4688 events: the parent powershell.exe shows [char]0x200B as visible text, the child setspn.exe receives the real, invisible character. So search the child for the Unicode codepoints, not the literal string. A Sigma rule for exactly that:

title: KerberLoss Detection - Zero-Width SPN Injection (CVE-2026-25177)
id: 5a8a1234-abcd-4e67-8901-23456789abcd
status: production
description: Detects setspn.exe execution containing invisible zero-width Unicode characters used to bypass SPN uniqueness checks.
author: Marko Mladenovic
date: 2026/08/26
tags:
 - attack.privilege_escalation
 - attack.t1098
 - attack.defense_evasion
 - attack.t1558
logsource:
 category: process_creation
 product: windows
detection:
 selection:
 Image|endswith: '\setspn.exe'
 CommandLine|re: '.*[\u200B\u200C\u200D\u200E\u200F\u2060\uFEFF].*'
 condition: selection
falsepositives:
 - Highly unlikely. Legitimate SPN configuration does not use zero-width Unicode.
level: high

❗ Three gotchas before you deploy it. First, the 4688 CommandLine field is empty by default; it needs the GPO "Audit Process Creation → Include command line in process creation events" (Microsoft's Event 4688 doc). Second, regex syntax differs per SIEM. QRadar's rule engine is Java regex, so \u200B works verbatim — this one is confirmed, not theoretical: Marko Mladenovic (co-author of this guide) built and tested the QRadar version of this rule, a custom rule over 4688 process-creation events with the image ending in \setspn.exe and the command line matching the same character class, and it fires. KQL/Sentinel uses RE2, where \u200B is not supported, so use [\x{200B}\x{200C}\x{200D}\x{200E}\x{200F}\x{2060}\x{FEFF}] or simply \p{Cf} (the Unicode format-character category, which covers all of them); if your tenant behaves differently, test both \u200B and \x{200B} against your own events. Splunk is PCRE-based and takes \x{200B}. Third, if your pipeline strips non-printable characters at ingest, no regex will save you: verify against raw events before trusting any of this.

Worth watching on the Kerberos side too: spikes of KDC_ERR_S_PRINCIPAL_UNKNOWN on previously healthy SPNs, and RC4 (etype 23) tickets appearing for services that normally do AES, which is the downgrade fingerprint the pyKerberloss README calls out when a user account holds the shadowed SPN. And if you want a ready-made scanner, danaug23/detect_CVE-2026-25177 is a read-only community tool that flags non-printable characters in SPNs, duplicates and recent SPN modifications. One caveat from the research itself: because the DC ignores the worst offenders, server-side LDAP filters can't match them, which is why all of this hunts in event logs and offline sweeps rather than LDAP queries.

05 Remediation

Install-Module PSWindowsUpdate; Get-WindowsUpdate -Install -AcceptAll

Set-ADObject <victim-DN> -Remove @{servicePrincipalName='<poisoned-SPN-from-the-sweep>'}

auditpol /set /subcategory:"Directory Service Changes" /success:enable

Set-SmbServerConfiguration -RequireSecuritySignature $true -EnableSecuritySignature $true -Confirm:$false

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 5

06 Verification

Patched, swept and hardened? Let's prove it rather than assume it.

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID,InstalledOn

Get-ADObject -LDAPFilter '(servicePrincipalName=*)' -Properties servicePrincipalName |
  ForEach-Object { $_.servicePrincipalName } | Where-Object { $_ -cmatch '[^ -~]' }

auditpol /get /subcategory:"Directory Service Changes"

For a functional check, the PoC doubles as the verifier: pyKerberloss's --check action plants and removes a colliding SPN, and per its README it fails cleanly against a patched DC, while --audit gives a read-only sweep. I've not run it against every build in the table, so treat that as the README's claim and verify in a lab first.

07 Rollback

The realistic rollback is the hardening, not the patch. If SMB signing breaks a legacy client that can't be fixed quickly, relax it on that scope while you remediate properly:

Set-SmbServerConfiguration -RequireSecuritySignature $false -Confirm:$false

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 3

Rolling back the security update itself is almost never justified: it reopens a publicly documented privilege escalation with a working PoC. If a cumulative update breaks something line-of-business, fix forward, or uninstall that specific KB while keeping the directory sweep and the write-permission review in place.

wusa /uninstall /kb:NNNNNNN /norestart

08 References

• NVD, CVE-2026-25177 ↗
• Microsoft Security Update Guide, CVE-2026-25177 ↗
• Semperis, Identity Crisis (Shai Laron's disclosure writeup) ↗
• Forestall, KerberLoss deep-dive, with detection queries ↗
• felixbillieres/pyKerberloss, public PoC and audit tool ↗
• danaug23/detect_CVE-2026-25177, read-only scanner ↗
• Microsoft KB5008382, the 2021 SPN/UPN uniqueness checks ↗
• Microsoft, Event 4688 (command-line auditing) ↗
• TrustedSec, DACL-based detections (5136 is off by default) ↗

If I've got anything wrong here, or you've hit an edge case I haven't covered, do say, corrections and questions are always welcome :)

exit(0);