Im vierten Teil unserer (E)SAE Deep Dive Serie geht es um das regelmäßige Ändern von nicht-personalisierten Konten. Zur Erinnerung: In unserem Juli-Blogpost haben wir bereits die erste unserer Top Ten-Maßnahmen vorgestellt. Heute folgt nun die zweite Maßnahme.

Laut dem Verizon Data Breach Investigations Report 2020 werden in rund 80 % der Hacker-Angriffe gestohlene oder durch Brute-Force-Angriffe  erbeutete Anmeldedaten verwendet. Demnach ist es erst einmal verwunderlich, dass das BSI, das NIST und Microsoft 2019 ihre Richtlinien zum Umgang mit Kennwörtern dahingehend geändert haben, dass sie ein regelmäßiges Ändern von Kennwörtern nicht mehr empfehlen. Doch was steckt dahinter?

Grund dafür ist die Erkenntnis, dass Benutzer von IT-Systemen bei häufig erzwungenen Kennwortwechseln aus Bequemlichkeit Kennwörter aufschreiben oder sehr ähnliche Kennwörter verwenden. Aufgrund dieses Verhaltens sei es deshalb besser, einmalig ein längeres, sichereres Kennwort, z.B. eine Passphrase, zu verwenden, das dann nur noch anlassbezogen (z.B. nach einem Sicherheitsvorfall) geändert wird. Das ist jedoch kein Phänomen, das auf nicht-personalisierte Konten zutrifft. Aus diesem Grund vertreten wir die Meinung, dass Kennwörter von nicht-personalisierten Konten weiterhin regelmäßig geändert werden sollten. Welche Typen von nicht-personalisierten Konten es gibt und welche Risiken sie bergen, erklären wir in diesem Artikel.

Was sind nicht-personalisierte Konten?

Ganz allgemein gesprochen sind das Konten, die nicht einer natürlichen Person zugeordnet sind. Dazu gehören zum Beispiel Service-Konten, das lokale Administratorkonto in Windows, das root-Konto in unixoiden Systemen wie Linux und MacOS oder vordefinierte Konten in Appliances und Datenbanken.

Im Kontext von Windows und Active Directory gibt es drei prominente Konten(-typen), die wir in unserer Infografik thematisieren:

1. 1. Service-Konten sind Konten, in deren Sicherheitskontext ein Windows Service ausgeführt wird. Neben einem vordefinierten Konto kann ein Service unter einem lokalen Benutzerkonto oder einem Active Directory-Benutzerkonto ausgeführt werden, die beide über Kennwörter verfügen. Fasst man die Definition etwas weiter, zählen hier auch noch Accounts hinzu, die zum Ausführen von Scheduled Tasks oder in Skripten zum Einsatz kommen.
   2. Fällt ein Domain Controller aus, kann dieser nur offline wiederhergestellt werden. Dazu wird der Domain Controller im Active Directory Service Restore Mode (DSRM) neugestartet. In diesem Modus sind die Active Directory Services nicht aktiv und die Konten in der Security Accounts Manager (SAM)-Datenbank werden verwendet.
   3. Das Konto krbtgt ist ein vordefiniertes lokales Konto, unter dem das Key Distribution Center (KDC) ausgeführt wird und das die Kerberos-Tickets verschlüsselt.

Angriffsszenarien und deren Auswirkungen

Nachfolgend möchten wir einige bekannte Szenarien vorstellen, die aufzeigen, welche Möglichkeiten ein Angreifer hat, in den Besitz von „Credential Material“ (Kennörter, -Hashes oder Kerberos Tickets) zu kommen und was er damit machen kann.

Service-Konten

Um den Zweck des Windows Service, des Scheduled Task oder des Skriptes zu erfüllen, benötigt ein Service-Konto oftmals mehr als reine Benutzerrechte. Die Rechte können je nach Zweck und (Miss-)Konfiguration von Schreibberechtigungen auf lokalen Verzeichnissen bis hin zu Domain Admin-Rechten reichen. Deswegen kann der Schaden einer Ausnutzung eines Service-Kontos nicht pauschal bewertet werden. Die Erfahrung aus Kundenprojekten zeigt allerdings, dass Service-Konten oftmals hohe Rechte (oftmals mehr als nötig) haben und ein lohnendes Ziel für Angreifer sind.

Doch wie gelangt ein Angreifer an das Kennwort?

Nicht-technische Möglichkeiten
Mit Kennwörtern wird leider allzu häufig nicht sachgemäß umgegangen. Sie werden in unverschlüsselten E-Mails verschickt, in Excel- oder SharePoint Listen gespeichert. Wir haben auch schon Domain Admin-Kennwörter auf Whiteboards gesehen😳 .

IT-Mitarbeiter kündigen oder werden gekündigt und die Trennung erfolgt nicht immer im Guten. Werden die Kennwörter nicht nach jedem Mitarbeiterwechsel geändert, kann der ehemalige Mitarbeiter diese Kennwörter bei einem Angriff nutzen.

Eher aus dem Bereich der Appliances bekannt, jedoch je nach Prozess auch für Service-Konten ein Problem: Standardpasswörter. Wird z.B. ein Standardkennwort beim Erstellen der Accounts genutzt und dieses nicht geändert, kann sich das ein Angreifer mit Kenntnis über die Vorgehensweise (Prozesse werden ja schließlich dokumentiert 😊 ) zu Nutze machen.

Technische Angriffsszenarien
Ein einfaches Angriffsszenario ist das wiederholte und zufällige Ausprobieren von Kennwörtern über eine Remote-Anmeldung. Da das Active Directory nach zu vielen erfolglosen Anmeldeversuchen in einem gewissen Zeitraum den Account sperrt, dauert ein realer Angriff auch bei einem relativ kurzen Kennwort schon recht lange.

Wesentlich schneller führt eine Kerberoasting-Attacke zum Ziel. Der genaue technische Hintergrund würde hier jedoch zu weit führen. Wichtig in unserem Kontext ist, dass sobald ein Dienst einen Service Principal Name für ein Benutzerkonto (nicht für das Computer-Konto) registriert hat, jeder Benutzer im AD ein Service Ticket (TGS) anfordern kann, welches mit dem Kennwort-Hash des Service Accounts verschlüsselt ist. Der Angreifer kann das Ticket aus dem Hauptspeicher herunterladen (z.B. bequem mit Rubeus) und auf seinem System mit einem Kennwort-Cracker wie Hashcat in aller Ruhe errechnen. Versteht uns nicht falsch, mit Ruhe meinen wir bei heutiger Rechenleistung Stunden und nicht Tage oder Wochen, wie noch vor einigen Jahren (bei einem komplexen 8-Zeichen-Kennwort).

Eine weitere Möglichkeit ist, mittels des mimikatz-Moduls sekurlsa und dem Kommando logonpasswords Hashes und ggf. Klartextkennwörter auszulesen. Dazu muss es dem Angreifer gelingen, lokale Administratorrechte auf einem System zu erlangen, auf dem der Service Account angemeldet ist. Die Kennwörter werden ab Windows 8.1/Windows Server 2012 R2 standardmäßig nicht mehr im Klartext im Hauptspeicher abgelegt. Allerdings reicht dem Angreifer auch der NTLM-Hash, um lokal oder remote Kommandos mit den Rechten des Service Account durchzuführen. Je nach verwendetem Authentifizierungsprotokoll ist das entweder eine Pass the Hash (PtH)– oder Pass the Ticket (PtT)Attacke. Wird ein Ticket von einem Service-Konto genutzt, spricht man auch von einem Silver Ticket .

Der Hash kann prinzipiell auch offline aus der NTDS.dit-Datenbank oder mittels DCSync extrahiert werden. Mehr dazu in den folgenden Abschnitten.

DSRM

Um an das Kennwort des DSRM-Kontos zu gelangen, gibt es analog zum Weg über die Service-Konten sowohl Social Engineering als auch die Extraktion mit mimikatz. Dazu muss der Angreifer allerdings schon Domain Administrator-Berechtigungen haben.

Nun stellt man sich natürlich die Frage, warum ein Angreifer sich mit dem DSRM Account beschäftigen sollte, wenn er doch schon Domain Administrator ist? Wenn der Angreifer im Besitz des Kennworts des DSRM-Kontos ist, kann er in den DSRM-Modus booten, mit dem PowerShell-Modul DSInternals die Active Directory-Datenbank NTDS.dit offline mounten und dort Konten anlegen, ohne dass diese Aktivitäten protokolliert werden. Das Ziel bei der Benutzung des DSRM-Kontos ist somit keine Rechteerhöhung, sondern einen Weg zu finden, sich unauffällig im Active Directory zu persistieren und dies unentdeckt über einen längeren Zeitraum benutzen zu können.

KRBTGT

Das Konto krbtgt ist, wie oben beschrieben, das Service-Konto des Key Distribution Center (KDC)-Dienstes und wird verwendet, um Kerberos-Tickets zu verschlüsseln.

Folgende Möglichkeiten sind uns bekannt, um an den Hash des krbtgt-Kontos zu gelangen:

• Auch hier kann ein Angreifer das Kennwort mittels mimikatz vom DC extrahieren.
• Eine alternative Möglichkeit, um an den Kennworthash des krbtgt-Kontos (oder jedes anderen Kontos) zu gelangen, ohne dass eine lokale Anmeldung an einem Domain Controller notwendig ist, ist die Verwendung des mimikatz-Moduls lsadump mit dem Kommando DCSync. Mit diesem Kommando kann man den Kennworthash des krbtgt-Kontos über eine Replikation mit einem Domain Controller über das Netzwerk anfordern.
• Letzte uns bekannte Möglichkeit ist, die Active Directory-Datenbank NTDS.Dit mit dem PowerShell-Modul DSInternals offline auszulesen. Für den Zugriff – entweder um sie direkt auszulesen oder zu kopieren – darf sich die Datenbank nicht im Schreibzugriff eines anderen Prozesses befinden. Daher müssen der Dienst NTDS und seine abhängigen Services für den Zugriff mit DSInternals beendet werden. Darüber hinaus wird der sogenannte Boot Key benötigt, der im Registry-Hive SYSTEM gespeichert ist. Dieser unterscheidet sich auf jedem Domain Controller und wird dafür verwendet, um den Password Encryption Key zu entschlüsseln, mit dem die Daten in der Datenbank verschlüsselt sind.

Hat der Angreifer den Hash im Besitz, kann er ihn anschließend verwenden, um ein Golden Ticket zu erzeugen. Ein Golden Ticket wird wie ein Silver Ticket in einer Pass the Ticket-Attacke verwendet. Im Unterschied zu einem Silver Ticket, bei dem man „nur“ die Rechte des Service Accounts erlangt, hat der Angreifer durch das Golden Ticket die Möglichkeit, jeden beliebigen Benutzer zu impersonifizieren (dieser muss nicht einmal im Active Directory existieren) und beliebige Gruppenmitgliedschaften zu seinem Ticket hinzuzufügen. Als ob das nicht schon schlimm genug wäre, kann ein Angreifer sich aber auch beliebige SIDs in die SID-History schreiben und somit aus einer beliebigen Subdomain den ganzen Forest kompromittieren! Als zusätzliches i-Tüpfelchen kann der Angreifer auch noch frei konfigurieren, wie lange das Ticket gültig ist 😊 .

Wie kann man sich schützen?

Generell gilt es sowohl ein langes komplexes Kennwort zu verwenden, um das Cracken von Kennwörtern und Hashen zu erschweren, als auch das Kennwort regelmäßig zu ändern, um die Dauer des Angriffs für den Angreifer zu erhöhen. Windows unterstützt Kennwörter mit einer Länge von bis zu 127 Unicode-Zeichen sowohl für lokale Konten als auch für Active Directory-Konten.

Im Folgenden wollen wir darauf eingehen, was bei den in der obigen Infografik dargestellten Szenarien beim Kennwortwechsel zu beachten ist und wie man sich bei Service-Konten den manuellen Kennwortwechsel sogar ganz sparen kann. 

Service-Konten

Das Ändern der Kennwörter von Service-Konten ist in einem typischen Unternehmensumfeld nicht trivial. Je nach Größe des Unternehmens und der Anzahl der eingesetzten Applikationen kann es zu einer Herausforderung werden, den Überblick über die Service-Konten zu behalten. Eine Änderung eines Service-Konto-Kennworts muss neben dem Windows Service oftmals auch in der Konfiguration der Applikation an einer oder mehreren Stellen aktualisiert werden. Der Speicherort und die Art und Weise der Aktualisierung unterscheidet sich von Applikation zu Applikation. Unter Umständen muss der Service neu gestartet werden, was zu einer Unterbrechung des Applikationsbetriebs führt.

Daher ist die einfachste Lösung, das Kennwort schon gar nicht manuell ändern zu müssen. Dafür gibt es mehrere Lösungsoptionen:

• Die Verwendung eines vordefinierten Kontos wie LocalSystem, LocalService oder NetworkService. Diese Konten haben alle kein Kennwort und sind daher einfach zu verwalten, bieten jedoch keine granulare Berechtigungsverwaltung und erlauben es nicht, Berechtigungen eines Services zu isolieren.
• Virtual Accounts sind lokale Konten, die auf Netzwerk-Ressourcen zugreifen können und deren Kennwort von Windows regelmäßig geändert wird. Der Name eines Virtual Accounts ist NT Service\<Service-Name>, z.B. ist der Virtual Account-Name für die Default-Instanz einer SQL Server Database Engine NT SERVICE\MSSQLSERVER.
• Ein Managed Service Account (MSA) ist ein Domänen-Konto, dessen Kennwort von einem Domain Controller verwaltet wird. Ein MSA kann einen Service Principal Name (SPN) registrieren und endet mit einem $-Zeichen (DOMAIN\ACCOUNTNAME$).
• Ein Group Managed Service Account ist im Gegensatz zu einem MSA nicht auf einen Server begrenzt, sondern kann auf mehreren Servern verwendet werden und kann daher für fehlertolerante Technologien wie Windows Clustering oder Network Load Balancing (NLB) verwendet werden.

Virtual Accounts oder Managed Service Accounts müssen jedoch auch von der Applikation unterstützt werden, was leider in vielen Fällen nicht der Fall ist.

Die Kennwörter herkömmlicher Service-Konten – entweder lokaler Windows-Konten oder von Active Directory-Benutzerkonten – müssen also weiterhin oftmals manuell geändert werden. Aufgrund der hohen Anzahl ist das keine triviale Aufgabe. Daher gibt es eine Vielzahl verschiedener Tools, die den Prozess unterschiedlich stark unterstützen. Neben Passwort-Managern wie KeePass, die nur bei der Generierung und sicheren Speicherung der Kennwörter unterstützen, gibt es auch vollumfängliche Privilege Access Management-Lösungen, die weit mehr Funktionen bieten als „nur“ Kennwörter von Service Accounts zu wechseln und zu verwalten. Marktführer sind CyberArk und BeyondTrust . Eine preisgünstige Alternative zu den Marktführern ist passwordstate.

DSRM-Konto

Das Kennwort kann über das Tool ntdsutil.exe geändert werden. Es ist wie beschrieben ein lokales Konto und muss daher auf jedem Domain Controller geändert werden.

Seit Windows Server 2008 kann das Kennwort des DSRM Accounts mit dem eines Domänen-Benutzerkontos abgeglichen werden. Dies wird auch über das Tool ntdsutil.exe durchgeführt. Achtung: Hierbei handelt es sich nicht um eine richtige Synchronisierung. Wird das Kennwort des Domänen-Benutzers geändert, wird nicht automatisch das Kennwort des DSRM Accounts geändert. Unsere Empfehlung ist für jeden Domain Controller ein separates und langes Kennwort einzurichten.

krbtgt-Konto

Das Kennwort des krbtgt Accounts kann ganz gewöhnlich mit Active Directory Users and Computers geändert werden. Das verwendete Kennwort ist dabei irrelevant, es wird automatisch ein langes, komplexes Kennwort generiert. Da die Kennwort-Historie des krbtgt-Kontos die zwei letzten Kennwörter speichert, muss das Kennwort zweimal geändert werden, um sicherzustellen, dass ein Angreifer, der den aktuellen Hash erbeutet hat, diesen nicht mehr verwenden kann.

Dabei ist allerdings Vorsicht geboten. Wird das Kennwort zweimal schnell hintereinander geändert, verlieren alle Tickets Ihre Gültigkeit. Alle Konten müssen sich erneut authentifizieren. Ggf. müssen Applikations-Dienste dazu neu gestartet werden. Um die einhergehende Unterbrechung zu vermeiden, sollte zwischen zwei Kennwortwechseln mindestens die Dauer der Kerberos Ticket Lifetime (Standard 10 Stunden) liegen.

Auch sollte sichergestellt werden, dass das neue Kennwort korrekt zu allen Domain Controllern repliziert werden kann. Klingt erstmal trivial, aber in großen globalen Active Directory-Implementierungen kann es schon einmal vorkommen, dass ein Domain Controller für eine gewisse Zeit nicht zu erreichen ist.

Um den Kennwortwechsel zu erleichtern, hat Microsoft das Skript New-KrbtgtKeys.ps1 zur Verfügung gestellt. Es hat mehrere Modi, um die Replikation im Vorfeld gefahrlos zu testen, bevor es dann das Kennwort wechselt und die tatsächliche Replikation überwacht.

Zusammenfassung

Ein Bild sagt mehr als tausend Worte. Das Sprichwort hat sich bei diesem Artikel mal wieder bewahrheitet. Was als kurzer Ergänzungs-Post zur Infografik startete, hat sich zu einem fast 2.500 Worte langen Artikel entwickelt. Wir hoffen, dass sich die Arbeit gelohnt hat und Ihr durch unsere Erklärungen, die Hintergrundinformationen und die verlinkten Artikel, die auf jedes Thema nochmal dediziert im Detail eingehen, versteht, warum es wichtig ist, sich um die Sicherheit von nicht-personalisierten Konten zu bemühen. Wie immer freuen wir uns auf eure Kommentare und treten gerne mit euch in einen Dialog 😊 .