von Bhabesh Raj Rai, Associate Security Analytics Engineer
PsExec ist ein kostenfreies, schlankes Tool, das Remote-Systemprozesse ausführen kann und die Interaktivität für Konsolenanwendungen unterstützt. PsExec ist ein wertvolles Werkzeug im Arsenal eines Systemadministrators. Administratoren und SOCs können das Tool nutzen, um interaktive Eingabeaufforderungen auf Remote-Systemen zu starten – ohne Software auf dem Client installieren zu müssen.
Systemadministratoren nutzen PsExec üblicherweise, um Dateien über Netzwerkfreigaben hinweg herunter- oder hochzuladen, oder Befehle, Skripte oder Binärdateien auf Remote-Systemen auszuführen. Was das Tool PsExec jedoch für Systemadministratoren so nützlich macht, macht es auch für Bedrohungsakteure so attraktiv. Sie dürfen nicht vergessen, dass Angreifer sich – getarnt als legitime Systemadministratoren – in Ihrer Umgebung verstecken und aktiv werden können.
Böswillige Entwendung des PsExec Tools
Zahlreiche Bedrohungsakteure haben PsExec bereits verwendet, darunter APT1, menuPass, Turla und Wizard Spider. FIN5, eine finanziell motivierte Bedrohungsgruppierung, verwendet beispielsweise eine abgeänderte Version von PsExec. Auch Ransomware-Betreiber wie Ryuk und Maze nutzen PsExec intensiv für laterale Bewegungen in Netzwerken.
Die Ausführung von PsExec erzeugt viele Events, die verschiedene Sensoren bei korrekter Konfiguration erfassen können. Die generierten Events, auf die es zu achten gilt, sind die Erstellung eines neuen Dienstes, die Authentifizierung am Zielendpunkt über SMB sowie die Erstellung und Verbindung von Named Pipes. Auch Intrustion Detection Systeme (IDS) und Intrustion Prevention Systeme (IPS), wie Snort und Suricata, können PsExec-Aktivitäten im Netzwerk leicht erkennen.
Wir konzentrieren uns darauf, PsExec-Aktivitäten in LogPoint aufzuspüren und die erfolgreiche Ausnutzung einer neu entdeckten Local-Privilege-Escalation-Schwachstelle (Local Privilege Escalation: LPE) aufzudecken.
Die Suche nach PsExec in LogPoint mit Sysmon
In LogPoint können Sie eine PsExec-Suchvorlage nutzen, um einen Überblick über alle zugehörigen Aktivitäten zu erhalten.
Wenn PsExec (oder ein anderes Sysinternals-Tool) zum ersten Mal ausgeführt wird, erstellt es einen neuen Registry-Key auf dem Source-Host, der die Zustimmung des Benutzers zu den Lizenzvereinbarungen (End User License Agreement, EULA) dokumentiert. Diese Registry-Änderung lässt sich sehr einfach in den Registry-Event-Logs von Sysmon erkennen.
norm_id=WindowsSysmon event_id=13 target_object="*EulaAccepted"
| norm on target_object Sysinternals
| chart count() by host, image, tool, target_object
Die Registry-Änderung wird jedoch nur bei offiziellen, von Microsoft freigegebenen PsExec-Versionen durchgeführt, während abgeänderte PsExec-Versionen die Änderung des Registry-Keys umgehen.
Standardmäßig erstellt PsExec auf dem Remote-System einen neuen Dienst mit dem Namen PSEXESVC, der über die Windows-Logdaten zur Erstellung neuer Dienste erkannt werden kann. Hierbei handelt es sich um die Event-IDs 7045 und 4697. Der Unterschied ist, dass letztere die Benutzerkonto-Informationen liefert.
norm_id=WinServer event_id=4697 service=PSEXESVC
| chart count() by host, user, service, file
Der Name des Dienstes kann jedoch über die Befehlszeile geändert werden und das Event allein kann nicht alle Ausführungen von Prozessen mit PsExec vollständig erkennen.
PsExec legt die veränderbare Binärdatei PSEXESVC.exe im SYSTEMROOT-Verzeichnis des Remote-Systems ab, die später von dem neu erstellten Dienst ausgeführt wird. Sie können die Event-Logs zur Erstellung neuer Dateien in Sysmon nutzen, um nach Binär-Informationen im SYSTEMROOT-Verzeichnis zu suchen.
norm_id=WindowsSysmon event_id=11 path="C:Windows" file="*.exe"
| chart count() by host, file, path
Jeder Remote-Befehl, der mit PsExec ausgeführt wird, wird von einem PSEXESVC.exe-Prozess erzeugt, der wiederum von den Windows-eigenen Events für die Prozesserzeugung (Event-ID 4688) erfasst werden kann.
norm_id=WinServer event_id=4688 parent_process="*PSEXESVC.exe"
| chart count() by host, parent_process, "process", command
Eine der wertvollsten Erkennungsmöglichkeiten, die Sysmon bietet, sind die Events für die Erstellung von Pipes (Event-ID 17) und Verbindungen (Event-ID 18).
norm_id=WindowsSysmon event_id IN [17, 18]| chart count() by host, message, pipe order by count() desc
PsExec benötigt viele Pipes für die Ausführung von \psexesvc, wobei der Name einer Pipe geändert werden kann. Die Pipes, die von Interesse sind, haben das Format –<stdin|stdout|stderr>. Die Erkennung einer Pipe-Erstellung oder einer Verbindung, die diesem Format entspricht, ist ein Indikator für die Aktivität von PsExec am Endpunkt.
norm_id=WindowsSysmon event_id IN [17, 18] pipe IN ["*-stdin", "*-stderr", "*-stdout"]| chart count() by host, message, pipe order by count() desc
Wir können ein Widget erstellen, das die wichtigsten Source-Hosts anzeigt, die für die Ausführungen von Prozessen mit PsExec verantwortlich sind.
norm_id=WindowsSysmon event_id IN [17, 18] pipe IN ["*-stdin", "*-stderr", "*-stdout"]| norm on pipe --<:word>-<:'stdin|stdout|stderr'>
| chart count() by source_host order by count() desc
Die Suche nach PsExec in LogPoint ohne Sysmon
Grundsätzlich können die Windows-Audit-Logs für die Dateifreigabe PsExec auch erkennen, wenn Sysmon nicht in der IT-Umgebung eingesetzt wird. Da die grundlegende Überwachung der Dateifreigabe jedoch nicht ausreicht, müssen Benutzer die Überwachung mit der Einstellung „Detaillierte Dateifreigabe“ aktivieren.
Die grundlegende Überwachung der Dateifreigabe (Event-ID 5140) besteht aus einem Benutzernamen, einer Quell-IP und Informationen zum Namen der Dateifreigabe.
norm_id=WinServer event_id=5140
| chart count() by host, user, source_address, share_name
Die wichtigste Erkennungsmöglichkeit besteht darin, das relative Zielfeld mit dem gleichen Format wie der Pipe-Name, der in den Sysmon-Events für die Pipe-Erstellung und Verbindung aufgezeichnet ist, zu vergrößern.
norm_id=WinServer event_id=5145 share_name=IPC$ relative_target IN ["*-stdin", "*-stderr", "*-stdout"]| norm on relative_target --<:word>-<:'stdin|stdout|stderr'>
| chart count() by host, user, source_address, source_host
Um jedoch Impackets Version von PsExec zu erkennen, muss die obige Abfrage leicht modifiziert werden, da das Feld „relative_target“ von Impackets PsExec ein anderes Format verwendet – RemCom_(stdin|stdout|stderr)t*. Beachten Sie auch, dass in PsExec von Impacket die Informationen über den Source-Host verloren gehen.
norm_id=WinServer event_id=5145 share_name=IPC$ relative_target IN ["RemCom_stdint*", "RemCom_stderrt*", "RemCom_stdoutt*"]| chart count() by host, user, source_address
Falls Sie IDS oder IPS nutzen, können Sie nach einer Signatur-Übereinstimmung suchen, um die Netzwerkaktivität von PsExec zu erkennen.
IDS- und IPS-Erkennung
Sie müssen nach einer IDS- oder IPS-Signatur-Übereinstimmung suchen, die die Netzwerkaktivitäten von PsExec abdeckt.
(norm_id=Snort OR norm_id=SuricataIDS) message IN ["Remote Service Control Manager Access*", "PsExec service created*",
"SMB2 NT Create AndX Request For an Executable File*", "Executable File Transfer*"]
Erkennung eines Local-Privilege-Escalation-Exploits über PsExec
Am 9. Dezember entdeckte David Wells, ein Forscher bei Tenable Security, eine LPE-Schwachstelle in PsExec, die es einem Nicht-Administrator-Prozess ermöglicht, zu „SYSTEM“ zu eskalieren. Die Sicherheitslücke wurde in der zuletzt veröffentlichten PsExec-Version 2.3 behoben.
Es ist einfach, die erfolgreiche Ausnutzung der Schwachstelle zu erkennen. Suchen Sie nach der Erstellung eines untergeordneten Prozesses bzw. Kindprozesses von PSEXESVC.exe mit dem Integritätslevel „SYSTEM“.
norm_id=WindowsSysmon event_id=1 integrity_level=SYSTEM parent_image="C:WindowsPSEXESVC.exe"
Sie können die folgende Abfrage und Befehlszeilenoption verwenden, um zu erkennen, wann die abgelegte Binärdatei umbenannt wird:
norm_id=WindowsSysmon event_id=1 integrity_level=SYSTEM parent_image="C:Windows*.exe" -parent_image="C:WindowsSystem32*.exe"
| chart count() by user, image, parent_image
Erkennung von PsExec mit den Regeln zur Reduzierung der Angriffsfläche
Die Regeln zur Reduzierung der Angriffsfläche oder „Defender’s Attack Surface Reduction Rules” (ASR) sind eine der Hauptfunktionen des Schutzpakets „Windows Defender Exploit Guard“. Ziel dabei ist es, bestimmtes Verhalten von schadhaften Makros oder verdächtigen Skripts, die von Malware genutzt werden, um Geräte zu infizieren, zu erkennen und zu stoppen. Defender verfügt über eine ASR-Regel mit dem Namen „Block Process Creations originating from PSExec and WMI Commands“. Ist diese Regel aktiviert, blockiert Defender die Ausführung von Prozessen über PsExec und es wird ein Event (Event-ID 1121) mit einem GUID (Globally Unique Identifier, globalen eindeutigen Bezeichner) der Regel erzeugt.
norm_id=WinServer event_id=1121 id="D1E49AAC-8F56-4280-B9BA-993A6D77406C" -process_name IN ["*wmic.exe", "*wmiprvse.exe"]| chart count() by host, file, path, process_name
Die Aktivierung der ASR-Regel im Windows Defender Exploit Guard blockiert die Ausführung von Prozessen, die über PsExec erstellt wurden, und erzeugt ein entsprechendes Event.
Nutzen Sie mehrere Erkennungsmethoden für eine vollständige Abdeckung
Als Sicherheitsverantwortliche haben Sie verschiedene Möglichkeiten, PsExec zu erkennen. Fortschrittliche Bedrohungsakteure manipulieren jedoch die Befehlszeilenparameter, um eine schnelle Erkennung zu vermeiden, indem sie auf einen Dienst oder eine Binärdatei verweisen. Wir empfehlen, mehrere Erkennungsverfahren einzusetzen, um eine vollständige Abdeckung zu erreichen.
In der aktuellen Bedrohungslandschaft ist Ransomware weit verbreitet. Die Erkennung von PsExec-Aktivitäten kann mögliche Ryuk-, Maze- oder andere Ransomware-Bedrohungen in einem Unternehmen verhindern. Wir empfehlen Systemadministratoren, für ihre Administrationsaufgaben von PsExec zu PowerShell Remoting zu wechseln und alle PsExec-Aktivitäten in ihrer IT-Umgebung als potenziell schadhaft zu betrachten.
