Microsoft RAMP stoppt am Rand Ihrer Zertifizierungsstelle

Microsoft hat CVE-2026-54121 am 14. Juli gepatcht. Die Forscher H0j3n und Aniq Fakhrul veröffentlichten 10 Tage später einen funktionierenden Proof of Concept und nannten ihn Certighost. Wenn Ihre AD CS-Server das kumulative Juli-Update erhalten haben, sind Sie geschützt. Wenn sie noch Juni-Builds verwenden, sind Sie öffentlichem Exploit-Code ausgesetzt.

Der Angriff selbst ist kurz. Ein Standard-Domänenbenutzer ohne Administratorrechte manipuliert Attribute an einem Computer-Konto, das er kontrolliert, löst fehlerhafte Fallback-Logik in der Zertifizierungsstelle aus und erhält ein signiertes Zertifikat, das sich über PKINIT als Domänencontroller authentifiziert. Von dort aus DCSync liefert den krbtgt-Hash und die Möglichkeit, Golden Tickets im gesamten Forest zu fälschen. Es benötigt eine Enterprise CA, die in Active Directory integriert ist, und die Fähigkeit, ein Computerkonto zu erstellen oder zu kontrollieren, was das Standardkontingent von 10 Computerkonten jedem Domänenbenutzer gewährt.

Das Konto, das die Kette gestartet hat, hatte zu keinem Zeitpunkt erhöhte Privilegien. Das ist hier das entscheidende Detail, denn Microsofts Fahrplan für privileged access basiert auf einem Bedrohungsmodell, das dieser Angriff umgeht.

Die drei Initiativgruppen von RAMP

Der Rapid Modernization Plan empfiehlt, privilegierte Konten zu trennen und zu verwalten, die Anmeldeerfahrung für deren Inhaber zu verbessern und Admin-Arbeitsstationen bereitzustellen. Darunter fallen die Details, an denen die meisten Sicherheitsteams derzeit arbeiten: Privileged Identity Management (PIM), Notfallzugangskonten, Kategorisierung von Microsoft Entra-Rollen nach Auswirkung, MFA und passwortloser Zugang für Administratoren, Blockierung von Legacy-Authentifizierung und Privileged Access Workstations.

Der Großteil davon ist Microsoft Entra ID-Arbeit. Was RAMP vor Ort verlangt, beschränkt sich auf separate Admin-Konten, dedizierte Arbeitsstationen für die Nutzer und eindeutige lokale Administratorpasswörter. Certighost ist ein Fehler in AD CS. Keines der drei betrifft es.

RAMP enthält keine Initiative für Zertifizierungsstellen. Microsoft hat dies bewusst so festgelegt, und die Anleitung bestätigt dies, basierend auf einem separaten Dokument zur Bereitstellung von Privileged Access Management. RAMP beantwortet die Frage, wer in Ihrer Umgebung erhöhte Zugriffsrechte besitzt. Wie Ihre CA entscheidet, welche Identität einem Zertifikat zugeordnet wird, ist eine andere Frage.

Certighost wird nicht der letzte sein

Die Integrität der Zertifikatsausstellung ist eine Kategorie, die weiterhin Vorfälle hervorbringt. Die meisten bekannten Wege sind die seit "Certified Pre-Owned" dokumentierten ESC-Angriffstechniken, bei denen eine Vorlage oder ein CA-Flag einem Benutzer ohne Rechte erlaubt, ein Zertifikat für eine Identität anzufordern, die ihm nicht gehört. Certighost ist eine andere Form. Die Vorlagenkonfiguration ist irrelevant. Der Fehler liegt in der eigenen Anforderungslogik der Zertifizierungsstelle, wie sie ermittelt hat, welches Verzeichnisobjekt die Anfrage tatsächlich betraf.

Diese Unterscheidung ist wichtig für das, was Sie dagegen tun. Ein Audit der Zertifikatvorlage, das die Standardempfehlung ist, hätte diesen nicht gefunden.

Was Kunden daran falsch verstehen

Die meisten Kunden betrachten AD CS als abgedeckt, weil jemand dafür verantwortlich ist. Die Zertifizierungsstelle liegt bei einem PKI- oder Infrastrukturteam, das Identity-Team geht davon aus, dass es damit erledigt ist, und eine andere Berichtslinie wird als Kontrolle angesehen. Wenn ich frage, ob sie ihre Konfigurationen anhand der ESC-Pfade geprüft haben, lautet die Antwort meist, dass sie davon nichts wussten.

Die Teams, die dafür verantwortlich sind, werden an der Verfügbarkeit gemessen. Die Ausstellung gelingt, Erneuerungen laufen nicht ab, die Authentifizierung funktioniert, die CA ist nach allen Metriken gesund, für die sie verantwortlich sind. Sie bleibt bei allen gesund, wenn ein Standardbenutzer ein Zertifikat für ein Konto registriert, auf das er keinen Anspruch hat, weshalb es niemand bemerkt.

Governance hat nichts, woran sie sich festhalten kann

Die Kontrollen von RAMP aktivieren sich um ein privilegiertes Konto. Certighost berührt es erst, wenn die CA das Zertifikat ausstellt, das es erstellt.

Es gibt kein Zwischenkonto, das PIM kontrollieren könnte, und keine Admin-Authentifizierung, die MFA herausfordern könnte. Eskalation und Auszahlung erfolgen in einer einzigen Transaktion innerhalb der Anforderungsverarbeitung der Zertifizierungsstelle, und das Startkonto des Angreifers bleibt genau dort, wo es begonnen hat, auf derselben Ebene wie jeder andere Standard-Domänenbenutzer. Das Maschinenkonto-Kontingent, das den Staging-Schritt ermöglicht, ist ebenfalls keine RAMP-Initiative.

RAMP verweist auf Microsoft Defender for Identity (MDI), und MDI bietet echten Zertifikatsschutz. Die Bewertung der Sicherheitslage prüft Vorlagen und CA-Einstellungen für bekannte Eskalationspfade, und die Prüfungen, die die CA selbst betrachten, erfordern einen MDI-Sensor auf dem AD CS-Server. Es gibt auch eine benannte Erkennung für diese Technik, die beim Anforderungsmuster ausgelöst wird.

Beide sind nützlich. Keiner lehnt die Anmeldeanfrage ab. Eine Posture-Bewertung ist ein Konfigurationsbericht, den Sie regelmäßig lesen, und eine Erkennung ist eine Warnung, die während des Abschlusses der Transaktion eintrifft.

So kann ein Sicherheitsteam RAMP von Anfang bis Ende abschließen, es gut machen, MDI daneben ausführen und hat trotzdem keine Kontrolle, die eine Zertifikatsanfrage bewertet und ablehnt. Privileged Access Management-Governance und die Integrität der Zertifizierungsstelle sind getrennte Probleme. RAMP löst eines davon, und ich würde sagen, dass die Annahme, ein abgeschlossener Rollout decke beide ab, die häufigste Fehlinterpretation des Zwecks dieser Roadmap ist.

Wenn mir jemand sagt, er habe seine RAMP-Arbeit abgeschlossen, ist meine erste Frage, wer die Zertifizierungsstelle besitzt. Wenn sie das erst herausfinden müssen, ist das die Antwort. RAMP ist der richtige Fahrplan, und ihn abzuschließen bedeutet, dass ihre privilegierten Konten verwaltet werden, was echter Fortschritt ist und nicht nichts. Es sagt nur nichts über das System aus, das eines dieser Konten aus einer Standardbenutzer-Zertifikatsanforderung erstellen kann. Die Überwachung dieses Systems ist das Minimum. Was ich als Nächstes möchte, ist etwas, das die Anfrage ablehnen kann.

Blockieren der Anmeldeanforderung

Netwrix Threat Prevention (NTP) und Netwrix Threat Manager (NTM) arbeiten auf beiden Seiten. Auf der Überwachungsseite deckt NTM denselben Bereich ab, auf den RAMP durch Defender for Identity hinweist, und erkennt Missbrauch von AD CS sowie Muster von Zertifikatsmissbrauch in Echtzeit.

Die Präventionsseite ist das, was sie unterscheidet. NTP bewertet Anmeldeanfragen anhand bekannter Missbrauchsmuster von AD CS, einschließlich der Techniken ESC1 bis ESC7, und blockiert sie, bevor ein Zertifikat existiert, anstatt einen Datensatz zu erstellen, dass eines ausgestellt wurde. Eine Statusbewertung zeigt an, dass eine Vorlage falsch ist, und eine Erkennung zeigt, dass eine Anfrage verdächtig war, aber die Durchsetzung ist die einzige der drei, die die Transaktion beendet.

Führen Sie RAMP durch, und sehen Sie sich dann Ihre Zertifizierungsstelle an

Folgen Sie RAMP. Die Arbeit, die es verlangt, ist Arbeit, die sich lohnt. Patchen Sie Ihre AD CS-Server und setzen Sie die Maschinenkonto-Quote auf null, solange Sie dort sind.

Schauen Sie dann bei Ihrer Zertifizierungsstelle nach, denn RAMP wird Sie nicht dorthin schicken. Prüfen Sie die Vorlagen, und stellen Sie dann die schwierigere Frage darunter: Wenn ein Standardkonto eine Anmeldeanforderung mit einer Identität stellt, auf die es keinen Anspruch hat, was bewertet diese Anforderung in Ihrer Umgebung, und wird sie gestoppt oder nur protokolliert?