Was ist eine Webshell? Definition für Hoster

Fragen Sie zehn Personen, was eine Webshell ist, und Sie erhalten zehn Antworten, die meisten davon mit Kapuzenpullover. Die brauchbare Definition ist deutlich nüchterner, und sie stammt aus einer neutralen Quelle: Eine Webshell ist ein Skript in einem Verzeichnis, das Ihr Webserver ausliefert, und sie verwandelt eine HTTP-Anfrage in ein Kommando auf Ihrer Maschine.

Die kurze Definition

MITRE ATT&CK führt Webshells als Persistenztechnik, T1505.003 , wörtlich:

Adversaries may backdoor web servers with web shells to establish persistent access to systems. A Web shell is a Web script that is placed on an openly accessible Web server to allow an adversary to access the Web server as a gateway into a network.

Zwei Begriffe tragen dabei das operative Gewicht. Persistent: Die Webshell ist nicht der Einbruch, sondern das, was den Einbruch Ihre Bereinigung überleben lässt. Und gateway: Sie ist der interaktive Brückenkopf, von dem aus alles Weitere bequem wird — Spam, SEO-Injektionen, Ransomware-Vorbereitung, der Sprung in das nächste Konto.

Der Einbruch selbst ist eine andere Technik, T1190 Exploit Public-Facing Application . Zusammen beschreiben beide fast jeden Vorfall auf einem geteilten Webhost: Ein verwundbares Plugin wird ausgenutzt, eine Datei wird geschrieben, und die Schwachstelle spielt danach keine Rolle mehr, weil der Angreifer sie nicht mehr braucht.

Wie eine Webshell auf der Platte aussieht

Eine einzige Datei, oft klein

Öffentliche Werkzeuge setzen den Maßstab. Das Projekt p0wny-shell beschreibt sich selbst wörtlich als

a very basic, single-file, PHP shell. It can be used to quickly execute commands on a server when pentesting a PHP application

mit Befehlshistorie, Tab-Vervollständigung, Dateisystemnavigation sowie Up- und Download — und die README warnt selbst: „THIS SCRIPT IS A SECURITY HOLE." Es ist ein legitimes Pentest-Werkzeug, und es zeigt die Bauform: eine Datei, abgelegt an einer Stelle, an der PHP ausgeführt wird, und das Konto gehört jemand anderem. In echten Vorfällen tauchen Ableger genau dieses Musters auf.

Wer sich die Familie im Detail ansehen möchte: bartblaze/PHP-backdoors ist ein CC0-lizenziertes Korpus, getrennt in obfuskierte und deobfuskierte Beispiele. Es taugt zugleich als fairer öffentlicher Prüfstand: Jede Erkennungsquote — auch unsere — sollte gegen beide Hälften berichtet werden, nicht nur gegen die einfache.

Polyglots und Handler-Missbrauch

Moderne Dropper kommen selten als shell.php. Zwei Techniken wiederholen sich, beide belegt durch mitgeschnittenen Angriffsverkehr statt durch Theorie. Erstens das Polyglot: eine Datei, die mit %PDF-1.4 oder GIF89a beginnt, damit eine naive Upload-Prüfung sie durchwinkt, und weiter unten PHP enthält. Zweitens der Handler-Missbrauch: Hochgeladen wird eine .htaccess, die eine harmlose Endung auf den PHP-Handler umbiegt, sodass eine .txt-Datei ausgeführt wird. Wordfences Analyse der Ninja-Forms-Kampagne zeigt genau das — eine .htaccess, eingereicht als image.jpg, mit der Zeile AddType application/x-httpd-php .txt (Wordfence ).

Wie diese Wege im Detail funktionieren, zeigt die WordPress-Webshell-Welle 2024–2026 .

Dateien, die sich selbst laden

Am längsten überdauern die Varianten, die niemand ansieht. WordPress-mu-plugins werden bei jedem Request geladen und erscheinen nie in der Plugin-Übersicht. Gefälschte Plugin-Verzeichnisse borgen sich den Namen von etwas Plausiblem. Eine veränderte Core-Datei liegt in einem Verzeichnis, dem Administratoren standardmäßig vertrauen.

Warum die Hintertür entscheidet, nicht der Einbruch

Sucuris 2023 Hacked Website Report formuliert es wörtlich :

In 2023, 49.21% of compromised websites were discovered to contain at least one backdoor at the time of infection. Our team successfully removed 21,062 backdoors from these infected sites.

Diese Zahl stammt aus dem Jahr 2023 — Sucuri hat seither keine Ausgabe mit Bereinigungsdaten mehr veröffentlicht, deshalb gehört die Jahreszahl immer dazu. Die Aussage bleibt trotzdem gültig: Auf rund der Hälfte der bereinigten Seiten hatte sich jemand den Rückweg gesichert.

Wordfences 2024 Annual WordPress Security Report zeigt aus einem anderen Datensatz in dieselbe Richtung: Die am zweithäufigsten erkannte Schadsoftware des Jahres war „a generalized obfuscated backdoor", gefunden auf 78.500 Seiten.

Was Webshells tatsächlich findet

Das NSA-Repository zur Eindämmung von Webshells ist ungewöhnlich klar in der Methodenfrage, wörtlich :

The most effective method of discovering most web shells is to compare files on a production web server with a known-good version of that application, typically a fresh install of the application where available updates have been applied.

Das ist eine Kontrolle auf Dateisystemebene, keine Anwendungsfunktion: Vergleich gegen einen bekannten Gutzustand, ausgeführt auf dem Server. MITREs Linux-Analytik zur selben Technik (AN1109) benennt die andere Hälfte:

File creation of unauthorized script (e.g., .php, .sh) in /var/www/html followed by execution of unexpected system utilities (e.g., curl, bash, nc) by apache/nginx

Beachten Sie das ehrliche Detail: MITRE koppelt Dateierzeugung mit anschließender auffälliger Prozessausführung. Das Beobachten von Schreibvorgängen im Webverzeichnis ist eine Hälfte dieser Analytik — die erste beobachtbare Stufe der Kette — aber niemand sollte sie als das Ganze verkaufen. Warum diese Kontrolle unterhalb der Anwendung gehört, steht in warum Webshell-Erkennung auf den Server gehört .

Dasselbe Repository ist ebenso deutlich beim Preis der Heuristik: Regeln, die Obfuskierung und Kodierung erkennen, erzeugen „a significant number of false positive results". Wer Ihnen Obfuskierungserkennung ohne Fehlalarme verspricht, widerspricht der NSA.

Die ehrliche Grenze: nicht alles ist eine Datei

Dateibasierte Erkennung deckt dateibasierte Persistenz ab — das ist der größere Teil und derjenige, der eine Website-Bereinigung überlebt. Sie deckt nicht alles ab. Sucuris Analyse der Sign1-Kampagne beschreibt über 39.000 in sechs Monaten infizierte Seiten, bei denen die Injektion vollständig in der Datenbank lag — JavaScript in Custom-HTML-Widgets — und kein Schadcode in Serverdateien landete.

Ein Scanner, der Dateien beobachtet, hätte diese Kampagne nicht gesehen, und das auszusprechen ist nützlicher, als es zu verschweigen. Datenbankseitige Injektionen brauchen eine andere Kontrolle: Integritätsprüfungen auf Optionen und Beiträge sowie einen zweiten Blick auf die Administratorkonten.

Was das für CyberPanel-Betreiber bedeutet

1. Behandeln Sie jede .php-Datei unterhalb von wp-content/uploads/ als bösartig, bis das Gegenteil bewiesen ist. Es gibt keinen legitimen Grund für eine solche Datei an dieser Stelle.
2. Prüfen Sie bei jeder Untersuchung die .htaccess-Dateien auf AddType, AddHandler und SetHandler — Handler-Missbrauch macht aus „harmlosen" Endungen ausführbaren Code.
3. Stellen Sie Funde in Quarantäne, statt sie zu löschen; Sie brauchen die Datei, um zu beantworten, was passiert ist.
4. Erkennen Sie auf der Ebene, auf der geschrieben wird. Ein Plugin lebt innerhalb des Kontos, das es verteidigen soll; der Weg zu einer Kontrolle darunter steht in der CyberPanel-Einrichtung .
5. Die Installation auf einem CyberPanel-Host ist Schritt für Schritt in der Installationsdokumentation beschrieben.

Shelltrap beobachtet Schreibvorgänge in den Webverzeichnissen Ihrer Kunden in Echtzeit, bewertet sie mit Signaturen, Hash-Sets und Heuristik und hält jeden Fund nachvollziehbar. Zum Produkt .