NTLM-Relay und Responder erkennen: LLMNR-Poisoning und die Abwehr

NTLM-Relay erkennen ist deshalb so wichtig, weil der Angriff ohne ein einziges geknacktes Passwort auskommt und trotzdem bis zum Domain Admin führen kann. Der Angreifer braucht nur Zugang zum Netz und wartet, bis ein System nach einem Namen fragt, den der DNS nicht kennt. Werkzeuge wie Responder springen dann ein, geben sich als das gesuchte System aus und fangen die NTLM-Authentifizierung des Opfers ab. Diese Anmeldung wird entweder offline geknackt oder, viel gefährlicher, mit ntlmrelayx in Echtzeit an einen anderen Dienst weitergereicht. Dieser Beitrag aus der Serie „Angriff erkennen“ nimmt die Technik aus Verteidigersicht auseinander: was der Angreifer tut, wo es im Log sichtbar wird, drei Sigma-Regeln, die Härtung, die den Angriff ins Leere laufen lässt, und der Test.

Was der Angreifer tut

Der Angriff besteht aus zwei Teilen, die sich kombinieren lassen. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• Namensauflösung vergiften (Responder). Findet ein Windows-Client einen Namen nicht per DNS, fragt er per LLMNR, NBT-NS oder mDNS ins lokale Netz: Wer ist das? Ein Angreifer im selben Segment antwortet einfach: Ich. Der Client schickt daraufhin seine NTLM-Authentifizierung an den Angreifer. Auslöser sind oft Tippfehler in Pfaden, veraltete Einträge oder automatische Suchen nach Freigaben.
• Anmeldung weiterleiten (Relay). Statt den abgefangenen NetNTLMv2-Hash nur offline zu knacken, leitet der Angreifer ihn live an einen anderen Dienst weiter und authentifiziert sich dort als das Opfer, ohne das Passwort zu kennen. Beliebte Ziele sind SMB (Dateizugriff, Remote-Ausführung), LDAP (RBCD und Shadow Credentials zur Rechteausweitung) und die HTTP-Schnittstelle der Zertifizierungsstelle (ESC8).
• Authentifizierung erzwingen (Coercion). Statt auf einen Zufallstreffer zu warten, zwingt der Angreifer ein privilegiertes System, meist ein Computerkonto oder sogar einen Domain Controller, zu einer Anmeldung bei ihm. Verfahren wie PetitPotam, der Drucker-Bug und DFSCoerce liefern dafür den Auslöser. Die erzwungene Anmeldung wird dann relayt. Das ist der direkte Weg von einem Standardkonto zur Domänenübernahme.

Der gemeinsame Nenner für die Erkennung: Irgendwo meldet sich ein Konto per NTLM an einem Ort an, an dem es das sonst nicht tut, oft ein Computerkonto, oft über einen unsignierten Kanal. Genau das machen die Regeln unten sichtbar.

Welche Logquellen die Technik zeigt

• Der Spoofer auf dem Endpunkt. Responder läuft meist auf einem Linux-System des Angreifers und hinterlässt dort keine Windows-Spur. Das PowerShell-Pendant Inveigh dagegen zeigt sich in Event 4104 (Script Block Logging) an seinen Funktions- und Parameternamen.
• Die Relay-Landung. Event 4624 zeigt die Anmeldung mit Logon-Typ, Anmeldepaket und Quelle. Eine Netzwerkanmeldung (Typ 3) per NTLM mit einem Computerkonto ist das klassische Relay-Muster. Am Domain Controller nennt Event 8004 Konto, Client und Zielserver einer NTLM-Anmeldung in einem Eintrag, Event 4776 die NTLM-Anmeldevalidierung.
• Das LDAP-Ziel. Event 2889 im Directory-Service-Log zeigt unsignierte LDAP-Binds, also genau die Kanäle, auf die LDAP-Relay zielt.
• Das SMB-Ziel. Wird auf eine Freigabe relayt, erscheint der Zugriff in Event 5145, oft gefolgt von einer Dienstinstallation bei Remote-Ausführung.

Das Muster im Log

Die beste Einzelmethode ist ein Köder: Eine geplante Aufgabe fragt in kurzen Abständen per LLMNR und NBT-NS nach einem Hostnamen, den es nicht gibt. In einem sauberen Netz bleibt diese Anfrage unbeantwortet. Kommt eine Antwort, läuft ein Spoofer. Dieser Honeypot erkennt Responder unabhängig davon, auf welchem Betriebssystem er läuft. Daneben gilt wie bei der Erkennung von seitlicher Bewegung: Verdächtig ist die Beziehung. Ein Computerkonto, das sich per NTLM an einem Server anmeldet, ein Client, der unsigniertes LDAP spricht, eine NTLM-Anmeldung dort, wo sonst nur Kerberos läuft. Eine Baseline der normalen Anmeldewege macht diese Ausreißer sichtbar.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft. Die erste fängt den Windows-seitigen Spoofer, die zweite die Relay-Landung als Maschinenkonto, die dritte das unsignierte LDAP-Ziel. Zusammen decken sie den Spoofer, das häufigste Relay-Muster und die wichtigste Relay-Vorbedingung ab.

1. NTLM-Spoofing mit Inveigh (T1557.001). Inveigh ist das PowerShell-Werkzeug, mit dem Responder-artiges Vergiften direkt auf einem Windows-Host läuft. Die Regel greift auf die charakteristischen Funktionsnamen im Script Block Log.

title: NTLM-Spoofing mit Inveigh (PowerShell-Pendant zu Responder)
id: bee1cda2-8280-4947-8eba-8544d79e37b2
status: experimental
description: Erkennt den Einsatz von Inveigh, dem PowerShell-Pendant zu Responder,
  an charakteristischen Funktions- und Parameternamen im Script Block Log. Inveigh
  vergiftet LLMNR-, NBT-NS- und mDNS-Antworten, um NTLM-Authentifizierungen
  abzufangen und weiterzuleiten.
references:
  - https://attack.mitre.org/techniques/T1557/001/
author: blue-team.net
tags:
  - attack.credential-access
  - attack.t1557.001
logsource:
  product: windows
  category: ps_script
  definition: 'Script Block Logging (Event 4104) erforderlich'
detection:
  selection:
    ScriptBlockText|contains:
      - 'Invoke-Inveigh'
      - 'Invoke-InveighRelay'
      - 'Inveigh.ps1'
      - '-SpooferIP'
  condition: selection
falsepositives:
  - Autorisierte Penetrationstests und Purple-Team-Uebungen
level: high

2. Maschinenkonto per NTLM über das Netzwerk (T1557.001). Wird eine erzwungene Anmeldung eines Computerkontos relayt, landet sie am Ziel als Netzwerk-Logon mit NTLM und einem Kontonamen, der auf $ endet. In einer Kerberos-Domäne ist das die Ausnahme. Die Regel ist bewusst auf level: medium gesetzt, weil Altlasten Fehlalarme erzeugen, die du gezielt ausnimmst.

title: Maschinenkonto meldet sich per NTLM ueber das Netzwerk an (Relay-Signatur)
id: 799e8145-603d-4aa3-8abe-c2936c798074
status: experimental
description: Erkennt Netzwerk-Anmeldungen eines Computerkontos ueber NTLM. Bei
  NTLM-Relay, oft kombiniert mit erzwungener Authentifizierung wie PetitPotam oder
  dem Drucker-Bug, wird die Anmeldung eines Computerkontos an einen anderen Dienst
  weitergeleitet und erscheint dort als Netzwerk-Logon mit Maschinenkonto und
  NTLM. In einer gesunden Domaene ist Kerberos der Normalfall; NTLM eines
  Computerkontos ist die Ausnahme und verdient Pruefung.
references:
  - https://attack.mitre.org/techniques/T1557/001/
author: blue-team.net
tags:
  - attack.credential-access
  - attack.t1557.001
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: 'NTLM'
    TargetUserName|endswith: '$'
  filter_anonymous:
    TargetUserName: 'ANONYMOUS LOGON'
  condition: selection and not filter_anonymous
falsepositives:
  - Altsysteme sowie Backup- oder Cluster-Dienste, die bewusst NTLM mit Computerkonten nutzen
  - Umgebungen ohne durchgaengiges Kerberos
level: medium

3. Unsignierte LDAP-Anmeldung (T1557.001). LDAP-Relay funktioniert nur, wenn der Domain Controller ungesicherte Binds akzeptiert. Diese Regel macht jeden solchen Bind sichtbar und ist damit zugleich die Inventur vor dem Erzwingen von LDAP-Signierung und Channel Binding.

title: Unsignierte LDAP-Anmeldung am Domain Controller (Ziel fuer LDAP-Relay)
id: 195005d1-c159-4819-bdb2-a1de63a1b9ba
status: experimental
description: Erkennt Clients, die sich ohne LDAP-Signierung oder per einfachem Bind
  am Domain Controller anmelden. Genau diese ungesicherten Binds sind das Ziel von
  NTLM-Relay auf LDAP, etwa um ueber RBCD oder Shadow Credentials Rechte
  auszuweiten. Event 2889 nennt die betroffene Client-Adresse und ist damit die
  Inventur vor dem Erzwingen von LDAP-Signierung und Channel Binding.
references:
  - https://attack.mitre.org/techniques/T1557/001/
author: blue-team.net
tags:
  - attack.credential-access
  - attack.t1557.001
logsource:
  product: windows
  service: directory-service
  definition: 'Directory Service Log auf Domain Controllern; erhoehte LDAP-Interface-Protokollierung (16 LDAP Interface Events auf 2)'
detection:
  selection:
    EventID: 2889
  condition: selection
falsepositives:
  - Alte Anwendungen, Drucker und Appliances mit unsigniertem LDAP; vor dem Erzwingen der Signierung inventarisieren
level: medium

Härtung: der Angriff, der ins Leere läuft

Anders als bei vielen Techniken lässt sich NTLM-Relay fast vollständig durch Konfiguration aushebeln. Die Erkennung oben ist das Sicherheitsnetz, die Härtung ist das eigentliche Ziel:

• LLMNR und NBT-NS abschalten. Per Gruppenrichtlinie die Multicast-Namensauflösung deaktivieren und NetBIOS über TCP/IP ausschalten. Damit entfällt der häufigste Auslöser, ohne den Responder kaum etwas abfängt.
• SMB-Signierung erzwingen. Verpflichtende SMB-Signierung auf allen Systemen macht das Relay auf SMB wirkungslos.
• LDAP-Signierung und Channel Binding erzwingen. Auf den Domain Controllern die Signierung verlangen und Extended Protection (EPA) aktivieren. Davor mit Event 2889 inventarisieren, damit keine legitime Anwendung ausfällt.
• Zertifizierungsstelle absichern. Auf der Web-Enrollment-Schnittstelle EPA und HTTPS erzwingen, sonst bleibt ESC8 offen. Details unter AD-CS-Missbrauch erkennen.
• NTLM einschränken. Mittelfristig NTLM per Richtlinie zurückdrängen und die verbleibende Nutzung mit Event 8004 überwachen.

Der Test

Im Lab lässt sich die Erkennung sauber prüfen, ohne echte Angriffswerkzeuge gegen Produktivsysteme zu richten:

• Für Regel 1 ein Inveigh-Aufruf im Audit- oder Testmodus auf einem isolierten Windows-Client mit aktivem Script Block Logging. Event 4104 muss die Funktionsnamen zeigen und die Regel auslösen.
• Für Regel 3 der Verzicht auf LDAP-Signierung bei einem Test-Client und ein einfacher LDAP-Bind gegen den Lab-DC. Event 2889 muss den Client nennen.
• Für Regel 2 eine im Lab erzwungene Authentifizierung eines Computerkontos, die per ntlmrelayx an einen SMB-Server weitergeleitet wird. Am Ziel muss Event 4624 mit Logon-Typ 3, NTLM und einem auf $ endenden Konto erscheinen. Der Vergleich mit den passenden Tests aus Atomic Red Team zeigt, welche Varianten abgedeckt sind.

Fehlalarme und Tuning

• Autorisierte Tests. Inveigh und ntlmrelayx tauchen in Penetrationstests und Purple-Team-Übungen auf. Halte Testfenster und Testkonten fest, damit die Treffer zugeordnet werden können, statt die Regel zu entschärfen.
• Legitimes NTLM mit Computerkonten. Altsysteme, Backup- und Cluster-Dienste nutzen manchmal bewusst NTLM. Nimm diese bekannten Paare aus Konto und Ziel als Ausnahme auf und behalte den Rest scharf.
• Unsigniertes LDAP im Bestand. Drucker, Scanner und alte Anwendungen sprechen oft unsigniertes LDAP. Event 2889 ist hier zunächst eine Inventarliste, kein Alarm; erst nach der Bereinigung wird daraus eine scharfe Regel.
• Priorität. Ein Inveigh-Treffer und eine relayte DC-Anmeldung gehören zu den hochprioren Alarmen. Ein einzelnes unsigniertes LDAP eher ins Hunting als in die sofortige Eskalation.

Fazit

NTLM-Relay und Responder leben davon, dass alte, ungesicherte Protokolle im Hintergrund weiterlaufen. Das macht sie gefährlich, aber auch angreifbar: Kaum eine Technik lässt sich so gründlich durch Härtung entschärfen. Die drei Regeln hier sind das Sicherheitsnetz für die Zeit, bis LLMNR aus ist und überall signiert wird, und die bleibende Kontrolle danach. Wer weiter in der Kette lesen will: Die Rechteausweitung nach einem erfolgreichen LDAP-Relay steht unter AD-CS-Missbrauch erkennen, die seitliche Bewegung mit den erbeuteten Rechten in den übrigen Beiträgen der Serie „Angriff erkennen“.