Wir können sehen, dass wir unseren Host vom Computer des Opfers aus erfolgreich anpingen können. Dabei gilt es zu beachten, dass wir nicht nur auf einen Ping beschränkt sind. Jede Betriebssystem-Anfrage ist an diesem Punkt eine mögliche Payload. Jeder Angreifer kann eine Reverse Shell öffnen oder andere Befehle ausführen, die auf dem Host verfügbar sind.

Wie unten dargestellt, haben wir eine effektive Shell auf dem Host.

Die Erkennung von Text4Shell mit Logpoint

Erforderliche Logdaten-Quellen

• Firewall
• – Server mit Apache Commons Text-Bibliothek
  • Sysmon für Linux
  • Auditd
  • Zugriffsprotokolle des Apache-Servers
• Apache läuft unter Windows
  • Native Event-Logdaten
  • Sysmon

Da die Ausnutzung der Schwachstelle die Verwendung einer der oben aufgeführten zusätzlichen Suchmethoden erfordert, können wir nach diesen Funktionen in den URLs suchen, um die Exploit-Versuche zu erkennen.

(url=* OR resource=*) 
| process eval("decoded_resource=urldecode(resource)") 
| process eval("decoded_url=urldecode(url)") 
| rename decoded_resource as resource, decoded_url as url 
| search ( resource IN ["*${script:*","*${url:*","*${dns:*","*script*java.lang.Runtime.getRuntime*"] 
OR url IN ["*${script:*","*${url:*","*${dns:*","*script:*:java.lang.Runtime.getRuntime*"])

Die Erkennung von Aktivitäten nach der Kompromittierung

Neben der Erkennung der Exploit-Versuche ist es äußerst wichtig, Aktivitäten nach der Kompromittierung zu erkennen. Es kann passieren, dass wir die Angriffe aus verschiedenen Gründen nicht erkennen. Daher müssen wir nach Spuren verdächtiger Aktivitäten Ausschau halten, die auf eine Kompromittierung hindeuten können. Hierzu zählen beispielsweise das Spawning einer Shell oder verdächtige ausgehende Verbindungen zu Remote-Hosts. Wir begannen die Suche nach verdächtigen Aktivitäten auf Basis der Hypothese, erste Aktivitäten zur Auskundschaftung von Systeminformationen sowie verdächtige Versuche zur Prozesserstellung und zur Befehlsausführung erkennen zu können.

Nachdem Angreifer eine Reverse Shell oder den Zugang zum System erhalten haben, versuchen sie möglicherweise, Systeminformationen zu erkunden. Dies können wir mit der folgenden Abfrage feststellen:

Für Unix-Systeme, die auditd für das Logging nutzen:

norm_id=Unix "process"=audit (event_type="EXECVE" argument_0 IN ["uname", "uptime"]) 
OR (event_type="PATH" path IN ["/sys/class/dmi/id/bios_version", "/sys/class/dmi/id/product_name", "/sys/class/dmi/id/chassis_vendor", "/proc/scsi/scsi", "/proc/ide/hd0/model", "/proc/version", "/etc/*version", "/etc/*release", "/etc/issue"])     

Für Windows:

label="Process" label=Create ("process"="*\systeminfo.exe" OR command="*net config*") -user IN EXCLUDED_USERS   

Wir können auch nach verdächtigen Prozessen suchen, die in Windows-Systemen erstellt werden. Je nach Umgebung kann es zu False-Positives (Fehlalarmen) kommen, die der Analyst herausfiltern muss.

label="Process" label=Create 
"process" IN ["*\whoami.exe", "*\systeminfo.exe", "*\ipconfig.exe", "*\cmd.exe", "*\powershell.exe", "*\wget.exe", "*\curl.exe", "*\nslookup.exe"] 
-command="cmd.exe /c set" 
| chart count() by host, parent_process, "process", command 

Falls Sie Sysmon auf Linux-Systemen einsetzen, können Sie das Spawning verdächtiger Prozesse wie folgt überwachen:

norm_id=UnixSysmon label="Process" label=Create 
(user="confluence" OR path="*/Atlassian/Confluence/bin") 
image IN ["/usr/bin/uname", "/usr/bin/whoami", "/usr/bin/hostname", "/usr/bin/ip", "/usr/bin/id", "/usr/bin/wget", "/usr/bin/curl", "/usr/bin/ss", "/usr/sbin/iptables", "/usr/bin/bash", "/usr/bin/sh"] 
| chart count() by host, image, command 

Sofortige Abhilfemaßnahmen

Wir empfehlen Administratoren, Apache Commons Text so schnell wie möglich zu überprüfen und auf die neueste Version zu aktualisieren. Analysten sollten auch nach Post-Exploit-Spuren sowie nach verdächtigen Aktivitäten suchen, die im Zusammenhang mit Taktiken stehen, die wir bisher nicht vollständig behandelt haben. Das Logpoint-Team hat bereits Warnungen zur Erkennung verdächtiger Aktivitäten erstellt. Wir raten Analysten, diese Alerts zu nutzen und kontinuierlich nach schadhaften Aktivitäten Ausschau zu halten. Die aktive Suche nach Indikatoren für eine Kompromittierung (IoCs) sowie die Überprüfung verschiedener Hypothesen kann dabei unterstützen, Zero-Day-Schwachstellen aufzudecken. Mit Logpoint SOAR können Analysten die Prozesse der Überwachung, der Erkennung und der Abwehr von Bedrohungen automatisieren.

Wir werden den Blog-Beitrag aktualisieren, sobald sich die aktuelle Situation weiterentwickelt.