Seit PHP2Shell bekannt wurde, kommt in jedem Gespräch dieselbe Frage: Der Patch ist eingespielt, die Seite läuft wieder – aber war vorher schon jemand da? Von außen lässt sich das nicht beantworten. Dafür muss jemand auf das System schauen.
Deshalb stellen wir ein Werkzeug kostenlos zur Verfügung, mit dem Sie genau das selbst tun können. Ohne Anmeldung, ohne Registrierung, ohne Gegenleistung.
Zum Werkzeug und zur Anleitung
Was es tut
Es ist ein einzelnes PHP-Skript. Sie legen es auf den Server, starten es auf der Kommandozeile, und nach zehn Sekunden bis drei Minuten haben Sie einen Bericht als Textdatei. Es läuft auf Linux und auf Windows Server, überall wo PHP 7.4 oder neuer liegt – und das ist auf einem betroffenen Server per Definition der Fall.
Gesucht wird nach den Spuren, die nach einem erfolgreichen Angriff typischerweise zurückbleiben:
- Ausführbarer Code im Webverzeichnis, erkannt an der Kombination aus einer Ausführungsfunktion und einer Benutzereingabe im selben Ausdruck. Das ist das Kennzeichen jeder Webshell.
- PHP-Dateien an Orten, die nur Daten enthalten sollten – in `wp-content/uploads`, `typo3temp` oder `var/cache` gehört kein Code hin. Einer der verlässlichsten Hinweise überhaupt.
- `auto_prepend_file` und `auto_append_file`, die bei jedem einzelnen Seitenaufruf eine Datei mitladen, ohne dass im Webverzeichnis etwas auffällt. Der eleganteste Dauerzugang, den es gibt.
- Geplante Aufgaben und Autostarts: unter Linux crontab, `/etc/cron.d`, systemd-Dienste und `ld.so.preload`, unter Windows die Aufgabenplanung und die Autostart-Schlüssel der Registry.
- Hinterlegte SSH-Schlüssel und Konten mit Anmeldemöglichkeit.
- Zugriffsprotokolle – und zwar mit der entscheidenden Unterscheidung, dazu gleich mehr.
- Doppelte Dateiendungen, veränderte `.htaccess`-Dateien, Zeitstempel in der Zukunft.
- Wie weit Ihre Protokolle zurückreichen. Das klingt nebensächlich und ist es nicht.
Drei Entscheidungen, die wir bewusst so getroffen haben
Es räumt nicht auf
Das Werkzeug findet und meldet. Es löscht nichts, verschiebt nichts, repariert nichts.
Das ist kein fehlendes Feature, sondern der Kern der Sache. Nach einem Vorfall entscheidet eine einzige Frage über alles Weitere: seit wann? Erst die Antwort darauf sagt Ihnen, welche Datensicherung noch sauber ist. Sie steckt in den Zeitstempeln der gefundenen Dateien und in den Zugriffsprotokollen.
Wer zuerst aufräumt, löscht genau die Angaben, die er danach braucht – und muss im Zweifel auf eine Sicherung zurück, die Monate alt ist. Dazu kommt: Eine entfernte Hintertür bei offener Lücke ist am nächsten Tag wieder da, nur ohne die Spur.
Es ist kein Programm, sondern Quelltext
Wir bitten Sie, auf einem möglicherweise betroffenen Server etwas mit hohen Rechten auszuführen. Das ist genau das, wovor wir sonst warnen.
Deshalb bekommen Sie keine fertige EXE, sondern eine lesbare, kommentierte Datei. Sie können sie vorher öffnen, und Ihr Dienstleister kann es auch. Suchen Sie darin nach einer Internetadresse – es gibt keine. Das Werkzeug baut keine einzige Verbindung nach außen auf, es sendet keine Statistik und es meldet nichts an uns. Der Bericht bleibt auf Ihrem Server, bis Sie selbst entscheiden, ihn jemandem zu zeigen.
Eine signierte Binärdatei hätte zwei Nachteile: Sie können nicht hineinsehen, und Virenscanner halten ein Programm, das Dateisysteme durchsucht und Autostarts liest, zu Recht für verdächtig.
Es unterscheidet Versuch und Erfolg
Diese Entscheidung kam aus dem ersten Testlauf, und sie war die wichtigste.
Beim Test gegen eine reale, gesunde WordPress-Installation meldete das Werkzeug zunächst sechzehn Aufrufe typischer Hintertür-Namen: `shell.php`, `bypass.php`, `mini.php`, `alfanew.PhP7`. Das sieht nach Katastrophe aus. In Wahrheit hatten alle den Status 404 – es waren Scanversuche, die ins Leere liefen.
Jeder öffentlich erreichbare Server wird rund um die Uhr nach Hintertüren abgesucht. Das ist Dauerrauschen. Ein Werkzeug, das Fehlschläge als Treffer meldet, erzeugt Panik, wo nichts ist.
Die Fassung, die Sie herunterladen, liest deshalb den Statuscode mit. Abgewehrte Versuche erscheinen als graue Information mit der Einordnung: Das ist normal, und es ist der Beleg, dass es funktioniert hat. Rot wird nur, was beantwortet wurde.
Im selben Testlauf fiel ein zweiter Fehlalarm auf: 52 angeblich verdächtige Dateien, die sich als reguläre Elementor-Plugin-Dateien herausstellten. Auch das ist korrigiert. Ein Werkzeug, dessen Meldungen man wegklickt, ist schlimmer als keines.
Was es ausdrücklich nicht leistet
Darüber schreiben wir lieber zu viel als zu wenig.
Ein leerer Befund ist kein Freispruch. Geprüft wird auf die gängigsten Varianten. Wer sich Mühe gibt, hinterlässt keine davon.
Es läuft auf dem System, das es prüfen soll. Wer dort genug Rechte hat, um sich einzunisten, hat auch genug, um ein Werkzeug zu täuschen. Belastbar ist nur eine Prüfung von außen oder an einem abgezogenen Abbild.
Datenbank und Anwendung bleiben außen vor. Neu angelegte Redakteurskonten, manipulierte Inhalte und Einträge in Erweiterungstabellen sieht es nicht.
Gelbe Treffer sind normal. WordPress, TYPO3 und ihre Erweiterungen verwenden Techniken, die auch in Schadcode vorkommen. Genau deshalb sind sie gelb.
Jeder Bericht endet mit diesen vier Punkten. Nicht im Kleingedruckten, sondern als eigener Abschnitt.
So gehen Sie vor
Die vollständige Anleitung liegt bei und steht auf der Werkzeugseite. In Kürze:
- Prüfen, ob PHP auf der Kommandozeile läuft – `php -v` muss eine Versionsnummer zeigen. Unter Windows liegt PHP häufig unter `C:\php\php.exe`.
- Die Datei ablegen, aber nicht ins Webverzeichnis. Das Skript weigert sich zwar, über einen Browser zu starten – trotzdem gehört es nicht dorthin, wo das Internet es erreicht.
- Mit Administratorrechten starten. Ohne sie bleiben Aufgabenplanung, Autostarts und Protokolle unlesbar. Es läuft auch ohne und sagt dann im Abschnitt „Nicht geprüft", woran es nicht herankam.
- Den Bericht lesen, von oben nach unten. Drei Stufen, und der Abschnitt am Ende gehört dazu.
Wenn Sie einen roten Befund haben
Nicht löschen. Zuerst den Bericht sichern, die Zugriffsprotokolle wegkopieren, bevor sie rotieren, und eine Sicherung des aktuellen Zustands anlegen – auch des befallenen, die braucht man später. Die ausführliche Reihenfolge steht in Webshell gefunden – und jetzt?.
Welche Spuren PHP2Shell konkret hinterlässt, steht in PHP2Shell-Angriff erkennen. Und warum die meisten Betreiber einen Einbruch gar nicht bemerken, in Merken Sie es überhaupt, wenn Ihre Seite kompromittiert wird?.
Checkliste: erste Schritte
- Werkzeug herunterladen und den Quelltext überfliegen, bevor Sie es starten
- Mit Administratorrechten laufen lassen, sonst bleibt zu viel unsichtbar
- Bericht als Datei mitschreiben lassen
- Den Abschnitt „Nicht geprüft" lesen, nicht nur die Befunde
- Bei rotem Befund: nichts löschen, Protokolle sichern
- Prüfen, wie weit die Protokolle zurückreichen – unter 30 Tagen wird es eng
- Die vollständige PHP-Versionsnummer beim Betreuer erfragen, mit allen drei Stellen
Wie DAVINCI unterstützt
Schicken Sie uns den Bericht, wenn Sie eine Einordnung möchten – wir sagen Ihnen, was darin steht, auch dann, wenn die Antwort lautet, dass nichts passiert ist. Für die Prüfung von außen ohne jeden Zugang gibt es den kostenlosen PHP-Sicherheitscheck. Bei bestätigtem Vorfall arbeitet unser Incident Response den Fall auf, und für den schnellen Blick durch einen Menschen gibt es den Quick-Check. Erreichbar sind wir über die Kontaktseite.
Häufige Fragen
Kostet das Werkzeug wirklich nichts?
Nein, und es gibt auch keine Anmeldung, keine Adresse und keine spätere Rechnung. Wir halten es für sinnvoller, in dieser Lage etwas Brauchbares bereitzustellen, als ein Formular davorzusetzen.
Kann es meinen Server beschädigen?
Nein. Es öffnet Dateien ausschließlich zum Lesen. Die einzige Datei, die es schreibt, ist der Bericht – und nur, wenn Sie das ausdrücklich verlangen.
Werden Daten an DAVINCI übertragen?
Nein. Es gibt keine Netzwerkverbindung im Code. Sie können das vor dem Start nachprüfen, und genau dafür veröffentlichen wir den Quelltext lesbar.
Reicht das als Nachweis gegenüber Versicherung oder Aufsichtsbehörde?
Nein. Der Bericht ist ein Ausgangspunkt, keine forensische Untersuchung. Für eine belastbare Aufarbeitung braucht es eine Prüfung an einem gesicherten Abbild und eine nachvollziehbare Dokumentation des Prüfumfangs.
Was, wenn ich keinen Kommandozeilenzugang habe?
Bei geteiltem Webspace fehlt er häufig. Viele Anbieter richten SSH auf Anfrage ein. Ohne Zugang bleibt die Prüfung von außen über unseren PHP-Sicherheitscheck.
Warum gibt es das kostenlos?
Weil ein Werkzeug, das nur bei uns läuft, niemandem hilft, der gerade um drei Uhr nachts vor dem Problem sitzt. Wer danach jemanden braucht, der den Bericht einordnet, weiß dann, wen er fragen kann.
Verwandte Themen: Wer hier weiterdenkt, liest bei Remote Code Execution, Webshell und PHP2Shell weiter.
Im Text erwähnt
Quellen
- PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet · Wiz Research
- PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit, Cybersicherheitswarnung 2026-297981-1032, Version 1.1 (21.10.2026) · BSIamtlich
- IT-Grundschutz-Baustein OPS.1.1.5 Protokollierung (Edition 2023) · BSIamtlich
