Kurz gesagt: Ob Sie einen Server nach einem Hack neu aufsetzen oder bereinigen, hängt davon ab, wie sicher Sie den Umfang des Einbruchs kennen. Hatte der Angreifer möglicherweise Root-Rechte, ist der Zeitpunkt des Einbruchs unklar oder fehlen Logs, ist ein Neuaufbau aus vertrauenswürdigen Quellen die verlässlichere Wahl. Eine Bereinigung kommt nur bei eng begrenztem, gut belegtem Befall infrage. In beiden Fällen gilt: erst Beweise sichern und die Lücke schliessen, dann aufräumen.
Warum diese Frage nach PHP2Shell besonders oft gestellt wird
PHP2Shell erlaubt laut php.net die Ausführung von Schadcode aus der Ferne ohne Anmeldung. Wer einen ungepatchten Server betrieben hat, muss sich deshalb fragen, ob in der Zeit seit dem 17.10.2026, dem laut Medienberichten ersten beobachteten Angriffsversuch, etwas passiert ist. Der Patch beantwortet diese Frage nicht, und es gibt keine veröffentlichten, bestätigten Indicators of Compromise.
Findet sich dann eine verdächtige Datei, ein unbekannter Prozess oder ein fremder Cronjob, steht die Entscheidung an. Der Impuls ist oft, schnell zu löschen oder sofort neu zu installieren. Beides kann richtig sein, aber nicht als erster Schritt.
Die Reihenfolge vor der Entscheidung
Bevor Sie zwischen Bereinigen und Neuaufsetzen wählen, gehören drei Dinge erledigt. Sie gelten für beide Wege.
- Eindämmen: Den Server vom Netz nehmen oder den Zugriff auf das Nötigste beschränken, ohne ihn auszuschalten, wenn noch Arbeitsspeicher gesichert werden soll.
- Beweise sichern: Logs, Dateien, Datenbank und möglichst ein Abbild des Systems sichern, mit Datum und Prüfsumme. Warum das vor jeder Neuinstallation nötig ist, erklärt Beweise sichern, bevor Sie neu aufsetzen.
- Versicherer und Datenschutz einbeziehen: Viele Cyberpolicen erwarten, dass wesentliche Schritte abgestimmt werden. Hinweise stehen unter Cyberversicherung: Was im Schadensfall zählt. Ob eine Meldepflicht nach DSGVO besteht, bewerten Datenschutzbeauftragte oder Anwalt.
Erst danach lohnt die eigentliche Abwägung.
Server neu aufsetzen nach dem Hack oder bereinigen: die Kriterien
| Kriterium | Bereinigen | Neu aufsetzen |
|---|---|---|
| Umfang des Einbruchs | Eng begrenzt, belegt, etwa eine Datei im Upload-Ordner ohne weitere Spuren | Unklar oder mit Hinweisen auf Systemzugriff |
| Mögliche Root-Rechte des Angreifers | Ausgeschlossen mit guten Belegen | Nicht ausschliessbar |
| Verfügbarkeit von Logs | Vollständig für den relevanten Zeitraum | Lückenhaft, überschrieben oder manipulierbar |
| Aufwand | Geringer, wenn der Befund klar ist | Höher, aber besser planbar |
| Verbleibende Unsicherheit | Höher, versteckte Hintertüren sind schwer auszuschliessen | Geringer, wenn sauber aus vertrauenswürdigen Quellen aufgebaut |
| Ausfallzeit | Meist kürzer | Meist länger, mit Vorbereitung gut steuerbar |
| Eignung für Altsysteme | Problematisch, wenn das System ohnehin veraltet ist | Gute Gelegenheit, auf eine unterstützte PHP-Version zu wechseln |
Als Faustregel gilt: Je weniger Sie wissen, desto mehr spricht für den Neuaufbau. Bei einer Lücke im PHP-Interpreter, die Code im Kontext des Webserver-Benutzers ausführt, kann ein Angreifer weitere Schwachstellen nutzen, um mehr Rechte zu erlangen. Das lässt sich ohne gründliche Untersuchung kaum ausschliessen.
Beide Wege in der Praxis
Was „neu aufsetzen“ wirklich bedeutet
Neu aufsetzen heisst nicht, das alte Backup auf einen frischen Server zu kopieren. Ein Neuaufbau beginnt mit einem sauberen Betriebssystem aus offizieller Quelle, aktuellen Paketen und einer gepatchten PHP-Version. Die Anwendung wird aus dem Original des Herstellers installiert, Plugins und Themes ebenso.
Erst dann kommen die eigenen Inhalte dazu, und zwar geprüft. Hochgeladene Dateien dürfen keine ausführbaren Skripte enthalten, die Datenbank kann eingeschleuste Inhalte enthalten, etwa versteckte Admin-Konten oder Skripte in Beiträgen. Konfigurationsdateien werden neu geschrieben statt kopiert. Alle Zugangsdaten werden erneuert: Datenbank, CMS-Admins, SSH-Schlüssel, API-Schlüssel, Hosting-Panel.
Backups spielen dabei eine wichtige Rolle, aber nur, wenn ihr Stand vor dem Einbruch liegt und sie selbst nicht verändert wurden. Mehrere Generationen an getrennten Orten machen das prüfbar; mehr dazu unter Backups nach der 3-2-1-Regel.
Wenn Bereinigen vertretbar ist
Eine Bereinigung kann sinnvoll sein, wenn der Befall früh entdeckt wurde, vollständige Logs vorliegen und die Untersuchung keinen Hinweis auf weitere Zugänge ergibt. Dann werden die gefundenen Dateien nach der Sicherung entfernt, Cronjobs, Benutzerkonten und SSH-Schlüssel geprüft und Kerndateien mit dem Original des Herstellers verglichen.
Wichtig ist eine realistische Einschätzung: Webshells sind oft unscheinbar und an mehreren Stellen versteckt. Wie man sie findet, beschreibt Webshells erkennen und entfernen. Nach einer Bereinigung sollte der Server engmaschig beobachtet werden, damit eine übersehene Hintertür auffällt.
Löschen Sie nichts, bevor Logs und Dateien gesichert sind, und schliessen Sie die Lücke, bevor der Server wieder ans Netz geht. Sonst verlieren Sie die Spuren und laden den nächsten Einbruch ein.
Wann Sie keinen Dienstleister brauchen
Bei einer einfachen Website auf Shared Hosting, bei der der Hoster das System verwaltet und den PHP-Patch bestätigt, liegt die Entscheidung oft gar nicht bei Ihnen. Sie können die Anwendung aus dem Original neu installieren, Inhalte prüfen und Zugangsdaten erneuern, unterstützt vom Hoster. Auch ein erfahrenes internes Team kann einen Neuaufbau selbst stemmen, wenn Beweissicherung und Dokumentation sitzen.
Externe Hilfe lohnt sich, wenn Root-Rechte nicht ausgeschlossen werden können, personenbezogene Daten betroffen sein könnten, die Versicherung beteiligt ist oder mehrere Systeme zusammenhängen.
Wie hilft PHP SOS konkret?
- Wir sichern Logs, Dateien und Datenbank beweisfähig, bevor etwas verändert wird.
- Wir bewerten den Umfang des Einbruchs und empfehlen Bereinigen oder Neuaufbau mit Begründung, getrennt nach belegt, wahrscheinlich und unbekannt.
- Wir bauen den Server bei Bedarf aus vertrauenswürdigen Quellen neu auf, mit gepatchter PHP-Version und erneuerten Zugängen.
- Wir übernehmen die Malware-Entfernung dort, wo eine Bereinigung vertretbar ist, und dokumentieren jeden Schritt.
Fazit
Die Frage „neu aufsetzen oder bereinigen?“ beantwortet sich über das Wissen um den Einbruch. Wer den Umfang nicht sicher kennt, baut neu auf. Wer ihn gut belegt eingrenzen kann, darf bereinigen. In beiden Fällen gilt dieselbe Reihenfolge: eindämmen, sichern, Lücke schliessen, dann aufräumen.
Häufige Fragen
Ist Neuaufsetzen nach einem Hack immer besser?
Nicht immer, aber häufig. Wenn unklar ist, wie weit der Angreifer kam, ist ein Neuaufbau aus vertrauenswürdigen Quellen meist die verlässlichere Wahl. Bei einem eng begrenzten, gut belegten Befall kann eine Bereinigung genügen.
Kann ich einfach ein altes Backup einspielen?
Nur, wenn sicher ist, dass das Backup vor dem Einbruch entstand und keine Hintertür enthält. Ausserdem muss die Lücke vorher geschlossen sein, sonst ist der Server sofort wieder angreifbar. Daten jüngeren Datums müssen gesondert geprüft werden.
Was muss ich vor dem Neuaufsetzen sichern?
Logs, eine Kopie der Dateien und der Datenbank sowie, wenn möglich, ein Abbild des Systems. Diese Beweise brauchen Sie für Ursachenanalyse, Versicherung und eine mögliche Meldung. Nach dem Löschen sind sie weg.
Reicht es, die gefundene Webshell zu löschen?
Selten. Angreifer legen oft mehrere Hintertüren an, etwa Cronjobs, Benutzerkonten oder SSH-Schlüssel. Wer nur die sichtbare Datei löscht, lässt die anderen Zugänge offen.