Im Kern steckt der Fehler in einem AD-CS-Einschreibungs-Fallback, den die Forscher als „Chase“ beschreiben. Kann eine Zertifizierungsstelle die Informationen einer Endeinheit nicht selbst abrufen, erlaubt das Windows-Einschreibungsprotokoll dem Antrag, mit „cdc“ den zu kontaktierenden Active-Directory-Server und mit „rmd“ das aufzulösende Maschinenobjekt anzugeben.
H0j3n und Aniq Fakhrul fanden heraus, dass die Zertifizierungsstelle dem vom Antragsteller gelieferten „cdc“-Host über Server Message Block und Lightweight Directory Access Protocol folgte, ohne zuvor zu prüfen, ob es sich tatsächlich um einen Domain Controller handelte. Ein Angreifer kann daher eigene LSA- und LDAP-Dienste betreiben, die Authentifizierungsanfrage der Zertifizierungsstelle über Netlogon an den echten Domain Controller weiterreichen und anschließend dessen objectSid und dNSHostName zurückgeben. Mit einem kontrollierten Maschinenkonto, das die benötigte gültige Domänenidentität liefert, setzt die Zertifizierungsstelle den Vorgang fort und signiert die Identität des angegriffenen Domain Controllers in das Zertifikat.
Der veröffentlichte Exploit automatisiert diese Kette. Er legt ein Computerkonto an oder verwendet ein mit „–computer-name“ angegebenes vorhandenes Konto weiter. Danach startet das Werkzeug Listener auf den Ports 445 und 389, leitet die Anfrage der Zertifizierungsstelle per Netlogon an den echten Domain Controller weiter, übermittelt die Attribute „cdc“ und „rmd“ und schreibt am Ende eine PFX-Datei sowie einen Kerberos-Credential-Cache.
Für die eigentliche Anmeldung als Zielsystem nutzt der Exploit PKINIT, also Public Key Cryptography for Initial Authentication in Kerberos. Die resultierende Anmeldeinformation kann dann über DCSync Kontogeheimnisse abrufen, darunter auch krbtgt.
Die Ausnutzung ist an mehrere Bedingungen geknüpft. Erforderlich sind laut den Forschern Netzwerkzugang und ein Domänenkonto, jedoch weder Administratorrechte noch Benutzerinteraktion. In ihrem Test konnte ein normales Konto aus der Gruppe Domain Users unter dem Standardwert von ms-DS-MachineAccountQuota von 10 ein Computerkonto anlegen oder ein bereits kontrolliertes Konto wiederverwenden. Zusätzlich war eine Enterprise CA nötig, die dem verwundbaren Pfad folgte, eine Einschreibung über die Standardvorlage „Machine“ sowie Netzwerk-Erreichbarkeit von der Zertifizierungsstelle zu den SMB- und LDAP-Listenern des Angreifers.
Microsoft klassifizierte CVE-2026-54121 als fehlerhafte Autorisierung. Laut Binäranalyse der Forscher ergänzt das Juli-Update in certpdef.dll die Funktion „CRequestInstance::_ValidateChaseTargetIsDC“, bevor die Zertifizierungsstelle einem Chase folgt. Diese Prüfung weist IP-Literale, überlange Namen und LDAP-Metazeichen zurück. Außerdem verlangt sie genau ein passendes Active-Directory-Computerobjekt, dessen DNS-Name mit dem Ziel übereinstimmt und dessen userAccountControl das Flag SERVER_TRUST_ACCOUNT (8192) enthält. Ein späterer SID-Abgleich verhindert zusätzlich das Austauschen von Objekten.
Getestet wurde der öffentliche Exploit in einer Windows-Server-2016-oder-neuer-Gesamtstruktur mit Enterprise CA, der Standard-Zertifikatsvorlage „Machine“ und der standardmäßigen Maschinenkonto-Quote. Der NVD-Eintrag führt separat Windows Server 2012 bis Windows Server 2025 einschließlich der aufgeführten Server-Core-Editionen als betroffen auf. Ebenfalls genannt werden Windows 10 Version 1607 und 1809.
Die Forscher meldeten die Schwachstelle am 14. Mai an Microsoft. Microsoft bestätigte sie am 22. Mai, stellte am 14. Juli einen Patch bereit und die Forscher veröffentlichten ihre Details am 24. Juli. Organisationen mit Enterprise CA sollten laut Quelltext die Juli-Updates auf AD-CS-Hosts installieren. Wenn ein sofortiges Patchen nicht möglich ist, beschrieben die Forscher einen im Labor getesteten Weg, das Chase-Fallback zu deaktivieren, indem das Chase-Flag entfernt und der Zertifikatsdienst neu gestartet wird. Sie weisen jedoch darauf hin, dass dies legitime Einschreibungsabläufe stören kann, und empfehlen das Juli-Update als dauerhafte Behebung.