CertiGhost Schwachstelle bedroht Active Directory

Zero Networks analysiert Schwachstelle „Certighost“ – Wie aus einem einfachen Benutzerkonto ein Domain Controller wird.

CertiGhost ermöglicht es, ausgehend von einem einfachen Active-Directory-Konto die vollständige Kontrolle über die Domäne zu erlangen. Dabei manipuliert es ein vertrauenswürdiges Zertifikatssystem so, dass es den Angreifer wie einen Domänencontroller behandelt.

Zusammenfassung (TL; DR):

• Die Schwachstelle „CertiGhost“ (CVE-2026-54121) ermöglicht es Angreifern, über ein einfaches Active-Directory-Konto die Identität eines Domänencontrollers zu fälschen und die gesamte Domäne zu übernehmen.
• Da der Microsoft-Patch vom 14. Juli 2026 an ein „Velocity Feature Gate“ gekoppelt ist, reicht die bloße Installation nicht aus.
• Administratoren müssen die tatsächliche Aktivierung auf den Zertifizierungsstellen verifizieren. Zudem sollten sie sich durch Mikrosegmentierung sowie „Default-Deny“-Regeln für ausgehenden Datenverkehr absichern.

Die Installation des Microsoft-Patches vom 14. Juli ist wichtig, doch Sicherheitsteams sollten zudem sicherstellen, dass der Schutz in ihrer gesamten Umgebung tatsächlich aktiv ist. CISOs und ihre Sicherheitsteams sollten Zertifikatsserver so einschränken, dass sie nur mit autorisierten Systemen kommunizieren können. So blockieren sie unbefugte Versuche, sensible Identitätsdaten von Domänencontrollern zu kopieren. Die wichtigere Erkenntnis: Patches beheben einzelne Schwachstellen, während Segmentierung und strikte Zugriffskontrollen ganze Angriffskategorien unterbinden können.

Microsoft behob die CertiGhost-Schwachstelle am 14. Juli 2026

Die Sicherheitsforscher H0j3n und Aniq Fakhrul veröffentlichten zehn Tage später einen funktionierenden Proof-of-Concept. Wenn Ihre Zertifizierungsstellen (CAs) und Domänencontroller die Juli-Updates erhalten haben, sind Sie wahrscheinlich ausreichend geschützt. Dennoch sollten Sie sich der Lücke bewusst sein – der Diskrepanz zwischen „gepatcht“ und „aktiviert“ –, auf die Angreifer setzen. Überprüfen Sie daher, ob der Fix auf Ihren CAs und DCs tatsächlich greift und nicht lediglich installiert, aber inaktiv ist.

Zero Networks zeigt, was „gepatcht“ im Kontext von AD CS konkret bedeutet

Als Microsoft im Mai 2022 die SID-Sicherheitserweiterung als Reaktion auf Certifried (CVE-2022-26923) bereitstellte, erfolgte die Implementierung in einem Kompatibilitätsmodus. Dieser ließ weiterhin eine schwache Zertifikatszuordnung (Certificate Mapping) zu. Erst im Februar 2025 – also drei Jahre später – hat man die vollständige Durchsetzung zum Standard gemacht. Das bedeutete, dass der Fix zwar fast überall installiert, aber kaum irgendwo tatsächlich aktiv war. Dies galt, sofern ein Administrator nicht gezielt Nachforschungen anstellte. Für Angreifer bot dies ein weit offen stehendes Einfallstor.

Der CertiGhost-Fix lässt einen Angriffsvektor offen

Dieser Angriffsvektor ist allerdings ist dieser für jeden sichtbar, ohne versteckt zu sein. Die neue Validierungslogik ist hinter einem „Velocity Feature Gate“ von Windows verborgen: `Feature_3185813818` in der gepatchten `certpdef.dll` schützt den Programmzweig, der `_ValidateChaseTargetIsDC` aufruft. „Velocity Gates“ sind gewöhnliche Wartungsmechanismen und kein Beleg für eine unvollständige Fehlerbehebung: Sie ermöglichen es Microsoft, Änderungen gestaffelt oder schrittweise einzuführen oder auch wieder rückgängig zu machen, ohne eine neue Binärdatei ausliefern zu müssen. Auch Sicherheits-Fixes des MSRC lassen sich über diese Mechanismen steuern. Die meisten Sicherheitsfunktionen sind so ausgeliefert, dass sie standardmäßig aktiviert sind. In diesem Fall fungiert der Mechanismus lediglich als „Rollback-Hebel“, der in der Praxis nie betätigt wird.

Problem: Laufzeitzustand

Für echte Sicherheitsteams bedeutet dies, dass die Durchsetzung von Sicherheitsrichtlinien einen Laufzeitzustand darstellt und keine Eigenschaft des Build-Prozesses ist. Einen solchen Laufzeitzustand muss man anhand der eigenen Zertifizierungsstellen (CAs) verifizieren, anstatt ihn lediglich aus einem Patch-Level abzuleiten.

Der weitere Verlauf dieses Beitrags widmet sich einer unangenehmeren Frage. Bei „CertiGhost“ agiert ein Domänenbenutzer mit eingeschränkten Rechten durch ein einziges automatisiertes Skript als „krbtgt“-Konto (dem Kerberos-Ticket-Granting-Ticket-Konto). Die Angriffskette ist kurz, die Voraussetzungen entsprechen weitgehend den Standardeinstellungen. Der Angriff nutzt weder Speicherfehler (Memory Corruption) aus noch hebelt er kryptografische Verfahren aus. Es handelt sich schlicht um eine fehlende Validierung bei einer Vertrauensentscheidung.

Katalog von Eskalationspfaden für AD CS

Seit Will Schroeder und Lee Christensen im Jahr 2021 ihre Arbeit „Certified Pre-Owned“ veröffentlicht haben, führt die Community einen laufend aktualisierten Katalog von Eskalationspfaden für AD CS (Active Directory Certificate Services): von ESC1 bis ESC8 in der ursprünglichen Studie, später erweitert bis ESC17. Es handelt sich dabei weder um ein offizielles Microsoft-Schema noch um eine CVE-Reihe, sondern um eine informelle Nummerierung, die immer dann erweitert wird, wenn jemand einen neuen Weg findet. Sie münzen die Ausstellung von Zertifikaten in Domänenprivilegien um. Bei den meisten dieser siebzehn Fälle handelt es sich um falsch konfigurierte Vorlagen oder schwache Zugriffssteuerungslisten (ACLs) für PKI-Objekte. Zwei davon – ESC8 und ESC11 – sind Relay-Angriffe, die aus einem denkbar simplen Grund funktionieren: Ein Endpunkt für die Zertifikatsregistrierung ist für eine Instanz erreichbar, die dort eigentlich niemals hätte Zugriff haben dürfen. CertiGhost gehört zur selben Kategorie: Die Zertifizierungsstelle traf eine Vertrauensentscheidung auf der Grundlage von Daten, die ein Angreifer bereitgestellt hatte. Es wird auch eine achtzehnte Variante geben.

Was in Ihrem Netzwerk hätte diesen Angriff gestoppt?

Die Frage lautet also: Wenn Sie das Update vom 14. Juli nicht eingespielt hätten – was in Ihrem Netzwerk hätte diesen Angriff gestoppt?

Für die meisten Umgebungen lautet die ehrliche Antwort: nichts, denn der Angriff erscheint in jeder Phase wie gewöhnlicher Windows-Netzwerkverkehr. Doch zwei der vier Netzwerkabschnitte in der Angriffskette lassen sich durch Sicherheitsmechanismen unterbinden, die weder von der Existenz von CertiGhost wissen noch diese berücksichtigen müssen. Genau das ist der entscheidende Punkt.

Wichtige Antworten

• Was ist CertiGhost (CVE-2026-54121) und warum reicht ein Patch allein nicht aus, um das Risiko zu beseitigen? CertiGhost ist eine Exploit-Kette für Active Directory Certificate Services (AD CS), die einen Domänenbenutzer mit geringen Rechten in einen Domänencontroller (DC) verwandelt. Dies geschieht, indem eine Zertifizierungsstelle (CA) dazu verleitet wird, ein Zertifikat mit der Identität eines DCs zu signieren; dies führt über PKINIT und DCSync zur Kompromittierung des krbtgt-Kontos. Microsoft veröffentlichte am 14. Juli 2026 einen Patch, doch die Korrektur ist an ein „Velocity Feature Gate“ von Windows gekoppelt. Das bedeutet, dass die Durchsetzung von einem Laufzeitstatus der jeweiligen CA abhängt und keine garantierte Eigenschaft des Patches selbst ist. Dieses Muste führte bereits dazu, dass der „Certifried“-Fix aus dem Jahr 2022 fast drei Jahre lang im Kompatibilitätsmodus verblieb.
• Wie funktioniert die CertiGhost-Angriffskette genau? Der Exploit nutzt den „Chase“-Fallback-Mechanismus von AD CS aus: Dabei folgt die CA vom Angreifer bereitgestellten Registrierungsattributen (cdc und rmd) zu einem sekundären Lookup-Host, ohne zu validieren, ob es sich tatsächlich um einen Domänencontroller handelt. Ein Angreifer setzt manipulierte SMB-, LDAP- oder LSA-Dienste auf, erstellt über das Standardkontingent (ms-DS-MachineAccountQuota) ein Computerkonto, leitet die Netlogon-Authentifizierung an einen echten DC weiter und erhält ein Zertifikat, das die Identität dieses DCs trägt.

Noch mehr Antworten

• Welche einzelne Netzwerkkontrollmaßnahme neutralisiert die gefährlichste Phase des Angriffs? Eine „Default-Deny“-Regel für ausgehenden Datenverkehr (Egress) an der Zertifizierungsstelle – die ausgehende SMB- und LDAP-Verbindungen nur zu bekannten Domänencontrollern zulässt. Sieunterbindet den Angriff, noch bevor es zu einer Identitätsverwechslung kommt. Diese Maßnahme erfordert weder Wissen über CertiGhost noch Signaturen oder Informationen zum ch-Stand. Sie stellt lediglich sicher, dass die Menge der legitimen Kommunikationspartner einer CA klein, stabil und klar definierbar bleibt.
• Warum ist Mikrosegmentierung auf Asset-Ebene wichtiger als Regeln, die auf Subnetzen oder VLANs basieren? Eine CA, die sich in einem weit gefassten Server-VLAN mit freizügigem Ost-West-Verkehr befindet, unterliegt faktisch keinerlei Egress-Richtlinie. Der Sicherheitsnutzen ergibt sich gerade daraus, dass Regeln auf das einzelne Asset (oder sogar auf den Prozess, wie etwa certsrv.exe) zugeschnitten sind. Denn CAs weisen ein deutlich eingeschränkteres legitimes Kommunikationsprofil auf als das Netzwerksegment, in dem sie sich befinden.
• Welche einzelne Regel bietet das beste Kosten-Nutzen-Verhältnis (ROI), um diese gesamte Klasse von AD CS-Angriffen zu blockieren? Die Unterbindung von DCSync-Operationen (MS-DRSR / DRSGetNCChanges) von Quellen, die keine Domänencontroller sind, ist eine gezielte Maßnahme mit geringem Risiko für Nebenwirkungen. Sie setzt CertiGhost, sämtliche AD-CS-ESC-Eskalationspfade, Zerologon sowie alle anderen Angriffe außer Gefecht, deren entscheidender Schritt im Abzug von Geheimnissen aus dem Verzeichnisdienst besteht.

Welche architektonische Lehre lässt sich aus diesem CVE ziehen?

CertiGhost lässt sich – wie schon die ESC-Schwachstellen zuvor – innerhalb weniger Monate patchen und dann in Vergessenheit geraten. Doch all diesen Schwachstellen ist eine gemeinsame Schwäche eigen: Eine Vertrauensentscheidung, die auf Daten basiert, welche der Angreifer beeinflusst hat. Eine Verteidigungsstrategie, die langfristig Bestand hat, setzt nicht an der spezifischen Erkennung von „cdc“ an. Sie beschränkt den Zugriffsbereich kompromittierter oder fehlgesteuerter Systeme: Wenn eine Zertifizierungsstelle (CA) keine SMB-Verbindung zu einem beliebigen Host aufbauen kann, spielt es keine Rolle, welche Validierung man im konkreten Fall versäumt hat.

Die Kette in Kürze

Die Zertifikatsbeantragung in AD CS verfügt über einen Fallback-Mechanismus, den die Forscher als „Chase“ (Verfolgung/Weiterleitung) bezeichnen. Wenn die Zertifizierungsstelle (CA) das Verzeichnisobjekt des Antragstellers nicht lokal auflösen kann – ein durchaus realistisches Szenario in Multi-Domain-Gesamtstrukturen mit Replikationsverzögerung –, kann die Anforderung zwei Attribute enthalten. Diese steuern eine sekundäre Suche: `cdc` (gibt den Host an, den die CA kontaktieren soll) und `rmd` (gibt das aufzulösende Sicherheitsprinzipal an).

Vor dem Juli-Patch folgte die CA dem `cdc`-Wert, ohne zu überprüfen, ob es sich bei dem Host tatsächlich um einen Domänencontroller (DC) handelte. In der Datei `certpdef.dll` las die Funktion `CRequestInstance::_LoadPrincipalObject` das Attribut direkt aus der Anforderung aus und übergab es mit aktiviertem „Chase“-Modus an `_GetDSObject`. Der Juli-Build kapselt diesen Aufruf nun in `_ValidateChaseTargetIsDC`. Diese Funktion weist IP-Adressen, LDAP-Metazeichen sowie übermäßig lange Hostnamen ab und fragt anschließend das Active Directory nach genau einem Computerobjekt ab. Dessen `dNSHostName` stimmt überein und dessen `userAccountControl`-Attribut enthält das Flag `SERVER_TRUST_ACCOUNT` (8192).

Noch mehr Details

Der Exploit setzt auf einem vom Angreifer kontrollierten Host manipulierte SMB-, LDAP- und LSA-Dienste auf. Sie erstellt mithilfe des Standardwerts von 10 für `ms-DS-MachineAccountQuota` ein Computerkonto (um über eine echte Domänenidentität zu verfügen). Damit verweist sie mit dem `cdc`-Attribut auf sich selbst. Wenn die CA eine Verbindung herstellt, leiten die manipulierten Dienste die Authentifizierungsanfrage (Challenge) per Netlogon an den echten DC weiter. Hierdurch werden die Authentifizierungsprüfungen der CA erfolgreich durchlaufen, während sie gleichzeitig die `objectSid` und den `dNSHostName` des Ziel-DCs als Verzeichnisdaten zurückgeben. Die CA signiert daraufhin ein Zertifikat, das die Identität eines Domänencontrollers trägt. PKINIT wandelt dieses in Kerberos-Anmeldeinformationen für den DC um, und DCSync nutzt diese, um das `krbtgt`-Konto zu kompromittieren.

Vier Netzwerkabschnitte sind von Bedeutung

• Registrierungsanfrage mit cdc / rmd        Angreifer → CA
• Die Verfolgung: SMB und LDAP zum cdc-Ziel       CA → Angreifer
• Netlogon-Relay der Challenge der CA     Angreifer → DC
• DCSync via Verzeichnisreplikation             Angreifer → DC

Phase 2 ist der entscheidende Punkt, den man sich genauer ansehen sollte. Bei allen anderen Phasen handelt es sich um einen Angreifer, der in Ihre Infrastruktur eindringt. Dies ist genau das Szenario, für das Sicherheits-Tools konzipiert sind. In Phase 2 hingegen ist es Ihre Zertifizierungsstelle (CA) – eine der vertrauenswürdigsten Maschinen in der Domäne –, die eine ausgehende SMB- und LDAP-Sitzung zu einem Linux-Rechner des Angreifers aufbaut. Eine nicht vertrauenswürdigen Anfrage hat sie dazu veranlasst.

Phase 2: Die Liste der zulässigen ausgehenden Kommunikationspartner der CA ist kurz, und dieser Rechner gehört nicht dazu.

Eine Zertifizierungsstelle ist kein Allzweck-Client. Ihre legitimen ausgehenden Verbindungen sind wenige, stabil und genau auflistbar: Domänencontroller, die eigene Datenbank, möglicherweise ein HSM und die Systeme, auf denen Zertifikatssperrlisten (CRLs) veröffentlicht werden. Diese Liste ändert sich im Schnitt nur einmal pro Jahr.

Das bedeutet, dass die kritische Phase des Exploits nicht nur verdächtig ist, sondern völlig außerhalb des normalen Verhaltensspektrums der CA liegt. Eine „Default-Deny“-Regel für ausgehenden Datenverkehr (Egress-Filterung) auf der CA, die SMB- und LDAP-Verbindungen nur zu bekannten Domänencontrollern zulässt. Sie unterbindet den Angriff, noch bevor es zur Identitätsverwechslung kommt. Der manipulierte LSA-Dienst erhält keine Verbindung. Es werden keine Verzeichnisdaten abgerufen. Es wird kein Zertifikat ausgestellt.

Die gesetzte Hürde ist hoch, wenn auch nicht unüberwindbar

Ein Angreifer, der bereits einen Host kompromittiert hat, auf den die CA zugreifen darf, könnte die manipulierten Dienste stattdessen dort einrichten und den Angriff erfolgreich durchführen. Damit verschiebt sich jedoch die Voraussetzung: von „Erstellen eines Maschinenkontos“ (was laut Standardkontingent jedem Benutzer möglich ist) hin zu „Kontrolle über ein System auf der kurzen Liste der zulässigen Kommunikationspartner der CA“. Dies stellt eine grundlegend andere Problemkategorie dar. Es ist eine, für die Sie mit hoher Wahrscheinlichkeit bereits Überwachungsmechanismen implementiert haben.

Schutzmaßnahme setzen keinerlei Wissen über „CertiGhost“ voraus

Besonders bemerkenswert ist, dass diese Schutzmaßnahme keinerlei Wissen über „CertiGhost“ voraussetzt. Sie analysiert keine „cdc“-Daten. Sie prüft keine Registrierungsattribute. Sie benötigt weder eine Signatur noch einen bestimmten Patch-Stand oder einen Threat-Intelligence-Feed. Sie setzt eine Regel durch, die schon vor der Existenz der CVE-Schwachstelle galt und auch danach gültig bleibt. Diese CA kommuniziert mit diesen Hosts über diese Ports – und sonst mit nichts anderem.

Zwei Faktoren machen diesen Ansatz praktikabel und nicht nur zu einem theoretischen Wunschszenario. Der erste Punkt ist die automatisierte Erstellung von Richtlinien: Es ist unmöglich, Egress-Richtlinien für jeden einzelnen Server einer Infrastruktur manuell zu schreiben. Stattdessen lässt sich beobachten, mit welchen Zielen eine Ressource tatsächlich kommuniziert, um daraus ein Regelwerk nach dem „Least-Privilege“-Prinzip (Prinzip der minimalen Rechtevergabe) abzuleiten. Dieses kann zunächst im Überwachungsmodus betrieben werden, um zu prüfen, welche Verbindungen blockiert worden wären, bevor es tatsächlich zu Blockierungen kommt. Probleme mit Least-Privilege-Netzwerkrichtlinien treten vor allem bei Organisationen auf, die diese auf der Grundlage von Architekturdiagrammen statt auf Basis des tatsächlich beobachteten Datenverkehrs erstellt haben.

Richtlinien auf Ressourcenebene und nicht auf Subnetzebene

Zweitens müssen Richtlinien auf Ressourcenebene und nicht auf Subnetzebene definiert werden. Eine Zertifizierungsstelle (CA) in einem allgemeinen „Server-VLAN“ mit freizügigen East-West-Regeln verfügt faktisch über keinerlei Egress-Richtlinie. Der eigentliche Nutzen liegt gerade in einem restriktiven Regelwerk, da die Kommunikationsanforderungen einer CA sehr spezifisch und begrenzt sind.

Geht man noch einen Schritt weiter, lässt sich die Egress-Kontrolle auf Prozessebene weiter verfeinern: Der Prozess `certsrv.exe` kommuniziert mit einer kleineren Menge legitimer Gegenstellen als der Host als Ganzes. Die entsprechende Kommunikation geht genau von diesem Prozess aus.

Abschnitte 1 und 4: Steuerung auf RPC-Ebene

Die verbleibenden Abschnitte basieren auf RPC, wodurch sie auf einer anderen Ebene adressierbar sind.

Abschnitt 1 betrifft die MS-WCCE-Registrierung. Im öffentlichen PoC – der auf *impacket* basiert und keinen Web-Registrierungs-Endpunkt nutzt – bedeutet dies die Verwendung von *ICertPassage* über DCERPC auf der Named Pipe `\pipe\cert` (Schnittstelle `91ae6020-9e3c-11cf-8d7c-00aa00c091be`, Opnum 0, `CertServerRequest`). Die Attribute `cdc` und `rmd` lassen sich im Attribut-String dieses Aufrufs übertragen. Beachten Sie das Transportprotokoll: Es handelt sich um `ncacn_np` über Port 445, nicht um `ncacn_ip_tcp` über Port 135. Eine portbasierte Regel zielt auf den RPC-Endpoint-Mapper abz, erfasst diesen Datenverkehr daher nicht. Eine RPC-Firewall hingegen, die in die RPC-Laufzeitumgebung eingreift, anstatt lediglich Ports zu filtern, erkennt ihn.

Filterung auf Schnittstellen- und Opnum-Ebene

Man muss sich genau darüber im Klaren sein, welchen Nutzen dies bietet. Eine Filterung auf Schnittstellen- und Opnum-Ebene legt fest, wer Registrierungsanfragen per RPC übermitteln darf; sie unterscheidet jedoch nicht zwischen einem schädlichen und einem legitimen `cdc`-Attribut, da das Unterscheidungsmerkmal ein String innerhalb der Parameter ist. Abschnitt 1 ist also eine Maßnahme auf Basis einer Positivliste (Allow-List): RPC-Registrierungsanfragen an die Zertifizierungsstelle (CA) sollten von verwalteten Endpunkten und Registrierungs-Proxys stammen. Sie sollten nicht von einem nicht verwalteten Host stammen, der erst vor vierzig Sekunden in der Domäne aufgetaucht ist. Dies schränkt den Kreis der potenziellen Angreifer ein, identifiziert den Angriff selbst jedoch nicht.

Abdeckung durch Abschnitt 1 ist unvollständig, sobald Web-Registrierung genutzt wird

Zudem wird nur der RPC-Transport abgedeckt. Wenn „Certificate Enrollment Web Services“ (Webdienste für die Zertifikatsregistrierung) eingesetzt werden, erreicht MS-WSTEP über HTTPS dasselbe Richtlinienmodul. Dieselbe Weiterleitungslogik (*chase logic*) istfür die eine Filterung auf RPC-Ebene blind. Die Abdeckung durch Abschnitt 1 ist also unvollständig, sobald Web-Registrierung genutzt wird. Das ist ein weiteres Argument dafür, dass Abschnitt 2 die Hauptlast der Absicherung tragen sollte. Denn die Egress-Richtlinie der CA ist unabhängig davon, auf welchem Weg die Anfrage eingegangen ist. Diese Positivliste bietet noch einen weiteren nennenswerten Vorteil. Bei ESC11 handelt es sich um einen NTLM-Relay-Angriff genau auf diese Schnittstelle – den RPC-basierten Registrierungs-Endpunkt. Dies ist im Gegensatz zu ESC8, bei dem der Relay-Angriff auf den HTTP-Endpunkt erfolgt. Die Einschränkung des Zugriffs auf *ICertPassage* beschränkt also sowohl die Übermittlungsphase von CertiGhost als auch ESC11 durch dieselbe Regel. Das ist der Unterschied zwischen einer architektonischen Kontrollmaßnahme und einem Patch: Der Patch behebt einen einzelnen Fehler, die Regel schließt eine ganze Klasse von Erreichbarkeitspfaden aus.

Vortritt für Domänencontroller

Bei Schritt 4 beweist die RPC-Filterung unmissverständlich ihren Wert. DCSync basiert auf MS-DRSR – konkret der Schnittstelle `e3514235-4b06-11d1-ab04-00c04fc2dcd2` und der Funktion `DRSGetNCChanges` (Opnum 3). Nur Domänencontroller sollten diese Funktion aufrufen dürfen. Den Zugriff auf diese Funktion auf Ihren DCs für alle Quellen, die keine DCs sind, zu unterbinden, ist eine präzise Regel mit geringem Risiko für Nebenwirkungen. Sie neutralisiert den Nutzen dieses Angriffs, sämtlicher AD-CS-ESC-Pfade, von Zerologon (und dessen Derivaten). Sie neutralisiert aber auch jede andere Angriffskette, deren letzter Schritt das Replizieren von Geheimnissen aus dem Verzeichnis ist. Wenn Sie nur eine einzige Regel aus diesem Beitrag umsetzen, dann diese.

Blockade auf Protokollebene?

Schritt 3, das Netlogon-Relay, betrifft MS-NRPC (`12345678-1234-abcd-ef00-01234567cffb`). Es handelt sich zwar um RPC, doch jeder in die Domäne eingebundene Rechner kommuniziert legitimerweise über dieses Protokoll mit DCs. Eine Blockade auf Protokollebene würde daher den Betrieb stören. Der praktikable Ansatzpunkt ist hier die Identität der Quelle statt des Protokolls: Ein nicht verwalteter Linux-Host, der NRPC-Aufrufe tätigt, stellt die Anomalie dar. Betrachten Sie dies als Gelegenheit zur Erkennung, nicht als Engpass für den Datenverkehr.

Vor der Durchsetzung sollte eine Audit-Phase stehen

Für beide Regeln gilt: Vor der eigentlichen Durchsetzung (Enforcement) sollte eine Audit-Phase stehen. Wenn Sie eine Woche lang die Aufrufe an `ICertPassage` und `DRSUAPI` protokollieren, erhalten Sie einen Überblick über die tatsächlichen Aufrufer. Dieser Kreis ist fast immer kleiner und ungewöhnlicher, als die Dokumentation vermuten lässt. Er umfasst bisweilen einen Backup-Agenten, dessen Installation längst in Vergessenheit geraten ist.

Eine nicht netzwerkbasierte Maßnahme gehört ebenfalls auf diese Liste, da sie kostengünstiger ist als alle zuvor genannten: Setzen Sie `ms-DS-MachineAccountQuota` auf 0. Der Exploit benötigt ein Computerkonto, um eine gültige Domänenidentität zu besitzen. Die Standardeinstellung erlaubt es jedoch jedem authentifizierten Benutzer, zehn solcher Konten zu erstellen.

Fazit

CertiGhost wird innerhalb weniger Monate überall gepatcht und anschließend weitgehend in Vergessenheit geraten – ähnlich wie es bei der vorangegangenen ESC-Serie der Fall war. Die strukturelle Erkenntnis dahinter bleibt jedoch bestehen. Bei jedem dieser Fehler handelt es sich um eine Vertrauensentscheidung auf der Grundlage von Daten, die vom Angreifer beeinflusst wurden. Die Lösung sieht dabei immer gleich aus: Man muss die fehlende Validierung nachrüsten. Die Verteidigungsstrategie, die sich langfristig bewährt, ist daher nicht jene, die spezifisch auf „CDC“ (Credential Delegation/Compromised Domain Controller) ausgelegt ist. Vielmehr ist es jene, die den Aktionsradius einer kompromittierten oder manipulierten Komponente einschränkt. Denn eine Zertifizierungsstelle, die keine SMB-Verbindung zu einem beliebigen Host aufbauen kann, und ein Domänencontroller, der keine Geheimnisse an einen Nicht-Domänencontroller repliziert, sind davon unbeeindruckt, welche Validierung im jeweiligen Fall gefehlt hat.