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.
MVP: 2013 – 2016
Für das Erneuern des krbtgt-Passworts gibt es von Microsoft ein Powershell-Script.
Das 2 mal mit einem Abstand von 2 Tagen ausführen (damit auf allen Maschinen auch die gecachten Passworte tatsächlich weg sind) und zwar regelmäßig (alle 2-3 Jahre reicht).
Und was die AD-Sicherheit allgemein angeht:
Aktuelle AD-Sicherheitsbewertungstools meckern, wenn die auf solche Sachen stoßen.
Beispielsweise die kostenlosen Tools PingCastle, PurpleKnight, etc. etc.
Die sollte man mal durchlaufen lassen und alle gefundenen Probleme beseitigen.
als Abstand werden 7-10 Tage empfohlen, da die Tickets, bei Default Konfiguration, bis zu 7 Tage erneuert werden.
bei kürzerer Zeit, hat ein System ein gültiges Ticket und sieht ohne reboot keine Notwendigkeit ein neues Ticket anzufordern
Einige Quellen sprechen von einer Änderung alle 180 Tage und eine Zeitdifferenz von ersten zur zweiten Änderung von mind. 10 Stunden. Hier lese ich jetzt von 2 – 3 Jahren und 2 Tagen und dann wieder von 7 – 10 Tagen. Was ist denn jetzt das richtige!??
https://www.semperis.com/de/blog/golden-ticket-attacks-active-directory/#:~:text=Seien%20Sie%20vorsichtig%2C%20wenn%20Sie,alle%20180%20Tage%20zu%20%C3%A4ndern.
https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-reset-the-krbtgt-password
Es gibt sogar 3 Ticket-Lauftzeiten:
1. Ein normales Ticket hat standardmäßig eine Laufzeit von 10 Stunden.
2. Das Ticket kann verlängert werden.
Aber nur bis max. 7 Tage.
Und nicht zu vergessen:
3. Ein Ticket für Benutzer, die in der Gruppe Protected Users sind.
Das hat eine Laufzeit von nur 4 Stunden und kann nicht verlängert werden.
Die Standardlaufzeiten können per GPO geändert werden.
Die 2-3 Jahre betreffen nicht die Ticketlaufzeit, sondern der Zeitraum, in dem das krbtgt-passwort erneuert werden soll.
Da muss ich mich allerdings korrigieren:
Best practice ist, es alle 180 Tage zu erneuern.
Und man soll es 2 mal erneuern, weil immer 2 Passworte gespeichert werden: Das aktuelle und das vorhergehende.
Mit beiden ist eine Anmeldung möglich.
Durch die 2-malige Erneuerung ist kein altes Passwort mehr gespeichert. und eine Anmeldung damit daher nicht möglich.
Also du schaust in deiner Domain Policy was du da bei "Maximum lifetime for user ticket" stehen hast. Üblicherweise sind das 10h Default, das ist dann dein absoluter Minimum für die Rücksetzung + etwas Puffer einplanen, aber mindestens Domain Controller Replikationszeit. Es geht darum, dass die Tickets so lange gültig sind und so viel Zeit musst du den Clients Minimum einräumen, würdest du den krbtgt kurz hintereinander das PW ändern und das Ticket wäre eigentlich noch gültig, würdest du den Clients quasi den Boden unter den Füßen wegreißen.
Da der Wert aber individuell in jeder Domäne abweichen kann, ist das was in deiner Policy steht dein einziger professionieller Ansatzpunkt! (Wenn jemand mit pauschalen Zeitangaben daherkommt ist das schon falsch.)
Mit dem Ticketerneuerungszeitraum der standardmäßig 7 Tage sind, hat das eigentlich nix zu tun, die sagt nur aus in welchem Zeitraum das selbe Ticket erneuert werden darf, bis ein komplett Neues angefordert wird. Im Falle eines Breaches verliert man da wertvolle Zeit, würde man so lange warten.
Welches ist nun das richtige Intervall zum Erneuern des krbtgt? Es kommt auf den Anwendungsfall an. Bei einem Breach möglichst bald und Abstände so kurz wie möglich halten, aber deine "Maximum lifetime for user ticket" berücksichtigen (s. oben)
Die reguläre Änderung machst du je nach Bedürfnis deines Sicherheitsbewusstsein und was ihr operativ auch sauber managen könnt in der IT Abteilung, ob nun 180 Tage oder 360 Tage ist da egal….meine Empfehlung wäre aber mind. einmal jährlich ein kompletter Wechsel (also 2 Passwortänderungen in den nötigen Abständen)
es mir 2 Mal geändert werden, damit es "durch-roliert".
1te Änderung, das neue und das alte Ticket ist gültig. praktisch. keine Änderung, da das alte noch gültig ist, damit keine Dienste beeinflusst werden
2te Änderung, das ehemals neue ersetzt das alte und das ganz neue ist das aktive. jetzt sind nur noch 2 geänderte in Benutzung.
damit es keine Job, Authentifizierungsprobleme gibt, sollte man zwischen der ersten und der 2ten Änderung 7-10 Tage haben, aufgrund der möglichen 7 Tage Ticket Laufzeit.
ab jetzt kann das Kennwort alle x Tage erneuert werden. ich mache es als geplanter Task, idR jeden Monat.
Das ist aber falsch. Tickets sind nicht 7 Tage lang gültig sondern so lange gültig wie es in der policy definiert wurde, und das sind standardmäßig 10h. "Maximum lifetime for user ticket"
Was du beschreibst ist die mögliche renewal time des selben Tickets, relevant ist nur die ticket life time nicht die renewal life time zum Rücksetzen des krbtgt s. meine Erklärung oberhalb.
Ich kenne das auch so, dass man zwischen den 2 Wechseln mindestens 12 Stunden warten soll. Das war mal z.B. auf den AD-Hardening-Lehrgängen auf der Troopers die Empfehlung.
Das stimmt. Deswegen auch "bei Default Konfiguration".
Die 10 Tage hatte Sean (https://adsecurity.org) vor Jahren "aus Praxisgründen" empfohlen und sie mit der 7 Tage (Default Wert +3)Renew Zeit erklärt
Solange das System/eine Anwendung denkt, das Ticket ist noch gültig, wird es kein neues anfordern. Es gibt Tickets die längere Laufzeiten haben (dürfen).
https://www.rfc-editor.org/info/rfc4120/#section-2.3
ja, aber das genau ist immer noch falsch und irreführend, die Tickets sind per Default eben NICHT 7 Tage lang gültig!
Du verweist auf die mögliche Renewal time, die aber nicht relevant ist für die krbtgt PW rotation. Relevant ist nur "Maximum lifetime for user ticket" und die hat per Default einen Wert von 10h – ganz andere Zeitangabe.
Ich schätze Seans Arbeit sehr, weiß aber jetzt aktuell nicht ob er die Empfehlung gemacht hat, glaube ich dir einfach Mal, aber die wäre schlicht nicht korrekt und würde im Falle eines Breaches wertvolle Zeit kosten.
danke für die Aufklärung. ich habe die Zeit von 10 Tagen in seinen Artikeln nicht wiedergefunden.
ich war sicher, es bei ihm vor Jahren gelesen zu haben, das habe ich im Kopf als mögliche Fehlerquelle gespeichert und dann nie wieder in Frage gestellt.
@Mark:
da ich nicht mehr direkt unter deine Antwort antworten kann, schreibe ich dir so.
kein Thema, habe ja auch schon das ein oder andere von dir lernen können ;)
Als geplanter Task ist etwas risky. Das von Microsoft zur Verfügung gestellte Script zum Ändern des krbtgt pw macht einige Prüfungen, um sicherzustellen, dass kein Unglück passiert. Ist schließlich eine heikle Sache. Und man soll sich diese Ergebnisse ansehen und danach bewerten, ob die Umgebung gerade tatsächlich für den Wechsel bereit ist. Das krbtgt pw einfach mal so ohne Prüfung automatisch zu wechseln könnte auch mal schief gehen.
Wann ist bei dir zuletzt die Änderung eines Benutzerkennwortes fehlgeschlagen, im Sinne von:
– Keine Replikation
– Das Kennwort hat sich nicht geändert, der User konnte weiterhin das alte benutzen
… oder ähnliches?
Wenn wir davon ausgehen, das dein AD repliziert, dann ist da nichts "tricky". Wenn du allerdings davon ausgehst, das dein AD nicht repliziert und du deswegen erst 100 Tests machst, dann ist der krbtgt sicherlich nicht die erste Testperson, mit der du den Fehler finden möchtest.
AD repliziert. SYSVOL nicht immer … Ob per Script oder manuell "Kontextmenü auf User – Kennwort ändern", da gibt es keine Magie.
Wenn es für 60.000 User geht, dann auch für den krbtgt.
Und "alle 2-3 Jahre (das krbtgt pw zu erneuern) reicht" ist auch nicht genug. Wir machen das – laut einer Empfehlung eines anderen namhafteb Spezialisten wie M.H., den wir mal ein Audit machen gelassen haben – alle 6 Monate. Aber es gibt auch Empfehlungen, es alle 3 Monate zu machen.
PingCastle, PurpleKnight, die Tools sind beide gut, aber manche Ergebnisse sind auch umstritten oder werden größer aufgeblasen als sie sind oder in der Umgebung die man untersucht aus irgendwelchen Gründen nicht umsetzbar. Mit einer Handvoll Ergebnissen aus PingCastle bin ich da schonmal ziemlich auf die Nase gefallen, z.B. MS-SQL Datenbankaccounts mit Delegations. Und vorsichtig sein, PingCastle muss eigentlich für kommerzielle Umgebungen lizenziert werden, kostenlos ist das "eigentlich" nicht, hält sich nur kaum einer dran. Ich kann beide Tools derzeit nicht einsetzen, denn unser Antivirus kassiert sie ein, genau wie Blood- und Sharphound… :(
guter und hilfreicher Artikel
als Zusatzinformation: das Kennwort aus dem cpassword XML wird von dem Member nicht mehr übernommen.
wenn das betreffende Konto, aber seit 2014 keine Kennwort Änderung hatte, dann ist das cpassword Feld, praktisch Klartext.
https://www.gruppenrichtlinien.de/artikel/get-gpppasswordps1-kennworte-im-xml-in-plaintext-umwandeln
https://www.gruppenrichtlinien.de/artikel/passworte-in-gruppenrichtlinienobjekten-entfernen
Diese Aussage: "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."
Muss das tatsächlich auf jedem einzelnen DC gemacht werden? Das Sysvol wird doch über alle DCs repliziert! Reicht da nicht einmal \\domäne\SYSVOL\ zu durchsuchen, um das zu finden?
Es gibt im AD nichts kaputteres als die Filereplikation. ;-)
Es gibt in jedem AD nach Laufzeit "x" immer verwaiste Dateien/Ordner Strukturen im SYSVOL. Meist wird der Löschvorgang der GPO im AD (das GPC) vollständig abgeschlossen. Datenbank kann Microsoft. Das GPT, der Dateianteil der GPO bleibt gerne stehen und kann weg.
https://www.gruppenrichtlinien.de/artikel/sysvol-aufraeumen-verwaiste-gpt-objekte-finden
Den Sync kontrolliert jeder DC für sich, deswegen auch die Durchsicht, pro DC. Im DFS-Stamm wird dir nur die schöne Welt gezeigt.
Sehr interessant! Der Artikel ist wesentlich spannender, als mich die Überschrift vermuten lies. Meist ist es ja umgekehrt bei vielen Click Bait Artikeln in anderen Medien.