Jake Hildreth Leitender Sicherheitsberater

Im Rahmen meiner jüngsten Forschungsarbeit habe ich mir in aller Ruhe die Entwurfsdokumente zur Public-Key-Infrastruktur von Microsoft sowie die zugehörigen RFCs (insbesondere RFC 4556) angesehen, um eine zuverlässige Methode zu finden, mit der sich die Berechtigungen eines normalen Benutzers mit geringen Berechtigungen auf ein beliebiges Konto ausweiten lassen – ohne dass es dabei zu Fehlkonfigurationen kommt. (Ja, so verbringe ich meine Freizeit. Diese Themen sind für mich und meine Kollegen von Bedeutung, wenn wir Pläne zur Cyber-Notfallvorsorge erstellen.)

Leider habe ich, obwohl ich in ähnlichen Bereichen recherchiert habe, den „Certighost“-Angriff in der Dokumentation nicht gefunden , obwohl es sich dabei um eine bekannte Sicherheitslücke in den Active Directory-Zertifikatsdiensten (AD CS) handelt.

Tatsächlich habe ich überhaupt keine Methoden zur Ausweitung von Berechtigungen gefunden.

Ich habe jedoch eine auf Fehlkonfigurationen basierende Methode zur Persistenz nach dem Angriff entdeckt, die zwar nicht so spektakulär wie Certighost ist, aber fast ebenso beunruhigend.

  • Es ist kein Zugriff auf den privaten Schlüssel einer Zertifizierungsstelle erforderlich (eine Voraussetzung für einen „Golden Certificate“- oder „Golden Ticket “-Angriff).
  • Dies steht im Widerspruch zu den allgemein geltenden Leitlinien zur Wiedererlangung des Zugriffs auf kompromittierte Konten.
  • Im Gegensatz zu Certighost wird diese Schwachstelle nicht durch ein Patch behoben, da sie auf einer von Microsoft dokumentierten Konfiguration beruht, die für Test- und Fehlerbehebungszwecke vorgesehen ist.

Wenn Sie in Ihrer Umgebung für die Prävention und die Reaktion auf Sicherheitsverletzungen im Identitätsmanagementsystem verantwortlich sind, sollten Sie dieses Thema im Auge behalten.

Heute möchte ich Ihnen „Zombie-Zertifikate“ vorstellen – Authentifizierungszertifikate, die sich nicht löschen lassen!

„Wer ist da?“ Der PKINIT-Authentifizierungsprozess

In einer typischen Active Directory (AD)-Umgebung ist die gängigste Form der Authentifizierungsdaten die bekannte Kombination aus Benutzername und Passwort. Ihr Benutzername ist eine Angabe darüber, wer Sie sind; Ihr Passwort bestätigt diese Angabe.

AD unterstützt jedoch auch die Verwendung von Zertifikaten mit öffentlichem Schlüssel als Authentifizierungsnachweis, häufig in Form von Smartcards. Dieser zertifikatsbasierte Authentifizierungsprozess wird als „Public Key Cryptography for Initial Authentication“( PKINIT) bezeichnet. Die Microsoft-Implementierung von PKINIT wird in MS-PKCA ausführlich beschrieben; kurz gesagt verwenden Sie jedoch anstelle der Verschlüsselung authentifizierungsbezogener Tickets (AS-REP/AS-REQ) mit Ihrem Passwort einen von Ihnen kontrollierten privaten Schlüssel, um Ihre authentifizierungsbezogenen Tickets zu verschlüsseln.

Bei der Durchsicht von RFC 5280, Abschnitt 6.3.3, stieß ich auf die im Algorithmus enthaltene Definition dessen, was geschieht, wenn ein Prüfer den Sperrstatus nicht ermitteln kann:

Sollte der Sperrstatus nach der Verarbeitung solcher CRLs immer noch nicht ermittelt worden sein, geben Sie den Zertifikatsstatus „UNDETERMINED“ zurück.

„Kenne ich Sie?“ PKINIT in Active Directory

Wenn Sie versuchen, sich über PKINIT mit einem Zertifikat bei Active Directory (AD) zu authentifizieren, kommunizieren Sie mit einem Domänen Domain Controller (DC), der als Kerberos-Schlüsselverteilungszentrum (KDC) fungiert. Während des PKINIT-Vorgangs prüft das KDC, ob das von Ihnen verwendete Zertifikat derzeit für die Authentifizierung verwendet werden kann.

Das KDC überprüft verschiedene Attribute des Zertifikats, bevor es bestätigt: „Ja, ich kenne Sie“, darunter (unter anderem):

  • Aussteller: Das KDC muss der Zertifizierungsstelle (CA) vertrauen, die das Zertifikat ausgestellt hat. Wenn das KDC dem Aussteller des Zertifikats nicht vertraut, erhalten Sie keinen Zugriff.
  • Vorgesehene Verwendung: Zertifikate enthalten Informationen darüber, wie sie verwendet werden können (mehr dazu weiter unten). Wenn Sie versuchen, sich mit einem Zertifikat zu authentifizieren, das für die Codesignierung vorgesehen ist, erhalten Sie keinen Zugriff.
  • Gültigkeitsdauer: Wenn Sie heute versuchen, sich mit einem Zertifikat zu authentifizieren, das erst im Jahr 20X6 gültig wird, erhalten Sie keinen Zugang. Und wenn Sie heute versuchen, sich mit einem Zertifikat zu authentifizieren, das im Jahr 1666 abgelaufen ist, erhalten Sie ebenfalls keinen Zugang.
  • Widerrufsstatus: Ein Zertifikatsaussteller kann ein Zertifikat widerrufen, indem er es in eine Zertifikatswiderrufsliste (CRL) aufnimmt. Wenn Sie versuchen, ein Zertifikat zu verwenden, das in einer CRL aufgeführt ist, werden Sie – wie Sie sich sicher denken können – höchstwahrscheinlich keinen Zugriff erhalten.

Dieser letzte Punkt ist jedoch etwas knifflig…

Was geschieht, wenn die CRL nicht verfügbar ist? Schließlich werden CRLs in der Regel als HTTP-URLs auf Webservern veröffentlicht, und Webserver weisen so gut wie nie eine lückenlose Verfügbarkeit auf.

Wie wir bereits gesehen haben, sind die RFCs in dieser Frage eindeutig. Wenn eine CRL nicht verfügbar ist, sollte das KDC den Widerrufsstatus des Zertifikats als „UNDETERMINED“ kennzeichnen. Was aus den RFCs und der Microsoft-Dokumentation nicht ganz klar hervorgeht, ist die Bedeutung von „UNDETERMINED“ im Zusammenhang mit dem PKINIT-Prozess.


Das Unbekannte erzwingen

Bei der Erstellung von ESC16-Erkennungen für Schlüsseldienst und Schlüsseldienst 2 (Open-Source-Community-Tools, die Sie auf GitHub finden können), lernte ich das DisableExtensionList Einstellungen für Zertifizierungsstellen (CAs) der AD-Zertifikatsdienste (AD CS). Erweiterungen sind kurze Angaben, die einem Zertifikat hinzugefügt werden und erläutern, welchem Zweck das Zertifikat dient und wie es verwendet werden kann und sollte.

Auf einem AD-CS-CA-Server wird die DisableExtensionList Diese Einstellung dient dazu, verhindern dass bestimmte Erweiterungen nicht zu den von einer Zertifizierungsstelle ausgestellten Zertifikaten hinzugefügt werden. In der Regel bleibt diese Liste leer; es können jedoch zu Testzwecken, zur Verbesserung der Kompatibilität, zur Erhöhung der Sicherheit usw. Erweiterungen zur Liste hinzugefügt (und somit aus den ausgestellten Zertifikaten entfernt) werden.

Eine der Erweiterungen, die üblicherweise einem Zertifikat hinzugefügt werden, ist die CRL-Verteilungspunkt-Erweiterung (CDP), auch bekannt als OID 2.5.29.31. Die CDP-Erweiterung teilt einem KDC (oder einer anderen prüfenden Stelle) genau mit, wo der Sperrstatus eines Zertifikats zu finden ist.

Frage: Was geschieht, wenn ich die Erweiterung „CDP“ zur DisableExtensionList? Würde eine AD CS-Zertifizierungsstelle ein Zertifikat ohne die CDP-Erweiterung ausstellen?

Antwort: Wie sich herausstellt – ja! Wenn OID 2.5.29.31 existiert in der DisableExtensionList, jedem von der Zertifizierungsstelle ausgestellten Zertifikat fehlt die CDP-Erweiterung, da Abbildung 1 zeigt.

Abbildung 1: Ein typisches Zertifikat und ein Zertifikat ohne die CDP-Erweiterung

Nun zur wichtigeren Frage: Könnte ich ein Zertifikat ohne CDP-Erweiterung verwenden, um PKINIT erfolgreich durchzuführen?

Leider nein.

Während des PKINIT-Prozesses versucht das KDC, den Sperrstatus des vorgelegten Zertifikats zu überprüfen. Ohne die CDP-Erweiterung weiß das KDC nicht, wo es den Status des Zertifikats überprüfen soll. Es antwortet mit KDC_REVOCATION_UNKNOWN, und die Authentifizierungsanfrage wird abgelehnt. Das Zertifikat ist ungültig … zumindest vorerst.

Diese „Fail-Closed“-Reaktion entspricht der Standardkonfiguration von AD, doch dieses Verhalten ist nicht unveränderlich.


Das Unbekannte ignorieren

Als ich mich näher damit befasste, stellte ich fest, dass Microsoft die Situation mit der nicht zugänglichen CRL bereits berücksichtigt und einen Registrierungswert zur Behebung dieses Problems erstellt hatte: UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors. Wie der Name des Werts bereits andeutet, gilt: Wenn UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors ist auf 1, zwischengespeicherte CRLs werden zur Überprüfung des Sperrstatus verwendet (besser als gar nichts!) und Fehler wegen unbekannter Sperrstatus werden ignoriert.

Ich fragte mich daraufhin: Wenn dieser Registrierungswert gesetzt ist und ich einen unbekannten Fehler erzwingen kann, würde PKINIT dann erfolgreich sein?

Sehr geehrte Leserinnen und Leser, ich bin zugleich sehr traurig und überaus begeistert, Ihnen mitteilen zu können, dass die Antwort ein klares JA ist .

Ein einziger Registrierungswert bewirkt, dass der gesamte PKINIT-Prozess von „Fail-Closed“ auf „Fail-Open“ umgestellt wird.

Abbildung 2: Sind Sie ein „Good Cert“ oder ein „Bad Cert“?

Dieses Verhalten beunruhigt mich zutiefst. Aber es ist auch völlig nachvollziehbar. Laut der Dokumentation verschiedener Anbieter (einschließlich Microsoft) kann dieser Registrierungswert verwendet werden, um Sicherheitskontrollen in Situationen wie Tests und Fehlerbehebung zu lockern.

Es ist nicht für den dauerhaften Einsatz vorgesehen . Im Grunde weist es das KDC an, das Tor für alles offen zu lassen, was nicht nachweisen kann, dass es tatsächlich außer Betrieb ist.


Das Unbekannte verbergen

Ein Zertifikat ohne CDP-Erweiterung weist einen interessanten und unerwarteten Nebeneffekt auf: Es kann wie jedes andere Zertifikat widerrufen und in die CRL einer Zertifizierungsstelle aufgenommen werden, doch die Aufnahme in diese Liste ist im Grunde genommen bedeutungslos.

Stellen Sie sich die CRL als einen Friedhof vor und jeden Sperreintrag als einen Grabstein. Das „Zombie-Zertifikat“ hat einen Grabstein, auf dem sein Name steht, doch das Zertifikat enthält keine Wegbeschreibung zum Friedhof, sodass niemand jemals dort nachschaut.

Es sieht tot aus, ist es aber nicht. Es ist ein Zombie-Zertifikat!

Dies stellt bei einer Reaktion auf Sicherheitsvorfälle ( incident response, IR) ein echtes Problem dar. Manchmal ist es im Rahmen der IR erforderlich, alle mit einem kompromittierten Konto verbundenen Zugangsdaten zurückzusetzen oder zu widerrufen, einschließlich Passwörtern und aller Authentifizierungszertifikate.

Was geschieht, wenn Sie ein Authentifizierungszertifikat tatsächlich nicht widerrufen können?


Die einzelnen Teile für eine unauffällige Persistenz zusammenfügen

Zu diesem Zeitpunkt meiner Untersuchung hatte ich einige unterschiedliche Verhaltensweisen beobachtet:

  1. Authentifizierungszertifikate können ohne CDP-Erweiterung erstellt werden.
  2. Es ist nicht möglich, den Widerrufsstatus eines Zertifikats zu überprüfen, das keine CDP-Erweiterung enthält.
  3. Ohne eine CDP-Erweiterung kann ein Zertifikat für die Zertifizierungsstelle und deren Administratoren als widerrufen erscheinen; dieser Anschein ist jedoch bedeutungslos, wenn der Widerrufsstatus nicht überprüft werden kann.
  4. Kann ein Prüfer den Widerrufsstatus eines Zertifikats (aus welchem Grund auch immer) nicht abfragen, lautet der Status des Zertifikats „unbekannt“ und nicht „widerrufen“ oder „gültig“.
  5. Standardmäßig lehnt die PKINIT-Implementierung von Microsoft Zertifikate mit einem unbekannten Sperrstatus ab.
  6. Das standardmäßige „Fail-Closed“-Verhalten lässt sich durch Ändern eines einzigen Registrierungswerts auf „Fail-Open“ umstellen.

Alle Teile waren vorhanden. Ich musste lediglich aufhören, sie zum Laufen bringen zu wollen.

Ich habe viel zu viel Zeit damit verbracht, diese Verhaltensbausteine zu einer vollständigen Kette der Berechtigungserweiterung zusammenzufügen, habe es aber schließlich aufgegeben. Es schien mir einfach unmöglich. Ohne Administratorrechte für den CA-Host oder den CA-Dienst ist es unmöglich, Änderungen vorzunehmen DisableExtensionList. Die Änderung der UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors Für die Bearbeitung des Registrierungswerts auf Domänencontrollern ist in der Regel die Mitgliedschaft in der Domänengruppe „BUILTIN\Administrators“ (BA) erforderlich. Ohne bereits vorhandene Berechtigungen und Rechte ist keiner der beiden Vorgänge möglich.

Was wäre jedoch, wenn ich mich nicht mehr auf ESCs (Eskalationstechniken) konzentrieren würde, sondern stattdessen über PERSISTs (Beharrlichkeitstechniken) nachdenken würde?

Im Whitepaper „Certified Pre-Owned“ von SpecterOps aus dem Jahr 2021 führten die Autoren mehrere Optionen für die Persistenz auf Domänen-, Benutzer- und Rechner-Ebene auf , die auf AD CS basieren. Persistenz ist nicht so spektakulär wie die Eskalation und wird bei einem typischen Penetrationstest selten besonders hervorgehoben. Angreifer nutzen Persistenz jedoch, um sich erneut Zugang zu einer Umgebung zu verschaffen, die sie zuvor kompromittiert haben.

Das ist ein wichtiger Aspekt!


Zusammenfassung: Wie Angreifer „Zombie-Zertifikate“ einrichten

Als ich meine Denkweise von „Ich muss unbedingt einen neuen ESC finden!“ zu „PERSIST ist ebenfalls beängstigend!“ änderte, wurde mir die Situation klar – und ehrlich gesagt hat mich das ein wenig erschreckt. Stellen Sie sich vor, ein Angreifer würde die folgenden Schritte unternehmen:

  1. Sie erhalten Zugriff mit weitreichenden Berechtigungen auf Ihre AD-Umgebung: BA, Domänenadministratoren (DA) oder Unternehmensadministratoren (EA). (Dieser Schritt ist bewusst sehr allgemein gehalten. Finden Sie sich damit ab!)
  2. Der Angreifer vergewissert sich, dass in der Gesamtstruktur eine AD CS Public Key Infrastructure (PKI) vorhanden ist und PKINIT unterstützt, indem er prüft, ob eine oder mehrere Zertifizierungsstellen in der Gesamtstruktur enthalten sind. NtAuthCertificates Objekt.
  3. Mithilfe von „RemoteRegistry“ oder durch direkte Änderung der Registrierungsdatenbank legt der Angreifer die UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors Wert für 1 auf einem oder mehreren Rechenzentren.
  4. Sie fügen die OID hinzu 2.5.29.31 an eine CA DisableExtensionList, entweder über certutil.exe oder durch direkte Änderung der Registrierungsdaten des CA-Hosts.
  5. Der Angreifer fordert ein Authentifizierungszertifikat für einen Benutzer an, über den er die Kontrolle hat – wahrscheinlich das BA-/DA-/EA-Konto, das er gerade nutzt.
  6. Sie bestätigen, dass das „Zombie-Zertifikat“ mit PKINIT funktioniert.

In einer typischen Umgebung lassen sich die Phasen „Erkundung“, „Registrierungsänderung“, „Zertifikatsanforderung“ und „PKINIT-Validierung“ dieses Angriffs per Skript automatisieren und innerhalb von Sekunden ausführen, da viele dieser Komponenten allgemein bekannt sind oder sich mithilfe integrierter Binärdateien und .NET-Reste, die auf jedem modernen Windows-Computer vorhanden sind, äußerst leicht ermitteln lassen.

Sofern Sie Ereignisse aus mehreren Datenquellen nicht zu einem einzigen Indikatorensatz zusammenführen, werden Sie diesen Angriff schlichtweg nicht bemerken.

Stellen wir uns jedoch einmal vor, unsere tapferen Verteidiger bemerken das Eindringen und ergreifen umgehend Maßnahmen, um es einzudämmen. Sie:

  • Beenden Sie alle aktiven Anmeldesitzungen des kompromittierten Kontos
  • Setzen Sie das AD-Passwort des kompromittierten Kontos zurück
  • Entziehen Sie die Authentifizierungszertifikate des kompromittierten Kontos
  • Kümmern Sie sich um andere Dinge … Ich gehöre nicht zum IR-Team von Semperis, daher verlasse ich mich auf deren Erfahrung …

Trotz dieser Maßnahmen kann der Angreifer das in Schritt 6 oben angeforderte „Zombie-Zertifikat“ nutzen, um PKINIT durchzuführen und sich erneut Zugriff auf das Konto zu verschaffen , das er zuvor kontrolliert hat.

Wie? Weil der Sperrstatus des Zertifikats unbekannt ist und der Angreifer den PKINIT-Prozess so verändert hat, dass er bei unbekanntem Sperrstatus im „Fail-Open“-Modus arbeitet.


Es wird noch unheimlicher: Die Wiederbelebung von Zombies

Die von mir oben beschriebene Reaktion im Rahmen des Informationssicherheitsmanagements war bewusst unvollständig: Das kompromittierte Konto hätte deaktiviert und vollständig durch ein neues Konto ersetzt werden müssen. Doch in der Hektik eines Vorfalls können Abhilfemaßnahmen leicht übersehen werden.

Unvollständige Eindämmung ist eine reale Gefahr!

Ein vorausschauenderer Angreifer hätte jedoch einige Änderungen an seinem Vorgehen vornehmen können, um seinen Zugriff noch dauerhafter zu sichern . Anstatt eine bereits vorhandene Vorlage zu verwenden, um ein Authentifizierungszertifikat für das von ihm kompromittierte Konto anzufordern, hätte der Angreifer Folgendes tun können:

  • Erstellen Sie eine neue Vorlage, die die fehlerhafte Konfiguration des ESC1 enthält
  • Verwenden Sie die Vorlage „ESC1“, um ein Zertifikat anzufordern, das den SAN eines anderen privilegierten Kontos enthält.

Sollte nun der ursprünglich kompromittierte Benutzer deaktiviert oder gelöscht werden, würde der Angreifer dennoch die Kontrolle über das im SAN enthaltene privilegierte Konto behalten.

Dieser Zombie hat einen zweiten Herzschlag. Töten Sie den Wirt, und er wandelt in einer anderen Identität weiter.

Anmerkung: Es gibt noch einige weitere hinterhältige Methoden, um diesen Angriff noch unauffälliger zu gestalten, doch ich kann diese hier aus Gewissensgründen nicht näher erläutern.


So erkennen Sie „Zombie-Zertifikate“

Woran erkennen Sie, ob Sie es mit einer Zombie-Plage zu tun haben? Beginnen Sie mit den Gehirnen.

Das „Gehirn“ eines Zombie-Zertifikats ist das UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors Registrierungswert. Überprüfen Sie jeden „ Domain Controller “ in Ihrer Gesamtstruktur sowie alle vertrauenswürdigen Forests. Der vollständige Registrierungs-Pfad lautet:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\UseCachedCRLOnly AndIgnoreRevocationUnknownErrors

Falls bei einem DC dieser Wert auf 1, betrachten Sie dies als eindeutigen Hinweis auf eine Manipulation, bis das Gegenteil bewiesen ist. Gehen Sie mit den folgenden Maßnahmen vor:

  • Überprüfen Sie, ob Authentifizierungszertifikate für privilegierte Benutzer ausgestellt wurden, auch wenn diese als widerrufen erscheinen.
  • Suchen Sie alle Authentifizierungszertifikate, die den SAN eines privilegierten Benutzers enthalten, unabhängig davon, ob der Anforderer aktiviert oder deaktiviert ist.
  • Überprüfen Sie alle Zertifizierungsstellen (CA) DisableExtensionList indem Sie den folgenden Befehl ausführen: certutil -config <CA-HOST-FQDN\CAName> -getreg policy\DisableExtensionList

Sollten Sie die folgende Ausgabe sehen, hat sich etwas geändert, das sich eigentlich nicht hätte ändern dürfen:

Abbildung 3: Der Angreifer befindet sich im Haus

Wie man den Zombie tötet

Der Registrierungswert ist der entscheidende Schlag. Ein „Zombie“-Zertifikat ist nur so lange gefährlich, wie mindestens ein Domänencontroller einen unbekannten Sperrstatus akzeptiert. Beseitigen Sie diese Bedingung als Erstes.

  1. Löschen Sie auf jedem betroffenen DC UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors und starten Sie das Kerberos Key Distribution Center neu. Dadurch wird das „Fail-Closed“-Verhalten sofort wiederhergestellt. PKINIT lehnt jedes Zertifikat ab, dessen Sperrstatus nicht bestätigt werden kann.
  2. OID entfernen 2.5.29.31 aus den CA’s DisableExtensionList. Neue Zertifikate werden wieder die CDP-Erweiterung enthalten.
    Ein entscheidender Punkt: Zertifikate, die bereits ohne CDP-Erweiterung ausgestellt wurden, können dauerhaft nicht widerrufen werden, unabhängig davon, was in der CRL der Zertifizierungsstelle vermerkt ist. Der Widerrufseintrag ist zwar vorhanden, wird jedoch von keinem Prüfer jemals gefunden, da das Zertifikat keinen Verweis auf die CRL enthält. Diese Zertifikate stellen nach der Behebung des Problems in der Registrierungsdatenbank keine Gefahr mehr dar, müssen jedoch nachverfolgt und ersetzt werden.
  3. Ermitteln Sie alle Zertifikate, die während des Zeitraums ausgestellt wurden, in dem DisableExtensionList enthielten die CDP-OID. Widerrufen Sie sie alle. Sobald der Registrierungswert korrigiert ist, sind sie zwar bereits funktional unwirksam, doch ein ausdrücklicher Widerruf schließt den Kreis und schafft einen Prüfpfad.
  4. Erzwingen Sie eine erneute Registrierung für alle betroffenen Konten, insbesondere für Konten mit erweiterten Berechtigungen. Stellen Sie neue Zertifikate aus, die eine gültige CDP-Erweiterung enthalten.

Den nächsten Ausbruch verhindern

Es reicht nicht aus, den aktiven Zombie zu töten. Sie müssen den nächsten aufhalten.

  • Überwachen Sie die Registrierung jeder „ Domain Controller “, der Sie vertrauen. Benachrichtigung bei jeder Änderung an UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors in allen Rechenzentren. Jeder andere Wert als absent oder 0 sollte eine unverzügliche Untersuchung auslösen.
  • Audit DisableExtensionList nach einem Zeitplan. Er sollte auf jeder Zertifizierungsstelle in Ihrer Gesamtstruktur leer sein. Sie können den Registrierungspfad direkt überprüfen oder ihn über certutil: certutil -config <CA-HOST-FQDN\CAName> -getreg policy\DisableExtensionList
    Profi-Tipp: Die Semperis Lightning-Plattform kann die Registrierung für Sie überwachen!
  • Verwenden Sie „Locksmith 2“. Sowohl „Locksmith“ als auch „Locksmith 2“ verfügen über eine Erkennung für die Fehlkonfiguration von „DisableExtensionList“. Führen Sie diese regelmäßig im Rahmen Ihrer AD CS-Zustandsprüfungen aus.

Damit es zu einem „Zombie-Zertifikat“-Ausbruch kommt, müssen zwei Bedingungen gleichzeitig erfüllt sein:

  • Eine Zertifizierungsstelle, die Zertifikate ohne CDP-Erweiterung ausstellt
  • Mindestens eine Zertifizierungsstelle (DC), die bei unbekanntem Sperrstatus im offenen Zustand ausfällt

Beseitigen Sie eine der beiden Bedingungen, und der Angriff schlägt fehl. Beseitigen Sie beide, und Sie verfügen über eine wesentlich sicherere PKI.


Rechnen Sie damit, dass die Zombies wieder auferstehen – und seien Sie darauf vorbereitet

„Zombie-Zertifikate“ sind kein theoretischer Sonderfall. Sie beruhen vollständig auf dokumentierten, von Microsoft beabsichtigten Funktionen.

Kein CVE wird dieses Problem beheben. Es wird kein Patch veröffentlicht. Der Angriff funktioniert, weil Administratoren gelegentlich die Überprüfung der Sperrung lockern müssen – und Angreifer können genau diese Flexibilität ausnutzen.

Die gute Nachricht ist, dass die Voraussetzungen erheblich sind. Ein Angreifer benötigt Zugriff mit weitreichenden Berechtigungen, bevor all dies überhaupt möglich ist, was bedeutet, dass eine gute Verwaltung von Zugriffsrechten bereits viel bewirkt. Die schlechte Nachricht ist, dass der Angriff, sobald diese Voraussetzungen erfüllt sind, schnell und automatisierbar ist und die meisten Standard-IR-Skripte umgeht.

Falls Sie AD CS in Ihrer Umgebung betreiben, überprüfen Sie den Registrierungswert und die DisableExtensionList auf jedem CA heute. Sollten Sie eines der beiden unerwartet vorfinden, liegt ein Problem vor, das einer Untersuchung bedarf. Sollten Sie beide zusammen vorfinden, könnte bereits ein Zombie durch Ihren Wald streifen.

Sollten Sie Unterstützung bei der Beseitigung von „Zombie-Zertifikaten“ benötigen, wenden Sie sich bitte an Semperis. Unsere Experten für „ incident response “ beschäftigen sich täglich mit diesem Thema – und wir stehen Ihnen gerne zur Seite.

Haftungsausschluss

Dieser Inhalt wird ausschließlich zu Bildungs- und Informationszwecken bereitgestellt. Er soll das Bewusstsein und die verantwortungsvolle Behebung von Sicherheitslücken fördern, die auf Systemen bestehen können, die Sie besitzen oder zu deren Prüfung Sie berechtigt sind. Die unbefugte Nutzung dieser Informationen zu böswilligen Zwecken, zur Ausbeutung oder zum unrechtmäßigen Zugriff ist strengstens untersagt. Semperis befürwortet oder duldet keine illegalen Aktivitäten und lehnt jede Haftung ab, die aus dem Missbrauch des Materials entsteht. Darüber hinaus übernimmt Semperis keine Garantie für die Richtigkeit oder Vollständigkeit der Inhalte und haftet nicht für Schäden, die sich aus der Verwendung der Inhalte ergeben.


Erfahren Sie mehr über die Verhinderung und Beseitigung von Persistenz in Active Directory und Entra ID