Pass-the-Hash und Pass-the-Ticket: Mechanik und Erkennung für Blue Teams

Der Diebstahl von Anmeldeinformationen bleibt einer der zuverlässigsten Wege, auf denen sich ein Angreifer durch eine Windows-Domäne bewegt, und zwei Techniken stehen dabei im Mittelpunkt: Pass-the-Hash (PtH) und Pass-the-Ticket (PtT). Beide missbrauchen die Funktionsweise von Authentifizierungsprotokollen und nicht einen einzelnen patchbaren Fehler — genau deshalb müssen Verteidiger sie gründlich verstehen. Dieser Artikel verfolgt den Ansatz verstehen, um zu verteidigen: Wir erklären, was diese Techniken sind, wie sie auf konzeptioneller Ebene funktionieren, wo das Anmeldematerial liegt und — vor allem — welche konkreten Erkennungssignale und Härtungsmaßnahmen es einem Blue Team erlauben, laterale Bewegung zu entdecken und einzudämmen. Hier finden sich keine Angriffsrezepte, nur das Wissen, das ein Verteidiger braucht, um belastbare Überwachung aufzubauen und den Schadensradius eines kompromittierten Hosts zu verkleinern.

Was Pass-the-Hash und Pass-the-Ticket wirklich sind

In einer Windows-Umgebung geben Benutzer selten für jede Ressource ihr Passwort erneut ein. Stattdessen bewahrt das Betriebssystem Authentifizierungsartefakte im Speicher auf, um die Identität stellvertretend zu belegen. Bei der NTLM-Authentifizierung ist dieses Artefakt ein passwortäquivalenter Hash; bei Kerberos ist es ein Ticket, entweder ein Ticket-Granting-Ticket (TGT) oder ein Service-Ticket. Pass-the-Hash ist die Wiederverwendung eines gestohlenen NTLM-Hashes zur Authentifizierung als Benutzer, ohne das Klartextpasswort zu kennen. Pass-the-Ticket ist der entsprechende Gedanke für Kerberos: Ein gestohlenes oder gefälschtes Ticket wird vorgelegt, um Zugriff zu erlangen. Der strategische Punkt für Verteidiger ist, dass beide Techniken einen einzigen kompromittierten Endpunkt in eine Startrampe verwandeln, weil die dort gesammelten Artefakte anderswo in der Domäne gültig sind.

Wie die Techniken auf hoher Ebene funktionieren

Beide Techniken teilen eine Voraussetzung: einen Angreifer, der bereits privilegierte Codeausführung auf einem Host erlangt hat und geschützten Speicher des LSASS-Prozesses lesen kann — jenes Windows-Subsystems, das Anmeldematerial für Single Sign-on zwischenspeichert. Sobald dieses Material extrahiert ist, spielt PtH den Hash gegen Dienste ab, die NTLM akzeptieren, und PtT injiziert ein gültiges Ticket in eine Anmeldesitzung, sodass Kerberos-basierte Dienste ihm vertrauen. Varianten wie Overpass-the-Hash überbrücken beide Welten, indem sie einen NTLM-Hash nutzen, um ein Kerberos-TGT anzufordern; Varianten mit gefälschten Tickets — das aus dem krbtgt-Schlüssel gebaute Golden Ticket und das auf einen einzelnen Dienst begrenzte Silver Ticket — erlauben es einem Eindringling, eigene Tickets zu prägen, statt vorhandene zu stehlen. Das verbindende Motiv ist, dass der Angreifer nie das Passwort braucht: Das Geheimnis, das er benötigt, ist das abgeleitete Artefakt, und dieses Artefakt ist per Design von legitimer Software wiederholbar. Deshalb ist die verteidigende Antwort mehrschichtig — man kann ein Protokoll, das sich spezifikationsgemäß verhält, nicht einfach wegpatchen, also begrenzt man, wo Artefakte auftauchen, isoliert sie im Speicher und instrumentiert die Umgebung, damit ihr Missbrauch laut wird.

Angriffsfläche: wo das Anmeldematerial liegt

Das Verständnis der Fläche sagt, was zu schützen ist. Das primäre Reservoir ist der LSASS-Speicher auf jedem Host, auf dem sich kürzlich ein privilegiertes Konto interaktiv, über Remotedesktop oder über einen Dienst mit zwischengespeicherten Anmeldedaten angemeldet hat. Sekundäre Reservoire sind die lokale SAM-Datenbank, zwischengespeicherte Domänen-Anmeldeprüfer, die NTDS.dit-Datenbank auf Domänencontrollern sowie Backups oder VM-Snapshots, die eines davon enthalten. Hoch privilegierte Konten — Domänenadministratoren, Dienstkonten mit weitreichenden Rechten und Sicherungsoperatoren — sind die Kronjuwelen, denn ein einziger gesammelter Hash oder ein Ticket für eines davon kann das gesamte Verzeichnis öffnen. Die verteidigende Konsequenz ist ein Prinzip der Credential-Hygiene: Ein Tier-0-Konto darf sich niemals an einer weniger vertrauenswürdigen Arbeitsstation authentifizieren, denn dabei wird der Speicher dieser Maschine mit einem domänenbeherrschenden Geheimnis versorgt.

Erkennungssignale: Logs, Event-IDs und Telemetrie

Erkennung ist der Bereich, in dem Blue Teams gewinnen. Weil diese Techniken legitime Protokolle wiederverwenden, ist kein einzelnes Ereignis ein eindeutiger Beweis; stattdessen korreliert man mehrere schwache Signale zu einem starken. Beobachten Sie die Windows-Sicherheitsprotokolle auf Event-ID 4624 (erfolgreiche Anmeldung) mit Logon Type 3 (Netzwerk) oder Type 9 (NewCredentials), besonders wenn das Authentifizierungspaket NTLM ist bei Konten, die Kerberos nutzen sollten. Kombinieren Sie 4624 mit 4776 (NTLM-Anmeldeprüfung) und 4672 (spezielle Rechte zugewiesen), um privilegierte Netzwerkanmeldungen zu erkennen, die nicht dem Normalmuster entsprechen. Für Kerberos-Missbrauch überwachen Sie 4768 (TGT angefordert) und 4769 (Service-Ticket angefordert); Tickets mit ungewöhnlichen Verschlüsselungstypen, unpassenden Laufzeiten oder Anfragen für Konten, die sich nie interaktiv anmelden, verdienen genaue Prüfung. Gefälschte Tickets erzeugen oft eine Laufzeit, die die Domänenrichtlinie übersteigt — eine starke Anomalie.

Endpunkt-Telemetrie schließt die Lücke. Eine gute EDR-Lösung meldet verdächtige Handle-Anforderungen an LSASS — Prozesszugriff mit Rechten wie PROCESS_VM_READ von einem Nicht-System-Prozess ist ein hochwertiger Alarm — ebenso das Laden ungewöhnlicher Treiber und die Injektion von Ticket-Material in Anmeldesitzungen. Sysmon liefert Präzision: Event-ID 10 (ProcessAccess) auf lsass.exe, Event-ID 1 (Prozesserstellung) für bekannte Muster von Credential-Werkzeugen und Event-ID 3 (Netzwerkverbindung) für laterale Verbindungen von Arbeitsstation zu Arbeitsstation. Das haltbarste Verhaltenssignal ist die laterale Bewegung selbst: ein Konto, das sich von einer nie zuvor genutzten Maschine, zu einer nie üblichen Zeit, zu nie berührten Hosts authentifiziert. Wer normale Authentifizierungspfade als Basislinie erfasst und auf Abweichungen alarmiert, erkennt PtH und PtT auch bei neuartigen Werkzeugen.

Abwehr und Härtung

Die wirksamste Kontrolle ist die Credential-Tiering: Konten und Systeme in Verwaltungsebenen unterteilen (Tier 0 für Domänencontroller und Identitätsinfrastruktur, Tier 1 für Server, Tier 2 für Arbeitsstationen) und höheren Anmeldedaten die Anmeldung an niedrigeren Ebenen verbieten. Allein das verwehrt dem Angreifer die Kronjuwelen-Artefakte auf weichen Zielen. Aktivieren Sie Credential Guard, das mit virtualisierungsbasierter Sicherheit die LSASS-Geheimnisse vom laufenden Betriebssystem isoliert und die Extraktion drastisch verteuert. Setzen Sie LSASS-Schutz (RunAsPPL / Protected Process Light) ein, damit gewöhnlicher Code kein Lese-Handle auf den Prozess öffnen kann. Verwenden Sie die Sicherheitsgruppe Geschützte Benutzer für sensible Konten; sie deaktiviert für ihre Mitglieder NTLM, schwache Kerberos-Verschlüsselung und das Zwischenspeichern von Anmeldedaten.

Reduzieren Sie die Zahl der Orte, an denen Geheimnisse landen. Erzwingen Sie das Prinzip der geringsten Rechte, damit die tägliche Arbeit nie ein Domänenadminkonto nutzt; stellen Sie separate, nicht per E-Mail erreichbare Administratorkonten bereit, die nur von gehärteten Privileged-Access-Workstations (PAWs) verwendet werden. Konfigurieren Sie Anmeldebeschränkungen mit Lokale Anmeldung verweigern und Anmeldung über Remotedesktop verweigern, um Tier-0-Konten von gewöhnlichen Maschinen fernzuhalten. Rotieren Sie das Passwort des krbtgt-Kontos planmäßig — zweimal, mit Verzögerung — um gefälschte Golden Tickets zu entwerten. Deaktivieren Sie NTLM, wo möglich, und prüfen Sie, wo es noch benötigt wird. Segmentieren Sie das Netzwerk, damit eine kompromittierte Arbeitsstation nicht direkt zu Nachbarn gelangt, und verlangen Sie SMB-Signierung sowie LDAP-Channel-Binding, um Relay-Missbrauch abzumildern. Verkürzen Sie schließlich die Kerberos-Ticketlaufzeiten im betrieblich vertretbaren Rahmen, damit gestohlene Tickets rasch ablaufen.

Häufige Fehler, die die Verteidigung schwächen

Selbst reife Teams unterlaufen sich selbst. Ein häufiger Fehler ist, Credential Guard auf Arbeitsstationen zu aktivieren, aber einen Domänenadministrator sich an Servern anmelden zu lassen, auf denen es nicht aktiviert ist — so werden abgreifbare Geheimnisse neu gesät. Ein weiterer ist, Erkennungsregeln als einmalige Sache zu behandeln: Authentifizierungs-Basislinien verschieben sich mit der Umgebung, sodass eine letztes Jahr abgestimmte Regel heute echte Alarme im Rauschen begräbt. Teams vertrauen auch zu sehr einer einzelnen Event-ID; da 4624 und 4769 ständig auslösen, erzeugt ein Alarm darauf ohne Korrelation nur Alarmmüdigkeit. Backups sind ein blinder Fleck — ein ungeschütztes NTDS.dit-Backup gibt jeden Hash der Domäne preis. Und schließlich lässt das Versäumnis, krbtgt nach einem Vorfall zu rotieren, die Persistenz gefälschter Tickets bestehen, selbst wenn man glaubt, den Eindringling vertrieben zu haben. Ebenso trügerisch ist der Glaube, ein einmaliges Zurücksetzen der Passwörter genüge: Solange Dienstkonten mit weitreichenden Rechten auf ungehärteten Servern angemeldet bleiben, entstehen die abgreifbaren Artefakte sofort neu, und die mühsame Bereinigung war umsonst.

Checkliste für Verteidiger

Nutzen Sie dies als Arbeitscheckliste. Identität: administratives Tiering umsetzen; sensible Konten in Geschützte Benutzer aufnehmen; PAWs für alle privilegierte Arbeit nutzen; krbtgt planmäßig und nach jedem Verdacht zweimal rotieren. Host-Härtung: Credential Guard und RunAsPPL aktivieren; LSASS-Schutz verifiziert halten, nicht nur konfiguriert; lokale und RDP-Anmelderechte je Ebene beschränken. Erkennung: Security-Event-IDs 4624, 4672, 4768, 4769, 4776 sammeln und zentralisieren; Sysmon mit ProcessAccess-Überwachung auf lsass.exe ausrollen; normale Authentifizierungspfade als Basislinie erfassen und auf Abweichung alarmieren; nach Tickets mit abnormer Laufzeit oder Verschlüsselung jagen. Eindämmung: Netzwerk segmentieren, SMB-Signierung und LDAP-Channel-Binding erzwingen, veraltetes NTLM deaktivieren und ein Incident-Runbook proben, das krbtgt-Rotation und das Zurücksetzen privilegierter Anmeldedaten enthält.

Häufig gestellte Fragen

Ist Pass-the-Hash noch relevant, wenn wir überall Kerberos nutzen? Ja. Viele Umgebungen fallen bei Sonderfällen auf NTLM zurück — direkte IP-Verbindungen, ältere Anwendungen oder fehlkonfigurierte Dienste — und jede verbleibende NTLM-Fläche hält PtH einsatzfähig. Zudem zielt Pass-the-Ticket direkt auf Kerberos, sodass ein Protokollwechsel kein Ersatz für Credential-Isolation und Überwachung ist.

Stoppt Mehr-Faktor-Authentifizierung diese Techniken? MFA ist am Punkt der interaktiven Anmeldung unverzichtbar, aber PtH und PtT verwenden Artefakte wieder, die nach einer erfolgreichen Authentifizierung entstehen. Sobald der Hash oder das Ticket im Speicher liegt, ist MFA nicht mehr beteiligt. Deshalb sind die haltbaren Kontrollen Artefakt-Isolation (Credential Guard, LSASS-Schutz), Tiering und Verhaltenserkennung statt allein die Stärke der Authentifizierung.

Fazit

Pass-the-Hash und Pass-the-Ticket überdauern, weil sie genau die Mechanismen ausnutzen, die Single Sign-on bequem machen. Es gibt keinen einzelnen Patch, der sie beseitigt; Verteidiger gewinnen, indem sie die gesammelten Artefakte schwer erreichbar, außerhalb eines engen Rahmens nutzlos und bei Missbrauch laut machen. Konzentrieren Sie sich auf Credential-Tiering, Speicherisolierung wie Credential Guard und RunAsPPL, disziplinierte Anmeldebeschränkungen und korrelierte Erkennung auf Basis von Windows-Event-IDs und Endpunkt-Telemetrie. Wenn diese Schichten zusammenwirken, bleibt eine einzelne kompromittierte Arbeitsstation eine einzelne kompromittierte Arbeitsstation — und die vertrauteste Technik des Eindringlings wird zu seinem sichtbarsten Fehler.