- Nach einem Hack gilt: erst isolieren und Spuren sichern, dann bereinigen. Wer zuerst aufräumt, vernichtet Beweise und öffnet Hintertüren für den nächsten Einbruch.
- Art. 33 DSGVO schreibt bei Datenpannen eine Meldung an die Datenschutzaufsicht vor, unverzüglich, spätestens 72 Stunden nach Bekanntwerden.
- Die häufigsten Einfallstore sind veraltete Plugins mit bekannten Lücken, schwache Passwörter und Erweiterungen aus unseriösen Quellen.
- Nach der Bereinigung bitte nicht vergessen: in der Google Search Console eine erneute Prüfung beantragen, sonst bleibt die Browser-Warnung länger bestehen als nötig.
Eines Montags geht ein Anruf ein: „Eure Website leitet auf eine Glücksspielseite weiter.“ Wer noch nie in dieser Situation war, unterschätzt, wie schnell der Kopf leer wird. Was tun zuerst? Alles löschen? Den Hoster anrufen? Kunden informieren? Dieser Ratgeber gibt Ihnen die Reihenfolge, die in solchen Momenten trägt, und erklärt kurz, warum die Schritte in genau dieser Folge stehen.
Woran Sie einen Hack erkennen
Der Angriff läuft in vielen Fällen schon eine Weile, bevor er auffällt. Automatisierte Crawler scannen das Netz rund um die Uhr nach bekannten Plugin-Lücken und nutzen sie sofort aus. Erst wenn Google die Seite in seine Safe-Browsing-Liste aufnimmt oder der Hoster die Website sperrt, weil sie für Spam-Versand missbraucht wird, bemerken viele Betreiber das Problem.
Klare Hinweise auf eine Kompromittierung sind:
- Browser zeigen eine rote Warnseite mit dem Hinweis auf Schadsoftware oder Phishing.
- Besucher werden auf fremde Domains umgeleitet, oft in Glücksspiel, Pharma oder Dating.
- Google Search Console meldet Sicherheitsprobleme oder zeigt im Index Seiten, die Sie nicht angelegt haben.
- Ihr Hoster hat die Website oder den E-Mail-Versand gesperrt, weil Spam-Mails von Ihrer Domain ausgesendet werden.
- Im WordPress-Administrationsbereich tauchen unbekannte Benutzerkonten auf.
- Dateimanager oder FTP zeigen neu angelegte PHP-Dateien, die Sie nicht kennen.
- Die Sucuri SiteCheck-Prüfung meldet Schadcode.
Nicht jede Auffälligkeit ist zwingend ein Hack. Eine defekte Weiterleitung durch ein Plugin-Update oder ein abgelaufenes SSL-Zertifikat erzeugen ebenfalls Browser-Warnungen. Der Unterschied liegt im Muster: Ist wirklich fremder Code im Spiel, finden sich meist mehrere der oben genannten Punkte gleichzeitig.
Schritt 1: Isolieren und Zugang sichern
Der erste Impuls ist verständlich: Website sofort offline nehmen, alles löschen, neu anfangen. Das ist in den meisten Fällen voreilig und kostet später mehr Zeit als es spart. Überlegen Sie kurz, was tatsächlich passiert:
- Werden Besucher aktiv umgeleitet? Dann raus aus dem Netz, sofort.
- Hat der Hoster bereits gesperrt, erledigt sich die Frage von selbst.
- Gibt es nur interne Auffälligkeiten ohne unmittelbare Gefahr? Dann nehmen Sie sich die Zeit, das System zu verstehen, bevor Sie eingreifen.
In jedem Fall sofort:
Alle Zugangsdaten ändern. Hosting-Panel, FTP und SFTP, den WordPress-Administrationsbereich und den Datenbankzugang. Vergeben Sie für jeden Zugang ein eigenes, langes Passwort. Wie Sie WordPress-Zugänge dauerhaft absichern, erklärt der Ratgeber WordPress Login absichern: Passwörter, Zwei-Faktor und Benutzerrollen.
Secret Keys erneuern. In der Datei wp-config.php stehen acht Sicherheitsschlüssel, die aktive Login-Sessions ungültig machen, sobald sie geändert werden. Neue Werte erzeugt der offizielle WordPress-Key-Generator. Die alten Zeilen in der wp-config.php einfach durch die neuen ersetzen. Damit wird auch ein Angreifer, der noch eingeloggt ist, sofort herausgeworfen.
Unbekannte WordPress-Benutzer deaktivieren. Prüfen Sie unter Benutzer im WordPress-Backend alle Konten. Administratoren, die Sie nicht kennen, sofort löschen.
Schritt 2: Beweise sichern, bevor Sie aufräumen
Wer direkt aufräumt, zerstört die Beweise. Serverprotokolle verraten, wann der Angreifer zum ersten Mal aktiv war, über welchen Pfad er eingedrungen ist und welche Dateien er verändert hat. Ohne diese Information bereinigen Sie vielleicht den sichtbaren Schaden, lassen aber die Hintertür offen, über die er hereinkam.
Sichern Sie jetzt:
- Alle Website-Dateien. Über den Dateimanager Ihres Hosters oder per FTP eine vollständige Kopie auf Ihren lokalen Rechner laden. Auch wenn die Dateien infiziert sind, werden sie für die spätere Analyse gebraucht.
- Serverprotokolle. Access-Log und Error-Log. Viele Hoster stellen diese im Control Panel unter einem Punkt wie Logs oder Statistiken bereit, manche nur auf Anfrage beim Support. Diese Protokolle zeigen in Zeitstempeln, welche Anfragen an den Server gingen, kurz bevor die Auffälligkeiten begannen.
- Datenbankexport. Eine Sicherung der Datenbank, auch im kompromittierten Zustand. Für den Fall, dass Sie später rekonstruieren müssen, was in der Datenbank stand.
Halten Sie außerdem schriftlich fest: wann Sie den Vorfall bemerkt haben, was genau zu sehen war, welche Personen in den letzten Wochen Zugriff auf das System hatten. Diese Dokumentation ist der erste Baustein eines Incident Reports, den Sie für eine eventuelle Datenschutzmeldung brauchen.
Schritt 3: Schadcode vollständig entfernen
Das ist der aufwändigste Teil. Die häufigste Falle: Man entfernt, was sichtbar ist, und übersieht eine versteckte Backdoor-Datei. Der Angreifer kehrt kurze Zeit später zurück. Gehen Sie deshalb systematisch vor.
Option A: Sauberes Backup einspielen
Ein Backup ist nur dann wirklich sauber, wenn es vor dem Zeitpunkt der Kompromittierung erstellt wurde. Das klingt selbstverständlich, ist es aber nicht immer. Wenn Serverprotokolle zeigen, dass der Angreifer schon seit vier Wochen aktiv war, taugt das Backup von letzter Woche nichts. Prüfen Sie anhand der Protokolle, ab wann verdächtige Anfragen auftauchen, und wählen Sie das letzte Backup davor. Was eine gute Backup-Strategie ausmacht und warum zeitgestaffelte Sicherungen mit externem Speicher so wichtig sind, erklärt der Ratgeber WordPress-Backup-Strategie: Der 3-2-1-Plan.
Wichtig: Nach dem Einspielen des Backups alle Zugangsdaten erneut ändern und die Secret Keys erneut erneuern, auch wenn das schon in Schritt 1 passiert ist. Das Backup enthält noch die alten Werte.
Option B: Manuelle Bereinigung ohne Backup
Haben Sie kein verlässliches Backup, müssen Sie das infizierte System bereinigen. Das ist aufwändiger, aber machbar.
WordPress-Core neu installieren. Laden Sie die aktuelle WordPress-Version von wordpress.org herunter und ersetzen Sie die Verzeichnisse /wp-admin und /wp-includes vollständig per FTP. Diese Verzeichnisse sollten keinerlei eigene Inhalte enthalten. Im Gegensatz zur Neuinstallation über den WordPress-Administrationsbereich werden so auch neu angelegte Dateien überschrieben, die ein Angreifer dort abgelegt hat. Das empfiehlt auch die offizielle WordPress-Dokumentation.
Plugins und Themes neu installieren. Deaktivieren Sie alle Plugins und installieren Sie sie aus dem offiziellen WordPress-Plugin-Verzeichnis neu. Themes ebenso. Verwenden Sie dabei ausschließlich die aktuellste Version aus einer geprüften Quelle. Plugins aus unbekannten Quellen oder sogenannte Nulled-Plugins, also raubkopierte kostenpflichtige Erweiterungen, fliegen raus.
Datenbank bereinigen. Viele Angriffe schleusen Code direkt in Datenbankfelder ein: Seiteninhalte, Widget-Einstellungen, die Tabelle wp_options. Suchen Sie per phpMyAdmin oder Adminer nach typischen Mustern wie eval(, base64_decode(, document.write( oder nach Weiterleitungscode in der wp_options-Tabelle (Felder home und siteurl).
.htaccess prüfen. Diese Datei im Webroot ist eines der am häufigsten manipulierten Ziele. Öffnen Sie sie und vergleichen Sie den Inhalt mit einer sauberen WordPress-.htaccess-Vorlage. Fremde Weiterleitungsregeln sind dort ein klares Zeichen.
Scanner als Ergänzung nutzen. Werkzeuge wie Wordfence oder der externe Sucuri SiteCheck erkennen bekannte Schadsoftware anhand ihrer Signaturen. Sie ersetzen die manuelle Prüfung nicht, geben aber einen guten ersten Überblick. Der externe Scanner von Sucuri sieht nur, was auf Browser-Ebene sichtbar ist; serverseitiger Schadcode bleibt ihm verborgen. Einen ausführlicheren Leitfaden zur Malware-Entfernung bietet der Ratgeber Malware in WordPress finden und sauber entfernen.
Schritt 4: Die Schwachstelle schließen
Das BSI benennt Patch-Management als eine der wichtigsten Schutzmaßnahmen für Betreiber von Webanwendungen: Bekannte Schwachstellen in eingesetzter Software müssen zeitnah durch Updates geschlossen werden. Für WordPress bedeutet das: Kern, Plugins und Theme müssen auf dem aktuellen Stand sein, bevor die Seite wieder live geht.
Die häufigsten Einfallstore bei WordPress-Seiten sind:
Veraltete Software. Nicht aktualisierte Plugins sind für einen großen Teil aller erfolgreichen Angriffe verantwortlich. Prüfen Sie mithilfe der gesicherten Serverprotokolle, welche Anfragen kurz vor dem Angriff auffällig waren. Oft zeigt sich direkt, welche Plugin-Datei aufgerufen wurde. Installieren Sie die aktuelle Version oder entfernen Sie das Plugin, wenn es keinen Unterhalt mehr hat.
Schwache oder mehrfach verwendete Passwörter. Automatisierte Brute-Force-Angriffe probieren Millionen von Kombinationen pro Stunde. Wer für FTP, Hosting und WordPress dasselbe Passwort verwendet, riskiert, dass ein kompromittierter Zugang alle Türen öffnet.
Plugins aus unseriösen Quellen. Nulled-Plugins enthalten häufig eingebauten Schadcode, der von vornherein eine Hintertür öffnet. Installieren Sie Erweiterungen ausschließlich aus dem offiziellen WordPress-Verzeichnis oder direkt beim Hersteller.
Fehlkonfigurierter Server. Zu weit gesetzte Schreibrechte auf Verzeichnisse (zum Beispiel 777 statt 755), eine offen erreichbare xmlrpc.php oder fehlende Sicherheitsheader vergrößern die Angriffsfläche. Was ein korrektes HTTPS-Setup und Sicherheitsheader leisten, erklärt der Ratgeber SSL, HTTPS und Sicherheitsheader einfach erklärt.
Kompromittiertes lokales Gerät. Manche Angriffe beginnen nicht am Server, sondern am Arbeitsrechner. Ein Trojaner auf dem Laptop liest FTP-Zugangsdaten mit, die der FTP-Client gespeichert hat. Lassen Sie Ihren Rechner von einem aktuellen Virenscanner prüfen, bevor Sie die Zugangsdaten nach der Bereinigung erneut einrichten.
Schritt 5: Prüfen, informieren und vorbeugen
Die Bereinigung ist abgeschlossen, aber die Seite ist noch nicht wieder live. Dieser letzte Schritt wird unter Zeitdruck oft abgekürzt, mit unangenehmen Folgen.
Funktionskontrolle. Öffnen Sie die Seite in einem privaten Browser-Fenster oder von einem anderen Gerät aus. Prüfen Sie, ob Formulare funktionieren, keine Weiterleitungen mehr aktiv sind und der Quelltext sauber aussieht. Ein kurzer Sucuri-SiteCheck-Scan gibt Ihnen eine externe Sicht.
Google Search Console. Wenn Ihre Website als kompromittiert markiert war oder Browser eine Warnung angezeigt haben, müssen Sie nach der Bereinigung aktiv eine erneute Prüfung beantragen. Den Antrag stellen Sie in der Search Console unter Sicherheitsprobleme. Ohne diesen Antrag bleibt die Warnung länger bestehen als nötig, weil Google sie nicht automatisch aufhebt.
Hoster informieren. Falls der Hoster die Seite gesperrt hat, braucht er eine Rückmeldung, dass die Bereinigung abgeschlossen ist, damit er die Sperre aufhebt. Bei manchen Hostern ist das ein formaler Prozess mit Bestätigung.
Für die Zukunft einrichten: regelmäßige Backups an einem externen Speicherort (täglich, automatisch), automatische Updates für WordPress-Core und Plugins, Zwei-Faktor für alle Zugänge. Der Rest kommt danach. Was ein umfassender Notfallplan für den Fall eines vollständigen Website-Ausfalls abdecken sollte, beschreibt der Ratgeber Disaster Recovery: Der Notfallplan, wenn die Seite komplett ausfällt.
DSGVO-Meldepflicht: Was gilt nach Art. 33
Ein Hack ist nicht automatisch eine meldepflichtige Datenpanne. Die entscheidende Frage ist, ob personenbezogene Daten betroffen sein könnten. Kontaktformular-Einsendungen, Kundendaten, Bestelldaten in einem Onlineshop oder E-Mail-Adressen zählen dazu.
Was Art. 33 DSGVO konkret vorschreibt:
- Frist: Meldung bei der zuständigen Datenschutzaufsichtsbehörde unverzüglich, spätestens 72 Stunden nach Bekanntwerden des Vorfalls.
- Adressat: Die Datenschutzaufsichtsbehörde des zuständigen Bundeslandes. Welche das für Ihr Unternehmen ist, richtet sich nach dem Sitz der verantwortlichen Stelle.
- Inhalt: Art der Verletzung, Anzahl betroffener Personen, Kontaktdaten des Datenschutzbeauftragten (sofern vorhanden), wahrscheinliche Folgen, ergriffene Abhilfemaßnahmen.
- Ausnahme: Keine Meldepflicht besteht, wenn die Verletzung voraussichtlich kein Risiko für die Rechte und Freiheiten natürlicher Personen mit sich bringt. Das müssen Sie aber dokumentiert begründen können.
Im Zweifel ist die Meldung der sicherere Weg. Eine nicht gemeldete Datenpanne kann als Verstoß gegen Art. 33 DSGVO geahndet werden. Wer sich unsicher ist, ob Daten abgeflossen sind, sollte einen Datenschutzbeauftragten hinzuziehen.
Zusätzlich zur Behördenmeldung gilt: Wenn der Angriff dazu geführt haben könnte, dass Kundendaten an Unbefugte gelangt sind, müssen die betroffenen Personen nach Art. 34 DSGVO informiert werden, sofern voraussichtlich ein hohes Risiko für sie besteht. Kunden merken, wenn ein Anbieter nach einer Datenpanne schweigt.
Übersicht: Schritte, Maßnahmen, Werkzeuge
| Schritt | Was tun | Werkzeug / Quelle |
|---|---|---|
| 1. Isolieren | Alle Zugangsdaten ändern (Hosting, FTP, WP-Admin, Datenbank), Secret Keys erneuern, unbekannte Benutzer löschen | WordPress-Key-Generator, Hosting-Panel |
| 2. Beweise sichern | Vollständige Dateikopie, Serverprotokolle (Access-/Error-Log), Datenbankexport erstellen | FTP-Client, Hoster-Support, phpMyAdmin |
| 3. Bereinigen | Sauberes Backup einspielen (bevorzugt) oder WordPress-Core/Plugins neu installieren, Datenbank auf Schadcode prüfen, .htaccess kontrollieren | Wordfence, Sucuri SiteCheck, wordpress.org/download |
| 4. Schwachstelle schließen | Ursache aus Protokollen ermitteln, Software aktualisieren, Konfiguration härten, lokalen Rechner scannen | Serverprotokolle, BSI Webanwendungen, WordPress Hardening |
| 5. Prüfen und melden | Funktionstest, Search Console, Hoster informieren, DSGVO-Meldung prüfen, Schutzmaßnahmen einrichten | Google Search Console, Sucuri SiteCheck, Landesdatenschutzbehörde |
Ein Beispiel aus der Praxis
In einem Projekt, das wir übernommen haben, lief eine WooCommerce-Installation seit mehreren Monaten ohne aktive Wartung. Das Plugin für das Buchungsformular war seit zwei Versionen nicht aktualisiert worden. Für genau diese Version gab es seit Wochen einen öffentlich bekannten Exploit. Über eine präparierte Anfrage an das Plugin schleuste der Angreifer eine Backdoor-Datei in das Upload-Verzeichnis ein.
Die Seite lief nach außen scheinbar normal weiter. Der Angreifer nutzte die Backdoor, um Spam-E-Mails über den Server zu versenden. Erst als der Hoster die Seite sperrte, weil die Server-IP auf einer Blacklist landete, wurde das Problem bemerkt.
Die Bereinigung dauerte einen halben Arbeitstag. Zwei Stunden davon entfielen auf die Analyse der Serverprotokolle, um sicherzustellen, dass keine Kundendaten abgegriffen worden waren. Das Ergebnis: keine personenbezogenen Daten betroffen, keine DSGVO-Meldung erforderlich, aber dokumentiert und begründet. Das Plugin wurde entfernt, der Server bereinigt, alle Zugänge erneuert. Eine monatliche Wartungspauschale für diesen Zeitraum hätte den Betreiber deutlich weniger gekostet als der Reparaturaufwand.
Sofort-Checkliste nach einem Hack
- Sind Besucher in Gefahr (Weiterleitungen auf Schadsoftware)? Falls ja, Website sofort offline nehmen.
- Alle Zugangsdaten geändert: Hosting-Panel, FTP/SFTP, WordPress-Admin, Datenbank?
- Secret Keys in der wp-config.php erneuert?
- Unbekannte WordPress-Benutzerkonten gelöscht?
- Vollständige Dateikopie und Serverprotokolle gesichert (vor der Bereinigung)?
- Datenbankexport erstellt?
- Vorfall dokumentiert: Datum, Uhrzeit, beobachtete Symptome?
- Sauberes Backup verfügbar? Falls ja: eingespielt und Zeitpunkt geprüft (vor dem Angriff)?
- Falls kein Backup: WordPress-Core, Plugins und Themes neu installiert?
- Datenbank auf Schadcode-Muster (eval, base64_decode) geprüft?
- .htaccess auf fremde Weiterleitungsregeln geprüft?
- Schwachstelle aus den Protokollen identifiziert und geschlossen?
- Alle Plugins und Themes auf aktuellem Stand?
- Lokalen Rechner mit Virenscanner geprüft?
- Seite funktional geprüft (privates Browser-Fenster, externer Scanner)?
- Google Search Console: erneute Prüfung beantragt, falls Warnung vorhanden?
- Hoster informiert, falls Sperre aktiv?
- Geprüft, ob personenbezogene Daten betroffen sein könnten (DSGVO Art. 33)?
- Falls Datenpanne: Meldung an Datenschutzaufsicht binnen 72 Stunden veranlasst?
- Automatische Backups, Update-Routine und Zwei-Faktor-Authentifizierung für die Zukunft eingerichtet?
- Die Reihenfolge ist entscheidend: erst isolieren und sichern, dann bereinigen. Wer zuerst aufräumt, vernichtet Beweise.
- Art. 33 DSGVO gilt: Sind personenbezogene Daten möglicherweise betroffen, muss die Datenschutzaufsicht unverzüglich, spätestens nach 72 Stunden informiert werden.
- Die häufigste Ursache sind veraltete Plugins mit bekannten Lücken, für die es seit Wochen ein Update gibt. Eine regelmäßige Update-Routine verhindert den größten Teil aller Angriffe.
- Nach der Bereinigung nicht vergessen: in der Google Search Console eine erneute Prüfung beantragen, sonst bleibt die Browser-Warnung aktiv.
Häufige Fragen
Muss ich die Polizei informieren, wenn meine Website gehackt wurde?
Eine gesetzliche Pflicht dazu besteht in den meisten Fällen nicht. Sinnvoll ist eine Anzeige bei der Polizei oder der Zentralen Ansprechstelle Cybercrime (ZAC) des jeweiligen Bundeslandes dann, wenn der Schaden erheblich ist, ein gezielter Angriff vermutet wird oder Sie rechtliche Schritte in Betracht ziehen. Die ZAC-Stellen haben Erfahrung mit IT-Vorfällen und beraten auch telefonisch.
Wie lange dauert eine professionelle Bereinigung?
Bei einer überschaubaren WordPress-Seite mit einem klaren Backup lässt sich die Bereinigung oft in zwei bis drei Stunden abschließen. Ist kein sauberes Backup vorhanden oder ist die Ursache schwer zu lokalisieren, können es ein bis zwei Arbeitstage sein. Bei Systemen ohne Backup und mit einer lang zurückliegenden Kompromittierung länger. Zeitdruck darf dabei nicht dazu führen, die Protokollanalyse abzukürzen.
Hilft ein SSL-Zertifikat gegen einen Hack?
Gegen die hier beschriebenen Angriffsformen nein. SSL und TLS verschlüsseln die Verbindung zwischen Browser und Server. Sie verhindern weder Code-Injection noch Brute-Force-Angriffe auf den Administrationsbereich, noch die Ausnutzung von Plugin-Schwachstellen. Ein HTTPS-Zertifikat ist notwendig, ersetzt aber kein Sicherheitskonzept.
Ich habe kein Backup. Bin ich verloren?
Nein. Prüfen Sie zuerst, ob Ihr Hoster automatische Snapshots erstellt, viele tun das täglich oder wöchentlich und bewahren diese Sicherungen für einige Zeit auf, auch ohne dass Sie das aktiv eingerichtet haben. Fragen Sie direkt beim Support nach. Ist kein Backup vorhanden, bleibt die manuelle Bereinigung des infizierten Systems. Das ist aufwändiger, aber in den meisten Fällen möglich.
Kann ich eine gehackte Website selbst bereinigen oder brauche ich Fachleute?
Das hängt von Ihren technischen Kenntnissen und vom Ausmaß des Angriffs ab. Wer mit FTP, phpMyAdmin und dem Lesen von Serverprotokollen vertraut ist, kann eine überschaubare WordPress-Installation in vielen Fällen selbst bereinigen. Sind große Datenmengen betroffen, hat der Angriff die Datenbankstruktur verändert, oder vermuten Sie, dass personenbezogene Daten abgeflossen sind, sollten Sie jemanden mit Erfahrung in der Vorfallsanalyse hinzuziehen.
Was ist der Unterschied zwischen einem Backup einspielen und manuell bereinigen?
Ein sauberes Backup ist schneller und zuverlässiger, weil es den Zustand vor dem Angriff vollständig wiederherstellt. Die manuelle Bereinigung ist aufwändiger und trägt das Risiko, eine versteckte Backdoor zu übersehen. Das Backup funktioniert aber nur, wenn es tatsächlich vor der Kompromittierung erstellt wurde und vollständig ist.