März 14, 2024
Leadership vs. Management, wo genau liegen da die Unterschiede? Und was braucht es in beiden Bereichen, um den aktuellen Herausforderungen
Kerberos ist das überwiegend genutzte Authentifizierung-Protokoll im Microsoft Active Directory und hat dort in der alltäglichen Verwendung den New Technology LAN Manager (NTLM) weitestgehend abgelöst. Kerberos hat dabei den großen Vorteil, dass es wesentlich sicherer ist als NTLM. Dennoch solltest du auch bei der Verwendung von Kerberos einige Dinge beachten, um eine sichere AD-Umgebung zu schaffen.
In diesem Artikel stellen wir daher einige wesentliche Kerberos Attacks vor. Voraussetzung für ein gutes Verständnis dieser Schwachstellen ist ein grundlegendes Verständnis des Protokolls, welches wir bereits in diesem Artikel behandelt haben. Das Wichtigste in Kürze: Kerberos verwendet für die Authentifizierung sog. Tickets, über die Domain-Nutzer Authentifizierungen gegen das Key Distribution Center (KDC) und den Authentication Service (AS) durchführen können. Den Kerberos-Dienst (KDC & AS) findet man in der Regel auf den Domain-Controllern einer Domain.
Da es sich bei Kerberos um ein Authentifizierungs-Protokoll handelt, ist es möglich, Brute-Force-Angriffe gegen dieses Protokoll durchzuführen. Ein Brute-Force-Angriff auf Kerberos hat einen entscheidenden Vorteil gegenüber Angriffen auf andere Authentifizierungsmethoden: Zur Durchführung des Angriffs ist kein Domänenkonto erforderlich, sondern lediglich eine Verbindung zum KDC.
Ein Angreifer kann beim Senden einer Authentifizierungsanforderung (AS-REQ) anhand der Antwort des KDC feststellen, ob ein Nutzer existiert oder nicht. Dadurch ist es Angreifern möglich, Benutzernamen effektiv durch die Verwendung von Wörterlisten zu bruteforcen. Es ist hierbei vorteilhaft für den Angreifer, dass Kerberos-Vorauthentifizierungsfehler in Active Directory nicht mit einem normalen Anmeldefehler-Ereignis (4625) protokolliert werden, sondern mit der spezifischen Event ID 4771 (Kerberos pre-authentication failed). Dieser Umstand verringert die Wahrscheinlichkeit, dass ein Angriff auffällt.
Anhand der Kerberos User Enumeration ist es außerdem möglich, Benutzerkonten ohne Vorauthentifizierung zu ermitteln. Dies kann für einen AS-REP Roasting Angriff nützlich sein, auf den wir im zweiten Abschnitt dieses Artikels eingehen.
Die Durchführung eines Brute-Force-Angriffs führt jedoch unter Umständen zu einer Sperrung von Benutzerkonten. Daher ist für die Angreifer bei dieser Kerberos Attack Vorsicht geboten.
Die Enumeration der Benutzernamen nutzen Angreifer über die folgenden Kerberos-Fehlercodes aus:
| User Status | Kerberos Error |
| Vorhanden/Aktiviert | KDC_ERR_PREAUTH_REQUIRED – Zusätzliche Vorauthentifizierung erforderlich |
| Gesperrt/Deaktiviert | KDC_ERR_CLIENT_REVOKED – Die Anmeldeinformationen des Clients wurden widerrufen |
| Existiert nicht | KDC_ERR_C_PRINCIPAL_UNKNOWN – Client nicht in Kerberos-Datenbank gefunden |
Die Kerberos User Enumeration kann schwer zu beheben sein, da sie von einer guten Kerberos-Überwachung abhängt. Diese Überwachung muss unrealistische Mengen von AS-REQ-Anfragen ohne Folgeanfragen erkennen können.
Um diese Events überhaupt im Event Log zu loggen, musst du zunächst die Standardeinstellung für das Monitoring von Account Logins angepassen. Hierzu passt du die Gruppenrichtlinien unter dem Pfad
Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\Account Logon
an: Setze die Richtlinien
jeweils auf den Wert „Erfolg und Fehler“, damit auch fehgeschlagene Anmeldungen geloggt werden. Danach kannst du das Event Log nach der EventID 4768 und dem darin enthaltenen String „0x6“ durchsuchen.
Warum genügt nicht die Suche nach EventID4768?
Das Event 4768 wird bei der Anfrage oder Erteilung eines TGT erstellt – also auch bei legitimen Anfragen. Daher ist eine Überwachung dieses Events alleine nicht ausreichend. Der String „0x6“ steht für den Fehlercode: „KDC_ERR_C_PRINCIPAL_UNKNOWN“. Nur, wenn du diesen Fehlercode findest und diese Events sich in einem kurzen Zeitraum auffällig häufen, kannst du von einer Kerberos Enumeration ausgehen.
Welche weiteren Angriffe kannst du durch diese Einstellungen im Event Log erkennen?
Kerberos Attacks, die den Kerberos-Dienst für Password-Spraying missbrauchen, kannst du ebenfalls über das Event Log erkennen. Auch in diesem Falle musst du das Event Logging über die oben beschriebenen Gruppenrichtlinien konfigurieren, damit die entsprechenden Events geloggt werden. Danach kannst du das Event Log auf das Auftreten der EventID 4771 („Fehler bei der Kerberos-Vorauthentifizierung“) überwachen. Auch hier solltest du reagieren, wenn eine ungewöhnlich große Zahl dieser Events in einem kurzen Zeitraum registriert wird.
Zur Überwachung des Event Logs solltest du auf weitere Tools und im Idealfall ein SIEM zurückgreifen, um das Active Directory dauerhaft zu überwachen und sofort auf Angriffe reagieren zu können.
Das Ziel von Kerberoasting ist es, TGS-Tickets für Dienste zu erlangen, die im Namen von Benutzerkonten im AD und nicht von Computerkonten laufen. Warum ist das nützlich? Ein Teil dieser TGS-Tickets ist mit von Benutzerpasswörtern abgeleiteten Schlüsseln verschlüsselt. Das führt dazu, dass Angreifer die betreffenden Anmeldedaten offline mithilfe von Brute-Force-Angriffen entschlüsseln könnten.
Für die Durchführung von Kerberoasting ist nur ein Domänenkonto erforderlich, das Service Principle Names (SPNs) anfordern kann – was jeder tun kann, da keine besonderen Rechte erforderlich sind.
Bei einem Kerberoasting-Angriff fordert ein Angreifer die TGS-Tickets (eins oder alle) an, die das verschlüsselte Kennwort eines Benutzers enthalten. Eine TGS-Anfrage kann durch Angabe eines beliebigen SPN gestellt werden.
Was sind SPNs?
SPNs werden von der Kerberos-Authentifizierung verwendet, um eine Dienstinstanz mit einem Benutzerkonto zu verknüpfen. Dies ermöglicht es einer Client-Anwendung, den Dienst zur Authentifizierung eines Kontos aufzufordern, auch wenn der Client den Kontonamen nicht kennt.
Wenn eine TGS-Anfrage unter Angabe eines SPN gestellt wird und dieser SPN in Active Directory registriert ist, stellt der Domänencontroller ein Ticket bereit. Dieses Ticket ist mit dem geheimen Schlüssel desjenigen Kontos verschlüsselt, das den Dienst ausführt. Mit diesen Informationen kann ein Angreifer nun versuchen, das Ticket offline mit Brute-Force-Angriffen zu knacken und so das Klartextpasswort des Benutzers zu erhalten.
Um sich vor dieser Art von Kerberos Attack zu schützen, müssen SPNs auf Benutzerkonten zugunsten von Maschinenkonten vermieden werden. Falls erforderlich, sollte die Funktion „Group Managed Service Accounts (gMSA)“ von Microsoft verwendet werden. Diese stellt sicher, dass das Kontokennwort robust ist und regelmäßig und automatisch geändert wird.
Es sind einige Voraussetzungen notwendig, um gMSA zu verwenden:
Sofern nicht bereits installiert, musst du das AD PowerShell Modul auf dem DC installieren. Hierzu verwendest du folgenden Befehl in der PowerShell:
Install-WindowsFeature -Name RSAT-AD-POWERSHELL
Die Anlage von gMSAs benötigt den Root Key. Ist dieser nicht vorhanden, bricht die Erstellung mit einer Fehlermeldung ab. Verwende den folgenden Befehl in Powershell, um zu prüfen, ob bereits ein Root Key erzeugt wurde:
Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId
Ist der Root Key nicht vorhanden, bekommst du einen Fehler angezeigt. Bei vorhandenem Root Key wird die Meldung True ausgegeben:
Wenn noch kein Root Key vorhanden ist, muss du diesen über den folgenden Befehl in PowerShell auf dem DC erzeugen.
⚠ ACHTUNG! Die Erzeugung bzw. Replikation des Keys kann bis zu 10 Stunden dauern.
Wenn also noch kein Key vorhanden war, kann ein gMSA erst nach ca. 10h erstellt werden.
Add-KdsRootKey -EffectiveImmediately
Zur Verwaltung und Zuteilung der Computerkonten von Servern, die den gMSA verwenden sollen, benötigst du eine neue Security Group. Diese kannst du über die PowerShell angelegen:
New-ADGroup -Name GRUPPENNAME -Description “DAS IST EINE BESCHREIBUNG DER GRUPPE, Z.B.: Security group for gMSA01 computers” -GroupCategory Security -GroupScope Global
Du solltest der Gruppe einen deskriptiven Namen geben und in der Beschreibung darauf hinweisen, dass es sich um eine Gruppe für die Verwendung eines spezifischen gMSAs handelt.
Add-ADGroupMember -Identity GRUPPENNAME -Members SERVERCOMPUTERACCOUNT1$, SERVERCOMPUTERACCOUNT2$
Hiermit fügst du der zuvor angelegten Gruppe (unter Verwendung des entsprechenden Gruppennamens) die Computer hinzu, auf denen der gMSA verwendet werden soll. Computeraccounts enden immer mit einem $-Zeichen.
Get-ADGroupMember -Identity GRUPPENNAME
Hiermit kann prüfst du, ob die Computeraccounts erfolgreich hinzugefügt wurden.
⚠ ACHTUNG! Damit in den weiteren Schritten der gMSA auf den betroffenen Servern installiert werden kann, müssen diese nach dem Hinzufügen in die Security Group neu gestartet werden!
Erstelle den gMSA mit folgendem Befehl in der PowerShell:
New-ADServiceAccount -Name NAME -PrincipalsAllowedToRetrieveManagedPassword GRUPPENNAME -Enabled:$true -DNSHostName NAME.DOMAIN -SamAccountName NAME -ManagedPasswordIntervalInDays 30
Der Wert NAME bestimmt den Namen des Accounts und sollte innerhalb des Befehles konsistent sein. Bei GRUPPENNAME gibst du den Namen der Security Group an, die du zuvor angelegt hast. Der Wert ManagedPasswordIntervalInDays gibt das Wechselintervall des Passworts an. Das AD wechselt das Passwort automatisch.
Um den gMSA auf einem Server zu installieren, muss auch hier das Active Directory PowerShell Modul installiert sein (siehe Schritt 1)
Install-WindowsFeature -Name RSAT-AD-POWERSHELL
Danach kannst du den Account installieren. Die Installation kann aber erst funktionieren, wenn du den Server nach der Zuteilung in die oben erstellte Security Group neu gestartet hast.
Install-ADServiceAccount -Identity NAME Test-ADServiceAccount -Identity NAME
Nach der Installation kannst du den gMSA als neuen Dienstaccount für den SQL-Server verwenden. Im hier gezeigten Beispiel ändern wir den Account über den SQL Server Konfigurations Manager. Hierzu wählst du unter SQL Server Dienste der Punt “SQL Server” (SQLSERVERNAME) aus und anschließend mit Rechtsklick den Punkt “Eigenschaften”.
Unter dem Reiter “Anmelden” wählst du dann “Dieses Konto” aus. Hier kannst du den gMSA eintragen oder über “Durchsuchen” finden. Wenn du nach dem Account suchen möchtest, musst du zuerst bei “Pfade…” die gesamte Domain auswählen und dann bei “Objekttypen” “Dienstkonten” auswählen. Wenn du den gewünschten Account ausgewählt hast, kannst du mit “OK” bestätigen. Ein Passwort wird nicht angegeben!
⚠ ACHTUNG! Der SQL-Server wird nach der Änderung neustarten.
Wenn du diese Schritte befolgt hast, ist der entsprechende SQL-Server nicht mehr mit einem User-Account SPN verknüpft. Der Account ist somit nicht mehr angreifbar, sofern er nicht zusätzlich mit anderen Instanzen verknüpft ist.
Sollte sich kein gMSA einsetzen lassen, kann ein normaler Domain-User verwendet werden. Dieser wird dann bei der Validierung als kerberoastable gemeldet werden! Die Anfrage des TGS wird also weiterhin möglich sein. Um zu verhindern, dass sich dieses Ausnutzen lässt, muss dieser Account mit einem sicheren Passwort versehen werden.
Das Passwort sollte regelmäßig (z.B. einmal im Jahr) geändert werden.
Der Account sollte auf nicht zu vielen Servern verwendet werden, um ein lateral Movement zu erschweren. Der Account sollte definitiv nicht auf Systemen eines unterschiedlichen Tier-Levels verwendet werden. Hier sollten unterschiedliche Accounts genutzt werden. Zudem sollten solche Dienstaccounts nur mit den zwingend notwendigen Rechten versehen werden.
Auf mögliche Versuche von Kerberoasting lässt sich zudem monitoren. Bei der Anfrage eines TGS wird ein Event mit der EventID 4769 ins Event Log geschrieben. Durch die Überwachung auf das Auftreten einer Vielzahl solcher Events in einem kurzen Zeitraum, die alle vom selben Nutzer erfragt werden, kannst du somit die oben beschriebene Anfrage über Impacket erkennen.
Leadership vs. Management, wo genau liegen da die Unterschiede? Und was braucht es in beiden Bereichen, um den aktuellen Herausforderungen
Sollten Standard-Nutzer in deinem Tenant eine Azure App Registration durchführen dürfen? Die Antwort ist ganz klar “Nein” und dieser Artikel
Die schlechte Nachricht vorweg: In Deutschland gibt es keine zentrale landesweite Notrufnummer für gehackte Unternehmen oder Behörden. Darum ist es
