Meta Description: Die Schwachstelle Certighost ermöglicht unter bestimmten Bedingungen die Übernahme einer Active-Directory-Domäne. Was Unternehmen jetzt prüfen müssen.
Ein kompromittiertes Benutzerkonto ohne administrative Berechtigungen gilt normalerweise noch nicht als vollständige Katastrophe. Bei der neu veröffentlichten Schwachstelle Certighost, geführt als CVE-2026-54121, kann jedoch genau ein solches Standardkonto der Ausgangspunkt für eine vollständige Übernahme der Active-Directory-Domäne sein.
Betroffen ist nicht der Domain Controller selbst, sondern eine besonders sensible Vertrauenskomponente: die Active Directory Certificate Services, kurz AD CS. Unter bestimmten Voraussetzungen kann ein Angreifer die Zertifizierungsstelle dazu bringen, ein gültiges Zertifikat für einen Domain Controller auszustellen.
Der Angreifer kann sich anschließend gegenüber Kerberos als dieser Domain Controller authentifizieren. Damit stehen ihm im schlimmsten Fall Replikationsrechte und der Zugriff auf zentrale Domänengeheimnisse offen.
Microsoft veröffentlichte den Sicherheitspatch am 14. Juli 2026. Am 24. Juli 2026 veröffentlichten die Sicherheitsforscher H0j3n und Aniq Fakhrul eine technische Analyse sowie einen funktionierenden Proof of Concept. Der CVSS-Wert der Schwachstelle liegt bei 8,8 von 10 Punkten. (Gist)
Was ist Certighost?
Certighost bezeichnet eine Schwachstelle in der Verarbeitung von Zertifikatsanfragen durch eine Microsoft Enterprise Certification Authority.
AD CS stellt Zertifikate aus, die innerhalb einer Windows-Domäne unter anderem für Authentifizierung, Verschlüsselung und digitale Signaturen eingesetzt werden. Ein solches Zertifikat ist nicht lediglich eine Datei, sondern ein kryptografischer Identitätsnachweis.
Genau hier liegt das Problem: Wer ein gültiges Authentifizierungszertifikat für einen privilegierten Benutzer oder einen Domain Controller besitzt, kann sich gegenüber anderen Systemen als diese Identität ausgeben.
Die Schwachstelle befindet sich in einem als „Chase“ bezeichneten Ausweichmechanismus. Kann die Zertifizierungsstelle die Informationen zu einem Antragsteller nicht direkt auflösen, darf die Zertifikatsanfrage über die Attribute cdc und rmd angeben, welchen Verzeichnisserver die CA kontaktieren und welches Objekt sie dort suchen soll.
Vor dem Juli-Update überprüfte die CA nicht ausreichend, ob das vom Antragsteller angegebene Ziel tatsächlich ein legitimer Domain Controller war. Dadurch konnte sie Verzeichnisinformationen von einem durch den Angreifer kontrollierten System übernehmen. (Gist)
Wie läuft der Angriff ab?
Für das Verständnis des Risikos reicht eine vereinfachte Darstellung der Angriffskette:
- Ein Angreifer erlangt Zugriff auf ein gewöhnliches Domänenkonto.
- Er erstellt oder kontrolliert zusätzlich ein Computerkonto innerhalb der Domäne.
- Über eine manipulierte Zertifikatsanfrage veranlasst er die Enterprise CA, einen von ihm kontrollierten Host zu kontaktieren.
- Dieser Host liefert Identitätsinformationen eines echten Domain Controllers zurück.
- Die Zertifizierungsstelle übernimmt diese Informationen und stellt ein Zertifikat aus, das den Angreifer als Domain Controller ausweist.
- Das Zertifikat wird zur Kerberos-Authentifizierung über PKINIT verwendet.
- Mit der Identität des Domain Controllers kann der Angreifer Verzeichnisreplikationsfunktionen wie DCSync missbrauchen und unter anderem auf das Geheimnis des krbtgt-Kontos zugreifen.
Der veröffentlichte Proof of Concept automatisiert weite Teile dieser Kette. Er kann ein Computerkonto anlegen, die erforderlichen Netzwerkdienste bereitstellen, die Zertifikatsanfrage übermitteln und anschließend Kerberos-Anmeldedaten für den Ziel-Domain-Controller erzeugen. (Gist)
Der entscheidende Punkt: Für den Einstieg sind weder Domain-Admin-Rechte noch eine Interaktion eines Benutzers notwendig. Ein gültiges, niedrig privilegiertes Domänenkonto kann unter den passenden Rahmenbedingungen ausreichen.
Warum ist die Schwachstelle so gefährlich?
Viele Angriffe auf Active Directory bestehen aus mehreren Eskalationsstufen. Angreifer kompromittieren zunächst einen Arbeitsplatz, sammeln Zugangsdaten, bewegen sich seitlich durch das Netzwerk und suchen nach immer höheren Berechtigungen.
Certighost kann diesen Weg erheblich verkürzen.
Statt verschiedene administrative Konten zu übernehmen, greift der Angreifer die Identitäts- und Vertrauensinfrastruktur selbst an. Die Zertifizierungsstelle bestätigt ihm anschließend kryptografisch eine Identität, die er eigentlich nicht besitzen dürfte.
Das macht den Angriff aus drei Gründen besonders kritisch:
Die Ausgangsberechtigung ist niedrig.
Ein normales Domänenkonto kann genügen. Solche Konten sind durch Phishing, infizierte Endgeräte, Passwort-Wiederverwendung oder gestohlene Sessions vergleichsweise häufig erreichbar.
Das ausgestellte Zertifikat ist ein legitimer Identitätsnachweis.
Für nachgelagerte Systeme sieht die Authentifizierung zunächst gültig aus. Der Angreifer verwendet kein erratenes Domain-Admin-Passwort, sondern ein von der internen CA signiertes Zertifikat.
Das mögliche Ergebnis ist eine vollständige Domänenkompromittierung.
Durch die Identität eines Domain Controllers erhält der Angreifer Zugriff auf besonders weitreichende Active-Directory-Funktionen. Dazu kann die Replikation von Passwort-Hashes und anderen sensiblen Verzeichnisdaten gehören. (Gist)
Ist jede Active-Directory-Umgebung betroffen?
Nein. Eine vorhandene Windows-Domäne allein reicht für den Angriff nicht aus.
Die Forscher demonstrierten die Angriffskette in einer Umgebung mit folgenden Eigenschaften:
- Eine Microsoft Enterprise Certification Authority war vorhanden.
- Die CA nutzte den verwundbaren Chase-Verarbeitungspfad.
- Das standardmäßige Machine-Zertifikatstemplate konnte verwendet werden.
- Das Konto durfte ein Computerkonto erstellen oder kontrollierte bereits eines.
- Die Zertifizierungsstelle konnte die vom Angreifer bereitgestellten SMB- und LDAP-Dienste erreichen.
- Die Sicherheitsupdates vom Juli 2026 waren auf dem AD-CS-System noch nicht wirksam.
Im Test nutzten die Forscher außerdem den Standardwert des Attributs ms-DS-MachineAccountQuota. Dieser erlaubt Domänenbenutzern üblicherweise die Erstellung von bis zu zehn Computerkonten. Die Existenz dieses Standardwerts bedeutet jedoch nicht automatisch, dass jede Umgebung erfolgreich ausnutzbar ist. Die gesamte Zertifikats- und Netzwerkkonfiguration muss betrachtet werden. (Gist)
Unternehmen sollten daher weder in Panik verfallen noch das Problem vorschnell als „nicht relevant“ einstufen. Entscheidend ist eine gezielte Prüfung der eigenen AD-CS-Architektur.
Was verändert der Microsoft-Patch?
Mit den Sicherheitsupdates vom 14. Juli 2026 ergänzt Microsoft eine Validierung des angegebenen Chase-Ziels.
Die Zertifizierungsstelle prüft nun, ob der übermittelte Hostname tatsächlich zu einem eindeutigen Computerobjekt in Active Directory gehört, das als Domain Controller gekennzeichnet ist. Zusätzlich werden unter anderem IP-Adressen, überlange Hostnamen und bestimmte LDAP-Sonderzeichen abgewiesen. Eine weitere SID-Prüfung soll verhindern, dass ein anderes Verzeichnisobjekt untergeschoben wird.
Der grundlegende Vertrauensfehler wird damit geschlossen: Die Zertifizierungsstelle akzeptiert einen erreichbaren Host nicht mehr allein deshalb als Domain Controller, weil dieser auf die Anfrage antwortet. (Gist)
Was Unternehmen jetzt tun sollten
1. Vorhandene AD-CS-Systeme identifizieren
Zunächst muss geklärt werden, ob im Unternehmen überhaupt Active Directory Certificate Services betrieben werden.
Besonders relevant sind Enterprise CAs, die Zertifikate für Benutzer und Computer innerhalb der Domäne ausstellen. Dabei sollten auch historisch gewachsene PKI-Systeme, untergeordnete CAs und nur noch selten genutzte Zertifizierungsstellen berücksichtigt werden.
Eine CA, die niemand mehr aktiv betreut, ist nicht automatisch ungefährlich.
2. Juli-Updates auf den CA-Systemen installieren
Die höchste Priorität hat die Installation der Microsoft-Sicherheitsupdates vom 14. Juli 2026 auf allen betroffenen AD-CS-Hosts.
Es genügt nicht, lediglich die Domain Controller zu aktualisieren. Die verwundbare Verarbeitung findet auf dem System statt, das die Enterprise Certification Authority betreibt.
Nach der Installation sollte kontrolliert werden, ob das Update tatsächlich erfolgreich angewendet wurde und ob alle erforderlichen Neustarts beziehungsweise Dienstneustarts erfolgt sind.
3. Zertifikatstemplates und Enrollment-Rechte überprüfen
Unternehmen sollten prüfen, welche Benutzer und Gruppen Zertifikate über Maschinen- und Authentifizierungstemplates anfordern dürfen.
Dabei geht es nicht nur um Certighost. Zu weit gefasste Enrollment-Rechte, unsichere Template-Einstellungen und unzureichend kontrollierte Subject-Informationen sind seit Jahren ein häufiger Ausgangspunkt für Angriffe auf AD CS.
Die PKI sollte daher als Teil der privilegierten Active-Directory-Infrastruktur behandelt und regelmäßig auditiert werden.
4. Machine Account Quota bewerten
Der Standardwert von ms-DS-MachineAccountQuota sollte nicht ungeprüft übernommen werden.
Benötigen normale Benutzer wirklich das Recht, selbstständig Computerobjekte in der Domäne anzulegen? In vielen Unternehmensumgebungen lautet die Antwort: nein.
Eine Reduzierung auf null kann die Angriffsfläche verkleinern. Vor einer Änderung müssen allerdings bestehende Deployment-, Imaging- und Join-Prozesse geprüft werden. Die Maßnahme ersetzt außerdem nicht den Microsoft-Patch.
5. Netzwerkzugriffe der Zertifizierungsstelle einschränken
Aus dem veröffentlichten Angriffspfad lässt sich eine wichtige Architekturmaßnahme ableiten: Eine Zertifizierungsstelle sollte nicht beliebige Systeme über SMB oder LDAP erreichen können.
Ausgehende Verbindungen der CA sollten auf die tatsächlich benötigten Domain Controller und administrativen Dienste begrenzt werden. Erreicht die CA ohne Einschränkungen Benutzer-, Client- oder Servernetzwerke, ist die Segmentierung wahrscheinlich zu großzügig.
Eine CA gehört in ein besonders geschütztes Netzwerksegment und sollte ähnlich restriktiv behandelt werden wie Domain Controller.
6. Verdächtige Aktivitäten überwachen
Security-Teams sollten insbesondere auf folgende Auffälligkeiten achten:
- unerwartete Erstellung neuer Computerkonten,
- ungewöhnliche Zertifikatsanfragen über Machine-Templates,
- Verbindungen der CA zu nicht autorisierten SMB- oder LDAP-Systemen,
- Zertifikate mit Identitätsmerkmalen eines Domain Controllers,
- ungewöhnliche PKINIT-Authentifizierungen,
- verdächtige Verzeichnisreplikationsaktivitäten.
Diese Indikatoren sind aus der veröffentlichten Angriffskette abgeleitet. Einzelne Ereignisse beweisen noch keinen Angriff, können aber wertvolle Hinweise für die Untersuchung liefern. (Gist)
Was tun, wenn der Patch nicht sofort installiert werden kann?
Die Forscher beschreiben als vorübergehende Mitigation das Abschalten des Chase-Fallbacks:
certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force
Diese Maßnahme wurde nach Angaben der Forscher nur in einer kontrollierten Laborumgebung getestet. Sie kann legitime Zertifikatsanforderungen beeinträchtigen, die auf diesen Ausweichmechanismus angewiesen sind.
Eine Umsetzung sollte daher zunächst in einer repräsentativen Testumgebung erfolgen. Das Deaktivieren des Features ist ausdrücklich kein Ersatz für das Sicherheitsupdate. (Gist)
Einordnung aus IT-Consulting-Sicht
Certighost ist ein gutes Beispiel dafür, warum Active-Directory-Sicherheit nicht bei Domain-Admin-Konten und Gruppenrichtlinien endet.
Die interne Zertifizierungsinfrastruktur bildet eine zweite Identitätsebene. Ein Unternehmen kann seine Passwörter, privilegierten Gruppen und Domain Controller sorgfältig absichern – und dennoch über eine falsch konfigurierte oder ungepatchte CA vollständig kompromittiert werden.
In vielen Organisationen wird AD CS allerdings weiterhin wie ein statischer Infrastrukturdienst behandelt: einmal installiert, selten verändert und nur dann beachtet, wenn ein Zertifikat abläuft.
Dieser Ansatz ist nicht mehr vertretbar.
Zertifizierungsstellen, Templates, Enrollment-Berechtigungen, private Schlüssel, Netzwerkverbindungen und Protokolldaten müssen Bestandteil des regulären Identity-Security- und Vulnerability-Managements sein. Dazu gehören dokumentierte Verantwortlichkeiten, regelmäßige Reviews und getestete Notfallprozesse.
Fazit
Certighost zeigt, wie schnell sich eine vermeintlich geringe Ausgangsberechtigung in eine vollständige Kompromittierung der Windows-Domäne verwandeln kann.
Die gute Nachricht: Microsoft hat die Schwachstelle bereits am 14. Juli 2026 geschlossen.
Die schlechte Nachricht: Seit dem 24. Juli steht ein funktionierender Proof of Concept öffentlich zur Verfügung. Zum Zeitpunkt seiner Veröffentlichung lagen zwar keine öffentlich bestätigten Berichte über eine aktive Ausnutzung vor. Das ist jedoch kein Grund, mit der Behebung zu warten. (The Hacker News)
Unternehmen mit einer Microsoft Enterprise CA sollten deshalb unverzüglich den Patchstand prüfen. Gleichzeitig bietet der Vorfall einen sinnvollen Anlass, die gesamte AD-CS-Architektur zu überprüfen.
Denn eine interne Zertifizierungsstelle ist kein gewöhnlicher Windows-Server. Sie entscheidet darüber, welchen Identitäten das Unternehmen vertraut.