- Anzeichen einer kompromittierten Website erkennen
- einen Vorfall in der richtigen Reihenfolge abarbeiten
- die Einstiegsstelle finden, statt nur aufzuräumen
- rechtliche Pflichten nach einem Vorfall einschätzen
Websites werden fast nie gezielt angegriffen – sie geraten in automatisierte Scans, die tausende Adressen pro Stunde nach bekannten Lücken absuchen. Ein veraltetes Plugin, ein schwaches Passwort, ein offenes Formular: Das genügt. Wer den Ernstfall einmal durchdacht hat, verliert im Fall der Fälle keine Zeit mit Panik. Diese Lektion beschreibt einen geordneten Ablauf: erkennen, sichern, bereinigen, absichern, beobachten – und die Frage, welche Pflichten dabei entstehen.
1. Erkennen
Besonders tückisch ist Schadcode, der sich je nach Besucher anders verhält: Für angemeldete Personen sieht die Website normal aus, nur Besucher aus der Google-Suche werden weitergeleitet. Prüfen Sie deshalb immer auch in einem privaten Fenster und mit einer Google-Suche nach site: gefolgt von der Domain – dort zeigen sich fremde Seiten oft zuerst.
2. Die Reihenfolge im Ernstfall
Der wichtigste und am häufigsten übersprungene Schritt ist der letzte. Wer nur aufräumt, ohne die Ursache zu finden, hat in wenigen Tagen dasselbe Problem. Typische Einstiegsstellen sind ein Plugin mit bekannter Lücke, ein schwaches oder wiederverwendetes Passwort, eine veraltete PHP-Version und Dateien aus zweifelhaften Quellen, etwa freigeschaltete Bezahl-Themes.
1# PHP-Dateien im Upload-Ordner – dort gehört niemals PHP hin2find wp-content/uploads -name "*.php"34# Zuletzt geänderte Dateien der vergangenen drei Tage5find . -type f -mtime -3 -name "*.php" | head -5067# Typische Tarnfunktionen suchen8grep -rn --include="*.php" -E "eval\(|base64_decode\(|gzinflate\(" wp-content | head910# Kerndateien mit dem Original vergleichen11wp core verify-checksums3. Bereinigen oder neu aufbauen?
Bei einem klaren, früh entdeckten Befall genügt oft das Ersetzen der Dateien. Steckt der Schadcode tief, sind Kerndateien verändert und liegt der Einstieg Wochen zurück, ist ein Neuaufbau meist schneller und sicherer: frische WordPress-Installation, Plugins und Themes neu aus offizieller Quelle, Inhalte gezielt übernehmen und den Ordner uploads sorgfältig prüfen. Eine ältere Sicherung von vor dem Vorfall einzuspielen ist verlockend, löst das Problem aber nur, wenn die Lücke danach geschlossen wird – und die Inhalte seitdem verlorene Tage kosten.
| Maßnahme | Wirkung |
|---|---|
| Automatische Updates für Sicherheitsversionen | schließt bekannte Lücken ohne Verzögerung |
| Zwei-Faktor-Anmeldung für alle Administratoren | verhindert Anmeldungen mit gestohlenen Passwörtern |
| Ausführung von PHP in uploads sperren | macht hochgeladene Schadskripte wirkungslos |
| Dateibearbeitung im Backend abschalten (DISALLOW_FILE_EDIT) | entzieht Angreifern ein bequemes Werkzeug |
| Anmeldeversuche begrenzen, Protokollierung | erschwert das Durchprobieren von Passwörtern |
| Regelmäßige, getrennt gespeicherte Backups | ermöglicht eine schnelle Rückkehr in den Normalzustand |
4. Pflichten nach einem Vorfall
Ein Angriff ist nicht nur ein technisches Problem. Wenn personenbezogene Daten betroffen sein könnten – Kundenkonten, Bestellungen, Formularnachrichten, Newsletter-Adressen –, greift die Datenschutz-Grundverordnung: Der Vorfall ist in der Regel binnen 72 Stunden der zuständigen Aufsichtsbehörde zu melden, und bei hohem Risiko müssen auch die Betroffenen informiert werden. Dokumentieren Sie deshalb von Anfang an: Wann wurde was entdeckt, welche Daten liegen auf dem System, welche Schritte wurden wann unternommen. Diese Dokumentation ist Pflicht und hilft zugleich, den Überblick zu behalten. Bei Spam-Versand sollte außerdem der Hoster informiert werden, und in der Search Console lässt sich nach der Bereinigung eine erneute Prüfung beantragen, damit die Warnung im Suchergebnis verschwindet.
5. Ein Beispiel
Eine Zahnarztpraxis bemerkte nichts, bis Patienten anriefen: Wer die Praxis googelte und auf das Ergebnis klickte, landete auf einer fremden Seite. Angemeldet war die Website unauffällig. Der Hoster meldete zugleich massenhaften Mailversand. Nach der Sicherung wurde die Website offline genommen, alle Zugänge erneuert und der Kern neu eingespielt. Im Ordner uploads fanden sich drei PHP-Dateien mit harmlos klingenden Namen. Die Einstiegsstelle war ein seit zwei Jahren nicht aktualisiertes Formular-Plugin mit bekannter Lücke. Nach der Bereinigung folgten Zwei-Faktor-Anmeldung, automatische Sicherheitsupdates, eine Sperre für PHP in uploads und ein monatlicher Wartungstermin. Weil nur Kontaktnachrichten betroffen waren, wurde der Vorfall dokumentiert und gemeldet; die Praxis informierte die betroffenen Personen zusätzlich von sich aus.
6. Häufige Fragen
Reicht ein Sicherheits-Plugin? Es hilft beim Erkennen und erschwert Angriffe, ersetzt aber keine Updates und keine guten Passwörter. Ein Scanner findet zudem nicht jeden Schadcode – ein negativer Befund ist kein Beweis für Sauberkeit.
Kann ich einfach ein Backup einspielen? Nur, wenn es sicher aus der Zeit vor dem Vorfall stammt und die Lücke danach geschlossen wird. Sonst wiederholt sich alles. Prüfen Sie, wie weit die Sicherungen zurückreichen – viele Hoster bewahren nur sieben Tage auf.
Wer haftet? Verantwortlich für die Website ist der Betreiber. Wer die Pflege beauftragt, sollte vertraglich festhalten, wer Updates einspielt, wie schnell Sicherheitslücken geschlossen werden und wie Backups organisiert sind.
7. Übung zum Selbermachen
Schreiben Sie eine Notfallkarte für eine Website, die Sie betreuen: Wo liegen Zugangsdaten, wer ist beim Hoster Ansprechpartner, wo liegen Backups und wie alt sind sie, wer muss informiert werden, welche personenbezogenen Daten liegen auf dem System. Prüfen Sie anschließend drei Dinge praktisch: Lässt sich eine Sicherung tatsächlich wiederherstellen? Gibt es PHP-Dateien im Ordner uploads? Wie viele Administratorkonten existieren und werden alle noch gebraucht?
- [1]WordPress.org (2026): FAQ My Site Was Hacked; Hardening WordPress – Advanced Administration Handbook.
- [2]BSI (2025): Maßnahmenkatalog für Webseitenbetreiber; Reaktion auf IT-Sicherheitsvorfälle.
- [3]Art. 33, 34 DSGVO – Meldung von Verletzungen des Schutzes personenbezogener Daten.
Stand: September 2026, WordPress 7.1, PHP 8.3. Kursmaterial der Klarwerk Akademie. WordPress entwickelt sich schnell – maßgeblich ist die aktuelle Dokumentation auf developer.wordpress.org.