Magic Quadrant™ für Privilegiertes Zugriffsmanagement 2026: Netwrix zum fünften Mal in Folge anerkannt. Bericht herunterladen.

Ressourcen­zentrumBlog

ESC9 vs. ESC16: gleicher Fehler, unterschiedlicher Explosionsradius

ESC9 vs. ESC16: gleicher Fehler, unterschiedlicher Explosionsradius

Nov 9, 2026

ESC9 und ESC16 sind dieselbe AD CS-Schwachstelle auf zwei Ebenen. Beide verhindern, dass die Zertifizierungsstelle die SID-Sicherheits-Erweiterung zu Zertifikaten hinzufügt, sodass ein Domänencontroller auf eine schwache, namensbasierte Zuordnung zurückgreifen muss. ESC9 ist ein Flag bei einer Zertifikatvorlage. ESC16 ist ein Registrierungswert auf der CA, der die Erweiterung bei allem entfernt, was sie ausstellt. Ein sauberer Vorlagen-Audit deckt ESC16 nicht ab, prüfen Sie also die CA selbst und bestätigen Sie, dass Ihre Domänencontroller eine starke Zuordnung durchsetzen.

ESC9 und ESC16 sind zwei der nummerierten Eskalationstechniken (ESC), die für Active Directory Certificate Services (AD CS) katalogisiert sind und dieselbe Schwachstelle auf unterschiedlichen Ebenen darstellen. Beide entfernen die Sicherheitskennung (SID)-Sicherheitserweiterung von ausgestellten Zertifikaten, was einem Angreifer ermöglicht, ein anderes Konto durch schwache Zertifikatszuordnung zu imitieren. ESC9 betrifft eine einzelne Zertifikatvorlage. ESC16 betrifft alle Zertifikate, die eine Zertifizierungsstelle (CA) ausstellt.

Wenn Sie ESC9 vor ein paar Jahren behoben haben, sagt das nichts über ESC16 aus.

Was ist ESC9?

ESC9 ist eine Vorlageneinstellung. Wenn CT_FLAG_NO_SECURITY_EXTENSION im Attribut msPKI-Enrollment-Flag einer Vorlage gesetzt ist, enthalten Zertifikate, die aus dieser Vorlage ausgestellt werden, nicht die SID-Erweiterung (szOID_NTDS_CA_SECURITY_EXT). Diese Erweiterung ermöglicht es einem Domänencontroller (DC), ein Zertifikat einem bestimmten Konto zuzuordnen. Ohne sie fällt der DC auf die Zuordnung anhand des Benutzerprinzipalnamens (UPN) zurück.

Der Angriff benötigt drei Dinge: einen Angreifer mit Schreibzugriff auf den UPN eines Opferkontos (GenericWrite reicht aus), Einschreiberechte für eine client-authentication-Vorlage mit gesetztem Flag und einen DC, der kein starkes Zertifikats-Mapping erzwingt. Der Angreifer ändert den UPN des Opfers, damit er einem privilegierten Konto entspricht, meldet sich an, stellt den UPN zurück und authentifiziert sich mit dem Zertifikat als privilegierter Benutzer.

Oliver Lyak dokumentierte ESC9 im August 2022, und viele Scanner können es finden, einschließlich Netwrix PingCastle. Die folgende Checkliste zeigt, wie Sie Ihre eigenen Vorlagen überprüfen.

Was ist ESC16?

ESC16 erreicht dasselbe Ziel, ohne eine Vorlage zu ändern. Wenn die OID 1.3.6.1.4.1.311.25.2, die szOID_NTDS_CA_SECURITY_EXT SID-Sicherheitserweiterung, im DisableExtensionList-Registrierungswert des Richtlinienmoduls der CA aufgeführt ist, hört die CA auf, die SID-Erweiterung zu allem hinzuzufügen, was sie ausstellt. Jede Vorlage hinter dieser CA verhält sich nun so, als wäre die ESC9-Flagge gesetzt, einschließlich Vorlagen, die seit Jahren niemand überprüft hat.

Eine Umgebung kann aus mehreren Gründen diese Einstellung erhalten: eine Kompatibilitätskorrektur für ein Drittanbieter-Tool, eine Migration oder eine Legacy-Anwendung, die die Erweiterung nicht unterstützt. Es handelt sich um einen einzelnen Registrierungseintrag, der leicht übersehen wird und stillschweigend den Schutz aufhebt, den Sie Vorlage für Vorlage aufgebaut haben.

Die Einstellung ist kein Template-Attribut. Es handelt sich um eine CA-Konfiguration, und viele Überprüfungen der Zertifikatshygiene öffnen nie die eigenen Richtlinienmodul-Einstellungen der CA. Eine Organisation kann bei jeder Vorlage sauber sein, den Bericht als Nachweis haben und dennoch über die CA exponiert sein. Wenn Sie vor Jahren für ESC9 gescannt haben und Ihre CAs seitdem nicht überprüft haben, kann ein Angreifer immer noch denselben Identitätsdiebstahl-Angriff über ESC16 durchführen.

Schützt Sie eine starke Zertifikatszuordnung?

Teilweise. Beide Techniken hängen davon ab, dass der DC schwache Zuordnungen akzeptiert, und DCs, die eine starke Zertifikatsbindung durchsetzen, machen beide wirkungslos. Seit den Windows-Updates vom September 2025 führen gepatchte DCs eine vollständige Durchsetzung durch und die Kompatibilitätsmodus-Einstellung wird nicht mehr unterstützt, sodass eine vollständig gepatchte Domäne nacktes ESC9 und ESC16 stoppt. Es bleiben jedoch zwei Lücken: Jeder DC, der diese Updates verpasst hat, und Ketten, bei denen der Angreifer seine eigene SID in der Zertifikatsanfrage angeben kann, wie ESC16 kombiniert mit ESC6 oder ESC15. Überprüfen Sie die Durchsetzung bei jedem DC und prüfen Sie auch die CA.

Wie überprüfen und beheben Sie beides?

Sie benötigen zwei Prüfungen, da ESC9 in den Vorlagen und ESC16 im CA lebt.

Auf ESC9 prüfen (Zertifikatvorlagen)

  1. Führen Sie einen PingCastle-Scan durch.
  2. Öffnen Sie den Bericht und suchen Sie nach CT_FLAG_NO_SECURITY_EXTENSION (das Risiko ist A-CertTempNoSecurity). Suchen Sie nach dem Text „Mindestens eine Zertifikatvorlage hat das Flag CT_FLAG_NO_SECURITY_EXTENSION gesetzt.“
  3. Wenn dieser Text nicht vorhanden ist, tragen keine der gescannten Vorlagen die Markierung. Ist er vorhanden, entfernen Sie die Markierung von den betroffenen Vorlagen.

Prüfen Sie ESC16 (die CA)

Führen Sie auf jeder CA Folgendes aus:

      certutil -getreg policy\DisableExtensionList
      

Wenn die OID 1.3.6.1.4.1.311.25.2 in der Ausgabe erscheint, entfernt diese CA die SID-Erweiterung von allem, was sie ausstellt. Entfernen Sie sie von der Liste, es sei denn, Sie haben einen dokumentierten Grund dafür.

Um das Problem zu beheben, entfernen Sie die OID und starten Sie Certificate Services neu, damit die Änderung wirksam wird:

      certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2
net stop certsvc
net start certsvc
      

Führen Sie anschließend certutil -getreg policy\DisableExtensionList erneut aus, um zu bestätigen, dass die OID entfernt wurde. Zertifikate, die bereits ohne die Erweiterung ausgestellt wurden, bleiben so, überprüfen Sie diese also, wenn Sie einen Missbrauch der Einstellung vermuten. Wenn eine Anwendung die Einstellung benötigte, testen Sie sie, bevor Sie sie breit ausrollen.

Bestätigen Sie dann die Durchsetzung: Prüfen Sie, ob Ihre DCs eine starke Zertifikatszuordnung durchsetzen, da dies beide Techniken abschwächt. Bei einem DC mit aktuellen Updates ist dies die Standardeinstellung. Für den Rest der Exposition Ihrer CA, einschließlich ESC8 bei der Webanmeldung, überprüfen Sie die riskanten AD CS-Einstellungen, die oft zusammen mit diesen beiden auftreten.

Wie erkennen Sie die nächste Änderung?

Für ESC9 künftig: Das Template-Flag befindet sich in Active Directory, was bedeutet, dass eine Änderung daran eine Änderung eines AD-Objekts ist. Netwrix Threat Prevention überwacht AD-Änderungen in Echtzeit und kann sie blockieren, sodass jemand, der CT_FLAG_NO_SECURITY_EXTENSION auf einem Template setzt, gestoppt werden kann, bevor es wirksam wird, und nicht erst bei der nächsten Bewertung gefunden wird.

Für ESC16 künftig: Die Einstellung befindet sich in der Registry auf dem CA-Server, nicht in AD, daher benötigt sie eine eigene Überwachung: Registry-Auditing auf den CA-Hosts, die Ihr SIEM speisen, plus die oben genannte periodische Prüfung. Netwrix korreliert außerdem zertifikatbasierte Anmeldungen mit der Ausstellung und meldet fehlende SID-Erweiterungsszenarien, sodass Missbrauch der Einstellung sichtbar wird, auch wenn die Registry-Änderung selbst unbemerkt bleibt.

Sehen Sie, wie Netwrix AD CS sichert.

Teilen auf

Erfahren Sie mehr

Über den Autor

Asset Not Found

Joe Dibley

Sicherheitsforscher

Security Researcher bei Netwrix und Mitglied des Netwrix Security Research Teams. Joe ist ein Experte für Active Directory, Windows und eine Vielzahl von Unternehmenssoftwareplattformen und -technologien. Joe erforscht neue Sicherheitsrisiken, komplexe Angriffstechniken sowie zugehörige Milderungs- und Erkennungsmaßnahmen.