WordPress gehackt: Sofortmaßnahmen, Wiederherstellung und Prävention

Wenn eine WordPress-Website plötzlich fremde Inhalte ausliefert, Besucher weiterleitet oder unbekannte Administratoren auftauchen, zählt ein ruhiges und strukturiertes Vorgehen. Überstürztes Löschen kann Spuren vernichten, den Geschäftsbetrieb zusätzlich stören und die eigentliche Ursache unentdeckt lassen. Dieser Leitfaden zeigt, welche Sofortmaßnahmen sinnvoll sind, wie eine belastbare Wiederherstellung gelingt und was anschließend gegen einen erneuten Vorfall hilft. Er richtet sich an Website-Verantwortliche und beschreibt ausschließlich defensive Schritte.

Woran lässt sich eine kompromittierte WordPress-Website erkennen?

Nicht jeder Fehler ist ein Angriff. Ein fehlgeschlagenes Update kann ebenfalls eine weiße Seite, PHP-Fehler oder Darstellungsprobleme verursachen. Mehrere der folgenden Anzeichen sollten jedoch ernst genommen werden:

• Unbekannte Weiterleitungen, Werbeseiten oder Warnungen des Browsers beziehungsweise einer Suchmaschine
• Neue Administrator-Konten oder unerwartete Änderungen an bestehenden Benutzern
• Veränderte Beiträge, Spam-Seiten, fremde Links oder Suchergebnisse, die nicht zur Website gehören
• Ungewöhnlich hohe Serverlast, viele ausgehende E-Mails oder unbekannte Prozesse
• Geänderte Core-, Theme- oder Plugin-Dateien ohne dokumentiertes Update
• Login-Probleme, obwohl das Passwort nachweislich korrekt war
• Alarme des Hosters, eines Sicherheitsdienstes oder von Google Search Console

Ein einzelner Scan reicht weder für die Entwarnung noch für eine sichere Diagnose. Schadcode kann verschleiert sein, zeitgesteuert ausgeführt werden oder außerhalb des sichtbaren WordPress-Verzeichnisses liegen. Umgekehrt können Scanner legitime, aber ungewöhnliche Anpassungen beanstanden. Ergebnisse müssen daher im Kontext von Änderungsprotokollen, Dateizeitstempeln, Server- und Zugriffslogs bewertet werden.

Sofortmaßnahmen: Schaden begrenzen, Beweise erhalten

1. Verantwortliche und Hoster kontaktieren

Informieren Sie die intern verantwortliche Person und den Hosting-Anbieter. Der Hoster kann Netzwerkzugriffe begrenzen, Snapshots sichern, verdächtige Prozesse prüfen und verhindern, dass andere Systeme auf demselben Vertrag betroffen sind. Nutzen Sie für die Abstimmung möglichst einen Kommunikationskanal, der nicht von der kompromittierten Website oder ihrem Mailserver abhängt.

Bei einer geschäftskritischen Website sollte vor Änderungen festgelegt werden, wer Entscheidungen trifft und wer jeden Arbeitsschritt dokumentiert. Notieren Sie Zeitpunkt, beobachtetes Symptom, handelnde Person und durchgeführte Maßnahme. Diese Chronologie hilft bei technischer Analyse, Versicherungsfragen und einer möglichen datenschutzrechtlichen Bewertung.

2. Website kontrolliert isolieren

Begrenzen Sie den öffentlichen Zugriff in Abstimmung mit dem Hoster, ohne den Server vorschnell auszuschalten oder Dateien zu löschen. Je nach Lage kann eine Wartungsseite auf einer sauberen, getrennten Umgebung sinnvoll sein. Eine reine WordPress-Wartungsmodus-Erweiterung genügt nicht, wenn WordPress selbst kompromittiert ist. Auch ausgehende Verbindungen und der E-Mail-Versand können vorübergehend eingeschränkt werden, damit die Installation keinen weiteren Schaden verursacht.

Ist ein Onlineshop betroffen, müssen laufende Bestellungen, Zahlungsrückmeldungen und Schnittstellen bedacht werden. Eine unkoordinierte Sperre kann Dateninkonsistenzen erzeugen. Sicherheit hat Vorrang, doch der Zustand sollte bewusst und nachvollziehbar eingefroren werden.

3. Forensisch brauchbare Kopien sichern

Erstellen Sie vor der Bereinigung eine unveränderte Kopie der Dateien, Datenbank, Serverkonfiguration und verfügbaren Logs. Halten Sie Datum, Uhrzeit und Quelle fest und speichern Sie die Kopie schreibgeschützt beziehungsweise getrennt von der Live-Umgebung. Ein solcher Snapshot ist kein sauberes Wiederherstellungs-Backup; er bewahrt den kompromittierten Zustand zur späteren Ursachenanalyse.

Sichern Sie insbesondere Webserver-, PHP-, Authentifizierungs-, FTP/SFTP-/SSH- und Hosting-Panel-Logs. Log-Rotation kann relevante Einträge schnell überschreiben. Verändern Sie Dateizeitstempel nicht unnötig. Falls rechtliche oder erhebliche finanzielle Folgen möglich sind, sollte eine qualifizierte Incident-Response-Fachkraft die Beweissicherung begleiten.

4. Zugänge von einem sauberen Gerät absichern

Ändern Sie Passwörter nicht auf einem möglicherweise infizierten Computer. Nutzen Sie ein geprüftes Gerät und beginnen Sie mit E-Mail-Konten und dem Hosting- beziehungsweise Domain-Konto, da diese Zugänge häufig die Rücksetzung weiterer Konten erlauben. Danach folgen:

• WordPress-Administratoren und andere privilegierte Benutzer
• Hosting-Panel, SFTP/FTP, SSH und Datenbank
• Domain-Registrar, DNS, CDN und Backup-Dienst
• SMTP, Transaktionsmail und angebundene Drittanbieter
• API-Schlüssel, Webhooks und Deployment-Zugänge

Verwenden Sie für jeden Dienst ein neues, einzigartiges Passwort und aktivieren Sie Mehrfaktor-Authentifizierung, wo sie verfügbar ist. WordPress-Salts sollten nach der Beweissicherung erneuert werden; dadurch werden bestehende Sitzungen ungültig. Prüfen Sie außerdem Wiederherstellungsadressen, hinterlegte Telefonnummern, aktive Sitzungen und neu erstellte Schlüssel. Nur das WordPress-Passwort zu ändern reicht nicht, wenn Angreifer weiterhin über Hosting, SFTP oder eine Hintertür zugreifen können.

Datenschutz und Meldepflichten früh bewerten

Eine gehackte Website bedeutet nicht automatisch, dass personenbezogene Daten abgeflossen sind. Die Möglichkeit muss jedoch unverzüglich bewertet werden. Klären Sie, welche Daten verarbeitet wurden, ob Vertraulichkeit, Integrität oder Verfügbarkeit betroffen sind, wie viele Personen betroffen sein könnten und welche Folgen drohen.

Nach Artikel 33 DSGVO kann eine Meldung an die zuständige Aufsichtsbehörde erforderlich sein und muss grundsätzlich unverzüglich, möglichst binnen 72 Stunden nach Bekanntwerden einer meldepflichtigen Verletzung erfolgen. Artikel 34 regelt unter bestimmten Voraussetzungen die Benachrichtigung betroffener Personen. Ziehen Sie Datenschutzbeauftragte und Rechtsberatung hinzu; dieser technische Leitfaden ersetzt keine Rechtsberatung. Dokumentiert werden sollte die Bewertung auch dann, wenn keine Meldung erfolgt.

Ursache bestimmen, bevor die Website wieder online geht

Eine Bereinigung ist erst belastbar, wenn der wahrscheinliche Erstzugang und vorhandene Persistenzmechanismen untersucht wurden. Häufige Ursachen sind veraltete Erweiterungen, gestohlene Zugangsdaten, unsichere Serverkonten, manipulierte Entwicklergeräte oder falsch konfigurierte Dienste. Die bloße Aktualisierung eines Plugins entfernt bereits abgelegte Schadsoftware nicht.

Vergleichen Sie WordPress-Core-Dateien mit offiziellen Prüfsummen und Erweiterungen mit vertrauenswürdigen Originalpaketen. Untersuchen Sie Upload-Verzeichnisse auf unerwartet ausführbare Dateien, geplante Aufgaben, Must-use-Plugins, Drop-ins, Konfigurationsdateien, unbekannte Benutzer und geänderte Rollen. Kontrollieren Sie ebenso Dateien oberhalb des Dokumentenstamms, weitere Websites desselben Hosting-Kontos, Datenbankinhalte, Cronjobs und Serverkonfiguration. Eine vermeintlich saubere WordPress-Installation kann sonst aus einem benachbarten kompromittierten Projekt erneut infiziert werden.

Die offizielle WordPress-Dokumentation empfiehlt bei einem Hack ebenfalls, ruhig zu bleiben, den Hoster einzubeziehen, Zugangsdaten zu ändern, Backups zu prüfen und die Installation sorgfältig zu bereinigen. Eine professionelle WordPress-Notfallhilfe ist sinnvoll, wenn Ursache oder Umfang nicht sicher festgestellt werden können.

Saubere Wiederherstellung statt kosmetischer Reparatur

Die bevorzugte Strategie ist eine Wiederherstellung aus einem nachweislich sauberen Backup von vor dem ersten Eindringen. „Das Backup lief erfolgreich“ genügt nicht: Dateien und Datenbank müssen zusammenpassen, vollständig sein und sich in einer isolierten Umgebung wiederherstellen lassen. Bestimmen Sie anhand von Logs und Änderungen, ob das gewählte Sicherungsdatum tatsächlich vor der Kompromittierung liegt.

Ist kein vertrauenswürdiges Backup vorhanden, wird die Installation aus sauberen Quellen neu aufgebaut. WordPress-Core, Themes und Plugins sollten aus offiziellen Repositories oder direkt vom seriösen Hersteller stammen. Individuelle Anpassungen werden geprüft und kontrolliert übernommen. Unbekannte Dateien werden nicht einfach kopiert. Nicht mehr benötigte Themes, Plugins und Benutzer werden entfernt; veraltete oder nicht mehr gepflegte Komponenten ersetzt.

Die Datenbank erfordert eine eigene Prüfung. Beiträge und Bestellungen können nicht pauschal verworfen werden, aber auch dort können unerwünschte Administratoren, Spam-Inhalte, manipulierte Optionen oder eingeschleuste Skripte liegen. Bei Shops und Mitgliederseiten muss zusätzlich geklärt werden, welche legitimen Transaktionen seit dem letzten sauberen Backup erfolgt sind und wie sie kontrolliert übernommen werden.

Vor der Freigabe: technische und fachliche Verifikation

Eine fehlerfrei ladende Startseite beweist keine erfolgreiche Bereinigung. Prüfen Sie vor der Wiederinbetriebnahme mindestens:

1. Core-Dateien, Plugins und Themes stammen aus verifizierten Quellen und sind aktuell.
2. Alle Benutzer, Rollen, API-Schlüssel, Cronjobs und Serverzugänge sind plausibel.
3. Mehrere voneinander unabhängige Prüfmethoden zeigen keine Auffälligkeiten.
4. Startseite, Unterseiten, Formulare, Suche, Login und geschäftskritische Abläufe funktionieren.
5. DNS, HTTPS, Sicherheitsheader, Dateirechte und Schreibzugriffe sind korrekt konfiguriert.
6. Server-, Fehler- und Zugriffslogs werden nach der Freigabe engmaschig beobachtet.
7. Suchmaschinen-Warnungen und Blocklisten werden nach erfolgreicher Bereinigung zur erneuten Prüfung eingereicht.

Bewahren Sie die forensische Kopie entsprechend interner und rechtlicher Vorgaben auf. Ersetzen Sie sie nicht durch das bereinigte System. Dokumentieren Sie Ursache, Reichweite, entfernte Artefakte, erneuerte Zugänge und Testergebnisse in einem Abschlussbericht.

Prävention: Das Risiko dauerhaft reduzieren

Absolute Sicherheit gibt es nicht. Mit einem mehrschichtigen Konzept sinken Eintrittswahrscheinlichkeit und Schadenshöhe jedoch deutlich. Dazu gehören zeitnahe Updates, eine minimale Zahl gepflegter Erweiterungen, starke individuelle Konten, Mehrfaktor-Authentifizierung und möglichst geringe Rechte. Administrator-Zugänge sollten nur Personen erhalten, die sie tatsächlich benötigen.

Backups müssen automatisiert, versioniert und außerhalb des Webservers gespeichert werden. Entscheidend sind regelmäßige Wiederherstellungstests. Überwachung sollte Dateiänderungen, fehlgeschlagene Logins, neue Administratoren, Verfügbarkeitsprobleme und ungewöhnlichen E-Mail-Versand erfassen. Ein Web Application Firewall oder CDN kann zusätzliche Angriffe abfangen, ersetzt aber weder Updates noch sichere Zugänge.

Ebenso wichtig ist ein vorbereiteter Notfallplan: aktuelle Kontakte zu Hoster, Agentur, Datenschutz und Geschäftsverantwortlichen, definierte Entscheidungswege, bekannte Backup-Speicherorte und eine getrennt erreichbare Statusseite. Unsere Leistungen zur WordPress-Sicherheit und laufenden WordPress-Wartung verbinden Prävention, Backups, Updates und Kontrollen. Transparente Optionen finden Sie unter Preise.

Fazit: Erst eindämmen, dann nachvollziehbar wiederherstellen

Bei einem WordPress-Hack sind drei Ziele entscheidend: weiteren Schaden stoppen, verwertbare Spuren erhalten und nur ein geprüftes System wieder freigeben. Wer sofort einzelne verdächtige Dateien löscht oder ein beliebiges Backup einspielt, riskiert eine unvollständige Bereinigung. Ein dokumentierter Ablauf mit Hoster, sauberen Zugangsdaten, Ursachenanalyse und Nachkontrolle schafft dagegen eine belastbare Grundlage.

Sie vermuten einen Angriff? Über die Analyse-Anfrage können Sie die Situation kurz schildern. Wir prüfen die Ausgangslage und empfehlen den nächsten sinnvollen Schritt – knapp, nachvollziehbar und ohne unnötige Maßnahmen.

Quellen und weiterführende Hinweise

• WordPress.org: FAQ – My site was hacked
• WordPress Developer Resources: Hardening WordPress
• Bundesamt für Sicherheit in der Informationstechnik: Reaktion auf IT-Sicherheitsvorfälle
• DSGVO, Artikel 33: Meldung von Verletzungen des Schutzes personenbezogener Daten