Zum Inhalt springen

Services, Wiki-Artikel, Blog-Beiträge und Glossar-Einträge durchsuchen

↑↓NavigierenEnterÖffnenESCSchließen
Lateral Movement erkennen und stoppen: Angreifer im Netzwerk abfangen - Cybersicherheit und digitaler Schutz
Threat Intelligence

Lateral Movement erkennen und stoppen: Angreifer im Netzwerk abfangen

Lateral Movement - die Ausbreitung eines Angreifers nach dem Initial Access - ist die Phase in der echte Schäden entstehen. Ransomware-Deployment, Datenbankzugriff, Domain Compromise beginnen mit Lateral Movement. Dieser Guide erklärt typische Techniken (Pass-the-Hash, Kerberoasting, PsExec, WMI), Erkennungsregeln für SIEM und effektive Präventionsmaßnahmen.

Vincent Heinen Vincent Heinen Abteilungsleiter Offensive Services
10 Min. Lesezeit
OSCP+ OSCP OSWP OSWA

TL;DR

Lateral Movement ist die kritische Phase

Diese Zusammenfassung wurde KI-gestützt erstellt (EU AI Act Art. 52).

Inhaltsverzeichnis (4 Abschnitte)

Der initiale Angriff ist selten das eigentliche Ziel. Der Angreifer landet auf einem Workstation-PC - aber er will die Produktionsdatenbank, den Domain Controller, das Backup-System. Um dorthin zu kommen, braucht er Lateral Movement. Das ist die Phase in der ein Incident zu einem Desaster wird.

Lateral Movement - Warum diese Phase kritisch ist

Durchschnittlicher Ransomware-Angriff - Zeitlinie:

Tag 1:    Initial Access (Phishing, Exploit)
Tag 1-7:  Reconnaissance: Netzwerk kartieren, Credentials sammeln
Tag 2-14: Lateral Movement: von Workstation zu Workstation
Day 7-21: Privilege Escalation: Domain Admin erreichen
Day 14-30: Data Exfiltration + Staging
Day 21-45: Ransomware Deployment (koordiniert auf ALLEN Systemen!)

"Dwell Time": Zeit von Infektion bis Entdeckung
  → Durchschnitt 2024: 16 Tage (Mandiant M-Trends)
  → Median Ransomware: 5 Tage bis Deployment
  → Ransomware Teams warten bis Wochenende/Feierabend!

Lateral Movement verhindern/erkennen:
  → Angreifer kommt sowieso rein (Phishing kann nicht 100% verhindert werden)
  → Ziel: ihn FRÜH entdecken, bevor er kritische Systeme erreicht
  → Blast Radius reduzieren: er kommt rein, aber kann nichts erreichen

Häufige Lateral-Movement-Techniken (MITRE ATT&CK)

T1021.002 - SMB/Windows Admin Shares (PsExec/PsExec-ähnlich):

  Wie es funktioniert:
  Angreifer hat kompromittierte Credentials:
  psexec.exe \\192.168.1.10 -u DOMAIN\admin -p Password123 cmd.exe
  → Vollständige Remote-Shell auf dem Zielsystem

  Erkennungsregel (Splunk SPL):
  EventCode=4624 LogonType=3
  | join User [search EventCode=4648 User=*]
  | where DestinationLogonId != "0x0"
    AND src_ip NOT IN ("10.0.100.0/24")  # Nicht von Management-VLAN
    AND TimeCreated > relative_time(now(), "-1h")

  Prävention:
  → SMB-Zugriff zwischen Workstations blockieren
    Firewall-Regel: Block All → Workstation → Workstation Port 445
  → Restricted Admin Mode: Credentials gehen nicht übers Netz

---

T1003.001 - LSASS Memory Dumping (Credential Access → Lateral Movement):

  Wie es funktioniert:
  1. Angreifer ist auf einem System (z.B. als normaler User)
  2. Dump LSASS: alle eingeloggten User-Credentials!
     Mimikatz: sekurlsa::logonpasswords
     Task Manager: LSASS als Dump-File speichern
  3. Credentials → Pass-the-Hash oder Plaintext-Passwort
  4. Seitwärtsbewegung mit gestohlenen Credentials

  Erkennungsregel (Microsoft Defender KQL):
  DeviceEvents
  | where ActionType == "OpenProcessApiCall"
  | where FileName == "lsass.exe"
  | where InitiatingProcessFileName !in (
      "svchost.exe","wininit.exe","csrss.exe","lsaiso.exe",
      "MsMpEng.exe","services.exe","smss.exe","winlogon.exe"
    )
  | project Timestamp, DeviceName, InitiatingProcessFileName,
    InitiatingProcessCommandLine, AccountName

  Prävention:
  → Windows Credential Guard aktivieren (Kein LSASS-Dump mehr möglich!)
  → Protected Process Light für LSASS:
    Computer Config → Windows Settings → Security Settings →
    Local Policies → Security Options:
    "LSASS auditieren und als geschützten Prozess konfigurieren"
  → Defender Attack Surface Reduction Rule:
    "Block credential stealing from the Windows local security authority subsystem"

---

T1550.002 - Pass-the-Hash (PtH):

  Wie es funktioniert:
  LSASS enthält: NT-Hash des Passworts (nicht Plaintext)
  NT-Hash ist genug für NTLM-Authentifizierung:
  Mimikatz:
  sekurlsa::pth /user:Administrator /ntlm:aad3b435... /run:cmd.exe
  → Shell mit gestohlenen Credentials ohne Passwort zu kennen!

  Erkennungsregel:
  EventCode=4624
  | where LogonType = 3                   # Netzwerk-Login
    AND AuthenticationPackageName = "NTLM" # NTLM (kein Kerberos)
    AND SubjectLogonId = "0x0"            # Kein vorheriger Login
    AND WorkstationName != ""             # Kommt von einem PC
  | stats count by User, WorkstationName, IpAddress
  | where count > 5                       # Mehrere Systeme = Verdacht

  Prävention:
  → Kerberos statt NTLM erzwingen (NTLM in modernen Netzen oft deaktivierbar)
  → Microsoft LAPS: lokale Admin-Passwörter einmalig pro PC
    → Pass-the-Hash für lokalen Admin: nutzlos wenn Passwörter verschieden!

---

T1558.003 - Kerberoasting:

  Wie es funktioniert:
  Kerberos TGS (Service Ticket) kann jeder authentifizierte User anfordern
  TGS ist mit Service Account Passwort-Hash verschlüsselt
  → Offline Brute-Force gegen TGS möglich!

  Ablauf:
  1. Angreifer listet Service Accounts mit SPNs (keine Admin-Rechte nötig):
     setspn -T DOMAIN -Q */*
  2. Für jeden SPN: TGS anfordern
  3. TGS offline cracken: hashcat -m 13100 tgs.hash wordlist.txt
  4. Passwort gefunden → Service Account kompromittiert
     (oft: lokaler Admin oder Domain Admin!)

  Erkennungsregel:
  EventCode=4769
  | where TicketEncryptionType = "0x17"   # RC4 = Kerberoastable!
    AND ServiceName != "krbtgt"
    AND ServiceName !endswith "$"
  | stats count by Account, ServiceName, IpAddress, bin(TimeCreated, 5m)
  | where count > 3                       # Mehrere TGS in kurzer Zeit

  Prävention:
  → Service Accounts: starke, zufällige Passwörter (> 25 Zeichen)
  → Group Managed Service Accounts (gMSA): Windows rotiert Passwort automatisch!
  → AES-Verschlüsselung erzwingen: RC4 (0x17) deaktivieren
  → Privilegierte Service Accounts minimieren

---

T1021.001 - Remote Desktop Protocol (RDP):

  Wie es funktioniert:
  Angreifer nutzt gestohlene Credentials für direktes RDP
  RDP-Verbindungen sind legitim → oft keine Alarme!

  Erkennungsregeln:
  # Neue RDP-Verbindungen zu ungewöhnlichen Zielen:
  DeviceNetworkEvents
  | where RemotePort == 3389
  | where RemoteIPType != "Private"  # RDP nach extern = verdächtig!
  | project Timestamp, DeviceName, RemoteIP, RemotePort

  # RDP von Workstation zu Workstation (unüblich):
  DeviceNetworkEvents
  | where RemotePort == 3389
  | where RemoteIPType == "Private"
  | where not (DeviceName startswith "IT-")  # Nicht IT-Workstations
  | project Timestamp, DeviceName, RemoteIP

  Prävention:
  → RDP nur von Management-VLAN (Firewall-Regel!)
  → RDP Gateway für externe Verbindungen
  → NLA (Network Level Authentication): Authentifizierung vor Session
  → MFA für RDP: Microsoft Entra + NPS Extension

Netzwerksegmentierung als Lateral-Movement-Killer

Ohne Segmentierung vs. Mit Segmentierung:

Ohne Segmentierung:
  PC-VLAN → Server → Datenbank → DC: alles erreichbar!
  Workstation-PC kompromittiert → Angreifer kann alles erreichen

Mit Segmentierung:
  PC-VLAN (10.0.10.0/24):   PCs untereinander: blockiert!
  Server-VLAN (10.0.20.0/24): Server-zu-Server: need-to-know
  DB-VLAN (10.0.30.0/24):    Nur bestimmte Server dürfen DB-Port

Firewall-Regeln für Lateral-Movement-Prävention:

  # Workstation darf KEINE anderen Workstations kontaktieren
  iptables -I FORWARD -s 10.0.10.0/24 -d 10.0.10.0/24 -j DROP

  # Workstation → Server: nur spezifische Ports
  iptables -I FORWARD -s 10.0.10.0/24 -d 10.0.20.0/24 -p tcp \
    --dport 443,80 -j ACCEPT
  iptables -I FORWARD -s 10.0.10.0/24 -d 10.0.20.0/24 -j DROP

  # Server → Datenbank: nur DB-Port, nur spezifische Server
  iptables -I FORWARD -s 10.0.20.10 -d 10.0.30.0/24 -p tcp \
    --dport 5432 -j ACCEPT  # Nur App-Server darf DB
  iptables -I FORWARD -s 10.0.20.0/24 -d 10.0.30.0/24 -j DROP

Microsegmentierung mit Windows Firewall (GPO):
  # Workstations können sich gegenseitig KEINE Admin-Shares öffnen
  Computer Config → Windows Settings → Security Settings →
  Windows Defender Firewall → Inbound Rules:
  Block: File and Printer Sharing (SMB-In) from Workstation-Subnet

Tier-Modell für Active Directory (Microsoft ESAE):
  Tier 0: Domain Controller, PKI (nur Tier-0-Admins)
  Tier 1: Server (nur Tier-1-Admins)
  Tier 2: Workstations, Users
  → Tier-2-Admin kann sich NICHT auf Tier-1-Server einloggen!
  → Kompromittierter Workstation-Admin: kann keinen Server angreifen

SIEM-Erkennungsregeln Zusammenfassung

Prioritäts-Alerts für Lateral Movement:

Alert 1 (KRITISCH): LSASS-Zugriff von unbekanntem Prozess
  → Sofortiger Alert, manuelle Prüfung innerhalb 30 Minuten

Alert 2 (HOCH): Kerberoasting-Muster
  → 3+ TGS-Anfragen für verschiedene Service-Accounts in 5 Min
  → Alert + automatische Blockierung des Source-IPs

Alert 3 (HOCH): PsExec-ähnliche Aktivität
  → psexec64.exe, psexesvc.exe, paexec.exe von nicht-Management-Systemen
  → SIEM-Query: ProcessName in (psexec*, paexec*, smbexec*)

Alert 4 (HOCH): SMB Login von Workstation zu Workstation
  → Netzwerk-Login (Type 3) von Workstation-VLAN zu Workstation-VLAN

Alert 5 (MITTEL): Pass-the-Hash Indikatoren
  → NTLM-Auth + LogonType 3 + viele Systeme in kurzer Zeit

Alert 6 (MITTEL): RDP-Verbindungen zu/von ungewöhnlichen Systemen

Alert 7 (MITTEL): BloodHound-Reconnaissance
  → LDAP-Abfragen mit klassischen BloodHound-Patterns
    (Masse-Enumeration aller User, Groups, ACLs)

Automatische Reaktion (SOAR):
  Level 1 (Alert 1-2): Sofortige Host-Isolation + SOC-Alert
  Level 2 (Alert 3-4): Block Source-IP + SOC-Alert
  Level 3 (Alert 5-7): SOC-Alert + Enrichment automatisch

Lateral Movement zu erkennen bevor kritische Systeme erreicht werden ist der entscheidende Unterschied zwischen einem Incident und einer Katastrophe. AWARE7 hilft beim Aufbau von Erkennungsregeln, führt Lateral-Movement-Tests durch und bewertet Netzwerksegmentierung.

Threat-Detection-Beratung anfragen | Penetrationstest Netzwerk

Nächster Schritt

Unsere zertifizierten Sicherheitsexperten beraten Sie zu den Themen aus diesem Artikel — unverbindlich und kostenlos.

Kostenlos · 30 Minuten · Unverbindlich

Artikel teilen

Über den Autor

Vincent Heinen
Vincent Heinen

Abteilungsleiter Offensive Services

M.Sc. IT-Sicherheit mit über 5 Jahren Erfahrung in offensiver Sicherheitsanalyse. Leitet die Durchführung von Penetrationstests mit Spezialisierung auf Web-Applikationen, Netzwerk-Infrastruktur, Reverse Engineering und Hardware-Sicherheit. Verantwortlich für mehrere Responsible Disclosures.

OSCP+ OSCP OSWP OSWA
Zertifiziert ISO 27001ISO 9001AZAVBSI

Cookielose Analyse via Matomo (selbst gehostet, kein Tracking-Cookie). Datenschutzerklärung