Certighost (CVE-2026-54121) — Wie ein Standard-Konto die ganze Domäne übernimmt

Ein Zertifikat, das die Domäne öffnet

Am 14. Juli 2026 schloss Microsoft im Rahmen des Patch Tuesday eine Schwachstelle in Active Directory Certificate Services (AD CS), die unter dem Namen „Certighost" (CVE-2026-54121) geführt wird. Microsoft klassifiziert sie als Elevation of Privilege mit einem CVSS-Wert von 8.8 und stufte die Ausnutzung zunächst als „weniger wahrscheinlich" ein. Diese Einschätzung ist überholt, seit Sicherheitsforscher rund zehn Tage nach dem Patch, am 24. Juli 2026, einen funktionsfähigen Proof-of-Concept auf GitHub (Repository aniqfakhrul/CVE-2026-54121) veröffentlichten. Der öffentlich verfügbare Exploit-Code senkt die Hürde für Angreifer erheblich und macht eine Ausnutzung deutlich wahrscheinlicher als noch am Patch Tuesday absehbar.

Das Beunruhigende an Certighost ist die niedrige Einstiegshürde: Ein Angreifer benötigt kein privilegiertes Konto, keine Administratorrechte und keine Interaktion eines Opfers. Ein gewöhnliches Domänenbenutzerkonto mit Netzwerkzugang reicht aus, um die Zertifizierungsstelle dazu zu bringen, ein Zertifikat auszustellen, das die Identität eines Domain Controllers trägt. Von dort ist es nur ein kleiner Schritt bis zur vollständigen Übernahme der Domäne.

Wer AD CS betreibt und die Juli-Updates noch nicht auf allen Zertifizierungsstellen eingespielt hat, sollte diesen Artikel als Weckruf verstehen. AD CS ist Teil der Tier-0-Infrastruktur: Eine kompromittierte Enterprise-CA ist gleichbedeutend mit einer kompromittierten Domäne.

Warum AD CS ein so lohnendes Ziel ist

AD CS ist die PKI-Rolle von Microsoft. Sie stellt digitale Zertifikate aus, die für Smartcard-Anmeldung, TLS-Verschlüsselung, VPN-Zugang und die Authentifizierung von Maschinen im Netzwerk verwendet werden. Genau diese Authentifizierungsfunktion macht AD CS für Angreifer so attraktiv: Ein Zertifikat, das eine bestimmte Identität bescheinigt, lässt sich über das Kerberos-Verfahren PKINIT (Public Key Cryptography for Initial Authentication) in ein gültiges Kerberos-Ticket umwandeln. Wer ein Zertifikat für ein privilegiertes Konto erhält, kann sich als dieses Konto anmelden — ganz ohne dessen Passwort.

Seit der Veröffentlichung des Forschungsberichts „Certified Pre-Owned" durch SpecterOps im Jahr 2021 ist eine ganze Familie von AD-CS-Angriffstechniken bekannt. Der ursprüngliche Bericht beschrieb die Techniken ESC1 bis ESC8; in den Folgejahren wuchs die Familie durch weitere Forschende auf inzwischen ESC16 an. Certighost reiht sich in diese Tradition ein, unterscheidet sich aber in einem wichtigen Punkt: Die Lücke steckt nicht in einer fehlkonfigurierten Zertifikatvorlage, die ein Administrator hätte anders einrichten können, sondern im Verhalten der Zertifizierungsstelle selbst. Die Standardkonfiguration genügt.

Wie der Angriff technisch funktioniert

Der Kern von Certighost ist ein Fehler in einem Fallback-Mechanismus der Enterprise-CA, den die Forschenden als „chase" bezeichnen. In Umgebungen mit mehreren Domain Controllern kann es vorkommen, dass die CA einen anfragenden Prinzipal nicht auf ihrem primären Verzeichnisserver findet. In diesem Fall führt sie eine sekundäre Auflösung durch und kontaktiert dafür einen anderen Verzeichnisserver — und genau hier setzt der Angriff an.

Der Angriff läuft in mehreren Schritten ab:

1. Maschinenkonto anlegen. Der Angreifer nutzt das Standardattribut ms-DS-MachineAccountQuota (Voreinstellung: 10), das jedem Domänenbenutzer erlaubt, bis zu zehn Computerkonten anzulegen. Das ist seit Jahren ein beliebter Einstiegspunkt für AD-Angriffe.
2. Rogue-Verzeichnisdienst bereitstellen. Auf einem kontrollierten Host stellt der Angreifer einen gefälschten LDAP-Dienst bereit, der auf Anfragen mit manipulierten Identitätsdaten antwortet.
3. Enrollment mit manipulierten Attributen. Bei der Zertifikatsanforderung über die Standard-Maschinenvorlage setzt der Angreifer zwei Request-Attribute: cdc (Client DC) benennt den Host, den die CA kontaktieren soll, und rmd (Remote Domain) benennt den nachzuschlagenden Prinzipal.
4. CA kontaktiert den Angreifer-Host. Die CA öffnet SMB- und LDAP-Verbindungen zu dem im cdc-Attribut angegebenen Host — ohne vorher zu prüfen, ob es sich tatsächlich um einen echten Domain Controller handelt.
5. Gefälschte Identität liefern. Der Rogue-LDAP-Dienst antwortet mit den Identitätsmerkmalen eines echten Domain Controllers, insbesondere dessen objectSid und dNSHostName.
6. Zertifikat wird ausgestellt. Die CA stellt ein Zertifikat aus, das die Identität des Ziel-Domain-Controllers trägt.
7. PKINIT-Anmeldung. Der Angreifer nutzt das Zertifikat per PKINIT, um ein Kerberos-Ticket für das Domain-Controller-Konto zu erhalten.
8. DCSync und vollständige Kompromittierung. Mit den Rechten eines Domain Controllers führt der Angreifer einen DCSync-Angriff durch, extrahiert das Geheimnis des krbtgt-Kontos und kontrolliert damit die gesamte Domäne.

Microsoft beschreibt den Kern nüchtern: Ein authentifizierter Angreifer könne „Attribute eines Maschinenkontos manipulieren und ein Zertifikat von AD CS erhalten, das die Authentifizierung als diese Maschine per PKINIT erlaubt". Der eigentliche Fehler liegt darin, dass die CA einem vom Anfragenden gelieferten Verzeichnisziel vertraut, ohne dessen Echtheit zu verifizieren.

Die Nähe zu Certifried — und der Unterschied

Wer die AD-Sicherheitslage der letzten Jahre verfolgt hat, wird sich an „Certifried" (CVE-2022-26923) erinnert fühlen. Auch dort ging es um ein Maschinenkonto, ein manipuliertes dNSHostName-Attribut und ein Zertifikat, das per PKINIT in eine Domänenübernahme mündete. Microsoft begegnete Certifried damals mit der starken Zertifikatzuordnung (Strong Certificate Mapping), die über KB5014754 ausgerollt und Anfang 2025 in den Erzwingungsmodus überführt wurde.

Certighost zeigt, dass diese Härtung das Problemfeld nicht abschließend geschlossen hat. Der neue Angriff verlagert die Manipulation weg von den Attributen des eigenen Kontos hin zur Antwort eines Rogue-Verzeichnisdienstes, den die CA im „chase"-Fallback kontaktiert. Die starke Zertifikatzuordnung hilft hier nicht zuverlässig, weil das ausgestellte Zertifikat sauber auf das Ziel-DC-Konto abgebildet wird — die CA wurde ja gerade dazu gebracht, es für diese Identität auszustellen. Der einzige verlässliche Riegel ist der Patch selbst, der das „chase"-Ziel vor dem Verzeichnis-Lookup validiert.

Betroffene Systeme und Patch-Stand

Betroffen sind Windows-Server-Versionen von 2012 bis 2025, ausdrücklich auch Server-Core-Installationen, sofern die AD-CS-Rolle als Enterprise-CA im Active Directory integriert ist. Voraussetzung für die Ausnutzung sind lediglich die Enrollment-Berechtigung über die Standard-Maschinenvorlage sowie SMB- und LDAP-Erreichbarkeit — beides in typischen Umgebungen gegeben.

Der Patch vom 14. Juli 2026 ergänzt im Enterprise-Policy-Modul (certpdef.dll) eine Prüffunktion, die sicherstellt, dass das im cdc-Attribut angegebene Ziel tatsächlich ein im Verzeichnis registrierter Domain Controller ist. Ein Detail sollten Administratoren dabei kennen: Die Forschenden weisen darauf hin, dass die neue Prüfung an einen internen Feature-Schalter (Feature_3185813818) gekoppelt ist. Nach dem Einspielen des Updates empfiehlt es sich daher, die Wirksamkeit der Härtung aktiv zu verifizieren, statt sie als selbstverständlich vorauszusetzen.

Zum Zeitpunkt dieses Artikels sind keine Angriffe in freier Wildbahn dokumentiert, und die Lücke ist nicht im KEV-Katalog der US-Behörde CISA gelistet. Microsoft beobachtet Aktivitäten von Sicherheitsforschenden, hat aber noch keinen aktiven Missbrauch durch böswillige Akteure bestätigt. Diese Ausgangslage kann sich nach der PoC-Veröffentlichung schnell ändern — funktionsfähiger Exploit-Code senkt die Hürde für Ransomware-Gruppen erheblich.

Sofortmaßnahmen für Betreiber

Die wichtigste Maßnahme ist eindeutig: Das Juli-2026-Update auf allen Enterprise-Zertifizierungsstellen einspielen. Anders als bei vielen AD-CS-Fehlkonfigurationen lässt sich Certighost nicht durch das Umstellen einer Zertifikatvorlage entschärfen — der Fehler steckt im Verhalten der CA, und nur der Patch behebt ihn.

Wo ein sofortiges Patchen im Ausnahmefall nicht möglich ist, lässt sich der optionale cdc-Chase-Mechanismus vorübergehend über die Registry deaktivieren. Dazu wird das entsprechende EditFlag entfernt und der CA-Dienst neu gestartet:

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force

Diese Maßnahme ist als Übergangslösung gedacht — sie ersetzt den Patch nicht, sondern verschafft im Notfall Zeit. Prüfen Sie vor dem Einsatz, ob der Chase-Mechanismus in Ihrer Umgebung produktiv benötigt wird.

Über die reine Fehlerbehebung hinaus lohnt es sich, das lange bekannte ms-DS-MachineAccountQuota zu überdenken. Der Standardwert von 10 erlaubt jedem Benutzer das Anlegen von Maschinenkonten und ist Voraussetzung für zahlreiche AD-Angriffe, nicht nur für Certighost. In den meisten Umgebungen gibt es keinen fachlichen Grund, dieses Recht allen Benutzern einzuräumen — ein Wert von 0 in Kombination mit einer delegierten Verwaltung von Computerkonten schließt diesen Einstiegspunkt dauerhaft.

Angriffe erkennen

Selbst nach dem Patchen bleibt die Frage: Wurde die Lücke in der Zeit vor dem Update bereits ausgenutzt? Microsoft Defender for Identity erkennt verdächtige Zertifikatsanforderungen und löst dabei eine Warnung mit der Bezeichnung „Potential Certighost (CVE-2026-54121) AD CS abuse" aus. Umgebungen mit entsprechender Lizenzierung sollten diese Alarme priorisiert behandeln.

Unabhängig von Defender empfiehlt Microsoft, die Überwachung der Zertifikatdienste sowohl für erfolgreiche als auch für fehlgeschlagene Vorgänge zu aktivieren. Zwei Windows-Ereignisse sind dabei zentral: 4886 (Zertifikat angefordert) und 4887 (Zertifikat ausgestellt). Auffällig sind insbesondere Zertifikate, die über eine Maschinenvorlage angefordert wurden und unerwartete Domain-Controller-Identitätsmerkmale enthalten — ein deutliches Indiz für einen Certighost-Versuch.

Diese Detection-Logik gehört idealerweise in ein SIEM, das die AD-CS-Ereignisse zentral sammelt und mit weiteren Auffälligkeiten korreliert — etwa dem plötzlichen Anlegen neuer Maschinenkonten oder ungewöhnlichen DCSync-Mustern. Erst die Kombination aus Patch, Härtung und kontinuierlicher Überwachung schließt das Zeitfenster, in dem ein bereits erfolgter Angriff unbemerkt bleiben könnte.

Einordnung: AD CS gehört auf die Prioritätenliste

Certighost ist kein exotischer Sonderfall, sondern das jüngste Beispiel eines Musters: AD CS ist eine hochprivilegierte, oft stiefmütterlich behandelte Komponente, deren Kompromittierung direkt zur Domänenübernahme führt. Viele Organisationen betreiben Zertifizierungsstellen, die vor Jahren aufgesetzt und seither kaum überprüft wurden. Wir finden in Assessments regelmäßig CAs, deren Konfiguration, Vorlagenberechtigungen und Überwachung nicht auf dem Stand der aktuellen Bedrohungslage sind.

Die richtige Konsequenz aus Certighost ist nicht nur das Einspielen eines Patches, sondern die Einordnung von AD CS als Tier-0-System — mit demselben Schutzniveau, denselben Zugriffskontrollen und derselben Überwachung wie die Domain Controller selbst. Ein sauberes Patch-Management, eine restriktive Vorlagenverwaltung und die Aufnahme von AD-CS-Ereignissen in die Detection sind die Bausteine, die aus einem reaktiven Notfall eine beherrschbare Routine machen.

Ihre Zertifizierungsstelle auf dem Prüfstand. Im Rahmen unseres Identity & Access Hardening analysieren wir Ihre AD-CS-Konfiguration auf ausnutzbare Vorlagen, überprüfen Berechtigungen und Maschinenkonten-Quota und richten die Detection für Zertifikatsmissbrauch ein — damit Certighost und verwandte Angriffe erkannt und blockiert werden, bevor daraus eine Domänenübernahme wird. Sprechen Sie mit uns über eine AD-CS-Härtung.