CyberDefenders: PsExec Hunt Lab

[!ABSTRACT] Fallbeschreibung: PsExec Hunt

Link zum Lab: CyberDefenders - PsExec Hunt

Szenario-Übersicht:

Ein Intrusion Detection System (IDS) hat Alarm geschlagen: Es wurden Anzeichen für Lateral Movement mittels PsExec im internen Netzwerk entdeckt. PsExec ist ein legitimes Administrations-Tool von Sysinternals, das jedoch häufig von Angreifern missbraucht wird, um remote Befehle auf anderen Systemen auszuführen und sich privilegierten Zugriff zu verschaffen.

Analyseschwerpunkte:

• Identifizierung des Entry-Points: Ermittlung des Ursprungssystems, von dem die PsExec-Aktivität ausging.
• Targeting-Analyse: Bestimmung der Zielrechner innerhalb der kompromittierten Umgebung.
• Beweissicherung: Untersuchung des PCAP-Files auf kritische Indikatoren (IoCs) wie SMB-Authentifizierungen, Dateiübertragungen (Binaries) und Service-Installationen.
• Schadensausmaß: Feststellung, wie weit sich der Angreifer bereits lateral bewegen konnte und welche Ziele verfolgt wurden.

Ziel der Untersuchung:

Als SOC-Analyst besteht die primäre Aufgabe darin, die Taktiken, Techniken und Ziele des Angreifers im Rahmen des lateralen Ausbreitungsversuchs lückenlos zu rekonstruieren. Die forensische Beweissicherung im Netzwerkverkehr dient dazu, das exakte Schadensausmaß sowie den initialen Entry-Point zu isolieren. Dies bildet das fundamentale Fundament, um eine vollständige Eindämmung (Containment) und nachhaltige Bereinigung (Eradication) des Vorfalls zu ermöglichen, sowie strategische Governance-Vorgaben für das Härten der Active-Directory-Infrastruktur abzuleiten. >

Management Summary

• Vorfallsart: Lateral Movement via PsExec.
• Impact: Kompromittierung von Sales- und Marketing-Segmenten.
• Kernursache: Fehlende Netzsegmentierung & privilegierte Überberechtigung.
• Top-Empfehlung: Implementierung von Tier-Modell & Application Whitelisting.

Toolset

• Wireshark

Untersuchungsbericht

1. Initial Triage & Identifizierung

• Analyse des Netzverkehrs: Über Statistics > Conversations wurde ein ungewöhnlich hohes Verkehrsaufkommen identifiziert, das von einer spezifischen internen IP ausging.

Abbildung 1: Identifizierung der verdächtigen Quell-IP durch das höchste Verkehrsaufkommen (Paketanzahl und Byte-Volumen)

• Identifizierung des Quellsystems: Durch die Filterung auf die verdächtige Quell-IP und smb2 wurde in Paket 131 eine NTLMSSP-Authentifizierung sowie Hinweise auf DCE/RPC-Kommunikation gefunden.

Abbildung 2: Identifizierung des Ziel-Hostnamens innerhalb der SMB-Session-Details

• Hostname-Ermittlung: Die Analyse von DCE/RPC-Paketen (Response des Ziel-Hosts) bestätigte den Namen des ersten betroffenen Rechners: <details><summary>Anzeigen</summary>Sales-PC</details>
• Benutzer-Kontext: Unmittelbar auf die Authentifizierung folgend (Paket 132) wurde der spezifische Benutzer-Account bestätigt, den der Angreifer für den Zugriff missbrauchte: <details><summary>Anzeigen</summary>ssales</details>

2. Deep Dive Analysis & Lateral Movement Artefakte

• Malware-Deployment: Dem SMB2-Stream folgend wurde in Paket 144 der Transfer eines verdächtigen Executables detektiert, welches typisch für Remote-Service-Installationen ist.

Abbildung 3: Nachweis der Dateiübertragung eines Service-Executables via SMB2 Write-Request

• Share-Analyse: Der SMB2-Header von Paket 144 belegt präzise, welcher administrative Share für die Platzierung des Dienstes im Windows-Verzeichnis genutzt wurde. Der Nachweis erfolgt hierbei nicht allein über den Pfadnamen, sondern technisch fundiert über die im Header hinterlegte Tree ID. Diese ID verknüpft die Dateioperation eindeutig mit der zuvor etablierten Verbindung zum administrativen Share, was die unbefugte Nutzung privilegierter Zugänge zweifelsfrei dokumentiert.
• Kommunikations-Kanal: Die Rekonstruktion ergab, dass bereits ab Paket 134 ein spezieller Share für die Inter-Prozess-Kommunikation und Named Pipes verwendet wurde.

3. Pivot-Analyse (Ausweitung)

• Sekundäre Ziele: Eine erweiterte Suche nach weiterer Kommunikation der Angreifer-IP deckte eine Interaktion mit einer weiteren internen IP auf: <details><summary>Anzeigen</summary>10.0.0.131</details>
• Zweites Zielsystem: Die Untersuchung des DCE/RPC-Traffics in Paket 38742 identifizierte ein zweites Opfer des Lateral Movement.

Abbildung 4: Analyse der NTLMSSP-Challenge zur Identifizierung der lateralen Ausweitung auf einen weiteren Abteilungsrechner

Flag-Antworten

Die Lösungen sind als Spoiler markiert, um den Lerneffekt nicht zu gefährden.

Rekonstruktion (Post-Mortem)

Zusammenfassende Darstellung des Vorfalls basierend auf den gefundenen Beweisen.

Incident Timeline

• T0 (Initialer Zugriff): Der Angreifer authentifiziert sich erfolgreich via SMB/NTLMSSP am ersten Zielsystem.
• T1 (Dienst-Installation): Aufbau einer Verbindung zum administrativen Share und Transfer des PsExec-Binaries zur Remote-Ausführung.
• T2 (Command & Control / IPC): Kommunikation über Named Pipes zur Steuerung des Remote-Dienstes.
• T3 (Lateral Movement / Pivot): Ausweitung des Angriffs vom ersten kompromittierten System auf weitere Abteilungsrechner.

Zusammenfassung

Der Angriff demonstriert eine klassische Lateral Movement Kette. Der Angreifer nutzte kompromittierte Zugangsdaten, um sich mittels PsExec innerhalb der Windows-Umgebung von der Sales-Abteilung bis in die Marketing-Abteilung vorzuarbeiten. Besonders kritisch war hierbei die Verwendung administrativer Standard-Shares, die eine schnelle Ausbreitung ermöglichten.

Lessons Learned & GRC-Transfer

[!IMPORTANT] Transferleistung für Audit & Consulting Die folgenden Analysen sind für die Lösung des CTFs nicht zwingend erforderlich. Sie dienen der Vertiefung und zeigen auf, wie technische Befunde in strategische Handlungsempfehlungen für das IT-Audit und Security Consulting übersetzt werden.

1. Technische & Tooling-Erkenntnisse (Die forensische Ebene)

Entscheidende Artefakte: Der primäre Hebel zur Rekonstruktion des Lateral Movement lag in der Analyse der SMB2-Protokollstruktur. Der Nachweis des Malware-Deployments erfolgte hierbei nicht allein über den Dateinamen, sondern forensisch fundiert über die im SMB2-Header hinterlegte Tree ID in Paket 144. Diese ID verknüpfte die schreibende Dateioperation (PSEXESVC.exe) zweifelsfrei mit der unbefugten Nutzung des administrativen Shares.

Effektive Wireshark-Filter: Für die proaktive Jagd (Threat Hunting) nach verdeckten PsExec-Aktivitäten im Netzwerk sind folgende Filter-Profile im SOC zu hinterlegen:

• smb2.share_ca == "ADMIN$" (Isoliert gezielt Zugriffe auf den administrativen Remote-Installations-Share).
• smb2.filename matches ".*SVC.*" oder dcerpc.cn_bind_to_uuid == "367abb81-9844-35f1-ad32-98f038001003" (Identifiziert den DCE/RPC-Handshake, den PsExec zur Steuerung des Remote-Dienstes erzwingt).

Tooling-Herausforderungen: Die netzwerkbasierte Triage liefert zwar unumstößliche Beweise für den Transport des Binaries, stößt jedoch an ihre Grenzen, sobald Angreifer modifizierte oder umbenannte PsExec-Derivate nutzen. Um die Erkennungslücke zu schließen, ist eine Korrelation der Netzwerk-Pakete mit den lokalen Host-Artefakten (z. B. dem Registry-Schlüssel HKCU\Software\Sysinternals\PsExec) zwingend erforderlich.

2. Prozessuale & Organisatorische Optimierung (Die Verteidigungsebene)

Frühzeitige Kill-Chain-Unterbrechung: Der Angriff hätte bereits in der Rechte-Emanations-Phase (T0) isoliert werden müssen. Eine restriktive Rechtevergabe hätte dem Account des ersten kompromittierten Systems den Zugriff verweigern müssen, noch bevor eine Verbindung zu den administrativen Ressourcen aufgebaut werden konnte.

Host-Segmentierung & Härtung: Die flache Netzwerkhierarchie erlaubte ein ungehindertes Überspringen vom ersten kompromittierten System auf einen weiteren Host. Prozessual ist eine strikte Mikrosegmentierung und Host-basierte Firewall-Richtlinie zu implementieren, die eine direkte Kommunikation über SMB (Port 445) zwischen Client-Workstations untereinander (Client-to-Client Isolation) konsequent unterbindet. Das Sicherheitskonzept muss der Maxime folgen, den "Cost-of-Attack" durch interne Barrieren zu maximieren.

Incident-Response-Prozess: Das Monitoring darf Vorfälle dieser Art nicht erst während der lateralen Ausbreitung detektieren. Der IR-Prozess ist so zu optimieren, dass der automatisierte Zugriff auf administrative Freigaben durch Nicht-Admin-Accounts eine sofortige, isolierende Reaktion auf dem Endpunkt auslöst.

3. Strategische GRC-Analyse (Die Governance-Ebene)

Governance (Steuerung & Richtlinien): Die Auswahl der im Netzwerk eingesetzten Werkzeuge darf nicht der individuellen Präferenz der Administratoren überlassen werden. Es ist eine verbindliche Richtlinie zur Nutzung von administrativen Werkzeugen einzuführen, inklusive einer offiziellen Positivliste (Whitelisting). Für die temporäre Nutzung von Spezialwerkzeugen außerhalb des Standards ist ein strikter Change-Management-Prozess zu etablieren.

Risk (Risikomanagement): Der Vorfall dokumentiert ein eklatantes Defizit im Identity and Access Management (IAM). Der Missbrauch eines Kontos zeigt, dass „Dual-Use“-Tools wie PsExec im Risikoregister als kritisches Risiko für unbefugte Privilegienausweitung geführt werden müssen. Das Risikomanagement muss regelmäßige Bedrohungsszenarien für die Kompromittierung administrativer Standard-Shares (ADMIN$, C$) vorschreiben.

Compliance (Einhaltung & Kontrolle): Zur technischen Durchsetzung der Governance-Vorgaben ist Application Whitelisting (z. B. via WDAC oder AppLocker) zu implementieren, um die Ausführung nicht autorisierter Binaries im Keim zu ersticken. Aus Audit-Sicht ist die kontinuierliche Überwachung von Event-IDs wie 4697 (Dienstinstallation) und 5145 (Share-Zugriff) im SIEM zu verankern, um die Einhaltung der ISO/IEC 27001 Controls bezüglich des Zugriffsschutzes (A.9) und der Betriebssicherheit (A.12) nachzuweisen.