Lateral Movement: Erkennung und Verteidigung im Unternehmensnetzwerk

Der erste kompromittierte Host ist selten das Endziel eines Angreifers - er ist der Startpunkt. Lateral Movement bezeichnet alle Techniken mit denen ein Angreifer sich von diesem Brückenkopf aus durch das Netzwerk bewegt, um wertvolle Systeme (Domain Controller, Fileserver, Backup-Server, Datenbanken) zu erreichen. Das Verstehen dieser Techniken ist Voraussetzung um sie zu erkennen und zu verhindern.

Lateral-Movement-Techniken

Die häufigsten Lateral-Movement-Methoden:

Pass-the-Hash (PtH):
  → Angreifer nutzt NTLM-Passwort-Hash statt Klartext-Passwort
  → Kein Credential-Cracking nötig!
  → Windows-Authentifizierung akzeptiert Hash direkt (NTLM-Protokoll)

  Ablauf:
  1. Angreifer hat Zugriff auf Host A
  2. Mimikatz: sekurlsa::logonpasswords → NTLM-Hash von User
  3. Kein Crack: Hash direkt für Authentifizierung auf Host B nutzen
  4. cmd → wmic /node:HOST_B process call create "cmd" → Shell auf B!

  Warum möglich? NTLM: Challenge-Response ohne Passwort-Klartext
  → Hash IS the password in NTLM

Pass-the-Ticket (PtT):
  → Kerberos-Tickets stehlen + wiederverwenden
  → Tickets im LSASS-Prozess-Speicher gespeichert
  → Mimikatz: sekurlsa::tickets /export → Ticket-Dateien
  → Rubeus: /ticket:file.kirbi → Ticket laden + nutzen

Golden Ticket:
  → KRBTGT-Account-Hash kompromittiert
  → Angreifer kann beliebige TGTs erstellen
  → Für jeden User, jede Gruppe, beliebige Laufzeit!
  → Persistenz: Jahre wenn KRBTGT nicht rotiert

  Erkennung: Tickets mit Lifetime > 10h (Policy-Abweichung)

WMI Remote Execution (wmiexec.py):
  → Windows Management Instrumentation für Remote-Ausführung
  → Firewall erlaubt oft WMI (Port 135/dynamic)
  → wmiexec.py DOMAIN/User:Pass@HOST_B "ipconfig"
  → Alternative zu PSExec: weniger forensische Artefakte

PSExec (und Varianten):
  → Erstellt Service auf Ziel-System → Shell
  → Hinterlässt Spuren: Service-Events (EventID 7045)
  → SMBExec, CSExec: leisere Alternativen

Remote Services (sc.exe, Services API):
  → Service auf Ziel erstellen
  → DLL-Implant als Service → Persistence + Lateral Movement

WinRM / PowerShell Remoting:
  → Enter-PSSession -ComputerName HOST_B
  → Invoke-Command -ComputerName HOST_B -ScriptBlock {...}
  → Port 5985 (HTTP) / 5986 (HTTPS)
  → Normal erlaubt für Admins → gut zum Verstecken!

SSH Lateral Movement (Linux/Unix):
  → SSH-Keys stehlen: cat ~/.ssh/id_rsa
  → Known Hosts auslesen: ~/.ssh/known_hosts → Netzwerk-Topologie!
  → SSH-Agent-Forwarding missbrauchen

RDP (Remote Desktop Protocol):
  → Port 3389 intern oft offen
  → Credential-Nutzung für RDP-Sessions
  → SharpRDP: RDP ohne UI-Client
  → Anomalie: Admin-Account RDP zu unerwarteten Hosts

DCOM (Distributed COM):
  → Wenig geloggt, beliebtes Evasion-Tool für Red Teams
  → ShellBrowserWindow, MMC20.Application als Execution-Vektor

Erkennungsstrategien

Lateral Movement erkennen - Windows Event Log:

Key-Event-IDs:
  4624 (Logon Success):
    → Logon Type 3 (Network) + Admin-Account = RDP/WMI/PSExec
    → Logon Type 10 (Remote Interactive) = RDP
    → Unbekannte Workstations in AuthenticationPackageName "NTLM"
    → NTLM auf internen Hosts = Verdacht auf PtH!

  4648 (Explicit Credential Logon):
    → Logon mit explizitem Credential (runas, PtH)
    → Admin-Account auf vielen Hosts → Lateral Movement Scan

  4768/4769 (Kerberos TGT/Service Ticket):
    → 4769 mit encryption type 0x17 (RC4) = Kerberoasting!
    → Viele 4769-Events für verschiedene Services = Enumeration

  4672 (Special Privileges assigned):
    → SeDebugPrivilege vergeben = Mimikatz-Aktivität möglich

  7045 (New Service installed):
    → Unbekannter Service → PSExec/Service-basiertes Lateral Movement

  1102 (Audit Log cleared):
    → Anti-Forensik = Breach höchstwahrscheinlich!

SIEM-Erkennungsregeln (KQL/Sigma):

  Pass-the-Hash-Erkennung:
    SecurityEvent
    | where EventID == 4624
    | where LogonType == 3
    | where AuthenticationPackageName == "NTLM"
    | where AccountName !endswith "$"   -- kein Computerkonto
    | where IpAddress !in ("10.0.0.1")  -- kein legitimes System
    | summarize count() by AccountName, IpAddress, WorkstationName
    | where count_ > 5
    → Viele NTLM-Logins von gleicher IP = PtH oder Credential Stuffing

  Impossible Travel (Lateral Movement):
    SecurityEvent
    | where EventID == 4624
    | project TimeGenerated, AccountName, IpAddress
    | summarize by AccountName, IpAddress, bin(TimeGenerated, 5m)
    | join (
        SecurityEvent | where EventID == 4624
      ) on AccountName
    | where abs(datetime_diff('minute', TimeGenerated, TimeGenerated1)) < 10
    | where IpAddress != IpAddress1
    → Gleiches Konto von zwei IPs in 10min = Lateral Movement!

  Kerberoasting-Erkennung:
    SecurityEvent
    | where EventID == 4769
    | where TicketOptions has "0x40810000"
    | where TicketEncryptionType == "0x17"  -- RC4
    | summarize count() by AccountName, ServiceName, bin(TimeGenerated, 1h)
    | where count_ > 10
    → Viele RC4-Tickets für Service-Accounts = Kerberoasting!

EDR-basierte Erkennung:
  □ LSASS-Zugriff: Prozesse die auf lsass.exe zugreifen (Mimikatz!)
  □ Token-Impersonation: SeImpersonatePrivilege-Nutzung
  □ Remote-Thread-Injection in Remote-Systemen
  □ WMI-Remote-Calls mit PowerShell-Payload
  □ Unusual parent-child process chains (cmd.exe → psexec.exe → svchost.exe)

Network-Level-Erkennung:
  □ SMB-Verbindungen zwischen Workstations (Workstation→Workstation SMB = unüblich!)
  □ WMI-Traffic von Nicht-Admin-Systemen
  □ Port 5985/5986 zu vielen Zielen kurz nacheinander
  □ RDP-Sessions zu unerwarteten Zielen
  □ Netzwerk-Scans (Port-Scans intern = Reconnaissance)

Defense-Maßnahmen

Lateral Movement verhindern - Härtungsmaßnahmen:

1. LAPS (Local Administrator Password Solution):
   Problem: Alle Windows-Workstations haben GLEICHEN lokalen Admin-Pass
   → Ein kompromittiertes System → alle Systeme kompromittiert!

   Lösung: Microsoft LAPS
   → Jeder lokale Admin-Account bekommt einzigartiges, zufälliges Passwort
   → Passwort rotiert automatisch (Standard: alle 30 Tage)
   → Passwort gespeichert in AD-Objekt, nur autorisierte User können lesen
   → Windows LAPS (ab Windows 11 22H2): built-in, kein Add-On!

   Implementierung:
   # Windows LAPS aktivieren (PowerShell):
   Enable-WindowsOptionalFeature -Online -FeatureName "LAPS"
   # Oder per GPO: Computer Config → Admin Templates → Windows LAPS

   Impact: Pass-the-Hash mit lokalem Admin-Hash funktioniert NUR für diesen einen Host!

2. Protected Users Security Group:
   → Mitglieder: Domain Admins, Service Accounts, kritische User
   → Verhindert: NTLM-Authentifizierung, RC4-Kerberos, Credential Caching
   → Kerberos-Only, AES-Verschlüsselung erzwungen
   → Tickets: 4h TGT, max. 1h Service Tickets

   Folge für PtH: Ohne NTLM kein Pass-the-Hash für Protected Users!
   Folge für Kerberoasting: RC4 deaktiviert → nur AES → viel schwerer zu cracken!

   Konfiguration:
   Add-ADGroupMember -Identity "Protected Users" -Members "Domain Admins"

3. Credential Guard (Windows):
   → LSASS läuft in isolierter Virtualisierungs-Umgebung (VBS)
   → Mimikatz kann NTLM-Hashes nicht aus LSASS extrahieren!
   → Requirement: UEFI Secure Boot + virtualization-based security

   GPO: Computer Config → Admin Templates → System → Device Guard
       → "Turn on virtualization based security"

4. SMB Signing erzwingen:
   → SMB-Signing verhindert Relay-Angriffe (NTLM Relay)
   → Ohne Signing: Angreifer kann SMB-Verbindungen relay-en → PtH ohne Hash!

   GPO:
   Computer Config → Windows Settings → Security Settings → Local Policies
   → "Microsoft network server: Digitally sign communications (always)" = ENABLED

5. Network Segmentierung (Mikrosegmentierung):
   → Workstations dürfen NICHT direkt mit anderen Workstations kommunizieren!
   → Server-Segment: nur von Admin-Jump-Hosts erreichbar
   → East-West-Traffic-Kontrolle: jede Verbindung explizit erlaubt

   Regel: Workstation → Workstation (SMB, WMI, RDP) = DENY
   Ausnahme: nur über Jump-Server/PAW (Privileged Access Workstation)

6. Tiered Administration Model:
   Tier 0: Domain Controller, PKI, Azure AD Connect
           → Nur Tier-0-Accounts können sich hier anmelden
   Tier 1: Server (Member Servers, Cluster)
           → Tier-1-Accounts, kein Tier-0-Account!
   Tier 2: Workstations, Endgeräte
           → Standard-User-Accounts

   Warum: Admin-Account auf Workstation → Hash gestohlen → nur Workstations erreichbar
   Ohne Tiering: Workstation-Admin-Hash → gesamtes Active Directory!

7. Just-In-Time (JIT) Administration:
   → Keine permanenten Administratorrechte!
   → Privileged Access Management (PAM): Rechte auf Anfrage für begrenzte Zeit
   → Microsoft: Privileged Identity Management (PIM) in Entra ID
   → CyberArk, BeyondTrust: Enterprise PAM

8. Deception Technology:
   → Honeypots und Honeytoken im internen Netzwerk
   → Honeypot-Server: niemand außer Angreifer verbindet sich!
   → Honey-Credentials in Passwort-Managern
   → Canary-Tokens: Wenn aufgerufen → Alert!
   → Lateral Movement sofort erkannt wenn Honeypot berührt wird

9. EDR mit verhaltensbasierter Erkennung:
   □ LSASS-Dump-Erkennung (Mimikatz-Signatur)
   □ Pass-the-Hash-Erkennung via NTLM-Anomalien
   □ Unusual remote execution (WMI, WinRM von unbekannten Sources)
   □ Token-Manipulation-Erkennung

10. Network Access Control (NAC):
    → Nicht-registrierte Devices kommen nicht ins interne Netz
    → Verhindert: Rogue-Devices als Lateral-Movement-Sprungbrett
    → MDM-Compliance: kompromittierter Endpoint → VLAN-Isolation

---

Lateral Movement zu verhindern ist eine der wichtigsten, aber auch komplexesten Aufgaben in der Netzwerksicherheit. Perfekter Schutz ist nicht möglich - das Ziel ist Erkennung und Verlangsamung: den Angreifer zwingen so viele Spuren zu hinterlassen, dass ein gut konfiguriertes SIEM ihn entdeckt bevor er sein Ziel erreicht. AWARE7 bewertet die Lateral-Movement-Resilienz Ihrer Infrastruktur im Rahmen von Red Team Übungen und gibt konkrete Maßnahmenpläne.

Red Team Assessment anfragen | Penetrationstest