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

Ressourcen­zentrumBlog

ESC8 ist immer noch der häufigste AD CS-Befund, den wir sehen

ESC8 ist immer noch der häufigste AD CS-Befund, den wir sehen

Nov 3, 2026

ESC8 ist ein NTLM-Relay-Angriff gegen die AD CS-Webanmeldung und immer noch der am häufigsten gemeldete Eskalationspfad für Zertifikatdienste bei Active Directory-Gesundheitsprüfungen. Er besteht, weil die Installation von Web Enrollment standardmäßig HTTP und NTLM aktiviert. In Kombination mit einer Zwangstechnik wie PetitPotam ermöglicht er einem Angreifer, ein Zertifikat zu erhalten, das sich als Domänencontroller authentifiziert. Entfernen Sie die Rolle, wenn Sie sie nicht benötigen; wenn doch, verlangen Sie HTTPS und erzwingen Sie Extended Protection for Authentication.

In Berichten, die über die Schaltfläche „Mit Statistiken vergleichen“ an die öffentliche Statistikseite von Netwrix PingCastle gesendet wurden, wurde A-CertEnrollHttp bis November 2026 6.487-mal gemeldet. Das ist mehr als jeder andere Active Directory Certificate Services (AD CS) Eskalationspfad, den wir verfolgen.

Zusammen mit A-CertEnrollChannelBinding deckt es ESC8 ab. ESC8 ist gut dokumentiert und immer noch so verbreitet, weil es mit einer unsicheren Standardeinstellung beginnt.

Was ist ESC8?

ESC8 ist ein NTLM Relay-Angriff gegen die AD CS Web Enrollment-Schnittstelle. Wenn die Rolle Certification Authority Web Enrollment installiert ist und deren HTTP-Endpunkt (certsrv) NTLM-Authentifizierung ohne Schutzmaßnahmen wie Extended Protection for Authentication (EPA) oder Channel Binding akzeptiert, kann ein Angreifer einen abgefangenen NTLM-Authentifizierungsversuch an diesen Endpunkt weiterleiten und im Namen einer anderen Person ein Zertifikat anfordern.

Wenn ein Angreifer einen Domänencontroller dazu zwingt, sich bei ihm zu authentifizieren, beispielsweise mit der Technik PetitPotam, kann er diese Authentifizierung an den Web-Enrollment-Endpunkt weiterleiten und ein Zertifikat erhalten, das sich als dieser Domänencontroller authentifiziert. Von dort ist es nur ein kurzer Weg zu DCSync und der vollständigen Kompromittierung der Domäne.

MITRE erfasst dies unter T1557 (Adversary-in-the-Middle) für den Zwangs- und Relay-Mechanismus und T1649 (Steal or Forge Authentication Certificates) für das, was passiert, sobald der Angreifer das Zertifikat in der Hand hat.

Warum ist ESC8 so verbreitet?

Die Installation der Web Enrollment-Rolle aktiviert standardmäßig HTTP- und NTLM-Authentifizierung, während HTTPS mit durchgesetztem EPA zusätzliche Konfiguration erfordert. Teams, die diese Konfiguration nicht kennen, bleiben standardmäßig exponiert.

Niemand entscheidet sich, die Zertifikatsregistrierung für NTLM-Relay offen zu lassen. Jemand richtet eine CA ein und aktiviert Web Enrollment, und sechs Monate später erinnert sich niemand daran, dass die Rolle läuft, geschweige denn, dass EPA aktiviert sein muss.

Der Befund tritt sogar in gehärteten Umgebungen auf, wenn auch seltener, da das Bewusstsein für ESC8 inzwischen verbreitet ist.

Was kann ein Angreifer mit einem ESC8-Zertifikat tun?

ESC8 hat eine hohe Schwere, weil der Angreifer nach erfolgreichem Relay Zugriff hat. Eine NTLM-Sitzung endet schnell, aber das ausgestellte Zertifikat bleibt gültig, bis es abläuft oder widerrufen wird, oft ein Jahr oder länger.

Das Zertifikat funktioniert auch über Protokolle hinweg. Der Angreifer kann sich mit Kerberos oder Schannel (zertifikatbasierte TLS-Anmeldung) authentifizieren, wodurch alle NTLM-Beschränkungen in der Umgebung umgangen werden.

In Kombination mit einer Zwangstechnik benötigt die Kette nur Netzwerkzugang zu einem verwundbaren Web-Enrollment-Endpunkt und eine Maschine, die der Angreifer zur Authentifizierung zwingen kann. Das ist eine niedrige Hürde für einen Pfad, der mit Domain Admin-äquivalentem Zugriff endet.

Wie erkennt PingCastle ESC8?

PingCastle überprüft jede Zertifizierungsstelle und jeden Registrierungsserver, den es im Netzwerk findet. Für jeden sendet es eine Anfrage an zwei Endpunkte: die Webregistrierungsseite (certsrv/certrqxt.asp) und den Certificate Enrollment Service (CES)-Endpunkt. Wenn einer von beiden erfolgreich über unverschlüsseltes HTTP antwortet, kennzeichnet PingCastle die Domäne, da ein Angreifer im Netzwerk die NTLM-Authentifizierung an einen unverschlüsselten Registrierungsendpunkt weiterleiten kann.

A-CertEnrollChannelBinding betrifft die HTTPS-Seite. Es markiert Registrierungsendpunkte, die HTTPS akzeptieren, aber kein Channel Binding erzwingen, da eine weitergeleitete NTLM-Sitzung über HTTPS dennoch durchkommt.

Wie behebt man ESC8, ohne die Anmeldung zu unterbrechen?

Brauchen Sie Web Enrollment überhaupt? Wenn niemand in Ihrer Umgebung die certsrv-Schnittstelle für Zertifikatsanforderungen nutzt, entfernen Sie die Rolle. Das ist die einfachste Maßnahme und die erste, die Sie prüfen sollten.

Falls benötigt, schließt HTTPS allein ESC8 nicht. Der Enrollment-Endpunkt muss ebenfalls EPA oder Channel Binding durchsetzen, da eine weitergeleitete NTLM-Sitzung weiterhin über eine HTTPS-Verbindung übertragen werden kann.Microsofts Anleitung zur Minderung von NTLM-Relay-Angriffen gegen AD CS (KB5005413) führt durch die Konfiguration.

Weitere Maßnahmen: Beschränken Sie den Netzwerkzugriff auf die Weboberfläche der CA, deaktivieren Sie NTLM, wenn Kerberos ausreicht, und patchen Sie bekannte Zwangstechniken. Für den Rest der Angriffsfläche Ihrer CA überprüfen Sie die riskanten AD CS-Einstellungen, die zusammen mit ESC8 auftreten.

Meine Empfehlung

Ich empfehle, vor der Härtung zu prüfen, ob Web Enrollment benötigt wird. Falls ja, verlangen Sie HTTPS und EPA und befolgen Sie KB5005413.

Um zu prüfen, ob Sie exponiert sind, führen Sie einen kostenlosen PingCastle-Scan durch. Er kennzeichnet ESC8 direkt sowie die übrige AD CS-Risikofläche. Suchen Sie im Bericht nach "The certificate enrollment interface is accessible by unencrypted HTTP" und "Channel Binding is not enforced for the HTTPS Certificate Enrollment Interface", den beiden Befunden, die auf ein ESC8-Risiko hinweisen.

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.