Passwörter und Authentifizierung im Active Directory und Beispiele für Angriffsmethoden

Dieser Blog Post basiert auf einer Präsentation, die Linux Admins in der IT-Sicherheit das Thema Active Directory und Windows Sicherheits-Basics näher bringen sollte. Daher wird in diesem Artikel davon ausgegangen, dass der Lesende zumindest ein rudimentäres Verständnis von IT-Sicherheit und aktuellen Angriffsvektoren (zum Stand des Erscheinens dieses Artikels) besitzt.

Da sich dieser Eintrag an Personen richtet, die mit dem Thema Active Directory und Windows noch nicht tief vertraut sind, besteht bei weitem kein Anspruch auf Vollständigkeit. Einige Themen werden nur angeschnitten oder oberflächlich behandelt.

Dieser Artikel soll eine Übersicht über die Themen Active Directory, Windows Authentifizierung sowie einen Überblick über verschiedene Angriffsszenarien bieten.

• Was ist das Active Directory
• LDAP und Nutzerverwaltung
  • Speicherort
• Passwörter
  • LM Hash
  • NT Hash
  • Angriffe auf Passwörter
    • Angriff auf zwischengespeicherte Passwörter
    • Angriffe auf gehashte Passwörter
• Authentifizierungsmethoden
  • NTLM
  • Kerberos
    • Das KDC
    • Ablauf
  • Angriffsmethoden
    • Pass the Hash
    • Pass the Ticket

Was ist das Active Directory

Active Directory oder “AD” ist eine Microsoft Technologie, die im Hintergrund auf einem LDAP Verzeichnisdienst aufbaut. Das Active Directory stellt dabei eine Kernkomponente von On-Premise Microsoft Umgebungen dar.

Es regelt unter anderem die Nutzer- und Computerverwaltung und ermöglicht eine zentrale Authentifizierung. Die Authentifizierung selbst erfolgt über andere Technologien, welche im Hintergrund die Daten aus dem AD verwenden.

Weiterhin stellt das AD eine Möglichkeit einer zentralen Richtlinienverwaltung dar. Diese Funktion nennt sich Gruppenrichtlinien und ist ein zentraler Bestandteil auf dem Weg das AD abzusichern. Im Weiteren wird hierfür die Abkürzungen “GPO” verwendet.

Ein AD hat einen zentralen Server, den sogenannten “Domänen-Controller” oder “DC”. Dieser Server vereint in sich eine Reihe von Funktionen, die benötigt werden, um eine Windows Umgebung zu betreiben. Dieser Server hat vollständige Kontrolle über die gesamte Umgebung und ist daher besonders zu schützen.

LDAP und Nutzerverwaltung

Microsoft implementiert den OpenLDAP Standard mehr oder weniger vollständig. Abweichungen sind vorhanden, würden hier aber den Rahmen sprengen.

Innerhalb des ADs werden verschiedene Objekte verwaltet:

• Nutzer
• Gruppen
• Computer
• Server
• Kontakte
• …

Diese Objekte können selbst noch Unterobjekte besitzen und sind nicht immer trivial. Detaillierte Informationen über die verschiedenen Objekttypen lassen sich hier finden: https://docs.microsoft.com/en-us/windows/win32/adschema/active-directory-schema

Innerhalb des ADs finden sich auch die üblichen Nutzerdaten:

• Name
• Accountname
• Passwort + Passwort-Historie
• Ablaufdatum
• Gruppenzugehörigkeit

Speicherort

Während das AD die Daten über LDAP oder Microsoft APIs zur Verfügung stellt, liegen die Daten standardmäßig “physikalisch” in der folgenden Datei:

C:\Windows\NTDS\NTDS.DIT

Dieser Speicherort wird bei der Installation des DCs festgelegt.

Innerhalb dieser Datei liegen Passwörter (in der Regel) gehasht vor. Hierbei kommen zwei verschiedene Hash-Algorithmen zum Einsatz:

• LM Hash
• NT Hash

In dieser Datei liegt weiterhin auch der Kerberos-Key, der zur Ver- und Entschlüsselung von Kerberos-Anfragen verwendet wird.

Passwörter

Wie erwähnt werden Passwörter in Windows-Umgebungen in der Regel gehasht gespeichert. Im weiteren werden die Hash-Methoden sowie typische Angriffszenarien thematisiert.

LM Hash

Der LanMan Hash ist nach der älteren Windows Authentifizierungs-Komponente LanManager benannt. Das Hash-Verfahren ist ziemlich alt und gilt als unsicher.

Diese Hash-Variante ist seit Windows Server 2008 standardmäßig deaktiviert. Es ist jedoch möglich, diesen Hash via GPO zu reaktivieren und es kann in älteren Umgebungen durchaus vorkommen, dass dieser Hash noch aktiviert ist.

Das Hash-Verfahren funktioniert wie folgt:

1. Passwort wird in Uppercase umgewandelt
2. Wenn das Passwort kürzer als 14 Zeichen ist, werden NULL Bytes angehängt bis 14 Zeichen erreicht sind
3. Danach wird das Passwort in zwei 7 Zeichen lange Teile aufgeteilt
4. Diese Teile werden als DES Schlüssel verwendet, um damit den Text KGS!@#$% zu verschlüsseln
5. Die beiden verschlüsselten Texte werden zusammengefügt und ergeben damit den Hash

Dieses Verfahren hat einige Probleme.

• LM Hashs sind Case-Insensitiv - Password und pAsSwOrD ergeben denselben Hash
• Passwörter dürfen nicht länger als 14 Zeichen lang sein
• Die beiden 7 Zeichen langen Teile können einfach durch Rainbow Tables geknackt werden
• Wenn das Passwort kürzer als 8 Zeichen lang ist, kann der zweite Teil des Passworts ignoriert werden, da immer derselbe Hash generiert wird (0xAAD3B435B51404EE)
• Es können ausschließlich ASCII Zeichen verwendet werden

Weitere Informationen hierzu sind auf Wikipedia zu finden https://de.wikipedia.org/wiki/LM-Hash

NT Hash

Dieser Hash wurde 1993 mit der ersten Version von Windows NT eingeführt. Er bringt diverse Verbesserungen in der Sicherheit mit sich.

Dieses Verfahren verwendet einen MD4 Hash des UTF16-LE encodierten Passworts.

Im Gegensatz zu dem LM Hash ist dieser Hash daher Case-Sensitiv und kann den kompletten UTF16 Zeichensatz nutzen. Dadurch wird der Aufwand das Passwort zu knacken stark erhöht.

Angriffe auf Passwörter

Passwörter werden in Windows Systemen an verschiedenen Orten abgelegt.

Zum einen werden Sie - wie oben beschrieben - auf dem DC in der NTDS.DIT abspeichert, außerdem werden die Passwörter auf dem lokalen Client gecached und bei Nicht-Domänen Geräten auf dem Gerät selbst gespeichert.

Das Speichern dieser gehashten Passwörter erfolgt bei einer Nicht-Domänen-Anmeldung in der SAM Datei.
Die SAM (Security Accounts Manager) Datei/Datenbank enthält den Nutzernamen sowie das gehashte Passwort eines jeden lokalen Nutzers.

Weitere Informationen zu den oben genannten Punkten hier: Cached and Stored Credentials Technical Overview

Angriff auf zwischengespeicherte Passwörter

Auf einem Windows-Client werden in der Regel die letzten 10 Passwörter gehasht gecached. Passwörter, die nur in einer Session verwendet werden, werden durch den LSASS (Local Security Authority Subsystem Service) verwaltet.

Die Software mimikatz nutzt dies aus, indem sie das gehashte Passwort aus dem Arbeitsspeicher ausliest oder die Möglichkeit bietet, den lokalen (gehashten) Passwortspeicher auszulesen.

Angriffe auf gehashte Passwörter

Wie oben beschrieben werden Passwörter entweder als LM oder NT Hash gespeichert. Da diese Hashes keinen Salt enthalten, bieten sich Angriffe mit Rainbow Tables an.

Authentifizierungs­methoden

In Windows Active Directory Umgebungen werden vor allem zwei verschiedenen Authentifizierungsmechanismen verwendet, Kerberos und NTLM.

NTLM

Szenario Nutzer versucht sich an einem Server S anzumelden

0. Nutzername und Passwort werden auf dem Client abgefragt
1. Passwort wird auf dem Client gehasht
2. Nutzername wird im Klartext an den Server S übermittelt
3. Server erstellt eine 16 Byte Zufallszahl und sendet sie an den Client (Challenge)
4. Die Zufallszahl wird mit dem gehashten Passwort des Nutzers verschlüsselt und an den Server gesendet (Response)
5. Server sendet folgende Infos an den DC
   1. Nutzername
   2. Challenge
   3. Response
6. DC nutzt den Nutzernamen, um den Passwort-Hash abzurufen. Damit wird die Challenge verschlüsselt
7. DC vergleicht die Response mit der durch ihm in Schritt 6 verschlüsselten Challenge. Wenn beides übereinstimmt, war die Authentifizierung erfolgreich

Da in dieser Variante das Passwort nur in Schritt 1 verwendet wird, können alle weiteren Schritte ohne Wissen des Passworts ausgeführt werden, was ein Sicherheitsproblem darstellt. Mehr dazu später.

Weitere Details hier: https://docs.microsoft.com/en-us/windows-server/security/kerberos/ntlm-overview

Kerberos

Kerberos Authentifizierung basiert auf Tickets anstelle von gehashten Passwörtern.

Diese Erklärung ist an ein paar Stellen vereinfacht. Auch hier ist das Szenario eine Anmeldung von Nutzer N an Server S unter Verwendung von DC in der Rolle des KDC.

Streng genommen ermöglicht Kerberos die Authentifizierung an einem einzelnen Dienst auf dem Server S, was wir hier einfach mal ignorieren

Das KDC

Das KDC (Key Distribution Center) stellt einen vertrauenswürdigen dritten Partner in der Kommunikation zwischen N und S dar.
Die Rolle des KDC wird in Domänen Umgebungen durch einen der DCs übernommen.

Innerhalb des KDC werden zwei essentielle Dienste bereitgestellt:

1. Authentification Server (AS)
2. Ticket Granting Server (TGS)

Der Authentification Server führt die initiale Authentifizierung durch und verteilt Ticket-Granting-Tickets (TGT)

Der Ticket Granting Server nimmt dann diese TGTs und erstellt darauf basierend Service Tickets, mit denen eine Anmeldung an einem Dienst (z.B. Dateizugriff auf Server S) ermöglicht wird.

Ablauf

1. Der Nutzer N meldet sich am AS auf dem DC an.
   1. dazu sendet er folgende Informationen
      • eine Klartext-Nutzer-ID (DOMAIN\USERNAME)
      • die Art von Dienst, auf den Zugriff erfolgen soll (TGT)
      • Netzwerkinformationen (IP)
      • weitere Informationen (Gültigkeitsdauer, Verschlüsselungsoptionen etc.)
      • Teile dieser Anfrage sind mit dem Passwort des Nutzers verschlüsselt
   2. Der Server überprüft, ob der Nutzer existiert, ruft das Passwort* des Nutzers ab, entschlüsselt den Rest des Pakets und erstellt eine Antwort.
   3. Die Antwort der Servers enthält das TGT, welches mit einem Passwort* verschlüsselt wird, das dem AS und dem TGS bekannt ist.
2. N sendet das in 1. erhaltene TGT an den DC(TGS) und bittet um Zugriff auf S
3. DC(TGS) entschlüsselt das TGT und sendet ein Token an N, das mit einem Passwort verschlüsselt ist, welches S bekannt ist.
4. N sendet das Token an S
5. S entschlüsselt das Token und stellt damit sicher, dass der Client sich am DC angemeldet hat und das Passwort zur Entschlüsselung zwischen S und DC(TGS) ausgehandelt wurde.
6. Der Server erlaubt den Zugriff auf den im Token spezifizierten Dienst für die im Token angegebene Zeit

Mehr Details finden sich hier: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/58736756-53f7-4885-9968-70bc037ad5ff

Kerberos speichert nicht das wirklich das Passwort des Nutzers sondern in der Regel einen NTLM Hash des Passworts

Angriffsmethoden

Die hier angesprochenen Angriffsmethoden beziehen sich auf die Authentifizierung.

Teilweise wurden die hier erwähnten Aspekte weiter oben schon angesprochen.

Pass the Hash

Da bei einer NTLM-Anmeldung der Passwort-Hash sowie der Benutzername ausreichen um sich anzumelden, ist es einem Angreifer nach Erlangen dieses Hashes möglich, sich als Nutzer auszugeben, ohne das Passwort des Nutzers kennen zu müssen.

Es gibt mehrere Möglichkeiten an den Passwort-Hash einen Nutzers heranzukommen, zwei Möglichkeiten dies zu tun sind zum Beispiel:

1. LSASS Arbeitspeicher auslesen (siehe Angriff auf zwischengespeicherte Passwörter)
2. SAM Datei auslesen

Nachdem ein Hash erhalten wurde kann dieser verwendet werden, um sich mit den Rechten des Nutzers, dem der Hash gehört, an anderen Systemen anzumelden.

Pass the Ticket

Ein Angreifer erbeutet ein Kerberos-Ticket und kann dieses danach verwenden, um sich als Nutzer auszugeben.

Hierzu kann z.B. mimikatz verwendet werden:

PS> mimikatz.exe "privilege::debug" "sekurlsa::tickets /export"

Wenn der Angreifer hierbei ein TGT erhält, kann er dieses in die eigene Session einspeisen und sich damit mit den Rechten des Nutzers innerhalb des Netzwerkes authentifizieren, solange das Ticket gültig ist.

Sonderfälle: Golden-Ticket und Silber-Ticket

Bei einem Goldenem Ticket handelt es sich um einen Angriff auf den krbtgt Nutzer, der auf den DCs der Domäne für das Ausstellen der TGTs für alle Nutzer verantwortlich ist.

Hierbei wird sich eine Privilege-Escalation-Schwachstelle auf Domänen Ebene zu Nutze gemacht, um den Passwort Hash des krbtgt Nutzers zu erlangen. Danach können mit mimikatz oder Impacket Kerberos Tickets für beliebige (auch nicht existierende) Benutzer ausgestellt werden.

Bei einem Silbernem Ticket handelt es sich um einen Angriff auf einen Dienst- Benutzer. Hiermit ist es möglich, Zugriffe auf diesen Spezifischen Dienst für beliebige (auch nicht existierende) Benutzer zu ermöglichen.

Johannes Schöpp, GU-CERT, Johann Wolfgang Goethe-Universität Frankfurt am Main