Web Shell erkennen: die Hintertür im Webserver

Ein Webserver ist von außen erreichbar und läuft rund um die Uhr - ein idealer Ankerpunkt für einen Angreifer, der bleiben will. Eine Web Shell nutzt genau das: eine kleine serverseitige Skriptdatei, abgelegt im Verzeichnis des Webservers, nimmt über ganz normale Web-Anfragen Befehle entgegen und führt sie auf dem Server aus. Es braucht keinen neuen Dienst, keinen Autostart-Schlüssel und keine Anmeldung; der Zugang versteckt sich im regulären Web-Verkehr. Genau deshalb ist die Web Shell so beliebt und zugleich am Endpunkt erkennbar. Dieser Beitrag bleibt auf der Erkennungsseite und zeigt, woran sich eine Web Shell verrät, nicht, wie man eine schreibt.

Was der Angreifer tut

Der Weg zur Web Shell folgt - auf der Ebene des Prinzips, nicht als Anleitung - einigen wiederkehrenden Schritten, die alle auf dem Server Spuren hinterlassen:

• Die Datei ablegen. Eine serverseitige Skriptdatei - etwa aspx, php oder jsp - landet im Web-Verzeichnis, oft über eine Schwachstelle der Anwendung oder einen gekaperten Upload.
• Über das Web ansprechen. Der Angreifer ruft die Datei wie eine normale Seite auf und übergibt Befehle als Parameter - unauffällig im HTTP-Verkehr.
• Befehle ausführen. Die Web Shell reicht die Befehle an das Betriebssystem weiter; der Webserver-Prozess startet dafür eine Befehlsshell.
• Bleiben. Solange die Datei liegt, bleibt der Zugang bestehen - unabhängig von Neustarts, ohne Dienst und ohne Autostart-Eintrag.

Für die Erkennung ist entscheidend: Zwei Momente sind sichtbar. Erst entsteht eine Skriptdatei dort, wo sie nicht hingehört, dann führt der Webserver etwas aus, das er normalerweise nie tut. Nicht die Web-Anfrage ist der erste Ansatzpunkt, sondern die Datei und der Prozess.

Welche Logquellen die Technik zeigt

• Datei-Telemetrie zuerst. Sysmon Event 11 zeigt, wenn eine Skriptdatei im Web-Verzeichnis entsteht - der erste und oft einzige Vorlauf vor der Ausführung.
• Prozess-Telemetrie. Event 4688 zeigt, wenn ein Webserver-Prozess wie w3wp eine Befehlsshell startet - das verlässlichste Signal einer aktiven Web Shell.
• Eltern-Kind-Beziehung. Entscheidend ist, wer das Kind startet: Ein Webserver als Elternteil von cmd oder PowerShell ist im Normalbetrieb kaum zu erklären.
• Werkzeug-Kontext. cmd und PowerShell sind mitgelieferte Programme; erst der ungewöhnliche Elternprozess macht den Unterschied. Grundlagen zum Missbrauch solcher Bordmittel unter Living off the Land.

Das Muster im Log

Drei Signale tragen. Das erste ist eine neue aspx-, ashx- oder asp-Datei unterhalb von inetpub, also im IIS-Verzeichnis. Das zweite ist eine neue php- oder jsp-Datei in einem Web-Verzeichnis wie wwwroot, htdocs oder webapps. Das dritte und stärkste ist ein Webserver-Prozess, der eine Befehlsshell startet. Die beiden Datei-Signale stehen auf mittlerer Stufe, weil auch reguläre Deployments neue Skriptdateien schreiben; das Prozess-Signal steht auf hoher Stufe, weil ein Webserver als Elternteil von cmd oder PowerShell kaum je legitim ist. Entscheidend ist der Kontext: Legitime Dateitreffer stammen von bekannten Deploy-Konten, Pfaden und Zeitfenstern. Auffällig wird es, wenn eine Skriptdatei außerhalb eines Deployments auftaucht, von einem untypischen Konto geschrieben wird oder kurz darauf der Webserver eine Shell startet. Die Kette aus Dateiablage und anschließender Shell ist das eigentliche Signal.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Signale: die abgelegte IIS-Datei, die abgelegte PHP- oder JSP-Datei und den Webserver, der eine Shell startet. Die ersten beiden werten Datei-Telemetrie aus, die dritte die Prozess-Telemetrie.

1. Mögliche Web Shell im IIS-Verzeichnis (T1505.003). Eine aspx-, ashx-, asmx- oder asp-Datei unterhalb von inetpub. Wegen der Deployments auf level: medium.

title: Moegliche Web Shell im IIS-Verzeichnis abgelegt
id: 3d7a1c84-2e65-4b91-a7f2-6c9b4d8e3a17
status: experimental
description: |
  Erkennt das Schreiben einer serverseitigen Skriptdatei (aspx, ashx, asmx, asp) unterhalb von inetpub.
  Angreifer legen dort Web Shells ab, um ueber den Webserver dauerhaft Befehle auszufuehren
  (Server Software Component: Web Shell). Nicht jede neue Datei ist boesartig, der Ort und der Zeitpunkt
  ausserhalb eines Deployments machen den Unterschied.
references:
  - https://attack.mitre.org/techniques/T1505/003/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  product: windows
  category: file_event
detection:
  sel_dir:
    TargetFilename|contains: '\inetpub\'
  sel_ext:
    TargetFilename|endswith:
      - '.aspx'
      - '.ashx'
      - '.asmx'
      - '.asp'
  condition: sel_dir and sel_ext
falsepositives:
  - Regulaere Anwendungs-Deployments schreiben neue Skriptdateien - bekannte Deploy-Konten, Pfade und Zeitfenster als Baseline ausnehmen
level: medium

2. Mögliche Web Shell in einem Web-Verzeichnis (T1505.003). Eine php- oder jsp-Datei in wwwroot, htdocs oder webapps. Ebenfalls level: medium.

title: Moegliche Web Shell in einem Web-Verzeichnis abgelegt
id: 8c2e6a35-4b93-4d57-b2f1-5a7c9d3e6b40
status: experimental
description: |
  Erkennt das Schreiben einer PHP- oder JSP-Datei in ein typisches Web-Verzeichnis (wwwroot, htdocs,
  webapps, www). Angreifer legen so Web Shells fuer Apache, Tomcat oder PHP ab, um ueber den Webserver
  persistenten Zugriff zu behalten (Server Software Component: Web Shell).
references:
  - https://attack.mitre.org/techniques/T1505/003/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  product: windows
  category: file_event
detection:
  sel_dir:
    TargetFilename|contains:
      - '\wwwroot\'
      - '\htdocs\'
      - '\webapps\'
      - '\www\'
  sel_ext:
    TargetFilename|endswith:
      - '.php'
      - '.jsp'
      - '.jspx'
      - '.war'
  condition: sel_dir and sel_ext
falsepositives:
  - Regulaere Anwendungs-Deployments und Updates - bekannte Deploy-Konten, Pfade und Zeitfenster als Baseline ausnehmen
level: medium

3. Webserver-Prozess startet eine Befehlsshell (T1505.003). w3wp, httpd oder tomcat als Elternteil von cmd oder PowerShell. Wegen der Eindeutigkeit auf level: high.

title: Webserver-Prozess startet eine Befehlsshell
id: 5a3d9c74-6e82-4b16-a1f7-3c8b4d7e2a58
status: experimental
description: |
  Erkennt, wenn ein Webserver-Arbeitsprozess (w3wp, httpd, php-cgi, tomcat) eine Befehlsshell wie cmd oder
  PowerShell startet. Das ist das klassische Merkmal einer aktiven Web Shell: Der Webserver fuehrt
  ueber die abgelegte Datei Betriebssystembefehle aus (Server Software Component: Web Shell).
references:
  - https://attack.mitre.org/techniques/T1505/003/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  product: windows
  category: process_creation
detection:
  sel_parent:
    ParentImage|endswith:
      - '\w3wp.exe'
      - '\httpd.exe'
      - '\php-cgi.exe'
      - '\tomcat.exe'
      - '\tomcat9.exe'
  sel_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
  condition: sel_parent and sel_child
falsepositives:
  - Manche Webanwendungen starten legitim Hilfsprozesse - bekannte Anwendungen und Aufrufmuster als Baseline ausnehmen
level: high

Härtung: der Angriff, der ins Leere läuft

• Schreibrechte im Web-Verzeichnis trennen. Das Konto, unter dem der Webserver läuft, darf in seinem eigenen Inhaltsverzeichnis möglichst nicht schreiben dürfen; Deployments laufen über getrennte Konten und Pfade.
• Uploads einschränken. Hochgeladene Dateien gehören in ein Verzeichnis ohne Skriptausführung; Dateityp und Ziel streng prüfen.
• Prozessstart überwachen. Den Start einer Befehlsshell durch einen Webserver-Prozess zuverlässig erfassen (Event 4688 mit Command-Line-Auditing oder Sysmon) - das ist das stärkste Signal.
• Anwendung aktuell halten. Die meisten Web Shells kommen über eine bekannte Schwachstelle der Webanwendung; zügiges Patchen nimmt dem Angriff den Weg hinein.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem Testserver mit aktivem Sysmon und Command-Line-Auditing:

• Für Regel 1 eine harmlose aspx-Testdatei unterhalb von inetpub ablegen und prüfen, dass Sysmon Event 11 sie zeigt und die Regel greift.
• Für Regel 2 eine php-Testdatei in ein Web-Verzeichnis schreiben und kontrollieren, dass die Regel anspringt.
• Für Regel 3 eine Test-Web-Shell lokal ein harmloses Kommando ausführen lassen und prüfen, dass der Webserver-Prozess als Elternteil der Shell erkannt wird.
• Breiter wird der Test mit den Fällen zu T1505.003 aus Atomic Red Team.

Fehlalarme und Tuning

• Deployments. Reguläre Anwendungs-Updates schreiben neue Skriptdateien ins Web-Verzeichnis. Die bekannten Deploy-Konten, Pfade und Zeitfenster als Baseline aufnehmen, bevor alarmiert wird.
• Datei-Signale staffeln. Eine neue Skriptdatei allein ist schwach; in Kombination mit einem untypischen schreibenden Konto oder einem Treffer außerhalb des Deploy-Fensters wird sie belastbar.
• Webanwendungen mit Hilfsprozessen. Einzelne Anwendungen starten legitim Hilfsprozesse; solche bekannten Aufrufmuster bei Regel 3 als Baseline ausnehmen, den Rest aber immer untersuchen.
• Kette schlägt Einzelzeile. Eine abgelegte Skriptdatei, gefolgt von einem Webserver, der eine Shell startet, ist weit aussagekräftiger als ein Treffer allein - die Korrelation schärft die Bewertung.

Fazit

Die Web Shell ist eine der leisesten Formen von Persistenz: eine unscheinbare Skriptdatei im Webserver, die über ganz normale Web-Anfragen Befehle entgegennimmt - ohne Dienst, ohne Autostart, ohne Anmeldung. Gerade weil der Zugang in der Webanwendung steckt, ist er am Endpunkt an zwei Stellen sichtbar: wenn die Datei ins Web-Verzeichnis geschrieben wird und wenn der Webserver-Prozess eine Befehlsshell startet. Die verlässlichen Signale sind die abgelegte Skriptdatei in inetpub oder wwwroot und vor allem der Webserver als Elternteil von cmd oder PowerShell. Weil Deployments dieselben Dateien schreiben, liegt die Stärke in der Abgrenzung: Konto, Pfad, Zeit und die Verkettung entscheiden. Die wirksamste Härtung ist, dem Webserver das Schreiben im eigenen Inhaltsverzeichnis zu nehmen und die Anwendung aktuell zu halten. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Persistence.