Pass-the-Hash erkennen: Anmeldetyp 9 und NTLM ohne Passwort

Pass-the-Hash erkennen heißt, eine Anmeldung zu finden, die technisch korrekt ist und trotzdem nie hätte stattfinden dürfen. Der Angreifer kennt das Passwort nicht, er braucht es auch nicht: NTLM authentifiziert mit dem Hash, und der Hash liegt im Speicher jedes Systems, an dem sich das Konto angemeldet hat. Mit einem lokalen Adminpasswort, das auf hundert Clients gleich ist, oder dem Hash eines Domain-Admins, der sich einmal an einem infizierten Rechner angemeldet hat, ist das Netz in einer Stunde verloren. Dieser Beitrag beschreibt, wie die Technik funktioniert, die drei Stellen, an denen sie Spuren hinterlässt, das Muster, das sie von normalem NTLM-Verkehr unterscheidet, zwei Sigma-Regeln, den Test und die Fehlalarme, die bei NTLM aus alten Anwendungen kommen.

Was der Angreifer tut

NTLM ist das ältere der beiden Windows-Authentifizierungsprotokolle und beweist die Identität über eine Challenge-Response, die aus dem NT-Hash des Passworts berechnet wird. Wer den Hash hat, kann die Antwort berechnen, ohne das Passwort je zu sehen. Der Angriff hat drei Schritte. Erstens der Diebstahl: Auf einem System mit lokalen Adminrechten liest ein Werkzeug wie Mimikatz die Hashes angemeldeter Konten aus dem Speicher des LSASS-Prozesses, oder aus der SAM-Datenbank die lokalen Konten. Zweitens die Vorbereitung: Der Angreifer startet auf seinem System einen Prozess mit dem gestohlenen Hash als Anmeldeinformation, technisch eine Anmeldung vom Typ 9, so wie runas /netonly sie erzeugt, nur mit Hash statt Passwort. Drittens die Nutzung: Jeder Netzwerkzugriff aus diesem Prozess, auf Freigaben, per WMI, per PsExec, authentifiziert sich beim Ziel per NTLM mit dem gestohlenen Hash, und das Ziel fragt beim Domain Controller nach, ob die Antwort stimmt. Sie stimmt. In ATT&CK ist die Technik T1550.002 unter Lateral Movement und Defense Evasion, weil sie beides ist: ein Weg zu anderen Systemen und ein Weg, MFA und Passwortrichtlinien zu umgehen. Die Detection Strategy verweist auf genau die drei Stellen, die im nächsten Abschnitt stehen.

Welche Logquellen die Technik zeigen

Der Diebstahl ist die Stelle mit der besten Erkennung, weil ein Zugriff auf LSASS aus einem unbekannten Prozess in einer gepflegten Umgebung nie legitim ist; die Detection Strategy dazu ist im Beitrag zu ATT&CK durchgespielt. Die Nutzung ist die Stelle mit der größten Reichweite, weil sie auch dann sichtbar ist, wenn der Diebstahl auf einem System ohne Sysmon stattfand. Die Ereignisse im Einzelnen stehen in der Referenz zu den Event-IDs.

Das Muster im Log

NTLM kommt in jeder Domäne vor, weil alte Anwendungen, Zugriffe per IP-Adresse statt Hostname und Systeme außerhalb der Domäne es brauchen. Die Erkennung lebt deshalb vom Kontext. Erstens der Anmeldeprozess: 4624 mit Typ 9 und seclogo ist auf Arbeitsplätzen von Standardbenutzern so selten, dass jeder Fall angeschaut werden kann; Administratoren mit runas /netonly erzeugen dasselbe und sind die Ausnahmeliste. Zweitens die Kombination: ein 4624 Typ 9 auf einem System, gefolgt innerhalb von Minuten von 4624 Typ 3 mit NTLM auf anderen Systemen mit demselben Konto und derselben Quelladresse, ist die vollständige Kette. Drittens der Bruch mit der Gewohnheit: Ein Domänenkonto, das sich sonst per Kerberos anmeldet, meldet sich plötzlich per NTLM an, oder ein lokales Adminkonto meldet sich per Netzwerk an einem anderen Client an, was ohne LAPS das Muster eines geteilten Passworts ist. Viertens die Menge: dasselbe Konto per NTLM auf zehn Systemen in fünf Minuten, das ist die Ausbreitung. Alles zusammen ergibt eine Erkennung, die in drei Stufen arbeitet: LSASS-Zugriff als Alarm mit Isolierung, Typ 9 auf Nicht-Admin-Systemen als Alarm, NTLM-Ausbreitung als Korrelation.

Zwei Sigma-Regeln

Die erste fängt die Vorbereitung auf der Quelle, die zweite die Nutzung auf dem Ziel. Die Regel für den LSASS-Zugriff ist dieselbe wie bei jedem Auslesen von Zugangsdaten und steht in der Community-Sammlung unter T1003.001.

title: Logon Type 9 With Seclogo On Workstation
id: 1c6e9a3f-4b2d-4d8c-9f1e-7a5b3c2d1e0f
status: test
description: Anmeldung mit neuen Anmeldeinformationen (runas /netonly oder
  Pass-the-Hash-Werkzeug) auf einem Arbeitsplatz eines Standardbenutzers.
references:
  - https://attack.mitre.org/techniques/T1550/002/
author: Blue Team
date: 2026-09-13
tags:
  - attack.lateral_movement
  - attack.defense_evasion
  - attack.t1550.002
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 9
    LogonProcessName: 'seclogo'
    AuthenticationPackageName: 'Negotiate'
  filter_admin_workstations:
    Computer|startswith: 'paw-'
  filter_admin_accounts:
    SubjectUserName|startswith: 'adm-'
  condition: selection and not 1 of filter_*
falsepositives:
  - Administratoren mit runas /netonly auf normalen Arbeitsplätzen; bestimmte Verwaltungswerkzeuge mit Alternativanmeldung
level: high

title: NTLM Network Logon Of Domain Account Where Kerberos Expected
id: 7f2d4b8e-9c1a-4e6b-a3d5-2b0c9e8f7a6d
status: test
description: NTLM-Netzwerkanmeldung eines Domaenenkontos auf einem Server,
  auf dem Kerberos der Normalfall ist.
references:
  - https://attack.mitre.org/techniques/T1550/002/
author: Blue Team
date: 2026-09-13
tags:
  - attack.lateral_movement
  - attack.t1550.002
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: 'NTLM'
    KeyLength: 0
  filter_local:
    TargetDomainName:
      - ''
      - 'NT AUTHORITY'
  filter_anonymous:
    TargetUserName: 'ANONYMOUS LOGON'
  filter_legacy_sources:
    IpAddress|startswith:
      - '10.10.40.'     # Segment mit Altsystemen, die NTLM brauchen
  filter_machine_accounts:
    TargetUserName|endswith: '$'
  condition: selection and not 1 of filter_*
falsepositives:
  - Zugriffe per IP-Adresse statt Hostname, Altsysteme, Dienste ohne Kerberos-Unterstuetzung; nach Quelle und Anwendung ausnehmen
level: medium

Die zweite Regel ist in einer Umgebung mit viel NTLM zunächst laut; sie läuft zwei Wochen im Beobachtungsmodus, wie im Beitrag zu Sigma-Regeln beschrieben, und die Treffer werden zur Liste der Systeme und Anwendungen, die NTLM tatsächlich brauchen. Diese Liste ist zugleich der Arbeitsvorrat für die Abschaffung von NTLM, und mit jedem Eintrag, der von der Liste verschwindet, wird die Regel schärfer. Eine dritte Regel als Korrelation, dasselbe Konto mit NTLM-Typ-3-Anmeldungen auf fünf oder mehr Zielen in fünf Minuten, gruppiert nach Konto und Quelladresse, findet die Ausbreitung und ist in der Community-Sammlung vorhanden.

Der Test

Im Homelab in drei Schritten, die die drei Stellen abbilden. Erstens auf dem ersten Client als lokaler Admin ein Speicherabbild von LSASS oder ein Aufruf von Mimikatz mit sekurlsa::logonpasswords: Sysmon 10 muss erscheinen, und wenn das EDR im Lab läuft, ist hier bereits Schluss, was das Ergebnis für Stufe 5 der Bewertung ist. Zweitens auf demselben Client mit Mimikatz sekurlsa::pth oder von der Kali-VM mit Impacket und dem Parameter -hashes eine Anmeldung mit dem Hash des lokalen Adminkontos des zweiten Clients: Bei Mimikatz entsteht 4624 Typ 9 mit seclogo auf der Quelle und die erste Regel trifft; bei Impacket entfällt dieser Schritt, weil das Werkzeug NTLM direkt spricht, und genau das zeigt, warum die Nutzung auf dem Ziel die verlässlichere Stelle ist. Drittens ein Freigabezugriff oder ein PsExec-Aufruf auf den zweiten Client: dort 4624 Typ 3 mit NTLM und Schlüssellänge 0, auf dem Domain Controller 4776 nur dann, wenn ein Domänenkonto benutzt wurde, im Zeek-Sensor ein Eintrag im ntlm.log. Atomic Red Team hat für T1550.002 Tests mit Mimikatz und Invoke-WMIExec, die dasselbe erledigen. Alle drei Stellen mit Datum in den Navigator.

Fehlalarme und Tuning

• Zugriffe per IP-Adresse. Wer eine Freigabe über die IP statt den Hostnamen anspricht, bekommt kein Kerberos-Ticket und fällt auf NTLM zurück. Das erzeugt legitime Treffer der zweiten Regel, ist aber auch eine Gewohnheit, die sich abstellen lässt; bis dahin Filter auf die bekannten Skripte und Konten.
• Altsysteme und Anwendungen ohne Kerberos. NAS-Systeme, alte Anwendungsserver, Drucker und manche Backup-Lösungen sprechen nur NTLM. Sie kommen als Quelle oder Ziel auf die Ausnahmeliste, und die Liste geht an das Projekt zur NTLM-Abschaffung.
• Administratoren mit runas /netonly. Die erste Regel trifft sie. Die richtige Antwort ist ein Admin-Arbeitsplatz, auf dem der Filter greift; die falsche ist, das Konto auszunehmen, weil ein gestohlener Admin-Hash dann unsichtbar ist.
• Sicherheitssoftware auf LSASS. Antivirus, EDR und manche Backup-Agenten öffnen LSASS legitim. Der Filter der LSASS-Regel nennt sie nach Pfad und Signatur, und jeder neue Prozess in dieser Liste wird einmal geprüft, weil Angreifer ihre Werkzeuge gern in diese Pfade legen.
• Die Gegenmaßnahme, die die Regel entlastet. LAPS für lokale Adminpasswörter, damit ein Hash nur auf einem System gilt. Credential Guard, damit die Hashes von Domänenkonten nicht mehr im lesbaren Speicher liegen. Die Gruppe der geschützten Benutzer für Administratoren, die NTLM für diese Konten verbietet. Und die NTLM-Überwachung per Gruppenrichtlinie als Vorstufe zur Abschaffung. Mit jedem dieser Schritte wird ein Treffer der Regeln wahrscheinlicher ein echter, und am Ende ist Pass-the-Hash keine Technik mehr, sondern eine Fehlermeldung.

Fazit

Pass-the-Hash ist der Grund, warum ein einziger infizierter Client zum verlorenen Netz wird, und die Erkennung hat drei Chancen: beim Diebstahl aus LSASS, bei der Vorbereitung mit Anmeldetyp 9 und bei der Nutzung als NTLM dort, wo Kerberos sein sollte. Wer alle drei Stellen im Lab durchgespielt hat, weiß, welche davon in der eigenen Umgebung trägt, und die Liste der NTLM-Treffer aus dem Beobachtungsmodus ist das beste Argument für LAPS, Credential Guard und den Abschied von NTLM, das ein Blue Team der Administration liefern kann. Zusammen mit der Erkennung der seitlichen Bewegung ist das der Abschnitt der Kill Chain, in dem sich Ransomware noch stoppen lässt.