Certighost (CVE-2026-54121): Jeder AD-Konto kann sich als Domain-Controller ausgeben

Cybersicherheit yesterdayZu Lesezeichen hinzufügen

Certighost (CVE-2026-54121): Jeder AD-Konto kann sich als Domain-Controller ausgeben
Illustration : Momiji Shirogane

CVE-2026-54121, CVSS 8.8. Ein Domänenkonto ohne Privilegien reicht aus, um ein von AD CS signiertes Zertifikat für die Identität eines Domain Controllers zu erhalten, sich dann über PKINIT zu authentifizieren und krbtgt über DCSync zu extrahieren. Gefixt am 14. Juli 2026, öffentlicher Exploit seit heute.

Die Fakten

Die Forscher H0j3n und Aniq Fakhrul veröffentlichen am 24. Juli 2026 die vollständige Mechanik von Certighost - CVE-2026-54121, CVSS 8.8 - eine Privilegieneskalation auf Forestebene von Active Directory, die einen Ausweichpfad des Protokolls zur Registrierung von Active Directory Certificate Services (AD CS) ausnutzt.

Offizielle Chronologie:

  • 14. Mai 2026 - Meldung an Microsoft (MSRC).
  • 22. Mai 2026 - Microsoft bestätigt die Schwachstelle.
  • 14. Juli 2026 - Patch im Patch Tuesday ausgeliefert.
  • 24. Juli 2026 - Technische Veröffentlichung + funktioneller Exploit.

Betroffene Systeme: Windows Server 2012 bis 2025, Windows 10 Versionen 1607 und 1809. Mit anderen Worten: fast die gesamte heute eingesetzte AD CS-Umgebung.

Analyse - die Mechanik „chase“

Die AD CS-Registrierung ermöglicht es einer Maschine, ein Zertifikat für ihr eigenes objectSid und dNSHostName anzufordern. Wenn die Zertifizierungsstelle (Certificate Authority, CA) nicht über die erforderlichen End-Entity-Informationen verfügt, verwendet sie einen internen Ausweichpfad, der als „chase“ im Microsoft-Code bezeichnet wird. Dieser Ausweichpfad ermöglicht dem Antragsteller die Angabe von:

  • cdc - dem Host des zu befragenden Domain Controllers,
  • rmd - dem zu auflösenden Maschinenobjekt.

Die Schwachstelle liegt in einer Zeile: Die CA folgte dem vom Antragsteller über SMB und LDAP bereitgestellten cdc, ohne zuvor zu überprüfen, ob es sich um einen echten Domain Controller handelte. Mit anderen Worten, sie akzeptierte die Kommunikation mit jedem erreichbaren Host, als wäre er autoritativ.

Angriffskette

Ein Benutzer der Domäne, ohne Admin-Privilegien, geht wie folgt vor:

  1. Er erstellt (oder nutzt) ein Computer-Konto - in einem Standard-Tenant ermöglicht ms-DS-MachineAccountQuota = 10 jedem Benutzer die Erstellung von bis zu zehn Maschinen.
  2. Er startet LSA- und LDAP-Rogue-Dienste auf seinem Gerät, die von der CA erreichbar sind.
  3. Er löst eine Registrierungsanfrage mit cdc aus, die auf seinen eigenen Host zeigt.
  4. Die CA verbindet sich mit seinem SMB-Dienst, leitet die Authentifizierungsherausforderung an den echten DC über Netlogon weiter, und der Angreifer sendet die objectSid + dNSHostName des Ziel-DCs zurück.
  5. Die CA stellt ein signiertes Zertifikat für die Identität des Ziel-Domain Controllers aus.
  6. Der Angreifer authentifiziert sich mit diesem Zertifikat über PKINIT - er ist nun der DC aus Sicht der Domäne.
  7. DCSync: Er extrahiert den krbtgt-Schlüssel. Spiel vorbei.

Voraussetzungen: Netzwerkzugriff auf die CA von den SMB/LDAP-Listen des Angreifers, ein gültiges Domänenkonto, eine Unternehmens-CA mit dem anfälligen Chase-Pfad, das Standard-Template Machine für die Registrierung aktiviert.

Wer ist betroffen

  • Jeder AD-Wald mit AD CS und einem Template Machine (oder äquivalent), das für authentifizierte Benutzer zugänglich ist - was in enorm vielen Tenants die Standardkonfiguration bleibt.
  • Interner Vektor: Löst sich nur mit einem gültigen Domänenkonto, aber ohne hohe Privilegien aus.
  • Endziel: Komplette Domänenkompromittierung über krbtgt.

Der Microsoft-Fix

Der Juli-Patch fügt die Routine CRequestInstance::_ValidateChaseTargetIsDC hinzu, die ablehnt:

  • IP-Literale in cdc,
  • Namen, die unnormal lang sind oder LDAP-Metazeichen enthalten,
  • und eine exakte Übereinstimmung mit einem Active Directory-Computer-Objekt mit dem Flag SERVER_TRUST_ACCOUNTund Überprüfung seines SID verlangt.

Mit anderen Worten: Die CA vertraut nicht mehr dem, was der Client sagt, sie überprüft, ob sie tatsächlich mit einem legitimen DC spricht, der in AD registriert ist.

Was jetzt zu tun ist

  1. Installieren Sie den Patch Tuesday von Juli 2026 auf allen Ihren AD CS-Servern. Das ist die einzige echte Antwort.
  2. In der Zwischenzeit Workaround nur labortestiert, nicht ohne Validierung in die Produktion bringen:
    certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
    Restart-Service CertSvc -Force

    Dieser Schlüssel deaktiviert das Chase-Verhalten auf Seiten der CA. Überprüfen Sie die Auswirkungen auf Ihre Legacy-Registrierungsströme, bevor Sie dies tun.

  3. Reduzieren Sie ms-DS-MachineAccountQuota auf 0 für Standardbenutzer - eine allgemeine gute Praxis, unabhängig von Certighost.
  4. Überwachen Sie Ihre CA-Logs (EventID 4886/4887 in Windows Security) auf ungewöhnliche Registrierungsanfragen im Template Machine.

Was jetzt zu tun ist - das Wesentliche

Patch Tuesday Juli 2026 + Senkung von MachineAccountQuota auf 0. Der PoC ist öffentlich, das Fenster für opportunistische Ausnutzung öffnet sich jetzt.

Certighost gehört zur Familie der AD CS-Angriffe nach Certipy (ESC1 bis ESC15), die die Windows-PKI-Infrastruktur zu einem der zuverlässigsten Pfade für die Privilegieneskalation in einem schlecht gesicherten Domain machen. Die Botschaft hat sich seit SpecterOps nicht geändert: Auditieren Sie Ihre AD CS-Templates.

Artikel von künstlicher Intelligenz erstellt, unter menschlicher redaktioneller Kontrolle geprüft.

Unsere Redaktion
War dieser Artikel hilfreich?

3 Personen gefiel dieser Artikel

Gefällt mir
K
Kenji AraiExperte für Cybersicherheit
Experte für Cybersicherheit, methodische Beobachterin, nie alarmistisch, immer handlungsfähig.
Teilen:
LIVERadio Geek Kitsune
Tippen zum Hören – für alle derselbe Sound
0··
// Programm
// all stations
// Track teilen →
Themen
Erkunden
Informationen