Schwachstellen zur Fern-Codeausführung können es einem Angreifer ermöglichen, von einer verwundbaren Anwendung in das Betriebssystem vorzudringen, das sie hostet. Obwohl die ursprüngliche Schwachstelle von Produkt zu Produkt unterschiedlich sein kann, erzeugt die Aktivität nach der Ausnutzung oft ähnliche Prozessbeziehungen, die Verteidiger überwachen können.

Ein besonders nützliches Signal ist ein Anwendungs- oder Webserver-Prozess, der unerwartet eine Befehls-Shell, einen Skript-Interpreter oder ein Systemprogramm startet. Unter Windows lässt sich so der Punkt erkennen, an dem die Ausnutzung der Anwendung zur Ausführung auf dem Host wird.

Von der Ausnutzung von Webanwendungen zu Systembefehlen

Die Erkennung konzentriert sich auf serverseitige Prozesse wie IIS, WSUS, Tomcat, Java, Apache, Nginx, PHP und Node.js. Diese Prozesse weisen normalerweise vorhersehbare Ausführungsmuster auf. Wenn sie beginnen, Kindprozesse wie cmd.exe, powershell.exe, pwsh.exe, wscript.exe, mshta.exe, rundll32.exe, certutil.exe, bitsadmin.exe oder curl.exe zu erzeugen, verdient die Aktivität eine Untersuchung.

Die Quelle bringt dieses Verhalten mit RCE in SharePoint, WSUS, IIS-gehosteten Anwendungen, SAP unter Windows, Web-Management-Konsolen und Schwachstellen im Zusammenhang mit Deserialisierung oder dem Hochladen von Dateien in Verbindung.

Eine verdächtige Prozesskette kann so aussehen:

w3wp.exe → powershell.exe

oder:

java.exe → cmd.exe

Die Prozessbeziehung allein ist kein Beweis für eine Kompromittierung, kann aber darauf hindeuten, dass eine serverseitige Anwendung begonnen hat, Befehle außerhalb ihres normalen Anwendungsablaufs auszuführen.

Erkennungsabfrage

data.win.system.eventID:1 and data.win.eventdata.parentImage:(*\w3wp.exe or *\wsusservice.exe or *\tomcat*.exe or *\java.exe or *\httpd.exe or *\nginx.exe or *\php-cgi.exe or *\php.exe or *\node.exe) and data.win.eventdata.image:(*\cmd.exe or *\powershell.exe or *\pwsh.exe or *\wscript.exe or *\cscript.exe or *\mshta.exe or *\rundll32.exe or *\regsvr32.exe or *\certutil.exe or *\bitsadmin.exe or *\curl.exe)

Die Quelle verzeichnete 15,523 Treffer in den vorangegangenen 30 Tagen.

Warum die Anzahl der Ergebnisse wichtig ist

Eine hohe Trefferzahl bedeutet nicht automatisch, dass Tausende von Angriffen stattgefunden haben. Anwendungsserver führen mitunter aus legitimen betrieblichen Gründen Skripte oder Befehlszeilenwerkzeuge aus. Java-Anwendungen können Shell-Befehle aufrufen, Node.js-Anwendungen können Befehlsinterpreter starten, und IIS-gehostete Systeme können administrative Skripte ausführen.

Aus diesem Grund eignet sich diese Abfrage gut als Ausgangspunkt für das Threat Hunting. Das erste Ziel sollte sein zu verstehen, welche Kombinationen aus übergeordnetem und untergeordnetem Prozess das Volumen erzeugen.

Nützliche Gruppierungen sind:

• übergeordneter Prozess;

• untergeordnetem Prozess;

• Rechnername;

• Dienstkonto oder Benutzer;

• Befehlszeile;

• Ausführungspfad;

• Häufigkeit.

Stammen die meisten Ereignisse von einem bekannten Anwendungsserver, der wiederholt dasselbe genehmigte Skript startet, lässt sich dieses Verhalten dokumentieren. Ein seltenes Ereignis w3wp.exe → powershell.exe auf einem aus dem Internet erreichbaren Server kann jedoch eine sofortige Untersuchung rechtfertigen.

Verdächtige Ereignisse untersuchen

Die Befehlszeile ist eines der wichtigsten Felder für die Prüfung. Ein bekanntes administratives Skript hat ein ganz anderes Risikoprofil als ein unerwarteter kodierter PowerShell-Befehl, eine externe Download-URL oder ein Befehl, der eine Ermittlung durchführt.

Analysten sollten auch die Aktivität unmittelbar vor und nach dem Ereignis der Prozesserstellung prüfen. Nützliche Fragen sind:

• Hat die Anwendung vor dem Start des Prozesses ungewöhnliche Anfragen erhalten?

• Hat der untergeordnete Prozess weitere Prozesse erstellt?

• Hat er Dateien in temporäre oder Anwendungsverzeichnisse geschrieben?

• Hat er ausgehende Netzwerkverbindungen aufgebaut?

• Hat er Sicherheitseinstellungen oder Persistenzmechanismen verändert?

• Gab es ähnliche Aktivitäten auf anderen Systemen?

Je stärker die Belege im Umfeld sind, desto mehr Vertrauen kann das SOC in die Erkennung setzen.

Die Erkennung abstimmen

Die Erkennung sollte sorgfältig abgestimmt werden. Pauschale Ausnahmen wie das Ignorieren jedes Ereignisses java.exe → cmd.exe oder w3wp.exe → powershell.exe könnten wertvolle Sicherheitstransparenz beseitigen.

Besser ist es, eng gefasste Ausnahmen mit Kombinationen wie den folgenden anzulegen:

bekannter Host + bekannter Prozesspfad + bekannte Befehlszeile + bekanntes Dienstkonto

So bleibt die verhaltensbasierte Erkennung erhalten, während das erwartete operative Rauschen sinkt.

Von der Regel für das Threat Hunting zur Erkennungsregel

Sobald die normale Aktivität in der Umgebung verstanden ist, kann dieselbe Abfrage in einen präziseren Alarm überführt werden. Hochwertige Varianten können sich auf seltene Beziehungen zwischen übergeordneten und untergeordneten Prozessen, unerwartete Hosts, ungewöhnliche Befehlszeilen, externe Downloads oder die Ausführung aus benutzerschreibbaren Speicherorten konzentrieren.

Das Grundprinzip ist einfach: Web- und Anwendungsdienste sollten sich nicht unerwartet wie interaktive Benutzer verhalten. Die Überwachung des Moments, in dem sie beginnen, Shells oder Systemwerkzeuge zu starten, kann ein wertvolles Signal für die Erkennung von RCE und Aktivität nach der Ausnutzung liefern.