goSecurity BLOG

Einleitung

Das Active Directory ist das Rückgrat vieler Unternehmensnetzwerke. Es verwaltet Benutzer, Gruppen, Computer und ihre Rechte und das oft über mehrere Domänen und sogar über Vertrauensstellungen hinweg. Gerade diese Vertrauensstellungen sollen eigentlich Sicherheit und klare Grenzen schaffen. Doch was passiert, wenn genau diese Mechanismen zum Einfallstor für Angreifer werden?

Ein besonders gefährliches Szenario ergibt sich, wenn Active Directory Certificate Services (AD CS) ins Spiel kommen. Die PKI-Infrastruktur in Windows-Umgebungen ist komplex und bietet viele Angriffsflächen, insbesondere dann, wenn sie nicht sauber konfiguriert ist. AD CS wird oft als reines Infrastruktur-Feature gesehen, das einfach läuft. Dass darin jedoch gefährliche Schwachstellen lauern können, ist vielen Administratoren nicht bewusst. Angreifer, die einmal Fuss in einer Domäne gefasst haben, können über falsch konfigurierte Zertifikatsvorlagen und schwach abgesicherte Vertrauensstellungen mitunter ganze Gesamtstrukturen (Forest) kompromittieren. Die Kombination aus Trust Abuse und Missbrauch von AD CS eröffnet dabei besonders perfide Möglichkeiten. Mit einem einzigen Zertifikat lässt sich nicht nur Authentifizierung erschleichen, sondern auch der Zugang zu bisher unerreichbaren Ressourcen in einer fremden Domäne.

In diesem Blog schauen wir uns an, wie genau solche Angriffe ablaufen, welche Voraussetzungen erfüllt sein müssen und wie Unternehmen sich davor schützen können. Dabei richten wir den Fokus auf ein oft unterschätztes, aber brandgefährliches Szenario. Die Kompromittierung von Active Directory-Vertrauensstellungen durch den gezielten Missbrauch von AD CS.

Was sind Active Directory-Vertrauensstellungen?

In einer typischen Active Directory-Umgebung besteht selten nur eine einzelne Domäne. Gerade in grösseren Organisationen, bei Fusionen oder bei der Anbindung von Partnerunternehmen entstehen komplexe Strukturen mit mehreren Domänen oder sogar verschiedenen Gesamtstrukturen. Um dennoch eine zentrale Authentifizierung und Autorisierung über diese Grenzen hinweg zu ermöglichen, kommen Vertrauensstellungen zum Einsatz.

Eine Vertrauensstellung ist eine logische Beziehung zwischen zwei Active Directory-Domänen oder zwei Gesamtstrukturen (Forests), die auf dem Prinzip basiert, dass eine Domäne der anderen die Authentizität von Benutzeranfragen abnimmt. Sie erlaubt es Benutzern einer Domäne, auf Ressourcen in einer anderen Domäne zuzugreifen, ohne dort ein eigenes Benutzerkonto zu besitzen. Technisch basiert das Ganze auf dem Austausch von Kerberos-Tickets und NTLM-Informationen. Das Active Directory sorgt dabei dafür, dass die Authentifizierung zwischen den vertrauenden und vertrauenswürdigen Parteien reibungslos funktioniert.

Es gibt unterschiedliche Typen von Vertrauensstellungen. Innerhalb Gesamtstrukturen (Forests) entstehen transitive Vertrauensstellungen automatisch, wenn neue Domänen hinzugefügt werden. Diese erlauben es, dass Vertrauen entlang einer Kette weitergegeben wird. Bei gesamtstrukturübergreifenden Beziehungen hingegen handelt es sich meist um explizite administrative Entscheidungen. Diese sogenannten Gesamtstruktur-Vertrauensstellungen (Forest Trusts) können entweder einseitig oder gegenseitig konfiguriert werden.

Vertrauensstellungen sind ein mächtiges Werkzeug, das administrative Trennung mit funktionaler Zusammenarbeit vereinen soll. Doch genau diese Macht birgt auch erhebliche Risiken. Denn wenn eine der beiden Seiten kompromittiert wird, kann ein Angreifer unter Umständen die Vertrauensstellung ausnutzen, um auf Ressourcen zuzugreifen, die eigentlich ausserhalb seiner Reichweite liegen sollten.

AD CS und seine Rolle im AD

Active Directory Certificate Services (AD CS) sind Microsofts integrierte Lösung für den Aufbau und Betrieb einer Public Key Infrastructure in Windows-Umgebungen. In vielen Unternehmen läuft AD CS im Hintergrund nahezu unsichtbar mit. Es stellt Zertifikate aus, die für verschiedenste Zwecke verwendet werden. Dazu gehört die Absicherung von HTTPS-Verbindungen, E-Mail-Verschlüsselung und vor allem die Authentifizierung von Benutzern und Computern.

Gerade dieser letzte Punkt ist sicherheitsrelevant. Wenn Zertifikate zur Authentifizierung eingesetzt werden, ersetzt ein digitales Zertifikat das klassische Passwort oder das Kerberos-Ticket. Windows bietet mit dem Protokoll PKINIT die Möglichkeit, sich mit einem Zertifikat gegenüber dem Domänencontroller zu authentifizieren. Wird ein solches Zertifikat akzeptiert, vergibt das Active Directory ein reguläres Ticket Granting Ticket. Der Benutzer oder Computer erhält dadurch die exakt gleichen Rechte wie bei einer normalen Anmeldung.

AD CS ist sehr flexibel. Diese Flexibilität macht die Infrastruktur jedoch auch anfällig für Fehlkonfigurationen. Im Zentrum stehen die sogenannten Zertifikatsvorlagen. Sie legen fest, wer welches Zertifikat beantragen darf, mit welchen Eigenschaften und zu welchem Zweck. Jede Vorlage definiert genau, welche Sicherheitseinstellungen gelten, welche Felder im Zertifikat enthalten sein dürfen und welche Rechte der Antragsteller haben soll.

Problematisch wird es, wenn Vorlagen so konfiguriert sind, dass sie sich leicht missbrauchen lassen. Das ist etwa der Fall, wenn normale Benutzer Zertifikate mit erweiterten Rechten beantragen dürfen oder wenn sie die Felder im Zertifikat frei bestimmen können. Besonders kritisch ist das Feld für den Subject Alternative Name (SAN). Wenn ein Benutzer dort einen beliebigen Namen eintragen darf, kann er sich beispielsweise ein Zertifikat für einen Domänen-Administrator ausstellen und sich damit authentifizieren.

Missbrauch von AD CS

Der Missbrauch von Active Directory Certificate Services ist kein theoretisches Konstrukt, sondern ein realer Angriffsvektor, der in vielen Unternehmensnetzwerken praktisch umsetzbar ist. Seit der Veröffentlichung der Studie Certified Pre-Owned von SpecterOps ist klar, dass AD CS in zahlreichen Umgebungen gefährlich falsch konfiguriert ist. Die Angriffsfläche ist gross, weil AD CS oft standardmässig installiert und über Jahre hinweg nicht hinterfragt wird.

Viele dieser Angriffe basieren darauf, dass ein Zertifikat für eine andere Identität beantragt werden kann. Das funktioniert immer dann, wenn eine Vorlage es erlaubt, den Subject Name oder SAN-Wert frei zu setzen, ohne dass dieser mit der tatsächlichen Identität des Antragstellers abgeglichen wird.

Angriffsszenario: Von der Zertifikatsvorlage zur Domänenübernahme

Ein besonders effektives Angriffsszenario ergibt sich, wenn ein Angreifer einen Domänencontroller in einer untergeordneten Domäne (Child Domain) kompromittiert hat. Mit Zugriff auf das LocalSystem-Konto dieses Systems kann er administrative Werkzeuge ausführen und direkt mit den internen Strukturen des Active Directorys interagieren. Besonders gefährlich wird dies in Umgebungen mit Enterprise-Zertifizierungsstellen, die automatisch Active Directory-Objekte verwalten und vertrauenswürdig gegenüber anderen Domänen sind.

Schauen wir uns das Ganze mal genauer an. Wir befinden uns auf einem kompromittierten Domänencontroller innerhalb einer untergeordneten Domäne (Child Domain). Über das LocalSystem-Konto haben wir vollen Zugriff auf das System und können nun beginnen, die AD-CS-Infrastruktur gezielt zu missbrauchen. Ziel ist es, ein Zertifikat zu erlangen, mit dem wir uns in der übergeordneten Domäne (Parent Domain) als privilegierter Benutzer authentifizieren können.

Zunächst öffnen wir die Zertifikatvorlagen-Verwaltung (certtmpl.msc) direkt auf dem Domänencontroller als LocalSystem. Dort duplizieren wir die bestehende Benutzer-Zertifikatvorlage und passen sie an. Wichtig ist vor allem, dass wir unter den Eigenschaften der Vorlage auf dem Reiter Subjektname (Subject Name) die Option Informationen werden in der Anforderung bereitgestellt (Supply in request) aktivieren. Damit ist es möglich, den Namen des gewünschten Zielkontos später selbst zu definieren. Wir sorgen ausserdem dafür, dass die Vorlage zur Client-Authentifizierung genutzt werden kann.

Bevor wir die Vorlage einsetzen können, müssen wir die Berechtigungen anpassen. Unter dem Reiter Sicherheit (Security) fügen wir den Administrator der untergeordneten Domäne (Child Domain) hinzu und weisen ihm das Recht Vollzugriff (Full Control) zu. So stellen wir sicher, dass wir das Zertifikat später ganz regulär mit einem legitimen Benutzerkonto beantragen können. Wir könnten hier einen beliebigen anderen Benutzer nehmen.

Nun wechseln wir in den ADSI-Editor mit dem Benutzer-Konto LocalSystem und verbinden uns mit der Konfigurationspartition (Configuration Partition) des Active Directorys. Unter CN=Public Key Services,CN=Services,CN=Configuration,DC=child,DC=local bearbeiten wir die Sicherheitseinstellungen und aktivieren die Vererbung für LocalSystem, damit auch untergeordnete Objekte wie Enrollment Services abgedeckt sind. Das ist notwendig, um die Zertifikatsvorlage gleich in der Zertifizierungsstelle eintragen zu können.

Jetzt gehen wir zu CN=Enrollment Services, suchen dort nach dem Objekt der aktiven Enterprise-Zertifizierungsstelle, öffnen die Eigenschaften und bearbeiten das Attribut certificateTemplates. Wir fügen den Namen unserer manipulierten Vorlage hinzu. Sobald wir diese Änderung speichern, erkennt die Zertifizierungsstelle die Vorlage als gültig an und wird ab sofort Zertifikate auf dieser Basis ausstellen.

Im nächsten Schritt melden wir uns als Administrator der untergeordneten Domäne (Child Domain) auf einem beliebigen System an. Mit Certify erstellen wir eine Zertifikatsanforderung. Im Feld Subject Alternative Name (SAN) geben wir gezielt ein Konto aus der übergeordneten Domäne (Parent Domain) an, in unserem Fall PARENT\Administrator. Die Anfrage wird erfolgreich verarbeitet, da die Vorlage bewusst keine Überprüfung des angegebenen Namens verlangt. Wir erhalten ein gültiges Benutzerzertifikat, ausgestellt durch eine vertrauenswürdige Enterprise CA.

Mit dem Zertifikat in der Hand starten wir Rubeus und nutzen den asktgt-Modus mit der Option /certificate:. Damit beantragen wir ein Kerberos-Ticket über PKINIT. Die übergeordneten Domäne (Parent Domain) akzeptiert die Authentifizierung, stellt ein gültiges TGT für den Administrator-Account aus, und Rubeus zeigt uns das Base64-kodierte Ticket an. Wir laden das Ticket mit der Option /ptt direkt in den aktuellen Arbeitsspeicher.

Jetzt können wir den letzten Schritt ausführen. Mit Enter-PSSession verbinden wir uns über PowerShell auf den Domänencontroller dc01.parent.local. Dank des geladenen Kerberos-Tickets wird die Verbindung erfolgreich aufgebaut, ohne dass wir jemals ein Passwort eingegeben haben. Wir haben nun interaktive, administrative Kontrolle über ein zentrales System der übergeordneten Domäne (Parent Domain).

Was hier wie eine reguläre Anmeldung aussieht, basiert in Wahrheit auf einem gezielten Missbrauch der Zertifikatsinfrastruktur in Verbindung mit einer offenen Vertrauensstellung. Die Technik ist legitim, der Ablauf ist leise, und klassische Sicherheitsüberwachung wird kaum auf diesen Vorgang anspringen. Genau deshalb ist diese Art Angriff so effektiv und genau deshalb sollte sie in jeder AD-Sicherheitsstrategie berücksichtigt werden.

Empfehlungen

Der Schutz vor solchen Angriffen beginnt bei der Infrastruktur. Innerhalb der Active Directory-Konfigurationspartition, insbesondere im Zweig CN=Public Key Services, sollten die Berechtigungen regelmässig überprüft werden. Es muss sichergestellt sein, dass keine unnötigen expliziten Schreibrechte für Gruppen wie Authentifizierte Benutzer (Authenticated Users), Domänen-Benutzer (Domain Users) oder Computerkonten von Domänencontrollern auf sensible Objekte wie Zertifikatsvorlagen oder Enrollment Services gesetzt wurden. Auch wenn Domänencontroller auf Basis ihrer Rolle grundsätzlich Lesezugriff auf diesen Bereich haben, benötigen sie keine zusätzlichen administrativen Rechte zum Bearbeiten dieser Konfiguration.

Zertifikatsvorlagen sollten restriktiv konfiguriert werden. Für Vorlagen, die zur Authentifizierung verwendet werden, sollte die Option Informationen werden in der Anforderung bereitgestellt (Supply in request) auf dem Reiter Subject Name deaktiviert bleiben, es sei denn, ein spezieller Anwendungsfall erfordert diese Funktionalität. In solchen Fällen ist eine zusätzliche Absicherung notwendig, zum Beispiel durch manuelle Genehmigungen, restriktive Zielgruppenzuweisung oder dedizierte Enrollment-Prozesse. Vorlagen mit potenziell missbrauchbaren Konfigurationen sollten regelmässig identifiziert, dokumentiert und kritisch bewertet werden.

Vertrauensstellungen zwischen Gesamtstrukturen (Forests) oder Domänen sollten nur dort eingerichtet werden, wo sie technisch und organisatorisch notwendig sind. Ihre Konfiguration sollte dokumentiert und möglichst restriktiv gehalten werden. Funktionen wie SID Filtering, Selective Authentication oder eingeschränkte Namensräume bieten Möglichkeiten, die Wirkung von Trusts gezielt einzuschränken. Bestehende Vertrauensstellungen müssen in regelmässigen Abständen überprüft und bei Bedarf entfernt werden.

Ein klar definiertes Tiering-Modell ist eine der wichtigsten Sicherheitsmassnahmen in Active Directory-Umgebungen. (Für mehr Informationen zum Tiering-Modell lesen hierzu unseren BLOG) Administrative Konten sollten strikt getrennt und nur innerhalb ihrer jeweiligen Sicherheitsstufe eingesetzt werden. Konten mit Berechtigungen auf Enterprise-Zertifizierungsstellen, sensiblen AD-Objekten oder in der Root-Domäne dürfen nicht im täglichen Betrieb, auf Endgeräten oder für Wartungsaufgaben in unteren Zonen verwendet werden.

Ebenso entscheidend ist eine durchgängige Überwachung. Änderungen an Zertifikatsvorlagen, das Veröffentlichen neuer Templates sowie PKINIT-basierte Authentifizierungen mit Zertifikaten sollten zentral erfasst und ausgewertet werden. Dazu können Windows-eigene Protokollierung, Event Forwarding oder spezialisierte SIEM-Integrationen verwendet werden. Besonders aufmerksam sollte man auf unerwartete Änderungen in CN=Certificate Templates, CN=Enrollment Services und anderen PKI-bezogenen Objekten in der Konfigurationspartition sein.

Wer die Möglichkeiten und Risiken von AD CS in Kombination mit Vertrauensstellungen verstanden hat, erkennt schnell, dass diese Komponenten gezielt abgesichert werden müssen. Mit klaren Verantwortlichkeiten, technischem Verständnis und einem wachsamen Blick auf die administrative Oberfläche lässt sich verhindern, dass Vertrauen zur Schwachstelle wird.