PHP-Shell gefunden — alle Hintertüren finden, nicht nur eine.
Der Hoster meldet eine verdächtige Datei, ein Scanner schlägt Alarm, oder im Upload-Ordner liegt eine PHP-Datei mit kryptischem Namen. Das ist fast nie ein Einzelfall: Eine Webshell ist das Werkzeug, mit dem ein Angreifer wiederkommt. Wer nur diese eine Datei löscht, hat meist nur die sichtbarste von mehreren entfernt.
Eine PHP-Shell (Webshell) ist ein Skript, über das ein Angreifer per Browser Befehle auf deinem Server ausführt, Dateien hochlädt oder die Datenbank ausliest. Sie liegt fast nie allein. Vorgehen: Spuren sichern, alle Shells und Hintertüren finden — Dateien, Datenbank, geplante Aufgaben, Benutzerkonten —, Einfallstor schließen, bereinigen, alle Zugänge erneuern und PHP-Ausführung dort sperren, wo sie nichts zu suchen hat.
Website down oder gehackt? Schreib mir per WhatsApp oder E-Mail mit Domain und kurzer Beschreibung — ich melde mich in der Regel innerhalb weniger Stunden, auch am Wochenende, wenn es brennt. Zugangsdaten bitte nie in der ersten Nachricht, sondern erst nach Absprache über einen sicheren Weg.
Was eine PHP-Shell ist.
Eine PHP-Shell ist eine Datei, die Angreifer nach einem erfolgreichen Einbruch auf dem Server ablegen. Über sie lassen sich später per Browser Befehle ausführen, Dateien lesen und schreiben, weitere Schadsoftware nachladen oder Spam verschicken — ganz ohne Passwort. Manche Shells sind komplette Dateimanager mit Oberfläche, andere bestehen aus einer einzigen Zeile, die Code aus einem Formularfeld oder einem Cookie ausführt.
Wichtig für die Einordnung: Die Shell ist nicht die Lücke, sondern die Folge. Irgendwo gab es ein Einfallstor — ein veraltetes Plugin, ein unsicheres Upload-Formular, gestohlene FTP-Zugangsdaten. Solange das offen ist, kommt die Shell wieder (Website gehackt — erste Schritte).
Woran du sie erkennst.
Webshells sind fast immer verschleiert, damit sie bei einem flüchtigen Blick nicht auffallen. Typische Merkmale im Code:
| Merkmal | Warum verdächtig |
|---|---|
eval(), assert() mit Variablen | Führt beliebigen Code aus, der von außen kommt |
base64_decode, gzinflate, str_rot13 verschachtelt | Versteckt den eigentlichen Code vor Lesern und Scannern |
Zugriff auf $_POST, $_REQUEST, $_COOKIE direkt in Ausführung | Befehle kommen unauffällig im Formular oder Cookie |
system, exec, shell_exec, passthru | Startet Programme auf dem Server |
| Sehr lange Zeilen mit Zeichensalat | Verschlüsselter Code statt lesbarem Programm |
| PHP-Code in Bild- oder Textdateien | Tarnung als harmlose Datei |
Keines dieser Merkmale ist für sich allein ein Beweis — manche Plugins nutzen einzelne Funktionen legitim. Verdächtig ist die Kombination: verschleierter Code, der Eingaben von außen ausführt, in einer Datei, die dort nicht hingehört.
Auch außerhalb des Codes gibt es Zeichen: Der Hoster meldet Spam-Versand, die Website leitet auf fremde Seiten um, Google zeigt fremde Seiten in den Suchergebnissen (Website als gefährlich markiert), oder es tauchen Administratoren auf, die niemand angelegt hat.
Wo sie sich verstecken.
- Upload-Ordner: In WordPress
wp-content/uploads/, oft in Jahres- und Monatsordnern. Dort gehört keine einzige PHP-Datei hin. - Cache- und Temp-Ordner: Werden selten angesehen und oft bei Updates nicht ersetzt.
- Plugin- und Theme-Ordner: Als zusätzliche Datei mit unauffälligem Namen oder als eingeschleuster Code in einer echten Datei.
- Namen, die nach System klingen: etwa
wp-log.php,class-cache.phpoder Dateien mit Punkt am Anfang, die in vielen Programmen ausgeblendet sind. - Kern-Dateien: Ein paar Zeilen am Anfang einer echten Systemdatei, die bei jedem Aufruf mitlaufen.
Alle finden — nicht nur eine.
Die gefundene Datei ist der Anfang der Suche. Drei Wege ergänzen sich: geänderte Dateien nach Datum, Muster im Code und der Abgleich mit dem Originalzustand.
# PHP-Dateien im Upload-Ordner — dort sollte es keine geben
find wp-content/uploads -type f -name "*.php"
# Alle PHP-Dateien, die in den letzten 30 Tagen geändert wurden
find . -type f -name "*.php" -mtime -30 -printf "%TY-%Tm-%Td %p\n" | sort
# Typische Muster verschleierter Shells
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(|shell_exec\(" --include=*.php .Treffer sind Hinweise, keine Urteile — manche Plugins nutzen base64_decode harmlos. Jede Datei ansehen und mit dem Original vergleichen, bevor etwas gelöscht wird.
# Prüft alle WordPress-Kerndateien gegen die offiziellen Prüfsummen
wp core verify-checksums
# Prüft Plugins aus dem offiziellen Verzeichnis
wp plugin verify-checksums --allAbweichende oder zusätzliche Dateien im Kern sind ein starkes Warnzeichen. Für TYPO3 und Shops gilt dasselbe Prinzip: Kern frisch aus der Originalquelle beziehen und vergleichen.
Ein weiterer Blick lohnt in die Serverprotokolle: Anfragen per POST an Dateien, die normalerweise niemand aufruft, verraten oft sowohl die Shell als auch den Zeitpunkt des Einbruchs (Logfiles analysieren).
Hintertüren jenseits von Dateien.
Gründliche Angreifer sichern sich mehrfach ab. Deshalb gehören zur Suche auch:
- Die .htaccess: Weiterleitungen nur für Suchmaschinen oder nur für Mobilgeräte, oder eine Anweisung, die vor jeder Seite eine bestimmte Datei mitlädt.
- Die Datenbank: Eingeschleuste Skripte in Beiträgen, Widgets oder Einstellungen, fremde Administratoren in der Benutzertabelle.
- Geplante Aufgaben: Cronjobs beim Hoster oder im System, die die Shell regelmäßig neu anlegen.
- Zugänge: Neue FTP-, SSH- oder Datenbank-Benutzer.
Erst wenn alle diese Stellen geprüft sind, ist die Suche abgeschlossen. Eine Malware-Prüfung von außen ergänzt das, ersetzt es aber nicht (Malware-Scan).
Das Einfallstor.
Ohne geschlossenes Einfallstor ist jede Bereinigung nur eine Pause. Die häufigsten Ursachen:
| Einfallstor | Was hilft |
|---|---|
| Veraltetes Plugin, Theme oder System mit bekannter Lücke | Aktualisieren oder ersetzen, Software-Stand dauerhaft pflegen |
| Upload-Formular ohne Prüfung des Dateityps | Dateitypen streng prüfen, Uploads außerhalb ausführbarer Ordner speichern |
| Gestohlene FTP- oder Admin-Zugangsdaten | Alle Passwörter erneuern, SFTP statt FTP, Zwei-Faktor-Anmeldung |
| Aufgegebene Zusatzsoftware | Entfernen, was nicht mehr gepflegt wird |
| Nachbarseite auf demselben Webspace | Alle Websites im Account prüfen, nicht nur die auffällige |
Den Zeitpunkt des Einbruchs zeigt oft die älteste gefundene Shell. Was um diesen Zeitpunkt geändert oder hochgeladen wurde, führt meist direkt zum Einfallstor (Veraltete Software).
Sauber bereinigen.
- Spuren sichern: Vollständige Kopie von Dateien und Datenbank, bevor etwas geändert wird.
- In Quarantäne statt löschen: Verdächtige Dateien in einen gesperrten Ordner verschieben. So lässt sich später nachvollziehen, was passiert ist.
- Kern ersetzen: System, Plugins und Theme frisch aus der Originalquelle einspielen statt einzelne Dateien zu flicken.
- Datenbank säubern: fremde Benutzer, eingeschleuste Skripte, manipulierte Einstellungen.
- Alle Zugänge erneuern: Admin, FTP/SFTP, Datenbank, Hosting-Konto, Sicherheitsschlüssel in der Konfiguration.
- Nachkontrolle: Einige Tage beobachten, ob neue Dateien entstehen — sonst ist noch eine Hintertür offen.
Wenn personenbezogene Daten betroffen sein könnten, etwa Kundendaten im Shop, gilt die Meldepflicht an die Aufsichtsbehörde binnen 72 Stunden (Datenpanne melden).
PHP-Ausführung sperren.
Die wirksamste Vorbeugung gegen Webshells ist simpel: In Ordnern, in die hochgeladen wird, darf PHP gar nicht erst laufen. Selbst wenn dort dann eine Shell landet, ist sie wirkungslos.
# Verhindert die Ausführung von PHP-Dateien in diesem Ordner (Apache)
<FilesMatch "\.(php|phtml|php[0-9]|phar)$">
Require all denied
</FilesMatch>Auf Nginx-Servern wird das in der Serverkonfiguration eingetragen. Danach testen: Eine PHP-Datei in diesem Ordner muss mit 403 antworten.
Dazu kommen: Dateirechte so knapp wie möglich, Dateibearbeitung im Backend abschalten, Zwei-Faktor-Anmeldung für alle Admins und eine Überwachung, die bei neuen PHP-Dateien Alarm schlägt (WordPress absichern, Admin-Zugang absichern).
Aus meiner Praxis.
Auf einer meiner eigenen Lernseiten kam der Angreifer über eine Lücke in einem Lernplattform-Plugin. Er legte eine Weiterleitung in die .htaccess, die Suchmaschinen die normale Seite zeigte und Besucher auf fremde Seiten schickte, und dazu 76 statische Spam-Dateien — teils direkt in echte Seitenordner. Insgesamt habe ich 91 Dateien in Quarantäne verschoben, PHP im Upload-Ordner gesperrt und das Plugin aktualisiert.
Die wichtigste Lehre: Die erste gefundene Datei war nicht die einzige, und die Nachwirkung bei Google dauerte länger als die Bereinigung. Wer gründlich sucht, statt schnell zu löschen, spart sich den zweiten Einbruch.
Wenn du nicht weiterkommst.
Wenn auf deinem Server eine PHP-Shell gefunden wurde und du sicher sein willst, dass wirklich alles weg ist. Ich sehe mir deine Website an, sage dir, wo die Risiken liegen, und setze um, was nötig ist. Die Übersicht findest du unter Website-Sicherheit; wenn es gerade brennt, hilft der Notfall-Support.
Ursache finden, Website wieder zum Laufen bringen, kurzer Bericht — meist am selben Tag.
Für Anpassungen, Fehlerbehebung und Beratung nach Aufwand, abgerechnet in 15-Minuten-Schritten.
Updates, Backups, Sicherheitscheck, Monitoring — Kleinigkeiten inklusive.
Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.
Wer hilft.
B.A. Marketing & Digitale Medien (FOM Hochschule) · selbstständig seit 2022 · Mehr über mich
Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Website-Sicherheit gehört zu meiner täglichen Arbeit — ich härte WordPress, TYPO3, Shopware und eigene PHP-Anwendungen, richte Sicherungen und Überwachung ein und habe zahlreiche kompromittierte Websites bereinigt. Als Dozent erkläre ich regelmäßig, wie Angriffe auf Websites tatsächlich ablaufen.
Ich bin kein zertifizierter Penetrationstester und behaupte das auch nicht. Was ich biete: die Grundlagen, die den Großteil realer Angriffe abwehren, sauber umgesetzt — und eine ehrliche Einschätzung, wann zusätzlich ein spezialisierter Prüfer sinnvoll ist.
Was du bekommst: eine Bestandsaufnahme in verständlicher Sprache, Maßnahmen nach Dringlichkeit und eine Website, die nicht beim ersten automatisierten Angriff fällt.
Echte Projekte — live ansehen.
WordPress-Websites, die ich gebaut habe oder laufend betreue.
Markenfest
Stärkerer Online-Shop — Webdesign, Content und individuelle Shop-Funktionen.
Website ansehen ↗
KT Bodenteam
Professioneller Auftritt für einen Bodenleger — Vorher-Nachher-Slider und regionale SEO.
Website ansehen ↗
Potassco Solutions
Klare Website für ein KI-Unternehmen, die komplexe Technologie verständlich macht.
Website ansehen ↗FAQ — PHP-Shell entfernen.
Was ist eine PHP-Shell?
Eine Webshell ist ein Skript, das Angreifer nach einem Einbruch auf dem Server ablegen. Darüber führen sie per Browser Befehle aus, laden Dateien hoch oder verschicken Spam — ohne Passwort.
Reicht es, die gefundene Datei zu löschen?
Nein. Webshells liegen fast nie allein, dazu kommen oft Hintertüren in der .htaccess, der Datenbank oder in geplanten Aufgaben. Und solange das Einfallstor offen ist, kommt die Shell wieder.
Wo verstecken sich Webshells am häufigsten?
Im Upload-Ordner, in Cache- und Temp-Ordnern, in Plugin- und Theme-Ordnern und als eingeschleuster Code in echten Systemdateien, oft mit unauffälligen Namen.
Wie finde ich alle Shells?
Mit drei Wegen zusammen: geänderte Dateien nach Datum, typische Muster im Code wie eval und base64_decode, und dem Abgleich der Kerndateien mit dem Original, bei WordPress per WP-CLI.
Wie verhindere ich neue Webshells?
PHP-Ausführung in Upload-Ordnern sperren, Software aktuell halten, alle Zugänge mit starken Passwörtern und Zwei-Faktor-Anmeldung schützen und neue PHP-Dateien überwachen.
Muss ich den Vorfall melden?
Wenn personenbezogene Daten betroffen sein könnten, gilt nach DSGVO die Meldepflicht an die Aufsichtsbehörde binnen 72 Stunden.
Manuel Killert · Webentwickler & DozentErzähl mir, was dich beunruhigt.
Schreib mir die Adresse deiner Website, das System und was dir aufgefallen ist. Wenn du glaubst, dass die Website gerade angegriffen wird oder gehackt wurde, schreib das in die erste Zeile.
Antwort meist innerhalb von 24 Stunden · hallo@manuelkillert.de