Exploit Public-Facing Application erkennen: die Web-Shell im Blick

Am Anfang vieler Einbrüche steht kein Phishing, sondern eine verwundbare Anwendung am Rand des Netzes: ein ungepatchtes CMS, ein exponiertes Admin-Portal, eine Lücke in einer Webanwendung. Der Angreifer nutzt sie aus und führt Code im Kontext des Webservers aus - der erste Schritt ins Innere, neben dem Weg über Mark of the Web und HTML-Smuggling. Die Schwachstelle selbst sieht ein SOC selten; was es sieht, ist das, was danach passiert. Genau dort setzt die Erkennung an: Ein Webserver, der plötzlich eine Shell startet, verrät den Einbruch. Dieser Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.

Was der Angreifer tut

Die Ausnutzung einer öffentlichen Anwendung läuft auf der Ebene des Prinzips, nicht als Anleitung, in wenigen Schritten ab:

• Schwachstelle ausnutzen. Eine Lücke in Webserver, Framework oder Anwendung erlaubt es, eigenen Code im Kontext des Server-Prozesses auszuführen.
• Web-Shell ablegen. Eine kleine Skript-Datei (.aspx, .php, .jsp) wird im Webroot abgelegt und nimmt fortan Befehle über das Web entgegen.
• Befehle ausführen. Über die Web-Shell startet der Angreifer Shells und Erkundungswerkzeuge - als Kind des Webserver-Prozesses.
• Fuß fassen. Von hier aus folgen Erkundung, Rechteausweitung und die Bewegung ins Netz; der Webserver ist der Brückenkopf.

Für die Erkennung ist entscheidend: Der Exploit selbst bleibt oft unsichtbar, aber seine Folgen stehen in der Prozess- und Datei-Telemetrie - ein Server-Prozess als Elternteil einer Shell und eine frische Skript-Datei im Webroot. Genau daran setzen die Regeln an.

Welche Logquellen die Technik zeigt

• Prozess-Telemetrie. Event 4688 und Sysmon Event 1 zeigen den Elternprozess - w3wp, httpd, nginx, php oder sqlservr - und das gestartete Kind samt Kommandozeile. Die wichtigste Quelle.
• Dateiereignisse. Sysmon Event 11 zeigt das Anlegen einer Web-Shell im Webroot, etwa unter inetpub\wwwroot.
• Webserver- und WAF-Logs. Zugriffsmuster, ungewöhnliche POST-Anfragen und Status 500 am Perimeter ergänzen das Bild der Ausnutzung.
• Werkzeug-Kontext. Die Web-Shell nutzt Bordmittel wie cmd und powershell; Grundlagen dazu unter Living off the Land, Einrichtung unter Sysmon einrichten.

Das Muster im Log

Das klarste Signal ist ein Webserver-Prozess als Elternteil einer Shell: w3wp, httpd oder nginx startet cmd oder powershell. Dafür gibt es im Normalbetrieb praktisch keinen Grund, denn ein Webserver beantwortet Anfragen, er öffnet keine Konsolen. Das zweite Signal ist dieselbe Elternschaft mit einem Erkundungswerkzeug wie whoami oder net - die typische erste Orientierung nach dem Einbruch, auch von sqlservr aus per xp_cmdshell. Das dritte ist eine neue .aspx- oder .php-Datei im Webroot, die niemand deployt hat. Legitime Treffer stammen aus seltenen Setup-Vorgängen und aus Deployments auf bekannten Konten. Der Blick auf Elternprozess, Kind und Zielpfad trennt den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Folgen der Ausnutzung: die Shell aus dem Webserver, das Erkundungswerkzeug aus Webserver oder Datenbank und die Web-Shell im Webroot. Die ersten beiden sind die spezifischsten.

1. Webserver-Prozess startet eine Shell (T1190). w3wp, httpd, nginx oder php als Elternteil von cmd, powershell oder pwsh. Die Regel steht auf level: high.

title: Webserver-Prozess startet eine Shell
id: 71cec0de-31f9-48df-84a1-131af89cc917
status: experimental
description: |
  Erkennt einen Webserver-Prozess, der eine Kommando-Shell startet - IIS (w3wp), Apache, nginx oder
  PHP als Elternprozess von cmd, powershell oder pwsh. Nach der Ausnutzung einer oeffentlich
  erreichbaren Anwendung fuehrt die abgelegte Web-Shell Befehle als Kind des Webservers aus. Ein
  Server-Prozess als Elternteil einer Shell hat so gut wie nie einen legitimen Grund.
references:
  - https://attack.mitre.org/techniques/T1190/
author: blue-team.net
tags:
  - attack.initial-access
  - attack.t1190
logsource:
  product: windows
  category: process_creation
detection:
  sel_parent:
    ParentImage|endswith:
      - '\w3wp.exe'
      - '\httpd.exe'
      - '\nginx.exe'
      - '\php-cgi.exe'
      - '\php.exe'
  sel_shell:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
  condition: sel_parent and sel_shell
falsepositives:
  - Seltene Verwaltungs- oder Setup-Vorgaenge, die eine Shell aus dem Webserver starten - bekannte Faelle nach Host und Kommandozeile als Baseline ausnehmen
level: high

2. Webserver- oder DB-Prozess startet ein Erkundungswerkzeug (T1190). whoami, net, ipconfig oder systeminfo unter einem Server-Prozess. Ebenfalls level: high.

title: Webserver- oder DB-Prozess startet ein Erkundungswerkzeug
id: 69f04157-2f81-4762-b93b-a598482a1d42
status: experimental
description: |
  Erkennt ein Erkundungswerkzeug, das als Kind eines Webserver- oder Datenbank-Prozesses laeuft -
  whoami, net, ipconfig, systeminfo oder hostname unter w3wp, Apache, nginx, PHP oder sqlservr.
  Unmittelbar nach der Ausnutzung orientiert sich ein Angreifer per Web-Shell oder xp_cmdshell auf dem
  System. Solche Erkundung aus einem Server-Prozess heraus ist ein starkes Nachausnutzungs-Signal.
references:
  - https://attack.mitre.org/techniques/T1190/
author: blue-team.net
tags:
  - attack.initial-access
  - attack.t1190
logsource:
  product: windows
  category: process_creation
detection:
  sel_parent:
    ParentImage|endswith:
      - '\w3wp.exe'
      - '\httpd.exe'
      - '\nginx.exe'
      - '\php-cgi.exe'
      - '\php.exe'
      - '\sqlservr.exe'
  sel_recon:
    Image|endswith:
      - '\whoami.exe'
      - '\net.exe'
      - '\net1.exe'
      - '\ipconfig.exe'
      - '\systeminfo.exe'
      - '\hostname.exe'
  condition: sel_parent and sel_recon
falsepositives:
  - Monitoring- und Health-Check-Skripte, die unter einem Server-Prozess laufen - bekannte Faelle nach Host und Konto als Baseline ausnehmen
level: high

3. Web-Shell-Datei im Webroot angelegt (T1190). Eine .aspx-, .php- oder .jsp-Datei unter wwwroot, htdocs oder webapps. Die Regel steht auf level: medium.

title: Web-Shell-Datei im Webroot angelegt
id: 4d2dffdd-f961-4f62-a44b-07d0adc5b57b
status: experimental
description: |
  Erkennt das Anlegen einer Skript-Datei in einem Web-Verzeichnis - eine .aspx-, .ashx-, .php- oder
  .jsp-Datei unter inetpub\wwwroot, htdocs oder webapps. Nach der Ausnutzung legt ein Angreifer eine
  Web-Shell im Webroot ab, um dauerhaft Befehle ausfuehren zu koennen. Eine neue Server-Skript-Datei im
  Webroot ist ein deutliches Signal, besonders wenn sie von einem Server-Prozess geschrieben wird.
references:
  - https://attack.mitre.org/techniques/T1190/
author: blue-team.net
tags:
  - attack.initial-access
  - attack.t1190
logsource:
  product: windows
  category: file_event
detection:
  sel_path:
    TargetFilename|contains:
      - '\inetpub\wwwroot\'
      - '\htdocs\'
      - '\webapps\'
      - '\wwwroot\'
  sel_ext:
    TargetFilename|endswith:
      - '.aspx'
      - '.ashx'
      - '.asmx'
      - '.php'
      - '.jsp'
      - '.jspx'
  condition: sel_path and sel_ext
falsepositives:
  - Legitime Deployments und Updates der Webanwendung - bekannte Deployment-Konten und Pfade als Baseline ausnehmen
level: medium

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

• Patchen und abschalten. Öffentlich erreichbare Anwendungen zeitnah patchen und nicht benötigte Dienste und Portale vom Netz nehmen - die kleinste Angriffsfläche gewinnt.
• Webroot schreibschützen. Dem Webserver-Konto das Schreiben im Webroot entziehen, wo es geht, damit keine Web-Shell abgelegt werden kann.
• Child-Prozesse unterbinden. Per Richtlinie oder EDR verhindern, dass Webserver-Prozesse Shells starten - genau das Muster der ersten Regel.
• Segmentieren. Server in der DMZ eng berechtigen und vom internen Netz trennen, damit ein Brückenkopf nicht sofort weiterführt.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem isolierten Testserver mit aktivem Sysmon und einer harmlosen Testanwendung:

• Für Regel 1 eine Testseite so bauen, dass sie cmd oder powershell aufruft, und sie laden. In Event 4688 muss der Webserver als Elternteil der Shell erscheinen.
• Für Regel 2 über dieselbe Testseite whoami oder net user ausführen und den Elternprozess in der Prozess-Telemetrie prüfen.
• Für Regel 3 eine harmlose .aspx-Testdatei in den Webroot schreiben und das Dateiereignis in Event 11 kontrollieren.
• Breiter wird der Test mit den Fällen zu T1190 aus Atomic Red Team.

Fehlalarme und Tuning

• Deployments. Updates der Webanwendung legen legitim neue Skript-Dateien an. Bekannte Deployment-Konten, Pfade und Zeitfenster als Baseline ausnehmen.
• Management-Agenten. Manche Monitoring- und Verwaltungswerkzeuge starten Hilfsprozesse unter dem Webserver. Diese bekannten Fälle gezielt ausnehmen.
• Shell-Start ist spezifisch. Ein Webserver als Elternteil einer Shell hat kaum einen legitimen Grund - diese Treffer hochpriorisieren.
• Kette schlägt Einzelzeile. Shell, Erkundung und Web-Shell-Datei zusammen betrachtet sind aussagekräftiger als ein Ereignis allein - die Korrelation schärft die Bewertung.

Fazit

Exploit Public-Facing Application ist für viele Angriffe der erste Schritt - und seine Folgen sind gut sichtbar, auch wenn der Exploit selbst es nicht ist. Die verlässlichen Signale sind ein Webserver-Prozess als Elternteil einer Shell, dasselbe Muster mit einem Erkundungswerkzeug und eine neue Skript-Datei im Webroot. Die wirksamste Härtung patcht und verkleinert die Angriffsfläche, schützt den Webroot vor Schreibzugriff und unterbindet Shell-Starts aus dem Server. Weil hier der Einbruch beginnt, ist seine Erkennung besonders wertvoll - was folgt, zeigt das Living off the Land. Die weiteren Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Initial Access.