Kerberos Attacks

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.

Kerberos Attack 1: Kerberos User Enumeration

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.

Attack

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

Solution

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

Überprüfen der Anmeldeinformationen überwachen
Kerberos-Authentifizierungdienst überwachen
Ticketvorgänge des Kerberos-Dienst überwachen

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.

Hast du die Aktivitäten in deinem Netzwerk im Blick?

Teste jetzt die Reaktion deiner IT auf Hacking Angriffe durch einen Penetrationstest!

Zum Penetrationstest

Kerberos Attack 2: AS-REP Roasting

AS-REP Roasting ist eine Kerberos Attack, bei der Angreifer verschlüsselte Teile einer AS_REP-Nachricht von Benutzerkonten stehlen, um dieses dann offline zu knacken. Voraussetzung hierfür ist, dass bei dem betreffenden Konto die Kerberos-Vorauthentifizierung deaktiviert ist. Wenn dies der Fall ist, kann jeder eine AS_REQ-Anfrage im Namen dieses Benutzer an das KDC senden und eine AS_REP-Nachricht erhalten. Diese AS_REP enthält Informationen, die mit dem NTLM-Hash des Users verschlüsselt werden. Dieser verschlüsselte Teil des AS_REP kann dann zum Cracken des Passworts ausgenutzt werden.

Standardmäßig ist die Vorauthentifizierung in Active Directory aktiviert. Sie kann jedoch für ein Benutzerkonto mit folgender Einstellung deaktiviert werden:

Attack

Wenn die Vorauthentifizierung aktiviert ist, beginnt ein Nutzer, der Zugang zu einer Ressource benötigt, den Kerberos-Authentifizierungsprozess wie folgt: Er sendet eine Authentifizierungsserver-Anforderungsnachricht (AS-REQ) an den Domänencontroller (DC). Der Timestamp in dieser Nachricht ist mit dem Hash des Benutzerkennworts verschlüsselt. Wenn der DC diesen Timestamp mit seinem eigenen Datensatz des Passwort-Hashes des Benutzers abgleichen kann, sendet er eine Authentication Server Response (AS-REP)-Nachricht zurück. Diese AS-REP-Nachricht enthält das TGT, das für zukünftige Zugriffsanfragen dieses Nutzers verwendet wird. Die AS-REP-Nachricht enthält darüber hinaus auch Informationen, die mit dem Passwort des Nutzers gehasht werden.

Wenn jedoch die Vorauthentifizierung deaktiviert ist, kann ein Angreifer Authentifizierungsdaten für einen beliebigen Benutzer anfordern und erhält als Antwort eine AS-REP-Nachricht vom DC. Diese Nachricht enthält die gehashten Informationen, die mit dem Kennwort des Benutzers verschlüsselt sind. Der Angreifer kann dann versuchen, das Kennwort des Benutzers offline zu knacken, indem er versucht, das krb5asrep mit entsprechenden Inputs zu cracken. Gelingt es, das AS_REP in sinnvollen Klartext zu dechiffrieren, entspricht der verwendete Schlüssel dem Passwort des Nutzers.

Vorteilhaft für Angreifer: Für diese Kerberos Attacke ist kein Domänenkonto erforderlich, sondern nur eine Verbindung zum KDC. Verfügen die Angreifer jedoch über einen Domänenbenutzer, können sie mittels LDAP-Abfrage Benutzer ohne Kerberos-Vorauthentifizierung in der Domäne finden. Andernfalls müssen die Benutzernamen erraten werden. Die Kombination mit Kerberos Attacks wie der Kerberos User Enumeration vereinfach dies jedoch deutlich.

Solution

Wie kannst du dein Netzwerk vor dieser Kerberos Attack schützen?

Stelle zunächst sicher, dass alle Konten in deiner Domäne die Kerberos-Vorauthentifizierung aktiviert haben. (Dies ist seit Kerberos v5 bereits die Standardeinstellung.) Um zu prüfen, welche Nutzer innerhalb einer Domäne diese Einstellung noch falsch gesetzt haben, kannst du die entsprechende LDAP-Anfrage durchführen.

Zusätzlich ist die Durchsetzung effektiver Passwortrichtlinien für Active Directory unerlässlich, um sicherzustellen, dass deine Umgebung nicht für AS-REP Roasting anfällig ist. Wird bei einem anfälligen Konto ein sicheres Passwort verwendet, ist ein „Knacken“ der Verschlüsselung durch das Erraten des Passworts faktisch unmöglich.  Eine sichere, umsetzbare und somit wirksame Passwort-Richtlinie trägt zudem dazu bei, dass die Benutzer auch an anderen Stellen sichere Kennwörter verwenden. Diese sind dann ebenfalls nicht leicht zu erraten oder anderweitig durch Brute Force oder andere gängige Passwort-Attacken angreifbar.

Kerberos Attack 3: Kerberosting

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.

Attack

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.

Solution

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:

Domain Functional Level 2012 oder höher
Windows Server 2012 R2 Os oder höher
Installation des Active Directory PowerShell Modul auf einem DC und den entsprechenden Servern, auf denen die gMSAs verwendet werden sollen
SQL Server 2014 oder höher (wenn die gMSAs für SQL-Server verwendet werden sollen)

Die folgende Anleitung führt dich durch alle notwendigen Schritte:

Schritt 1 - Installation Active Directory PowerShell Modul DC

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

Schritt 2 - Prüfung, ob Root Key für den Key Distribution Service vorhanden ist und ggf. Erstellung

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

Schritt 3 - Anlage neuer Security Group

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!

Schritt 4 - Erstellung des gMSA

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.

Schritt 5 - Installation gMSA auf Server

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

Schritt 6 - Verwendung von gMSA auf Server

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.

Alternative Lösung

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.

Steigere jetzt die Sicherheit Deines IT-Systems!

Von uns erhältst Du eine ausführliche Beratung!

Jetzt kontaktieren

Follow for more!

ANDERE BEITRÄGE

Hier sehen Sie einen Monitor, der einen Screenshot des Artikels der Wirtschaftswoche zeigt.

Tim Schughart @ WirtschaftsWoche: Seine Einschätzung zur CrowdStrike-Panne

Juli 23, 2024

/*! elementor-pro – v3.15.0 – 09-08-2023 */ .elementor-slides .swiper-slide-bg{background-size:cover;background-position:50%;background-repeat:no-repeat;min-width:100%;min-height:100%}.elementor-slides .swiper-slide-inner{background-repeat:no-repeat;background-position:50%;position:absolute;top:0;left:0;bottom:0;right:0;padding:50px;margin:auto}.elementor-slides .swiper-slide-inner,.elementor-slides .swiper-slide-inner:hover{color:#fff;display:flex}.elementor-slides .swiper-slide-inner .elementor-background-overlay{position:absolute;z-index:0;top:0;bottom:0;left:0;right:0}.elementor-slides .swiper-slide-inner .elementor-slide-content{position:relative;z-index:1;width:100%}.elementor-slides .swiper-slide-inner .elementor-slide-heading{font-size:35px;font-weight:700;line-height:1}.elementor-slides .swiper-slide-inner .elementor-slide-description{font-size:17px;line-height:1.4}.elementor-slides