Drei Active-Directory-Fehlkonfigurationen, die Angreifern Ihre Domäne ausliefern

Werbung – Fehlkonfigurationen im Active-Directory können Angreifern eine Domäne ausliefern. Mihail Lupan, Head of Security Research, bei Holm Security zeigt drei solcher riskanten Fehlkonfigurationen.

Bei einem Active Directory-Sicherheitsvorfall denkt man zuerst an einen Exploit: beispielsweise einen Zero-Day, einen ungepatchten Server, ein raffiniertes Stück Schadsoftware. Die Realität kann im Active Directory aber wesentlich unspektakulärer und gefährlicher daherkommen. Die meisten Kompromittierungen einer Domäne beginnen nicht mit einem Exploit.

Sie beginnen mit einer AD-Einstellung, die vor Jahren jemand so belassen hat, die niemand mehr im Blick hat und die einem Angreifer ganz unauffällig genau das gibt, was er braucht. Nachfolgend werden drei dieser Einstellungen genannt, keine ist exotisch. Sie finden sich in einem großen Teil der Active Directory-Umgebungen, die wir von Holm Security prüfen. Und jede dieser AD-Einstellungen kann einen Angreifer von einem gewöhnlichen Domänenkonto bis zur vollständigen Kontrolle über die Domäne bringen.

Das ist am Ende des Tages kein Threat Hunting, sondern simple Konfigurationsarbeit! Ein Wort dazu, aus welcher Perspektive ich schreibe. Holm Security ist ein europäischer
Anbieter für Exposure- und Schwachstellenmanagement. Die Plattform wird vollständig in der EU gehostet und betrieben. Dieser Umstand wiegt heute schwerer als früher: Mit NIS2 und DORA wird Identitätshygiene von einer guten Praxis zu einer dokumentierten Pflicht, und europäische Kunden achten zunehmend darauf, wo ihre Sicherheitswerkzeuge entwickelt werden und wo ihre Daten liegen.

Drei Active-Directory-Fehlkonfigurationen

Wir haben kürzlich bei Holm Security die kontinuierliche Active-Directory-Bewertung in die Plattform aufgenommen, was den Anstoß zu diesem Beitrag gab. Die drei
nachfolgenden Punkte sind allerdings herstellerunabhängig und unabhängig davon relevant, was Sie einsetzen.

1. Das krbtgt-Passwort, das niemand jemals ändert

Jede Active-Directory-Domäne hat ein Dienstkonto namens krbtgt. Dessen Passwort-Hash verschlüsselt jedes Ticket Granting Ticket (TGT) in der Domäne. Extrahiert ein Angreifer, der bereits Domänenadministrator-Rechte erlangt hat, diesen Hash, kann er Tickets für beliebige Benutzer mit beliebigen Rechten fälschen. Dies sind gültig so lange der Angreifer dies möchte. Das ist der Golden-Ticket-Angriff, und die gefälschten Tickets funktionieren selbst dann weiter, wenn Sie jedes Administrator-Passwort in der Domäne zurücksetzen.

Für die Härtung entscheidend ist die Behebung. Das krbtgt-Passwort wird nicht automatisch geändert. In vielen Domänen hat es sich seit der Einrichtung der Domäne nicht geändert, mitunter seit über einem Jahrzehnt. Das Konto führt eine Historie der letzten beiden Passwörter, daher muss es zweimal zurückgesetzt werden, um alte Tickets vollständig ungültig zu machen, mit genügend Zeit zwischen den Zurücksetzungen, damit alle Domänencontroller replizieren können. Sowohl Microsoft als auch die CISA dokumentieren dies. Jemand muss schlicht daran denken, es korrekt und nach einem festen Zeitplan durchzuführen und zu prüfen, dass das Alter nicht abgedriftet ist. Das ist der Unterschied zwischen einer Maßnahme auf dem Papier und einer, die tatsächlich greift.

2. Das Passwort, dessen Entschlüsselungsschlüssel Microsoft veröffentlicht hat

Diese Sache überrascht noch immer viele Administratoren. Jahrelang verwendeten Administratoren die Gruppenrichtlinieneinstellungen (Group Policy Preferences), um Passwörter lokaler Konten, verbundene Laufwerke und geplante Aufgaben domänenweit auszurollen. Diese Einstellungen wurden in XML-Dateien im SYSVOL gespeichert, in einem Feld namens cpassword, verschlüsselt mit AES.

Das Problem: Microsoft hat den AES-Schlüssel, mit dem diese Passwörter verschlüsselt
wurden, in seiner eigenen öffentlichen Dokumentation veröffentlicht. SYSVOL ist für jeden authentifizierten Benutzer in der Domäne lesbar. Jedes gewöhnliche Konto kann also das SYSVOL durchsuchen, einen cpassword-Wert finden und ihn mit einem frei verfügbaren Schlüssel entschlüsseln, mithilfe von Werkzeugen, die seit Jahren in gängigen Penetrationstest-Kits enthalten sind. Microsoft selbst hat den Missbrauch der Gruppenrichtlinieneinstellungen als eine der häufigsten Methoden bezeichnet, mit denen Angreifer ihre Rechte innerhalb einer Domäne ausweiten.

Microsoft hat 2014 mit MS14-025 die Möglichkeit entfernt, neue GPP-Passwörter anzulegen. Doch hier ist der Punkt, der gerne übersehen wird: Der Patch verhinderte neue Einträge, entfernte aber nie die bereits im SYSVOL vorhandenen XML-Dateien. Sie bleiben dort, bis jemand sie löscht. Wir finden sie noch heute in Umgebungen, die vor einem Jahrzehnt gepatcht wurden, weil niemand zurückgegangen ist, um aufzuräumen, was der Patch hinterlassen hat. Von Hand bedeutet das, das SYSVOL auf jedem Domänencontroller nach alten XML-Dateien zu durchsuchen und jede einzelne zu prüfen, nach einem Zeitplan, den jemand einhalten muss.

3. Die Zertifikatvorlage, die im Stillen Domänenadministrator-Rechte bedeutet

Die dritte ist moderner und aus meiner Sicht die am meisten unterschätzte. Die Active Directory-Zertifikatdienste (ADCS) sind Microsofts Zertifizierungsstelle und laufen in einem großen Teil der Unternehmensumgebungen. Sie sind zugleich sehr häufig fehlkonfiguriert.

Der bekannteste Fall wird von Sicherheitsforschern als ESC1 bezeichnete. Er tritt auf, wenn eine Zertifikatvorlage es einem Benutzer mit geringen Rechten erlaubt, ein Zertifikat
anzufordern, eine beliebige Identität im Subject Alternative Name anzugeben und dieses
Zertifikat zur Authentifizierung zu verwenden. Konkret: Ist die Vorlage so konfiguriert, kann ein gewöhnlicher Domänenbenutzer ein Zertifikat anfordern, das den Domänenadministrator als Subjekt nennt, und anschließend versuchen, sich als Domänenadministrator anzumelden. Kein Exploit, keine Schadsoftware, nur eine Zertifikatanforderung gegen eine Vorlage, die seit Jahren in der Umgebung schlummert. ESC1 wurde in realen Angriffen eingesetzt, unter anderem von APT29.

Wer Windows administriert, kennt den Rest der Geschichte, denn sie war eines der größeren Patch-Management-Ärgernisse der letzten drei Jahre. Microsoft führte mit KB5014754 im Mai 2022 die starke Zertifikatzuordnung ein und bettet seither die Sicherheitskennung (SID) des Anforderers in ausgestellte Zertifikate ein, sodass ein Domänencontroller bestätigen kann, dass ein Zertifikat tatsächlich zu dem Konto gehört, das es vorgibt. Die schwache, namensbasierte Zuordnung wird seitdem schrittweise abgeschafft: Die vollständige Erzwingung wurde im Februar 2025 zum Standard, und seit September 2025 gibt es keine Möglichkeit mehr, sie zu umgehen. Auf einer vollständig gepatchten Domäne mit erzwungener Zuordnung funktioniert die naive Variante von ESC1 nicht mehr ohne Weiteres.

Warum steht das dann noch auf meiner Liste? Weil die Erzwingung einen
Authentifizierungsweg schließt, nicht aber das zugrunde liegende Problem. Die fehlkonfigurierte Vorlage ist weiterhin vorhanden. Die starke Zuordnung behebt keine überprivilegierte PKI, macht keine vor der Erzwingung ausgestellten Zertifikate rückgängig und ändert nichts an den übrigen Wegen derselben Familie (ESC2 bis ESC16, Tendenz steigend), von denen mehrere nicht auf dem SAN-Trick beruhen, den sie adressiert. Microsoft hat die Hürde deutlich höher gelegt, doch eine wuchernde, nie geprüfte Zertifizierungsstelle bleibt eine der ergiebigsten Angriffsflächen für Rechteausweitung in einer modernen Domäne. Die Vorlage ist die Exposure,
und den Status Ihrer Erzwingung sollten Sie überprüfen, nicht voraussetzen. Ältere Härtungs-Checklisten berühren all dies kaum, weil die Angriffsklasse jung ist und sich schnell weiterentwickelt.

Warum das für das Schwachstellen- und Exposure-Management wichtig ist

Keine dieser drei Fehlkonfigurationen besitzt eine CVE-Nummer. Es gibt keinen Patch, den man einspielen, keine Versionsnummer, der man hinterherjagen könnte. Es sind Konfigurations-Baselines, und genau deshalb halten sie sich: Ein Scanner, der nach fehlenden Patches sucht, läuft an allen dreien vorbei. Es sind keine Fehler in der Software, sondern Entscheidungen, vor Jahren getroffen und von niemandem je wieder hinterfragt. Rund neun von zehn großen Organisationen betreiben Active Directory, die Rechte, die es verwaltet, sind der Schlüssel zu allem, und was darin schiefgeht, ist selten das, was ein Patch-Zyklus erfasst.

AD Certificate Template Missing Security Extension

Deshalb haben wir Active Directory Security als kontinuierliche, geplante Bewertung in die
Plattform integriert und nicht als einmaliges Audit. Konfigurationen driften ständig, wenn
Administratoren Konten anlegen, Software ausrollen und Richtlinien ändern. Ein vierteljährliches Audit erfasst einen einzigen Moment. Die übrigen Tage bleiben ungemessen.

Härten Sie die Umgebung nach einem festen Zeitplan, dann schließen Sie diese Lücken, bevor jemand anderes sie für Sie testet. Das ist der ganze Gedanke dahinter. Wer sehen möchte, wie wir die kontinuierliche Active-Directory-Bewertung in die Plattform integriert haben, findet die Details in der Ankündigung zum Release. Unabhängig davon, welche Werkzeuge Sie einsetzen: Die drei oben genannten Lücken sind die, nach denen Sie zuerst suchen sollten.