Pass-the-Hash in AD: Erkennung und Gegenmaßnahmen

Was ist Pass-the-Hash?

Pass-the-Hash ist eine Authentifizierungsmethode, bei der gestohlenes, aus NTLM abgeleitetes Authentifizierungsmaterial anstelle des Klartext-Passworts eines Benutzers verwendet wird. In der Praxis stiehlt der Angreifer wiederverwendbares Material von einem kompromittierten Windows-System und nutzt es anschließend, um als dieser Benutzer auf einen weiteren Host oder Dienst zuzugreifen.

Der Geltungsbereich dieses Artikels ist bewusst eng gefasst: Windows, Active Directory, NTLM und laterale Bewegung. Es geht hier nicht allgemein um Credential Theft. Im Mittelpunkt steht das konkrete Betriebsmodell, das Pass-the-Hash in AD-Umgebungen relevant macht: ein kompromittierter Client oder Server, wiederverwendbares Authentifizierungsmaterial auf diesem System und ein zweiter Host, der weiterhin NTLM-basierte Authentifizierung akzeptiert.

Diese Abgrenzung ist wichtig, weil Pass-the-Hash häufig mit benachbarten Techniken vermischt wird:

Password Spraying testet häufige Passwörter gegen viele Konten und benötigt keine gestohlenen Hashes.
Pass-the-Ticket nutzt gestohlene Kerberos-Tickets, nicht NTLM-abgeleitetes Material.
Overpass-the-Hash verwendet NTLM-abgeleitetes Material, um Kerberos-Authentifizierungsmaterial zu erhalten, und pivotiert dann in Kerberos-basierten Zugriff.
Kerberoasting fordert Service Tickets an und knackt sie offline, um Kennwörter von Dienstkonten wiederherzustellen.

Pass-the-Hash ist also ein eigenes Problem: Der Angreifer besitzt bereits wiederverwendbares Authentifizierungsmaterial und braucht das Klartext-Passwort nicht, um sich weiterzubewegen.

Wie Pass-the-Hash funktioniert

MITRE führt Pass-the-Hash als T1550.002, eine Untertechnik von Use Alternate Authentication Material. Die Grundidee ist einfach: Nach einer Benutzeranmeldung erzeugen und halten Windows und angrenzende Authentifizierungsabläufe Material vor, das unter bestimmten Umständen wiederverwendet werden kann, wenn ein Angreifer es stiehlt.

In Windows-Umgebungen bleibt NTLM der Hauptgrund dafür, dass Pass-the-Hash weiterhin praktisch relevant ist. Wenn ein Zielsystem NTLM akzeptiert, kann ein Angreifer mitunter gestohlenes NTLM-abgeleitetes Material präsentieren und sich authentifizieren, ohne jemals das Klartext-Passwort zu kennen. Genau deshalb sind die Reduzierung von NTLM und die Begrenzung der Orte, an denen wiederverwendbare Credentials landen, zentrale Abwehrmaßnahmen.

Wiederverwendbares Material stammt in der Praxis meist aus einem dieser Pfade:

LSASS-Speicher auf einem kompromittierten Endpoint oder Server, nachdem sich das Opfer angemeldet hat
SAM- / SECURITY-Hives für Material lokaler Konten auf dem Host
Gemeinsam verwendete lokale Administratorkonten, die auf mehreren Systemen dieselben Zugangsdaten verwenden
Credential Dumping, nachdem der Angreifer bereits lokale Adminrechte oder gleichwertige Ausführung auf einem Host erreicht hat

Die Microsoft-Dokumentation zu Credential Guard ist hier besonders hilfreich, weil sie präzise beschreibt, was die Funktion tatsächlich schützt: NTLM-, Kerberos- und Credential-Manager-Geheimnisse werden per Virtualization-Based Security isoliert, statt nur im normalen LSASS-Prozessraum zu liegen. Das beseitigt nicht jedes Credential-Theft-Risiko, verändert aber die Angriffsfläche klassischer PtH-Ketten deutlich.

Voraussetzungen für eine erfolgreiche Pass-the-Hash-Attacke

Pass-the-Hash funktioniert meist nur dann, wenn mehrere Bedingungen gleichzeitig erfüllt sind.

1. Der Angreifer hat bereits einen Windows-Host kompromittiert

Pass-the-Hash ist selten der erste Schritt. Der Angreifer beginnt typischerweise mit Phishing, Malware, ausnutzbarem Remotezugriff, schwacher lokaler Admin-Hygiene oder einem anderen Initialzugang. PtH dient anschließend als Technik für laterale Bewegung.

2. Wiederverwendbares Authentifizierungsmaterial ist auf dem kompromittierten System vorhanden

Das ist die Kernvoraussetzung. Wenn privilegierte Benutzer sich an Systemen mit geringerem Vertrauensniveau anmelden, Administratoren RDP ohne stärkere Schutzmaßnahmen nutzen oder Server wiederverwendbare Admin-Secrets in LSASS ansammeln, hat der Angreifer etwas, das er stehlen kann.

3. Das nächste Ziel akzeptiert weiterhin NTLM-Authentifizierung

Die Technik wird deutlich schwieriger, wenn die Umgebung ihre NTLM-Abhängigkeit reduziert, Remote-Admin-Workflows gehärtet oder kritische Pfade weg von wiederverwendbarer NTLM-gestützter Authentifizierung verlagert hat.

4. Das kompromittierte Konto besitzt an anderer Stelle noch sinnvolle Rechte

Ein gestohlener Hash eines Kontos mit wenig Wert bringt wenig. Wirklich nützlich ist das Material eines lokal wiederverwendeten Administrators, eines Helpdesk-Kontos mit breiter Reichweite oder eines privilegierten AD-Kontos, das sich auf Mitgliedsservern anmeldet.

5. Die Administrationshygiene ist schwach genug, um Host-Ketten zu ermöglichen

Darum hängt Pass-the-Hash eng mit lateraler Bewegung zusammen und nicht nur mit Credential Theft. Wenn lokale Admin-Passwörter einzigartig sind, Administratoren dedizierte Arbeitsstationen verwenden und privilegierte Credentials nicht auf niedrig vertrauenswürdigen Systemen landen, verliert der Angreifer genau den Pfad, der PtH wertvoll macht.

Die Angriffskette

Eine typische Pass-the-Hash-Sequenz in einer AD-Umgebung sieht wie folgt aus.

Schritt 1 - Codeausführung auf einem ersten Host erlangen

Der Angreifer kompromittiert einen Client oder Server über Phishing, Malware, verwundbare Software oder einen bereits vorhandenen Zugangspfad.

Schritt 2 - Wiederverwendbares Material dumpen

Sobald er die nötigen Rechte auf diesem Host besitzt, zielt der Angreifer auf LSASS oder lokale Credential Stores und extrahiert wiederverwendbares Material. MITRE ordnet Werkzeuge wie Mimikatz explizit der Pass-the-Hash-Nutzung zu, einschließlich des Moduls SEKURLSA::Pth.

Schritt 3 - Das beste wiederverwendbare Konto auswählen

Der Angreifer braucht nicht jedes Konto. Er braucht das Konto, das den nächsten Host öffnet. In realen Umgebungen sind das häufig:

ein lokal wiederverwendetes Administratorkonto
eine Helpdesk- oder Endpoint-Admin-Identität
ein Server-Admin-Konto, das viele Hosts berührt hat
ein privilegiertes AD-Konto, das nie auf diesem Endpoint hätte landen dürfen

Schritt 4 - Über einen NTLM-gestützten Pfad zum nächsten Host authentifizieren

Danach bewegt sich der Angreifer über administrative Protokolle, Remote Service Creation, SMB-Adminzugriff, WMI, geplante Tasks oder andere Windows-Managementpfade weiter, die das wiederverwendete Material noch akzeptieren.

Schritt 5 - Wiederholen, bis eine höher privilegierte Ebene erreicht ist

Die Gefahr von Pass-the-Hash ist nicht ein einzelner Hop. Die Gefahr ist die Kette. Ein kompromittierter Client führt zu einem weiteren Admin-Kontext, dann zu einem Management-Server, anschließend zu einem System mit höherwertigen Credentials und letztlich möglicherweise zu Domain- oder Forest-Kontrolle. Das folgt derselben operativen Logik wie in AD-Angriffspfaden: Jede schwache Credential-Grenze macht den nächsten Schritt leichter.

Pass-the-Hash vs. Overpass-the-Hash vs. Pass-the-Ticket

Diese Techniken sind verwandt, aber nicht austauschbar.

Pass-the-Hash bleibt auf NTLM-abgeleitetes Authentifizierungsmaterial und Zugriffspfade fokussiert, die weiterhin NTLM akzeptieren.

Overpass-the-Hash beginnt mit NTLM-abgeleitetem Material, nutzt es jedoch, um Kerberos-Authentifizierungsmaterial zu erhalten, und verschiebt sich dann in Kerberos-basierten Zugriff.

Pass-the-Ticket verwendet kein NTLM-abgeleitetes Material, sondern nutzt direkt gestohlene Kerberos-Tickets wieder.

Diese Unterscheidung ist für Detection und Remediation gleichermaßen wichtig. Wenn Verteidiger alles unter einem Oberbegriff zusammenfassen, bauen sie meist eine schwache Erkennungsstrategie und setzen die falschen Gegenmaßnahmen am falschen Pfad an.

Detection

Es gibt kein einzelnes Windows-Ereignis, das sagt: „Das war Pass-the-Hash.“ Eine brauchbare Erkennungsstrategie ist eine Korrelationsstrategie.

MITREs Windows-Detection-Strategie für T1550.002 ist hier sinnvoll: Anomale NTLM-LogonType-3-Aktivität sollte mit Prozess-, Sitzungs- und Netzwerkkontext korreliert werden, statt sich auf einen einzelnen Indikator zu verlassen.

Worauf Sie achten sollten

Muster rund um 4624

4624 ist hilfreich, wenn Sie wissen wollen, wo die Sitzung auftaucht, welcher Logon Type verwendet wurde und welcher Kontokontext auf diesem System ungewöhnlich ist.

Typische High-Value-Beispiele:

eine Netzwerk-Anmeldung, die eine Admin-Identität auf einem Host platziert, den sie normalerweise nicht verwaltet
wiederholte laterale Bewegung von einem kompromittierten Client auf mehrere Peers oder Server
derselbe lokale Admin-Kontext auf mehreren Endpunkten

4672 auf dem Zielsystem

4672 ist nützlich, wenn eine neue Anmeldung Special Privileges auf dem Zielsystem erhält. Das Ereignis erkennt PtH nicht allein, hilft aber dabei, die wirklich relevanten Remote-Logons einzugrenzen.

NTLM-Kontext, sofern verfügbar

Wenn Ihre Telemetrie NTLM-Authentifizierungskontext abbildet, ist das wertvoll, weil PtH genau von NTLM-akzeptierenden Zugriffspfaden lebt. Ziel ist nicht, auf jedes NTLM-Ereignis zu alarmieren. Ziel ist es, unerwartete NTLM-gestützte administrative Aktivität zu identifizieren, bei der Konten, Systeme oder Pfade zusammenkommen, die in der Umgebung nicht üblich sind.

Ungewöhnliche privilegierte Bewegung zwischen Hosts

Die stärksten Signale kommen oft eher aus dem Verhalten als aus einer einzelnen Event-ID:

dieselbe Admin-Identität taucht in kurzer Zeit auf mehreren Hosts auf
lokaler Admin-Kontext wird auf Hosts wiederverwendet, die eigentlich jeweils eindeutige Admin-Passwörter haben sollten
administrative Aktivität startet auf einer Workstation, die nicht zum normalen Admin-Workflow gehört

EDR-Signale für Credential Dumping und LSASS-Zugriff

Pass-the-Hash setzt meist zuerst Credential Theft voraus. Wenn Ihr EDR verdächtigen LSASS-Zugriff, Credential-Dumping-Verhalten und danach Remote-Admin-Aktivität vom selben Host sieht, ist diese Korrelation oft deutlich wertvoller als eine reine Event-Regel.

Beispiel für eine sinnvolle Detection-Formulierung

Formulieren Sie Detection nicht als „4624 bedeutet Pass-the-Hash“. Eine bessere Form ist:

verdächtiges Credential-Access-Verhalten auf Host A
danach NTLM-gestützter Remote-Logon oder Admin-Aktivität auf Host B
mit einem Kontokontext, der weder zum üblichen Quellsystem noch zum normalen Admin-Workflow passt

Auf diesem Niveau wird PtH in der Praxis erkannt.

Abhängigkeit vom Monitoring

Wenn AD- und Windows-Monitoring schwach ist, ist diese Technik leicht zu übersehen. Deshalb gehört AD-Sicherheitsüberwachung in dieselbe Kontrollfamilie wie PtH-Detection.

Remediation

Die Abwehr von Pass-the-Hash besteht nicht aus einer einzelnen Einstellung. Es ist eine Strategie, um die Orte mit wiederverwendbaren Credentials zu reduzieren, die Zahl der NTLM-akzeptierenden Pfade zu senken und zu begrenzen, wie weit ein gestohlener Admin-Kontext reisen kann.

1. Credential Guard dort aktivieren, wo er unterstützt wird

Microsoft beschreibt, dass Credential Guard NTLM-Hashes, Kerberos-TGTs und andere Geheimnisse schützt, indem sie per Hardware-Virtualisierung isoliert werden. Das ist eine der direktesten Maßnahmen gegen klassische Credential-Theft-Ketten, die PtH ermöglichen.

Wichtige, von Microsoft dokumentierte Einschränkungen:

einige Authentifizierungsfunktionen werden blockiert; Anwendungen müssen daher vor dem Rollout getestet werden
Credential Guard schützt lokale Konten und Microsoft-Konten nicht auf dieselbe Weise wie domänenbasierte Geheimnisse
bereitgestellte Anmeldeinformationen für NTLM-Authentifizierung sind nicht in jedem Szenario vollständig geschützt
Microsoft empfiehlt ausdrücklich, Credential Guard nicht auf Domain Controllern zu aktivieren

2. Remote Credential Guard oder Restricted Admin für RDP-Workflows verwenden

Microsoft dokumentiert zwei unterschiedliche Schutzmechanismen für RDP-basierte Admin-Workflows.

Remote Credential Guard verhindert, dass Credentials an das Remotesystem übertragen werden, und ist die bevorzugte Option, wenn das Szenario unterstützt wird.

Restricted Admin ist ebenfalls relevant. Microsoft empfiehlt ihn insbesondere für Helpdesk-Support-Szenarien, weil dadurch wiederverwendbare Credentials und Benutzerressourcen einem kompromittierten Zielhost weniger stark ausgesetzt sind.

Wichtige Einschränkungen laut Microsoft-Dokumentation:

Remote Credential Guard funktioniert nur mit RDP
er benötigt Kerberos
er wird nur für direkte Verbindungen zum Zielhost unterstützt, nicht über RD Gateway oder Connection Broker
er kann nicht verwendet werden, wenn der Remotehost ausschließlich Microsoft-Entra-joined ist
er deckt nicht jedes Authentifizierungsszenario ab; Kompatibilitätstests bleiben notwendig

3. Wiederverwendung lokaler Admin-Passwörter mit Windows LAPS beenden

Gemeinsam genutzte lokale Admin-Passwörter sind einer der einfachsten Wege, Pass-the-Hash skalierbar zu machen. Microsoft positioniert Windows LAPS ausdrücklich als Schutz gegen Angriffe, die lokale Konten für laterale Bewegung missbrauchen, einschließlich PtH-artiger Fortschritte.

Wenn dasselbe lokale Admin-Passwort auf Dutzenden oder Hunderten Endpunkten existiert, kann aus einem einzelnen kompromittierten System schnell eine breite Lateralmovement-Kampagne werden. Windows LAPS nicht bereitgestellt sollte deshalb als direkte PtH-Exposition verstanden werden und nicht als bloßes Hygiene-Thema.

4. Privilegierte Credentials von weniger vertrauenswürdigen Hosts fernhalten

Microsofts eigene Credential-Guard-Dokumentation ist hier eindeutig: Hochwertige Konten sollten dedizierte PCs verwenden. Das ist eine der praktischsten Anti-PtH-Maßnahmen, weil dadurch die Wahrscheinlichkeit sinkt, dass privilegiertes Authentifizierungsmaterial überhaupt auf Commodity-Workstations landet.

Das kann mehrere Formen annehmen:

dedizierte Admin-Arbeitsstationen
Admin-Jump-Hosts mit strengem Rollenumfang
Tiered Administration, bei der niedrigere Ebenen keine Credentials höherer Ebenen einsammeln können
getrennte Admin-Identitäten statt alltäglicher privilegierter Nutzung

5. NTLM-Nutzung soweit möglich reduzieren

Pass-the-Hash bleibt operativ wertvoll, weil NTLM operativ wertvoll bleibt. Wenn kritische Verwaltungspfade weiterhin auf NTLM beruhen, hat der Angreifer mehr Bewegungsraum. Weniger NTLM, weniger unnötige NTLM-Abhängigkeiten und weniger stilles Fallback bedeuten daher auch weniger PtH-Exposition.

Aus demselben Grund sollten PtH und NTLM-Relay-Angriffe gemeinsam betrachtet werden. Es sind unterschiedliche Techniken, aber beide leben von derselben Protokollschuld.

6. Die Konten schützen, deren Diebstahl sich am meisten lohnt

Für besonders privilegierte Identitäten sollten Kontrollen in Betracht gezogen werden, die NTLM-Nutzung und das Ablegen wiederverwendbarer Secrets operativ deutlich weniger akzeptabel machen:

privilegierte Konten nicht auf allgemeine Systeme anmelden
die Gruppe Protected Users einsetzen, wenn die Umgebung ihre Einschränkungen tragen kann
veraltete und überprivilegierte Konten überprüfen und Altlasten mit unnötiger Reichweite entfernen
AD-Passwortsicherheit härten, damit schwache Passwortpraktiken den Schaden eines einzelnen gestohlenen Admin-Kontexts nicht weiter vergrößern

Protected Users ist stark, aber nicht kostenlos. Microsoft dokumentiert, dass Mitglieder dieser Gruppe sich nicht per NTLM, Digest oder CredSSP Default Delegation authentifizieren können und dass daher Legacy-Workflows scheitern können. Das macht die Gruppe zu einem starken Schutz für High-Value-Accounts, aber nicht zu einer Änderung, die man blind ausrollt.

Validierung nach der Härtung

Beenden Sie Pass-the-Hash-Remediation nicht, nur weil eine einzelne Einstellung aktiviert wurde. Validieren Sie den gesamten Pfad Ende zu Ende.

bestätigen Sie, dass privilegierte Konten sich nicht mehr an niedrigeren Tiersystemen anmelden, auf denen ihr Authentifizierungsmaterial exponiert werden könnte
prüfen Sie, dass Windows LAPS tatsächlich eindeutige lokale Admin-Passwörter auf den Systemen im Scope rotiert
testen Sie Credential-Guard-Kompatibilität auf repräsentativen Systemen vor breitem Rollout und prüfen Sie anschließend, dass die Funktion aktiviert geblieben ist
validieren Sie, dass RDP-Admin-Workflows wie vorgesehen Remote Credential Guard oder Restricted Admin verwenden
überprüfen Sie, ob verbleibende Verwaltungswege weiterhin auf NTLM oder stilles Fallback angewiesen sind
testen Sie, ob ein kompromittierter Endpoint noch andere Systeme mit wiederverwendetem lokalem Admin-Kontext erreichen kann

Das richtige Erfolgskriterium lautet nicht „Wir haben ein Feature aktiviert“. Das richtige Erfolgskriterium lautet: „Ein einzelner gestohlener Admin-Kontext erlaubt dem Angreifer nicht mehr dieselbe Bewegungskette.“

Wie EtcSec zugehörige Exposition erkennt

EtcSec braucht hier kein künstliches Pass-the-Hash-Taxonomie-Tag. Der Nutzen liegt in den verwandten Expositionen, die PtH überhaupt praktikabel machen.

Die relevantesten Kontrollfamilien rund um PtH sind:

Zusammen zeigen diese Kontrollen, ob die Umgebung noch die Zutaten enthält, die einen einzelnen gestohlenen Windows-Credential-Wert in eine Kette lateraler Bewegung verwandeln.

Pass-the-Hash: Wie gestohlene NTLM-Hashes noch immer laterale Bewegung ermöglichen