WordPress gehackt? Genau darauf können diese Anzeichen hindeuten: Ihre Website leitet plötzlich auf fremde Seiten weiter? Google zeigt Unterseiten, die Sie nie erstellt haben, der Hosting-Anbieter meldet Malware oder im WordPress-Backend tauchen unbekannte Administratoren auf? Dann wurde Ihre Website möglicherweise kompromittiert.
Jetzt zählt schnelles Handeln — aber kein hektisches Löschen. Denn ein sichtbarer Schadcode ist häufig nur ein Teil des Problems. Wer lediglich auffällige Dateien entfernt oder vorschnell ein altes Backup einspielt, übersieht möglicherweise versteckte Backdoors, manipulierte Datenbankeinträge oder die ursprüngliche Sicherheitslücke. Die Website funktioniert dann vielleicht kurzfristig wieder. Sicher ist sie deshalb noch lange nicht.
In diesem Leitfaden erfahren Sie, woran Sie einen WordPress-Hack erkennen, welche Sofortmaßnahmen jetzt sinnvoll sind und wie eine kompromittierte Website vollständig bereinigt und anschließend dauerhaft abgesichert wird.
Das Wichtigste in 60 Sekunden
Wenn Ihre WordPress-Website möglicherweise gehackt wurde, gehen Sie in dieser Reihenfolge vor:
Website isolieren
Nehmen Sie die Website vorübergehend vom Netz, schützen Sie sie mit einem serverseitigen Passwort oder lassen Sie sie durch den Hosting-Anbieter sperren.
Aktuellen Zustand sichern
Erstellen Sie vor jeder Änderung eine vollständige Sicherung der Dateien, Datenbank und vorhandenen Server-Logs. Auch eine infizierte Kopie kann später für die Analyse wichtig sein.
Nicht nur sichtbaren Schadcode löschen
Auffällige Dateien oder Codezeilen sind häufig nur ein Teil der Infektion. Versteckte Backdoors oder manipulierte Datenbankeinträge können weiterhin bestehen.
Alle Zugänge absichern
Ändern Sie die Passwörter für WordPress, Hosting, SFTP, Datenbank und verbundene E-Mail-Konten. Beenden Sie nach Möglichkeit alle aktiven Sitzungen.
Weitere Systeme kontrollieren
Prüfen Sie, ob andere Websites im selben Hosting-Paket, zusätzliche Administratoren oder gemeinsam verwendete Benutzerkonten ebenfalls betroffen sind.
Möglichen Datenzugriff bewerten
Wenn Kontaktanfragen, Kundenkonten, Bestellungen oder andere personenbezogene Daten betroffen sein könnten, muss eine DSGVO-Risikobewertung durchgeführt werden.
Erst nach vollständiger Prüfung freigeben
Stellen Sie die Website erst wieder öffentlich online, wenn Schadcode und versteckte Zugänge entfernt, die Sicherheitslücke geschlossen und alle wichtigen Funktionen kontrolliert wurden.
Woran erkennen Sie, dass Ihre WordPress-Website gehackt wurde?
Ein Hack ist nicht immer ein schwarzer Bildschirm mit Totenkopf. Viele Infektionen bleiben bewusst unauffällig und sollen möglichst lange unentdeckt bleiben. Die Website kann auf den ersten Blick weiterhin normal funktionieren, während im Hintergrund Schadcode ausgeführt, Spam verbreitet oder der Zugriff für einen späteren Angriff offengehalten wird.
Folgende Anzeichen sollten Sie deshalb ernst nehmen.
Die Website leitet auf fremde Seiten weiter
Plötzlich landen Besucher auf Glücksspiel-, Medikamenten-, Dating- oder anderen dubiosen Spam-Seiten. Solche Weiterleitungen gehören zu den auffälligsten Anzeichen einer kompromittierten WordPress-Website.
Das Problem: Die Weiterleitung tritt häufig nicht bei jedem Seitenaufruf auf. Sie kann beispielsweise nur ausgelöst werden:
- beim ersten Besuch der Website
- auf Smartphones oder bestimmten Browsern
- bei Besuchern aus einer bestimmten Region
- nach einem Klick aus der Google-Suche
- oder wenn bestimmte Cookies noch nicht gesetzt wurden
Rufen Sie die Website hingegen direkt über die Adresszeile auf, wirkt möglicherweise alles völlig normal. Dadurch bleibt die Manipulation für Betreiber, Entwickler und Hosting-Anbieter teilweise lange unentdeckt.
Technisch werden solche Weiterleitungen unter anderem durch manipulierte PHP-Dateien, Datenbankeinträge oder eingeschleustes JavaScript ausgelöst. Der Schadcode wird dabei häufig verschleiert, aufgeteilt oder über externe Quellen nachgeladen, damit er bei einer oberflächlichen Kontrolle nicht sofort auffällt.
Google zeigt Seiten, die Sie nie erstellt haben
Ein weiteres Warnsignal sind unbekannte Inhalte in den Google-Suchergebnissen. Statt Ihrer normalen Leistungen oder Produkte erscheinen dort plötzlich:
- fremdsprachige Produkttitel
- Casino- oder Wettseiten
- Medikamentenangebote
- unbekannte Kategorien und URLs
- veränderte Seitentitel und Meta Descriptions
- oder Tausende neu indexierte Unterseiten
Diese Seiten müssen innerhalb von WordPress nicht zwingend als normale Beiträge oder Seiten sichtbar sein. Angreifer können Inhalte dynamisch erzeugen, direkt in der Datenbank ablegen oder nur für Suchmaschinen ausliefern.
Für den Betreiber sieht die Website weiterhin unverändert aus. Google findet jedoch völlig andere Inhalte. Häufig wird das Problem deshalb zuerst durch einen ungewöhnlichen Rückgang der Sichtbarkeit, fremde Suchbegriffe in der Google Search Console oder eine Kontrolle mit einer site:-Abfrage entdeckt.
Auch nach dem Entfernen des Schadcodes können die unerwünschten URLs noch einige Zeit in den Suchergebnissen erscheinen. Deshalb müssen nach der technischen Bereinigung zusätzlich Indexierung, Sitemaps, Weiterleitungen und Google Search Console kontrolliert werden.
Browser oder Google Search Console warnen vor der Website
Browser, Sicherheitsdienste oder Google können Besucher aktiv vor einer kompromittierten Website warnen. Mögliche Meldungen sind beispielsweise:
„Diese Website könnte gehackt worden sein“
„Gefährliche Website“
„Malware erkannt“
„Diese Website versucht möglicherweise, Ihre Daten zu stehlen“
Hinweise auf Social Engineering oder Phishing
Sicherheitsprobleme in der Google Search Console
Solche Warnungen sollten keinesfalls ignoriert werden. Sie können dazu führen, dass Besucher die Website nicht mehr aufrufen, Werbeanzeigen abgelehnt werden und das Vertrauen in das Unternehmen erheblich leidet.
Eine Warnung verschwindet außerdem nicht automatisch, sobald eine auffällige Datei gelöscht wurde. Zuerst muss die gesamte Website bereinigt und abgesichert werden. Anschließend kann je nach Warnung eine erneute Überprüfung beantragt werden.
Der Hosting-Anbieter hat die Website gesperrt
Hosting-Anbieter überwachen ihre Systeme häufig auf verdächtige Dateien, ungewöhnliche Serverprozesse, massenhaften E-Mail-Versand oder bekannte Malware-Muster. Wird eine mögliche Infektion erkannt, kann die Website vorübergehend gesperrt oder vollständig deaktiviert werden.
Das ist zunächst unangenehm, schützt aber:
- die Besucher der Website
- andere Kunden auf demselben Server
- die Reputation der Server-IP
- und den weiteren Versand von Spam oder Schadcode
Wichtig ist jedoch: Die Sperre beendet lediglich den öffentlichen Zugriff. Sie entfernt weder die Malware noch die ausgenutzte Sicherheitslücke.
Vor einer Entsperrung verlangt der Hosting-Anbieter häufig eine Bestätigung, dass die betroffenen Dateien bereinigt, veraltete Komponenten aktualisiert und kompromittierte Zugangsdaten ersetzt wurden. Eine reine Wiederaktivierung ohne gründliche Prüfung kann dazu führen, dass die Website kurz darauf erneut gesperrt wird.
Unbekannte Benutzer oder Administratoren sind aufgetaucht
Kontrollieren Sie die Benutzerverwaltung in WordPress. Neue oder veränderte Administratoren können darauf hinweisen, dass sich jemand dauerhaft Zugriff auf die Website verschaffen wollte.
Achten Sie insbesondere auf:
- neue Benutzerkonten mit Administratorrechten
- Namen oder Benutzernamen, die Ihnen unbekannt sind
- veränderte E-Mail-Adressen bestehender Benutzer
- unerwartete Nachrichten zum Zurücksetzen eines Passworts
- geänderte Benutzerrollen
- oder den Verlust Ihres eigenen Backend-Zugangs
Ein unbekannter Administrator darf nicht nur gelöscht werden. Zuerst muss geprüft werden, wie das Konto erstellt wurde und ob weitere Zugänge bestehen. Andernfalls kann der Angreifer möglicherweise unmittelbar einen neuen Benutzer anlegen.
Auch ehemalige Mitarbeiter, frühere Dienstleister und gemeinsam verwendete Administrator-Konten sollten überprüft werden. Je weniger privilegierte Zugänge bestehen, desto kleiner ist die mögliche Angriffsfläche.
Dateien, Plugins oder Cronjobs sind unbekannt
Nicht jede unbekannte Datei ist automatisch gefährlich. Auffällige Veränderungen sollten dennoch genauer geprüft werden.
Typische Warnsignale sind:
- Dateien mit zufällig wirkenden Namen
- PHP-Dateien im Upload-Verzeichnis
- unbekannte oder plötzlich installierte Plugins
- nicht sichtbare Must-use-Plugins
- veränderte WordPress-Core-Dateien
- neue oder unerklärliche Cronjobs
- ungewöhnlich große Dateien
- sowie verdächtige Änderungen an
.htaccessoderwp-config.php
Besonders kritisch sind Dateien, die nach dem Löschen wieder auftauchen. Das deutet häufig darauf hin, dass ein anderer Schadcode, ein Cronjob oder eine versteckte Backdoor die Infektion automatisch wiederherstellt.
Auch deaktivierte Plugins und Themes müssen geprüft werden. Nur weil eine Erweiterung nicht aktiv ist, bedeutet das nicht automatisch, dass darin enthaltene Dateien nicht direkt aufgerufen oder missbraucht werden können.
Die Website verhält sich langsam oder instabil
Eine plötzlich langsame oder instabile Website ist nicht automatisch gehackt. Gemeinsam mit anderen Auffälligkeiten kann eine ungewöhnlich hohe Serverlast jedoch auf eine Infektion hinweisen.
Mögliche Ursachen sind:
- zusätzliche Prozesse durch Schadcode
- automatisierter Versand von Spam-E-Mails
- massenhaft erzeugte Unterseiten
- externe Skripte und Weiterleitungen
- automatisierte Zugriffe auf die Datenbank
- oder der Missbrauch des Servers für fremde Aktivitäten
Typische Folgen sind lange Ladezeiten, Fehlermeldungen, wiederkehrende Ausfälle oder ungewöhnlich hoher Speicher- und Prozessorverbrauch.
Auch plötzlich wachsender Speicherplatz kann ein Signal sein. Manche Angriffe erzeugen große Mengen an Dateien, Backups, Spam-Seiten oder Protokolldaten. Deshalb sollte nicht nur WordPress selbst, sondern auch die Serverumgebung kontrolliert werden.
Aus unserer Praxis
Bei kompromittierten Websites ist der Schadcode nicht immer offen erkennbar. Wir haben unter anderem Fälle bereinigt, bei denen obfuskiertes JavaScript in eine WordPress-Website eingeschleust wurde.
Der Code war absichtlich so verändert und verschleiert worden, dass seine eigentliche Funktion beim Lesen kaum erkennbar war. Die unerwünschte Weiterleitung wurde außerdem nur unter bestimmten Bedingungen ausgelöst – beispielsweise bei ausgewählten Besuchern oder bestimmten Zugriffswegen.
Für den Betreiber sah die Website bei einem normalen direkten Aufruf deshalb teilweise völlig unauffällig aus. Erst die gezielte Kontrolle der veränderten Dateien, des eingeschleusten Codes und der jeweiligen Ausführungsbedingungen machte die Manipulation sichtbar.
Genau deshalb reicht es häufig nicht, eine Website einmal aufzurufen oder nur einen automatischen Sicherheitsscan durchzuführen. Entscheidend ist die Kombination aus technischer Analyse, Prüfung der Dateien und Datenbank sowie der Suche nach der ursprünglichen Sicherheitslücke.
WordPress gehackt – diese Sofortmaßnahmen sind jetzt richtig
Wenn der Verdacht auf einen WordPress-Hack besteht, zählt jede Stunde. Trotzdem ist hektisches Löschen meistens der falsche erste Schritt. Wer sofort Dateien entfernt, Updates einspielt oder irgendein Backup wiederherstellt, kann wichtige Spuren zerstören und die spätere Bereinigung erschweren.
Gehen Sie stattdessen kontrolliert vor. Ziel ist zunächst, weiteren Schaden zu begrenzen, den aktuellen Zustand zu sichern und herauszufinden, wie weit der Angriff reicht.
Website isolieren, aber nicht unkontrolliert löschen
Eine kompromittierte Website sollte nicht einfach öffentlich erreichbar bleiben. Besonders bei unerwünschten Weiterleitungen, Phishing-Inhalten, Malware-Warnungen oder Spam-Versand können Besucher und weitere Systeme gefährdet werden.
Kontaktieren Sie möglichst frühzeitig Ihren Hosting-Anbieter. Je nach technischer Umgebung kann die Website beispielsweise:
- serverseitig gesperrt
- durch einen Passwortschutz abgeschirmt
- auf eine statische Wartungsseite umgeleitet
- oder vorübergehend vom öffentlichen Netz genommen werden
Welche Maßnahme sinnvoll ist, hängt vom Schadensbild ab. Eine reine WordPress-Wartungsseite ist jedoch nicht immer ausreichend.
Wenn WordPress selbst kompromittiert wurde, läuft auch ein Maintenance-Plugin innerhalb derselben infizierten Installation. Schadcode kann dadurch möglicherweise weiterhin ausgeführt werden, direkte Dateiaufrufe bleiben erreichbar oder bestimmte Besucher werden trotz Wartungsmodus weitergeleitet.
Eine zuverlässige Isolierung sollte deshalb möglichst auf Server- oder Hosting-Ebene erfolgen.
Wichtig ist außerdem: Löschen Sie nicht sofort alle verdächtigen Dateien. Eine auffällige Datei kann Teil der Infektion sein, aber zugleich Hinweise auf den Angriffsweg, den Zeitpunkt der Veränderung oder weitere betroffene Bereiche liefern.
Die richtige Reihenfolge lautet:
Isolieren, sichern, analysieren – und erst danach bereinigen.
Den aktuellen Zustand und vorhandene Logs sichern
Bevor Änderungen vorgenommen werden, sollte der aktuelle Zustand der Website vollständig gesichert werden. Das gilt auch dann, wenn die Sicherung bereits Schadcode enthält.
Eine solche Kopie ist nicht automatisch zur späteren Wiederherstellung gedacht. Sie dient vor allem der technischen Analyse und Dokumentation.
Gesichert werden sollten nach Möglichkeit:
- das vollständige Dateisystem
- die WordPress-Datenbank
- Server- und Zugriffslogs
- PHP- und Fehlerprotokolle
- Meldungen des Hosting-Anbieters
- Warnungen aus der Google Search Console
- Screenshots auffälliger Inhalte
- bekannte Spam- oder Weiterleitungs-URLs
- E-Mails zu Passwortänderungen oder neuen Benutzern
- sowie der ungefähre Zeitpunkt der ersten Auffälligkeiten
Notieren Sie außerdem, wie das Problem entdeckt wurde.
Wichtige Fragen sind beispielsweise:
- Wann trat die Weiterleitung zum ersten Mal auf?
- Betrifft sie jeden Besucher oder nur bestimmte Geräte?
- Kam die Warnung von Google, vom Hoster oder von einem Kunden?
- Wurden kurz davor Plugins, Themes oder Benutzer verändert?
- Gab es ungewöhnliche Login-Versuche?
- Wurden neue Dateien oder Administratoren angelegt?
Diese Informationen können später dabei helfen, den Angriffszeitraum einzugrenzen und ein möglicherweise sauberes Backup zu identifizieren.
Server-Logs sind besonders wertvoll, werden aber je nach Hosting-Paket nur für einen begrenzten Zeitraum gespeichert. Sie sollten daher möglichst früh gesichert werden.
Auch Zeitstempel von Dateien können wichtige Hinweise liefern. Werden sofort Updates installiert oder Dateien ersetzt, verändern sich diese Informationen möglicherweise. Dadurch wird es schwieriger, nachvollziehen zu können, welche Bestandteile während des Angriffs manipuliert wurden.
Alle relevanten Zugänge absichern
Ein WordPress-Hack betrifft nicht zwangsläufig nur das WordPress-Backend. Angreifer können über verschiedene Zugangsebenen in eine Website gelangen oder sich nach dem ersten Zugriff weitere Zugänge einrichten.
Deshalb sollten alle mit der Website verbundenen Konten überprüft und abgesichert werden.
Dazu gehören insbesondere:
- WordPress-Administratoren
- das Kundenkonto beim Hosting-Anbieter
- Plesk, cPanel oder eine vergleichbare Verwaltungsoberfläche
- SFTP- und SSH-Zugänge
- Datenbank-Benutzer
- verbundene E-Mail-Konten
- Cloudflare oder andere CDN-Dienste
- externe Backup-Systeme
- Deployment- und Staging-Zugänge
- sowie verwendete API-Schlüssel
Ändern Sie für diese Konten die Passwörter und verwenden Sie für jeden Zugang ein eigenes, starkes Passwort. Ein kompromittiertes Passwort darf nicht lediglich leicht abgeändert oder an anderer Stelle wiederverwendet werden.
Wichtig ist die Reihenfolge: Zugangsdaten sollten nach Möglichkeit von einem vertrauenswürdigen, sauberen Gerät aus geändert werden. Besteht der Verdacht, dass auch der verwendete Computer kompromittiert ist, könnten neue Passwörter sonst unmittelbar erneut abgefangen werden.
Zusätzlich sollten Sie:
- aktive Sitzungen beenden
- unbekannte Benutzer entfernen
- Rollen und Berechtigungen kontrollieren
- WordPress-Security-Keys beziehungsweise Salts erneuern
- unnötige Administratoren herabstufen oder löschen
- und für privilegierte Konten eine Zwei-Faktor-Authentifizierung aktivieren
Die Erneuerung der WordPress-Salts sorgt dafür, dass bestehende Anmeldesitzungen ungültig werden. Benutzer müssen sich danach erneut anmelden. Das ist hilfreich, wenn unklar ist, ob ein Angreifer noch über eine aktive Session verfügt.
Achten Sie auch auf verbundene E-Mail-Adressen. Wer Zugriff auf das E-Mail-Konto eines Administrators hat, kann möglicherweise Passwörter zurücksetzen und sich trotz bereits geänderter WordPress-Zugangsdaten erneut anmelden.
Prüfen, ob weitere Websites betroffen sind
Befinden sich mehrere Websites im selben Hosting-Paket oder auf demselben Server, darf die Analyse nicht bei der offensichtlich betroffenen Installation enden.
Eine infizierte Website kann unter bestimmten Voraussetzungen als Ausgangspunkt dienen, um weitere Verzeichnisse oder Installationen zu manipulieren. Ebenso kann die sichtbare Infektion lediglich die Folge eines Problems in einer anderen Website desselben Accounts sein.
Eine erweiterte Kontrolle ist besonders wichtig bei:
- mehreren WordPress-Websites im selben Hosting-Paket
- Reseller-Hosting
- gemeinsam verwendeten Administrator-Konten
- identischen Passwörtern
- gemeinsam genutzten SFTP-Zugängen
- denselben Plugins oder Themes auf mehreren Websites
- gemeinsam eingebundenen Skripten
- oder einer möglicherweise infizierten lokalen Entwicklungsumgebung
Kontrollieren Sie auch alte Staging-Versionen, Testinstallationen und vergessene Unterverzeichnisse. Eine nicht mehr verwendete WordPress-Installation kann weiterhin öffentlich erreichbar sein und veraltete Plugins enthalten.
Solche Systeme werden häufig übersehen, weil sie nicht mehr aktiv genutzt werden. Für einen automatisierten Angriff spielt das jedoch keine Rolle. Solange eine verwundbare Datei erreichbar ist, kann sie als Einstiegspunkt dienen.
Auch Backups, ZIP-Dateien alter Website-Versionen oder frühere Migrationen sollten überprüft werden. Sie können sensible Konfigurationsdaten enthalten oder selbst bereits infiziert sein.
Keine übereilten Updates durchführen
WordPress, Plugins und Themes aktuell zu halten, ist ein wichtiger Bestandteil der Website-Sicherheit. Nach einem konkreten Sicherheitsvorfall ist ein sofortiges „Alles aktualisieren“ jedoch nicht immer der richtige erste Schritt.
Blind durchgeführte Updates können:
- Zeitstempel und Dateiinformationen verändern
- Hinweise auf den Angriffsweg überschreiben
- manipulierte Dateien nur teilweise ersetzen
- eigene Dateien des Angreifers unangetastet lassen
- eine bereits beschädigte Website zusätzlich destabilisieren
- oder die spätere Ursachenanalyse erschweren
Ein Plugin-Update entfernt beispielsweise nicht automatisch jede fremde Datei, die innerhalb des Plugin-Verzeichnisses abgelegt wurde. Auch manipulierte Datenbankeinträge, unbekannte Administratoren, Cronjobs oder PHP-Dateien im Upload-Verzeichnis bleiben dadurch bestehen.
Ebenso bedeutet eine aktuelle WordPress-Version nicht automatisch, dass die Website wieder sauber ist.
Updates sind Teil der Bereinigung und Absicherung – aber nicht deren Ersatz.
Die sichere Reihenfolge lautet daher:
- aktuellen Zustand sichern
- Umfang der Infektion analysieren
- Schadcode und Backdoors entfernen
- kompromittierte Komponenten aus vertrauenswürdigen Quellen ersetzen
- Sicherheitslücke schließen
anschließend kontrolliert aktualisieren und testen.
Bei geschäftskritischen Websites sollte dieser Vorgang möglichst nicht direkt auf der öffentlich erreichbaren Live-Website durchgeführt werden. Eine isolierte Kopie oder Staging-Umgebung ermöglicht eine gründlichere Prüfung, ohne Besucher oder laufende Geschäftsprozesse zusätzlich zu gefährden.
Möglichen Datenzugriff bewerten
Ein kompromittiertes WordPress-System ist nicht nur ein technisches Problem. Sobald personenbezogene Daten gespeichert, verarbeitet oder über die Website übertragen werden, muss geprüft werden, ob diese Daten möglicherweise betroffen waren.
Relevant sind beispielsweise:
- Nachrichten aus Kontaktformularen
- Kundenkonten
- WooCommerce-Bestellungen
- Rechnungs- und Lieferadressen
- Newsletter-Daten
- Mitgliederbereiche
- Bewerbungsunterlagen
- Terminbuchungen
- Support-Anfragen
- gespeicherte IP-Adressen
- Formulareinträge in der Datenbank
- Zugangsdaten
- oder API-Verbindungen zu externen Systemen
Dabei geht es nicht nur darum, ob Daten sichtbar veröffentlicht wurden.
Auch ein möglicher unbefugter Zugriff, eine Veränderung, Löschung oder zeitweise Nichtverfügbarkeit kann relevant sein. Deshalb sollte geprüft werden:
- Hatte der Angreifer Zugriff auf die Datenbank?
- Wurden Administratoren oder Datenbank-Benutzer angelegt?
- Gibt es Hinweise auf einen Datenexport?
- Wurden Formulare oder Checkout-Seiten manipuliert?
- Könnten Zugangsdaten abgefangen worden sein?
- Wurden externe Skripte eingebunden?
- Ist nachvollziehbar, wie lange der Zugriff bestand?
Gerade bei Onlineshops, Mitgliederplattformen und Bewerbungsseiten sollte die Bewertung nicht auf die WordPress-Dateien beschränkt werden.
Dokumentieren Sie alle bekannten Informationen und getroffenen Maßnahmen. Wenn ein Zugriff auf personenbezogene Daten nicht ausgeschlossen werden kann, sollte eine fachliche DSGVO-Risikobewertung erfolgen.
Die technische Bereinigung und die datenschutzrechtliche Beurteilung sind dabei zwei getrennte Aufgaben. Eine wieder funktionierende Website beantwortet noch nicht automatisch die Frage, ob Daten betroffen waren.
Professionelle Hilfe holen, wenn der Umfang unklar ist
Nicht jeder verdächtige Fund bedeutet automatisch eine großflächige Infektion. Umgekehrt kann eine Website unauffällig aussehen, obwohl weiterhin Backdoors oder manipulierte Datenbankeinträge vorhanden sind.
Professionelle Unterstützung ist besonders sinnvoll, wenn:
- die Website für den laufenden Geschäftsbetrieb wichtig ist
- Kundendaten oder Formulareinträge gespeichert werden
- ein WooCommerce-Shop betroffen ist
- Google oder der Hosting-Anbieter bereits eine Warnung ausgegeben hat
- die Website fremde Weiterleitungen zeigt
- Schadcode nach dem Löschen erneut auftaucht
- unbekannte Administratoren angelegt wurden
- kein nachweislich sauberes Backup vorhanden ist
- mehrere Websites auf demselben Server liegen
- oder der ursprüngliche Angriffsweg nicht eindeutig erkennbar ist
Auch wiederkehrende Infektionen sind ein klares Warnsignal. Wenn Schadcode nach einer vermeintlichen Bereinigung erneut erscheint, wurde häufig nur das sichtbare Symptom entfernt. Eine versteckte Backdoor, ein Cronjob, ein kompromittierter Zugang oder die ursprüngliche Schwachstelle kann weiterhin bestehen.
Eine professionelle Bereinigung sollte deshalb nicht nur die Frage beantworten:
- Welche Datei ist infiziert?
- Sondern auch:
- Wie kam der Angreifer hinein, welche Bereiche wurden verändert und wie verhindern wir, dass derselbe Zugriff erneut möglich ist?
Je früher diese Fragen geklärt werden, desto besser lassen sich Ausfallzeiten, Schäden an der Google-Sichtbarkeit und mögliche Risiken für Besucher und Kundendaten begrenzen.
Was Sie nach einem WordPress-Hack nicht tun sollten
Nach einem Sicherheitsvorfall ist der Wunsch verständlich, die Website so schnell wie möglich wieder online zu bringen. Genau dabei passieren jedoch häufig Fehler, die wichtige Spuren zerstören, die eigentliche Ursache übersehen oder eine erneute Infektion begünstigen.
Nur ein Security-Plugin installieren
Ein Security-Plugin oder Malware-Scanner kann verdächtige Dateien erkennen und wichtige Hinweise liefern. Ein grüner Haken bedeutet jedoch nicht automatisch, dass die Website vollständig bereinigt ist.
Automatisierte Scans erfassen nicht immer:
- manipulierte Datenbankeinträge
- versteckte Benutzerkonten
- schädliche Cronjobs
- externe Skripte
- unbekannte Must-use-Plugins
- kompromittierte Zugangsdaten
- oder Sicherheitsprobleme in der Hosting-Umgebung
Ein Scanner ist ein Werkzeug. Keine vollständige Ursachenanalyse.
Nur die auffällige Codezeile löschen
Die sichtbar verdächtige Codezeile ist häufig nur das Symptom der Infektion.
Bei obfuskiertem JavaScript, eingeschleusten PHP-Dateien oder versteckten Backdoors kann Schadcode:
- auf mehrere Dateien verteilt sein
- über die Datenbank nachgeladen werden
- nur unter bestimmten Bedingungen aktiv werden
- sich nach dem Löschen selbst wiederherstellen
- oder einen weiteren Zugang für den Angreifer offenhalten
Wer nur den zuerst gefundenen Code entfernt, sorgt möglicherweise dafür, dass die Website kurzfristig wieder normal aussieht. Die eigentliche Sicherheitslücke bleibt jedoch bestehen.
Sofort irgendein altes Backup einspielen
Ein vorhandenes Backup ist wertvoll – aber nur dann, wenn es nachweislich aus einer sauberen Version der Website stammt.
Wird ein beliebiges älteres Backup eingespielt, kann es:
- dieselbe Malware bereits enthalten
- veraltete und unsichere Plugins zurückbringen
- aktuelle Inhalte oder Bestellungen überschreiben
- manipulierte Benutzerkonten wiederherstellen
- oder erneut in dieselbe offene Sicherheitslücke eingespielt werden
Vor einer Wiederherstellung muss deshalb geklärt werden, wann der Angriff vermutlich begonnen hat und wodurch der Zugriff möglich wurde.
Ein Backup ersetzt keine Ursachenanalyse.
Die Website trotz Weiterleitungen online lassen
Eine kompromittierte Website sollte nicht einfach weiterlaufen, nur weil die Weiterleitung nicht bei jedem Aufruf sichtbar ist.
Damit riskieren Sie:
- Besucher auf schädliche oder betrügerische Seiten weiterzuleiten
- Malware oder Phishing-Inhalte auszuliefern
- laufende Google- oder Meta-Kampagnen zu gefährden
- Browser- und Suchmaschinenwarnungen auszulösen
- Rankings und Sichtbarkeit zu verlieren
- sowie das Vertrauen von Kunden und Geschäftspartnern zu beschädigen
Besonders gefährlich sind Manipulationen, die nur bei mobilen Nutzern, beim ersten Besuch oder nach einem Klick aus Google ausgelöst werden. Für den Betreiber wirkt die Website möglicherweise normal, während echte Besucher weiterhin betroffen sind.
Annehmen, dass eine wieder funktionierende Website automatisch sicher ist
Eine Website kann wieder erreichbar sein, korrekt aussehen und alle wichtigen Funktionen erfüllen – und trotzdem weiterhin kompromittiert sein.
Im Hintergrund können noch immer:
- versteckte Administratoren bestehen
- Spam-Seiten an Google ausgeliefert werden
- Schadcode zeitgesteuert aktiviert werden
- nur bestimmte Besucher weitergeleitet werden
- externe Skripte Daten nachladen
- oder Backdoors einen erneuten Zugriff ermöglichen
Auch das Verschwinden einer Browser-Warnung oder einer offensichtlichen Fehlermeldung beweist nicht, dass alle Manipulationen entfernt wurden.
„Die Website funktioniert wieder“ ist noch kein Sicherheitsbericht.
So läuft eine professionelle WordPress-Malware-Bereinigung ab
Eine professionelle Malware-Bereinigung besteht nicht darin, einen Scanner zu starten und alle rot markierten Dateien zu löschen. Zuerst muss geklärt werden, wie weit der Angriff reicht, welche Bestandteile verändert wurden und ob weiterhin ein Zugang für den Angreifer besteht.
Erst danach kann die Website kontrolliert bereinigt, abgesichert und wieder freigegeben werden.
Ersteinschätzung und Schadensbegrenzung
Am Anfang steht eine strukturierte Aufnahme der aktuellen Situation. Dabei wird geklärt, welche Symptome auftreten, seit wann das Problem bekannt ist und wie dringend gehandelt werden muss.
Typische Fragen sind:
- Leitet die Website Besucher auf fremde Seiten weiter?
- Gibt es Warnungen des Hosting-Anbieters oder von Google?
- Ist das WordPress-Backend noch erreichbar?
- Wurden unbekannte Benutzer oder Administratoren entdeckt?
- Verschickt die Website ungewöhnlich viele E-Mails?
- Sind ein Onlineshop, Formulare oder Kundendaten betroffen?
- Befinden sich weitere Websites im selben Hosting-Paket?
Auf dieser Grundlage wird entschieden, welche Sofortmaßnahmen erforderlich sind. Bei gefährlichen Weiterleitungen, Phishing-Inhalten oder aktivem Schadcode muss die Website gegebenenfalls umgehend isoliert werden.
Gleichzeitig werden bestehende Zugriffe kontrolliert und relevante Hinweise dokumentiert. Dazu gehören beispielsweise:
- Warnmeldungen des Hosters
- Einträge in der Google Search Console
- Browser-Warnungen
- Screenshots auffälliger Inhalte
- verdächtige URLs
- unbekannte Benutzer
- sowie der vermutete Zeitraum der Infektion
Ziel dieser ersten Phase ist nicht, die Website vorschnell wieder online zu bringen. Zuerst muss verhindert werden, dass weiterer Schaden entsteht oder wichtige Spuren verloren gehen.
Umfang des Angriffs prüfen
Eine Infektion beschränkt sich nicht zwangsläufig auf die Datei, in der der erste Schadcode gefunden wurde. Angreifer legen häufig mehrere Zugriffsmöglichkeiten an oder verändern unterschiedliche Bereiche einer WordPress-Installation.
Deshalb muss die gesamte technische Umgebung geprüft werden.
Dazu gehören insbesondere:
- WordPress-Core-Dateien
- aktive und inaktive Plugins
- aktive und nicht verwendete Themes
- Must-use-Plugins
- das Upload-Verzeichnis
- die WordPress-Datenbank
- Benutzerkonten und Rollen
- WordPress-Cronjobs
- Server- und PHP-Konfigurationen
.htaccesswp-config.php- Server-, Fehler- und Zugriffslogs
- sowie weitere Websites im selben Hosting-Paket
Auch Verzeichnisse außerhalb der eigentlichen WordPress-Installation können relevant sein. Dazu zählen alte Staging-Seiten, Testinstallationen, vergessene Backups oder frühere Website-Versionen.
Bei mehreren WordPress-Websites auf demselben Hosting muss außerdem geprüft werden, ob die sichtbare Infektion tatsächlich dort entstanden ist oder von einer anderen kompromittierten Installation ausging.
Eine gründliche Analyse beantwortet deshalb nicht nur:
- Wo befindet sich der auffällige Schadcode?
- Sondern auch:
- Welche Systeme konnten erreicht werden und welche weiteren Zugriffsmöglichkeiten bestehen möglicherweise noch?
Manipulierte Dateien und Datenbankeinträge finden
Im nächsten Schritt werden Dateien und Datenbankinhalte systematisch auf Veränderungen untersucht.
Ein wichtiger Teil der Analyse ist der Vergleich mit sauberen Originaldateien. WordPress-Core, Plugins und Themes können mit den offiziellen beziehungsweise vertrauenswürdigen Ausgangsversionen verglichen werden. Dadurch lassen sich fremde Ergänzungen, veränderte Funktionen und ungewöhnliche Dateien leichter erkennen.
Geprüft werden unter anderem:
- kürzlich veränderte Dateien
- Dateien an ungewöhnlichen Speicherorten
- verdächtige JavaScript- und PHP-Skripte
- obfuskiertes beziehungsweise absichtlich verschleiertes JavaScript
- eingeschleuste PHP-Dateien
- fremde Iframes oder externe Skripte
- Spam-Inhalte in der Datenbank
- veränderte WordPress-Optionen
- manipulierte Widgets
- unbekannte Weiterleitungen
- sowie Inhalte, die nur für Suchmaschinen oder bestimmte Besucher ausgeliefert werden
Auch Datenbankeinträge können Schadcode enthalten. Häufig wird nur das Dateisystem kontrolliert, obwohl Weiterleitungen oder externe Skripte beispielsweise in Optionen, Beiträgen, Widgets oder Theme-Einstellungen gespeichert wurden.
Besonders vorsichtig muss mit vermeintlich eindeutig verdächtigen Codebestandteilen umgegangen werden.
Nicht jede Verwendung von base64, verschleierten Variablen, dynamischen Funktionen oder langen Zeichenketten ist automatisch Malware. Auch legitime Plugins können Code komprimieren, codieren oder dynamisch ausführen.
Verdächtiger Code muss deshalb immer im jeweiligen Kontext geprüft werden:
- Wo befindet er sich?
- Zu welcher Erweiterung gehört die Datei?
- Existiert derselbe Code in der offiziellen Originalversion?
- Wann wurde die Datei verändert?
- Welche Funktion wird tatsächlich ausgeführt?
- Wird externer Code nachgeladen?
- Unter welchen Bedingungen wird die Funktion aktiviert?
Wer pauschal jede auffällige Zeichenkette löscht, kann wichtige Funktionen beschädigen und trotzdem den eigentlichen Schadcode übersehen.
WordPress-Core, Plugins und Themes sauber ersetzen
Wurde eine WordPress-Installation kompromittiert, reicht es häufig nicht aus, einzelne Codezeilen zu reparieren. Manipulierte Komponenten sollten nach Möglichkeit vollständig durch saubere Originalversionen ersetzt werden.
Dabei wird der WordPress-Core aus einer vertrauenswürdigen Quelle neu eingespielt. Bestehende Inhalte und Konfigurationen bleiben erhalten, während die ursprünglichen Core-Dateien sauber ersetzt werden.
Auch Plugins und Themes sollten nicht aus der kompromittierten Installation kopiert, sondern aus offiziellen oder verifizierten Quellen neu installiert werden.
Das bedeutet:
- WordPress-Core sauber ersetzen
- Plugins aus Originalquellen neu einspielen
- Themes aus vertrauenswürdigen Quellen ersetzen
- nicht mehr verwendete Erweiterungen vollständig entfernen
- verlassene oder nicht mehr gepflegte Plugins austauschen
- unnötige Themes löschen
- und keine alten ZIP-Dateien unbekannter Herkunft wiederverwenden
Deaktivierte Plugins und Themes dürfen nicht automatisch behalten werden. Solange deren Dateien auf dem Server liegen, können verwundbare Bestandteile unter Umständen weiterhin direkt aufgerufen werden.
Besonders kritisch sind Erweiterungen, die:
- seit längerer Zeit keine Updates erhalten haben
- nicht mehr mit der aktuellen WordPress-Version kompatibel sind
- aus unbekannten Quellen stammen
- verändert wurden
- oder nicht mehr benötigt werden
Laufende Updates von WordPress-Core, Plugins und Themes gehören zu den wichtigsten Grundlagen einer sicheren WordPress-Installation. Nach einem Angriff dürfen Updates allerdings erst erfolgen, nachdem der aktuelle Zustand gesichert und die Infektion analysiert wurde.
Schadcode und Backdoors entfernen
Erst nach der Analyse beginnt die eigentliche Bereinigung.
Dabei müssen nicht nur die offensichtlichen Malware-Dateien entfernt werden. Ebenso wichtig ist die Suche nach Mechanismen, mit denen der Schadcode nach dem Löschen erneut hergestellt oder ein späterer Zugriff ermöglicht werden kann.
Eine vollständige Bereinigung kann unter anderem umfassen:
- eingeschleusten Schadcode entfernen
- manipulierte Dateien sauber ersetzen
- versteckte PHP-Backdoors löschen
- unbekannte Administratoren entfernen
- Benutzerrollen korrigieren
- verdächtige Cronjobs deaktivieren
- manipulierte Konfigurationen reparieren
- schädliche Datenbankeinträge entfernen
- externe Skripte kontrollieren
- Weiterleitungen beseitigen
- und unerwünschte Spam-Inhalte löschen
Backdoors sind besonders kritisch. Sie ermöglichen dem Angreifer einen erneuten Zugriff, auch wenn die ursprünglich ausgenutzte Sicherheitslücke bereits geschlossen wurde.
Solche Zugriffsmöglichkeiten können sich beispielsweise verstecken in:
- scheinbar harmlosen PHP-Dateien
- dem Upload-Verzeichnis
- Must-use-Plugins
- Theme-Dateien
- manipulierten Core-Dateien
- Cronjobs
- unbekannten Benutzerkonten
- oder der Datenbank
Auch wenn die sichtbare Weiterleitung nach dem Löschen einer Datei verschwindet, kann an anderer Stelle weiterhin eine Zugriffsmöglichkeit bestehen.
Eine professionelle Bereinigung endet deshalb nicht mit dem ersten erfolgreichen Seitenaufruf.
Den ursprünglichen Angriffsweg schließen
Nachdem Schadcode und Backdoors entfernt wurden, muss geklärt werden, wie der Zugriff ursprünglich möglich war.
Mögliche Ursachen sind unter anderem:
- ein veraltetes Plugin
- ein unsicheres oder manipuliertes Theme
- ein kompromittiertes WordPress-Passwort
- geleakte Zugangsdaten
- ein unzureichend geschütztes Hosting-Konto
- ein infizierter lokaler Computer
- eine verlassene Erweiterung
- unsichere Dateirechte
- ein offener SFTP- oder SSH-Zugang
- oder mehrere nicht ausreichend voneinander getrennte Websites
Nicht in jedem Fall lässt sich der ursprüngliche Angriffsweg zweifelsfrei rekonstruieren. Fehlende oder bereits gelöschte Logs können die Analyse erschweren. Trotzdem müssen alle wahrscheinlichen Zugriffswege überprüft und abgesichert werden.
Dabei wird beispielsweise kontrolliert:
- Welche Erweiterungen waren zum vermuteten Angriffszeitpunkt installiert?
- Gab es bekannte Schwachstellen?
- Welche Benutzer haben Administratorrechte?
- Wurden Passwörter mehrfach verwendet?
- Existieren alte oder vergessene Zugänge?
- Sind weitere Websites im Account kompromittiert?
- Waren Dateirechte zu großzügig gesetzt?
- Wurde das Hosting-Konto selbst übernommen?
- Könnten Zugangsdaten von einem lokalen Gerät abgegriffen worden sein?
Wer nur aufwischt, aber das offene Fenster nicht schließt, darf bald wieder anfangen.
Ohne Ursachenbehebung besteht ein hohes Risiko, dass die Website erneut kompromittiert wird.
Alle Zugänge und Sicherheitsmechanismen erneuern
Nach einer Infektion sollten sämtliche sicherheitsrelevanten Zugangsdaten als potenziell kompromittiert betrachtet werden.
Das betrifft nicht nur WordPress selbst.
Erneuert beziehungsweise überprüft werden sollten:
- WordPress-Passwörter
- Hosting-Zugangsdaten
- Plesk- oder cPanel-Zugänge
- SFTP- und SSH-Passwörter
- Datenbank-Benutzer und Datenbank-Passwörter
- WordPress-Security-Keys beziehungsweise Salts
- Administrator-Konten
- verbundene E-Mail-Adressen
- API-Schlüssel
- CDN- und Cloudflare-Zugänge
- Backup-Systeme
- sowie externe Dienste und Schnittstellen
Nicht mehr benötigte Zugänge werden entfernt. Bestehende Konten erhalten nur jene Rechte, die tatsächlich erforderlich sind.
Zusätzlich sollten:
- Zwei-Faktor-Authentifizierung eingerichtet
- gemeinsame Administrator-Logins abgeschafft
- ehemalige Dienstleister entfernt
- Rollen und Berechtigungen reduziert
- aktive Sitzungen beendet
- und für alle Systeme eindeutige Passwörter verwendet werden
Die Änderung der WordPress-Salts beendet bestehende Anmeldesitzungen. Das verhindert, dass ein Angreifer über eine bereits aktive Session weiterhin Zugriff behält.
Auch die hinterlegten E-Mail-Adressen müssen geprüft werden. Wer Zugriff auf das E-Mail-Konto eines Administrators besitzt, kann möglicherweise neue Passwörter anfordern und die Website erneut übernehmen.
Website in einer kontrollierten Umgebung testen
Nach der technischen Bereinigung sollte die Website nicht sofort ungeprüft wieder öffentlich erreichbar gemacht werden.
Zuerst wird sie in einer kontrollierten Umgebung getestet. Je nach Hosting und Website kann dafür eine isolierte Kopie, eine Staging-Umgebung oder eine serverseitig geschützte Version verwendet werden.
Dabei werden nicht nur Sicherheitsaspekte geprüft. Durch das Ersetzen von Dateien, Plugins und Themes können auch funktionale Probleme entstehen.
Kontrolliert werden sollten insbesondere:
- Kontaktformulare
- WooCommerce-Checkout
- Zahlungsanbieter
- Warenkorb und Kundenkonto
- E-Mail-Versand
- WordPress-Login
- Benutzerrollen
- mobile Darstellung
- interne und externe Weiterleitungen
- Tracking und Consent-Management
- Performance
- externe Schnittstellen
- Newsletter-Verbindungen
- Caching
- sowie bestehende Automatisierungen
Zusätzlich wird getestet, ob die ursprünglichen Symptome vollständig verschwunden sind.
Bei einer Weiterleitungsinfektion bedeutet das beispielsweise:
- direkte Aufrufe testen
- Zugriffe über Google simulieren
- unterschiedliche Browser verwenden
- mobile Geräte prüfen
- Cookies und Cache löschen
- Inkognito-Modus verwenden
- und betroffene URLs gezielt aufrufen
Gerade bedingte Weiterleitungen können bei einem normalen Desktop-Aufruf unsichtbar bleiben. Deshalb müssen die Bedingungen berücksichtigt werden, unter denen die Manipulation zuvor ausgelöst wurde.
Auch externe Caches, CDN-Dienste und Browser-Caches müssen kontrolliert beziehungsweise geleert werden. Andernfalls können bereits entfernte Inhalte weiterhin ausgeliefert werden.
Website wieder freigeben und überwachen
Erst wenn Schadcode entfernt, Zugriffsmöglichkeiten geschlossen und alle wichtigen Funktionen getestet wurden, sollte die Website wieder öffentlich freigegeben werden.
Damit ist der Vorgang jedoch noch nicht vollständig abgeschlossen.
In den Tagen und Wochen nach der Bereinigung sollte die Website gezielt überwacht werden. Dadurch lassen sich ungewöhnliche Veränderungen oder ein erneuter Zugriff frühzeitig erkennen.
Sinnvolle Maßnahmen sind:
- Dateiveränderungen beobachten
- Server- und Zugriffslogs prüfen
- regelmäßige Malware-Scans durchführen
- Uptime-Monitoring einrichten
- Google Search Console kontrollieren
- neue Benutzerkonten überwachen
- fehlgeschlagene Login-Versuche beobachten
- ungewöhnliche Serverlast prüfen
- E-Mail-Versand kontrollieren
- und Backups extern speichern
Bei einer vorherigen Google- oder Browser-Warnung muss zusätzlich geprüft werden, ob eine erneute Sicherheitsüberprüfung beantragt werden kann.
Spam-URLs, fremde Seitentitel oder manipulierte Suchergebnisse verschwinden häufig nicht sofort aus Google. Deshalb müssen auch nach der technischen Bereinigung:
- indexierte Spam-Seiten kontrolliert
- Sitemaps überprüft
- unerwünschte URLs korrekt beantwortet
- Sicherheitsprobleme in der Search Console bearbeitet
- und auffällige Suchanfragen beobachtet werden
- Eine erfolgreiche Malware-Bereinigung besteht somit aus drei Teilen:
Schadcode entfernen. Sicherheitslücke schließen. Website anschließend überwachen.
Erst diese Kombination reduziert das Risiko, dass dasselbe Problem wenige Tage später erneut auftritt.
Praxisfall: Obfuskiertes JavaScript in einer WordPress-Website
Wie unauffällig eine kompromittierte WordPress-Website wirken kann, zeigt ein Fall aus unserer Praxis. Betroffen war eine geschäftlich genutzte Website, die auf den ersten Blick weiterhin normal funktionierte. Inhalte waren erreichbar, das WordPress-Backend ließ sich öffnen und auch beim direkten Aufruf der Domain trat nicht jedes Mal ein sichtbares Problem auf.
Trotzdem wurden einzelne Besucher plötzlich auf fremde Spam-Seiten weitergeleitet.
Ausgangssituation
Die Weiterleitung war nicht dauerhaft sichtbar. Sie trat nur unter bestimmten Bedingungen auf und ließ sich deshalb zunächst nur schwer reproduzieren.
Beim normalen Aufruf der Website konnte alles unauffällig wirken. Abhängig vom Zugriffsweg, vom verwendeten Gerät oder von bereits gesetzten Cookies wurde jedoch fremder Inhalt geladen und der Besucher auf eine externe Website weitergeleitet.
Genau solche bedingten Weiterleitungen sind besonders problematisch: Der Betreiber kontrolliert die Website mehrmals und sieht keinen Fehler, während tatsächliche Besucher weiterhin betroffen sein können.
Dass die Website augenscheinlich funktionierte, war daher kein Beweis dafür, dass sie sauber war.
Analyse
Bei der technischen Analyse wurde eingeschleustes JavaScript gefunden, dessen eigentliche Funktion absichtlich verschleiert worden war.
Der Code bestand nicht aus einer offen erkennbaren Anweisung wie:
„Leite den Besucher auf diese Website weiter.“
Stattdessen wurden Variablen, Zeichenketten und Funktionsaufrufe so verändert und zusammengesetzt, dass die tatsächliche Wirkung beim bloßen Lesen kaum nachvollziehbar war. Dieses Vorgehen wird als Obfuskation bezeichnet.
Obfuskierter Code ist nicht automatisch Schadcode. Auch legitime Anwendungen können JavaScript komprimieren oder verschleiern. Entscheidend ist deshalb immer der Zusammenhang:
- In welcher Datei wurde der Code gefunden?
- Gehört er zur ursprünglichen Version des Plugins oder Themes?
- Wann wurde die Datei verändert?
- Welche externen Quellen werden aufgerufen?
- Unter welchen Bedingungen wird der Code ausgeführt?
- Welche Wirkung hat er im Browser des Besuchers?
In diesem Fall zeigte die genauere Prüfung, dass der eingeschleuste Code nicht zur ursprünglichen Website gehörte und für die unerwünschte Weiterleitung verantwortlich war.
Die Analyse wurde deshalb nicht auf die zuerst auffällige Codepassage beschränkt. Zusätzlich wurden unter anderem geprüft:
- WordPress-Core-Dateien
- installierte Plugins und Themes
- Datenbankeinträge
- Benutzerkonten und Administratoren
- Cronjobs
- Konfigurationsdateien
- Upload-Verzeichnisse
- sowie weitere mögliche Stellen, über die Schadcode nachgeladen oder erneut eingeschleust werden konnte
- Denn eine gefundene JavaScript-Passage beantwortet noch nicht die entscheidende Frage:
- War das der gesamte Angriff oder nur der sichtbare Teil davon?
Bereinigung
Der eingeschleuste Schadcode wurde kontrolliert entfernt. Gleichzeitig wurden die betroffenen Komponenten mit sauberen Originalversionen verglichen und bei Bedarf aus vertrauenswürdigen Quellen ersetzt.
Darüber hinaus wurden mögliche weitere Zugriffsmöglichkeiten untersucht. Dazu gehörten insbesondere versteckte Dateien, unbekannte Benutzerkonten, manipulierte Konfigurationen und Mechanismen, über die sich der Schadcode nach dem Löschen erneut hätte herstellen können.
Auch die relevanten Zugänge und Sicherheitsmechanismen wurden überprüft. Abhängig vom betroffenen System umfasst das beispielsweise:
- WordPress-Administratoren
- Hosting- und SFTP-Zugänge
- Datenbank-Zugangsdaten
- WordPress-Security-Keys
- aktive Sitzungen
- Plugins und Themes
- sowie Rollen und Berechtigungen
Nach der Bereinigung wurde die Website nicht einfach sofort wieder freigegeben. Zuerst wurde getestet, ob die Weiterleitung unter den zuvor auffälligen Bedingungen tatsächlich nicht mehr ausgelöst wurde.
Dazu gehörten unter anderem Kontrollen:
- über verschiedene Browser
- auf mobilen Geräten
- im privaten beziehungsweise Inkognito-Modus
- mit gelöschten Cookies und Caches
- über unterschiedliche Einstiegsseiten
- sowie über Zugriffe, die das frühere Verhalten möglichst genau nachstellten
Ergebnis
Nach der vollständigen Bereinigung funktionierte die Website wieder ohne unerwünschte Weiterleitungen. Der eingeschleuste Code war entfernt, die relevanten Bereiche waren geprüft und die Sicherheitsmaßnahmen wurden verbessert.
Der wichtigste Punkt war jedoch nicht, dass die Website wieder normal aussah. Entscheidend war, dass nicht nur die sichtbare JavaScript-Passage gelöscht, sondern auch nach weiteren Manipulationen und der möglichen Ursache gesucht wurde.
Der Fall zeigt sehr deutlich:
Bei einer kompromittierten WordPress-Website ist der zuerst gefundene Schadcode häufig nur der Anfang der Analyse.
Eine Website kann für den Betreiber völlig unauffällig wirken und trotzdem bestimmte Besucher weiterleiten. Deshalb reichen ein kurzer Seitenaufruf, das Leeren des Caches oder ein einzelner automatischer Scan nicht aus, um eine Website zuverlässig als sauber einzustufen.
Erforderlich ist eine kontrollierte Prüfung von Dateien, Datenbank, Zugängen und Serverumgebung – gefolgt von Tests unter genau jenen Bedingungen, unter denen die Manipulation zuvor ausgelöst wurde.
Kann ich einfach ein sauberes Backup wiederherstellen?
Ein Backup kann nach einem WordPress-Hack enorm wertvoll sein. Es ist jedoch nicht automatisch die schnellste oder sicherste Lösung.
Entscheidend ist nicht nur, ob ein Backup vorhanden ist, sondern auch, wann es erstellt wurde, ob es tatsächlich sauber ist und warum die Website ursprünglich kompromittiert werden konnte.
Wird eine alte Version eingespielt, ohne die Ursache des Angriffs zu beheben, kann dieselbe Website kurze Zeit später erneut infiziert sein.
Wann eine Wiederherstellung sinnvoll sein kann
Eine Wiederherstellung aus einem Backup kann sinnvoll sein, wenn sich der Angriffszeitraum zuverlässig eingrenzen lässt und eine eindeutig saubere Version der Website vorhanden ist.
Dafür sollten mehrere Voraussetzungen erfüllt sein:
Der ungefähre Zeitpunkt des Angriffs ist bekannt.
Das Backup stammt nachweislich aus der Zeit vor der Infektion.
Dateien und Datenbank wurden vollständig gesichert.
Das Backup wurde nicht im selben kompromittierten System manipuliert.
Die ursprüngliche Sicherheitslücke wird vor der Freigabe geschlossen.
Sämtliche relevanten Zugangsdaten werden erneuert.
Plugins, Themes und WordPress-Core werden auf einen sicheren Stand gebracht.
Die wiederhergestellte Website wird vor der Veröffentlichung erneut geprüft.
Gerade bei Onlineshops, Buchungssystemen oder Mitgliederplattformen muss zusätzlich berücksichtigt werden, welche Daten seit dem Zeitpunkt des Backups hinzugekommen sind.
Eine ältere Wiederherstellung kann beispielsweise aktuelle:
- Bestellungen
- Kontaktanfragen
- Kundenkonten
- Formulareinträge
- Buchungen
- Kommentare
- oder Inhaltsänderungen
überschreiben.
Deshalb muss vorab geklärt werden, welche Daten aus der aktuellen Installation übernommen werden können, ohne dabei erneut Schadcode oder manipulierte Datenbankeinträge einzuspielen.
Ein sauberes Backup ist somit häufig eine gute Grundlage. Es ersetzt aber weder die Ursachenanalyse noch die abschließende Sicherheitsprüfung.
Wann ein Backup das Problem nicht löst
Ein Backup hilft nur dann, wenn es tatsächlich aus einer sauberen Version der Website stammt. Genau das lässt sich bei länger unbemerkten Infektionen häufig nicht zweifelsfrei feststellen.
Eine reine Wiederherstellung reicht meistens nicht aus, wenn:
- der Zeitpunkt der Infektion unbekannt ist
- Backups nur wenige Tage aufbewahrt wurden
- die Malware bereits länger im System vorhanden war
- Zugangsdaten kompromittiert wurden
- die ursprüngliche Sicherheitslücke weiterhin besteht
- andere Websites im selben Hosting betroffen sind
- Backups ebenfalls auf dem kompromittierten Server lagen
- unbekannte Administratoren oder Backdoors vorhanden sind
- oder nach der Wiederherstellung keine erneute Prüfung erfolgt
Besonders tückisch sind Infektionen, die über Wochen oder Monate unauffällig bleiben. In diesem Fall können auch mehrere ältere Backups bereits denselben Schadcode enthalten.
Das Einspielen einer solchen Sicherung stellt dann nicht die saubere Website wieder her, sondern lediglich einen früheren Stand derselben Infektion.
Auch kompromittierte Zugangsdaten bleiben durch eine Wiederherstellung unverändert. Wenn ein Angreifer weiterhin Zugriff auf Hosting, SFTP, Datenbank oder ein Administrator-Konto besitzt, kann die Website unmittelbar erneut manipuliert werden.
Dasselbe gilt für unsichere Plugins oder Themes. Wird ein Backup inklusive der ursprünglichen Schwachstelle wiederhergestellt, bleibt der Angriffsweg weiterhin offen.
Die richtige Reihenfolge lautet daher:
- Angriffszeitraum möglichst eingrenzen
- Backup auf Schadcode und Manipulationen prüfen
- Sicherheitslücke schließen
- Zugänge erneuern
- Website kontrolliert wiederherstellen
anschließend erneut testen und überwachen.
Mehr darüber erfahren Sie in unserem Leitfaden, wie häufig WordPress-Backups erstellt und getestet werden sollten.
Ein Backup bringt Ihre Website zurück. Erst eine Sicherheitsprüfung zeigt, ob sie auch sauber zurückkommt.
Was kostet die Bereinigung einer gehackten WordPress-Website?
Die Kosten für eine professionelle WordPress-Malware-Bereinigung lassen sich nicht allein anhand der Anzahl gefundener Dateien bestimmen. Entscheidend ist, wie weit der Angriff reicht, welche Systeme betroffen sind und ob neben dem sichtbaren Schadcode noch weitere Zugriffsmöglichkeiten bestehen.
Eine kleine, klar begrenzte Infektion kann deutlich schneller bereinigt werden als eine Website mit mehreren Backdoors, manipulierten Datenbankeinträgen, unbekannten Administratoren und Tausenden eingeschleusten Spam-URLs.
Deshalb beginnt eine seriöse Bereinigung immer mit einer technischen Ersteinschätzung.
Davon hängt der Aufwand ab
Der konkrete Aufwand wird unter anderem durch folgende Faktoren beeinflusst:
- Größe und technischer Umfang der Website
- einfache Unternehmenswebsite oder komplexer WooCommerce-Shop
- Art und Verbreitung der Malware
- Anzahl manipulierter Dateien und Verzeichnisse
- mögliche Veränderungen in der Datenbank
- Anzahl der Websites im selben Hosting-Paket
- Qualität und Alter vorhandener Backups
- Verfügbarkeit von Server- und Zugriffslogs
- einmalige oder bereits wiederkehrende Infektion
- Warnungen durch Google, Browser oder Hosting-Anbieter
- notwendige Wiederherstellung beschädigter Funktionen
- angebundene Zahlungs-, Newsletter- oder Buchungssysteme
- möglicher Zugriff auf personenbezogene Daten
- erforderliche Nachkontrolle und Überwachung
Bei einem einfachen Fall kann sich die Manipulation beispielsweise auf wenige klar identifizierbare Bereiche beschränken. Bei einer umfangreicheren Infektion müssen hingegen möglicherweise WordPress-Core, Plugins, Themes, Datenbank, Benutzerkonten, Cronjobs und weitere Websites im Hosting überprüft werden.
Auch der Zustand der vorhandenen Backups spielt eine wichtige Rolle. Ein nachweislich sauberes und vollständiges Backup kann die Wiederherstellung erleichtern. Ist der Zeitpunkt der Infektion jedoch unbekannt, müssen möglicherweise mehrere Sicherungen geprüft werden.
Warum pauschale Billigpreise häufig zu kurz greifen
Manche Angebote versprechen eine Malware-Bereinigung zu einem sehr niedrigen Fixpreis. Dabei ist jedoch nicht immer klar, ob lediglich ein automatischer Scan durchgeführt und sichtbarer Schadcode gelöscht wird oder ob auch die Ursache des Angriffs untersucht wird.
Eine vollständige Bereinigung sollte mehr umfassen als:
- einen Malware-Scanner auszuführen
- einzelne auffällige Dateien zu löschen
- WordPress zu aktualisieren
- und die Website wieder online zu stellen
- Ebenso wichtig sind:
- die Suche nach versteckten Backdoors
- die Prüfung der Datenbank
- die Kontrolle unbekannter Benutzer
- das Schließen der ursprünglichen Sicherheitslücke
- die Erneuerung kompromittierter Zugänge
- sowie die abschließende Funktions- und Sicherheitsprüfung
Eine pauschale Berechnung nach Dateianzahl wäre daher unseriös. Eine kleine, klar begrenzte Infektion ist schneller behoben als eine Website mit mehreren Backdoors, manipulierten Datenbankeinträgen und Tausenden Spam-URLs.
Nach einer ersten technischen Prüfung erhalten Sie eine klare Einschätzung des notwendigen Aufwands und ein transparentes Angebot für die Bereinigung.
Was Sie vor der Beauftragung klären sollten
Achten Sie bei Angeboten zur Malware-Bereinigung darauf, welche Leistungen tatsächlich enthalten sind.
Wichtige Fragen sind:
- Werden nur gefundene Dateien gelöscht oder wird die gesamte Installation geprüft?
- Wird auch nach Backdoors und versteckten Administratoren gesucht?
- Werden Datenbank, Cronjobs und Konfigurationsdateien kontrolliert?
- Wird die ursprüngliche Sicherheitslücke untersucht?
- Werden Zugänge und WordPress-Security-Keys erneuert?
- Sind Funktionstests nach der Bereinigung enthalten?
- Wird die Website nach der Freigabe weiter überwacht?
- Werden Google- oder Browser-Warnungen mitbearbeitet?
- Gibt es eine klare Dokumentation der durchgeführten Maßnahmen?
Der günstigste Preis ist nicht automatisch die günstigste Lösung. Wenn die Website wenige Tage später erneut kompromittiert wird, entstehen zusätzliche Ausfallzeiten, erneute Kosten und möglicherweise weitere Schäden an Sichtbarkeit und Vertrauen.
Unsere Differenzierung ist nicht der billigste Scan, sondern eine gründliche Bereinigung mit Ursachenanalyse und anschließender Absicherung.
Wie lange dauert es, eine gehackte Website zu bereinigen?
Wie schnell eine gehackte WordPress-Website wieder sicher online gehen kann, hängt stark vom jeweiligen Schadensbild ab. Pauschale Versprechen wie „immer innerhalb von 24 Stunden“ sind deshalb wenig seriös.
Eine klar begrenzte Manipulation auf einer kleinen Unternehmenswebsite kann deutlich schneller behoben werden als ein WooCommerce-Shop mit kompromittierter Datenbank, mehreren Backdoors, unbekannten Administratoren und einer Sicherheitswarnung bei Google.
Entscheidend sind unter anderem:
- Art und Umfang der Infektion
- Größe und Komplexität der Website
- Verfügbarkeit aller notwendigen Zugänge
- technische Möglichkeiten des Hosting-Anbieters
- Qualität der vorhandenen Backups
- Verfügbarkeit von Server- und Zugriffslogs
- Anzahl weiterer Websites im selben Hosting
- sowie mögliche Schäden an Funktionen und Suchmaschinen-Sichtbarkeit
Auch die Frage, wie lange der Angriff bereits unbemerkt bestand, spielt eine wichtige Rolle. Je länger sich Schadcode im System befand, desto mehr Dateien, Datenbankeinträge oder Backups können betroffen sein.
Erste technische Einschätzung
Zu Beginn werden die bekannten Symptome aufgenommen und die Dringlichkeit bewertet.
Dabei wird beispielsweise geprüft:
- Ist die Website noch erreichbar?
- Werden Besucher weitergeleitet?
- Gibt es Malware- oder Phishing-Warnungen?
- Wurde die Website vom Hoster gesperrt?
- Sind ein Shop, Formulare oder Kundendaten betroffen?
- Gibt es Hinweise auf weitere kompromittierte Websites?
Eine erste Einschätzung kann häufig rasch erfolgen. Sie liefert jedoch noch keine Garantie dafür, dass der vollständige Umfang des Angriffs bereits bekannt ist.
Schadensbegrenzung
Bei einer aktiven Gefährdung muss die Website zunächst isoliert oder serverseitig geschützt werden.
Wie schnell das möglich ist, hängt davon ab:
- ob Hosting-Zugänge vorhanden sind
- ob der Hosting-Anbieter erreichbar ist
- welche Verwaltungsoberfläche verwendet wird
- und ob die Website bereits automatisch gesperrt wurde
Bei gefährlichen Weiterleitungen oder Phishing-Inhalten hat die Schadensbegrenzung Vorrang vor der vollständigen Wiederherstellung.
Analyse und Bereinigung
Dieser Teil nimmt in der Regel den größten Aufwand ein.
Untersucht werden möglicherweise:
- WordPress-Core
- Plugins und Themes
- Datenbank
- Benutzerkonten
- Cronjobs
- Konfigurationsdateien
- Upload-Verzeichnis
- Server-Logs
- weitere Installationen im Hosting
- sowie vorhandene Backups
Je mehr Bereiche betroffen sind, desto länger dauert die Analyse. Besonders aufwendig sind wiederkehrende Infektionen, weil hier häufig eine versteckte Backdoor, ein kompromittierter Zugang oder eine bisher übersehene Schwachstelle besteht.
Auch Tausende eingeschleuste Spam-Seiten oder manipulierte Datenbankeinträge erhöhen den Aufwand deutlich.
Funktionsprüfung
Nach der Bereinigung darf die Website nicht ungeprüft wieder freigegeben werden.
Kontrolliert werden müssen beispielsweise:
- Kontaktformulare
- Login und Benutzerkonten
- WooCommerce-Checkout
- Zahlungsanbieter
- E-Mail-Versand
- mobile Darstellung
- Weiterleitungen
- Tracking
- Caching
- externe Schnittstellen
- und bestehende Automatisierungen
Bei bedingten Weiterleitungen müssen zusätzlich unterschiedliche Geräte, Browser, Cookies und Zugriffswege getestet werden. Ein normaler direkter Seitenaufruf reicht dafür nicht aus.
Google-Nachbearbeitung
War die Website bei Google als gehackt oder gefährlich markiert, endet die Arbeit nicht mit der technischen Bereinigung.
Zusätzlich müssen möglicherweise:
- Sicherheitsprobleme in der Google Search Console bearbeitet
- Spam-URLs geprüft
- Sitemaps bereinigt
- unerwünschte Seiten aus dem Index entfernt
- und eine erneute Überprüfung beantragt werden
Die technische Website kann zu diesem Zeitpunkt bereits sauber sein. Bis Google Warnhinweise entfernt oder Suchergebnisse aktualisiert, kann jedoch zusätzliche Zeit vergehen.
Darauf hat die betreuende Agentur keinen direkten Einfluss.
Anschließende Überwachung
Auch nach der Freigabe sollte die Website über einen gewissen Zeitraum besonders aufmerksam überwacht werden.
Kontrolliert werden unter anderem:
- neue Dateiveränderungen
- unbekannte Benutzer
- auffällige Login-Versuche
- Serverlast
- erneute Malware-Funde
- Google Search Console
- E-Mail-Versand
- und die Erreichbarkeit der Website
Diese Nachkontrolle hilft dabei, verbliebene Auffälligkeiten oder einen erneuten Zugriff möglichst früh zu erkennen.
Eine schnelle Bereinigung ist wichtig. Eine übereilte Freigabe ist es nicht.
Nach der ersten technischen Prüfung erhalten Sie eine realistische Einschätzung des Umfangs und der notwendigen nächsten Schritte.
WordPress gehackt und DSGVO – muss der Vorfall gemeldet werden?
Ein Hackerangriff auf eine WordPress-Website ist nicht automatisch eine meldepflichtige Datenschutzverletzung. Entscheidend ist, ob personenbezogene Daten betroffen waren oder ein Zugriff darauf zumindest möglich gewesen sein könnte.
Die technische Bereinigung der Website und die datenschutzrechtliche Bewertung müssen deshalb parallel betrachtet werden. Dass die Website wieder funktioniert, beantwortet noch nicht die Frage, ob Kundendaten eingesehen, verändert oder entwendet wurden.
Nicht jeder Hack ist automatisch eine meldepflichtige Datenpanne
Eine Verletzung des Schutzes personenbezogener Daten liegt unter anderem dann vor, wenn personenbezogene Daten unbeabsichtigt oder unrechtmäßig:
- zerstört
- verloren
- verändert
- unbefugt offengelegt
- für Unbefugte zugänglich
- oder vorübergehend nicht verfügbar
gemacht wurden. Dazu zählt nicht nur ein bestätigter Datendiebstahl. Auch ein unbefugter Zugriff oder eine Manipulation gespeicherter Daten kann datenschutzrechtlich relevant sein.
Nach einem WordPress-Hack sollte deshalb geprüft werden, ob beispielsweise folgende Daten betroffen sein könnten:
- Nachrichten aus Kontaktformularen
- Namen, E-Mail-Adressen und Telefonnummern
- Kundenkonten
- WooCommerce-Bestellungen
- Rechnungs- und Lieferadressen
- Bewerbungsunterlagen
- Newsletter-Empfänger
- Mitgliederdaten
- Terminbuchungen
- gespeicherte Formulareinträge
- IP-Adressen und Logdaten
- Zugangsdaten
- oder Informationen aus angebundenen Drittsystemen
- Wichtige Fragen sind dabei:
- Hatte der Angreifer möglicherweise Zugriff auf die WordPress-Datenbank?
- Wurden unbekannte Administratoren oder Datenbank-Benutzer angelegt?
- Gibt es Hinweise auf einen Export oder eine Übertragung von Daten?
- Wurden Formulare, Login-Seiten oder der Checkout manipuliert?
- Könnten eingegebene Daten an externe Server übertragen worden sein?
- Wurden Daten verändert, gelöscht oder verschlüsselt?
- Lässt sich nachvollziehen, wie lange der Zugriff bestanden hat?
Nicht immer kann unmittelbar festgestellt werden, ob Daten tatsächlich kopiert wurden. Für die Risikobewertung ist deshalb auch relevant, welche Zugriffsmöglichkeiten der Angreifer hatte und welche Daten über die kompromittierte Website erreichbar waren.
Wann die österreichische Datenschutzbehörde relevant wird
Eine Meldung an die österreichische Datenschutzbehörde ist erforderlich, wenn die Verletzung des Schutzes personenbezogener Daten voraussichtlich zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt.
Die Meldung muss unverzüglich und – soweit möglich – innerhalb von 72 Stunden erfolgen, nachdem dem verantwortlichen Unternehmen die Datenschutzverletzung bekannt wurde. Die Frist beginnt somit nicht zwingend zum Zeitpunkt des ursprünglichen Angriffs, sondern mit der Kenntnis des relevanten Datenschutzvorfalls.
Wird die Meldung später als nach 72 Stunden eingebracht, muss die Verzögerung begründet werden. Sind zu Beginn noch nicht alle Informationen verfügbar, können diese unter bestimmten Voraussetzungen schrittweise nachgereicht werden.
Eine Meldung kann unterbleiben, wenn die Datenschutzverletzung voraussichtlich zu keinem Risiko für die Rechte und Freiheiten der betroffenen Personen führt. Diese Entscheidung sollte jedoch nachvollziehbar begründet und dokumentiert werden.
Besteht voraussichtlich ein hohes Risiko für die betroffenen Personen, kann zusätzlich eine unverzügliche und verständliche Benachrichtigung dieser Personen erforderlich sein. Das kann beispielsweise bei entwendeten Zugangsdaten, sensiblen Informationen oder einem erhöhten Risiko für Betrug und Identitätsmissbrauch relevant werden.
Welche Faktoren für die Risikobewertung wichtig sind
Ob eine Meldung erforderlich ist, lässt sich nicht allein anhand der Anzahl betroffener Datensätze beurteilen.
Berücksichtigt werden sollten unter anderem:
- Art und Sensibilität der betroffenen Daten
- Anzahl der möglicherweise betroffenen Personen
- mögliche Dauer des unbefugten Zugriffs
- Wahrscheinlichkeit eines Datenabflusses
- Möglichkeit der Identifizierung betroffener Personen
- mögliche finanzielle, berufliche oder persönliche Folgen
- vorhandene Verschlüsselungs- und Schutzmaßnahmen
- sowie bereits gesetzte Maßnahmen zur Schadensbegrenzung
Ein kompromittiertes Kontaktformular mit wenigen allgemeinen Anfragen kann anders zu bewerten sein als ein WooCommerce-Shop mit Kundenkonten, Bestellhistorie, Adressdaten und angebundenen Zahlungsdiensten.
Auch eine reine Weiterleitung auf eine Spam-Seite bedeutet nicht automatisch, dass personenbezogene Daten abgeflossen sind. Wurde jedoch Schadcode in Formulare, den Checkout oder den Login eingeschleust, steigt das mögliche Risiko erheblich.
Was Unternehmen dokumentieren sollten
Der Vorfall und die getroffenen Entscheidungen sollten von Beginn an nachvollziehbar dokumentiert werden.
Dazu gehören insbesondere:
- Zeitpunkt der ersten Auffälligkeit
- Zeitpunkt, zu dem der Vorfall intern bekannt wurde
- vermuteter Zeitraum des Angriffs
- betroffene Websites, Systeme und Benutzerkonten
- Art der gefundenen Manipulation
- möglicherweise betroffene Datenkategorien
- ungefähre Anzahl betroffener Personen und Datensätze
- vorhandene Hinweise auf einen Datenzugriff oder Datenabfluss
- getroffene Sofortmaßnahmen
- technische Bereinigungsschritte
- Kommunikation mit Hosting-Anbieter, Agentur und weiteren Dienstleistern
- Bewertung möglicher Folgen für Betroffene
- Entscheidung für oder gegen eine Behördenmeldung
- Zeitpunkt und Inhalt einer erfolgten Meldung
- sowie Maßnahmen zur Vermeidung weiterer Vorfälle
Die Dokumentation ist auch dann wichtig, wenn nach der Risikobewertung keine Meldung an die Datenschutzbehörde erfolgt. Die DSGVO verlangt, Datenschutzverletzungen einschließlich ihrer Auswirkungen und der ergriffenen Abhilfemaßnahmen so festzuhalten, dass die Einhaltung der gesetzlichen Pflichten überprüft werden kann.
Was tun, wenn nach 72 Stunden noch nicht alles geklärt ist?
Eine vollständige technische Analyse kann bei komplexen WordPress-Infektionen länger dauern. Das bedeutet jedoch nicht, dass mit der datenschutzrechtlichen Bewertung beliebig gewartet werden sollte.
Unternehmen sollten innerhalb der Frist mit den zu diesem Zeitpunkt verfügbaren Informationen prüfen:
- Liegt wahrscheinlich eine Datenschutzverletzung vor?
- Welche Systeme und Daten könnten betroffen sein?
- Welches Risiko besteht für die betroffenen Personen?
- Welche Sofortmaßnahmen wurden bereits gesetzt?
- Welche Informationen fehlen noch?
Ist eine Meldung erforderlich, können noch ausstehende Erkenntnisse nachgereicht werden. Entscheidend ist, den Vorfall nicht erst vollständig technisch abzuschließen und sich danach erstmals mit der Meldepflicht zu beschäftigen.
Rechtlicher Hinweis
Dieser Beitrag bietet eine allgemeine Orientierung und ersetzt keine individuelle rechtliche Beratung. Bei einem möglichen Zugriff auf personenbezogene Daten, unklarer Risikolage oder sensiblen Daten sollte zusätzlich eine qualifizierte Datenschutz- oder Rechtsberatung beigezogen werden.
Was passiert mit Google-Rankings nach einem Website-Hack?
Ein erfolgreicher Angriff betrifft nicht nur die Sicherheit und Funktionsfähigkeit Ihrer Website. Eingeschleuste Inhalte, fremde Weiterleitungen oder Malware können auch die Sichtbarkeit bei Google erheblich beschädigen.
Dabei muss die eigentliche Unternehmenswebsite nicht einmal sichtbar verändert worden sein. Angreifer können Inhalte gezielt nur für Suchmaschinen, mobile Besucher oder Nutzer ausspielen, die über ein Google-Suchergebnis auf die Website gelangen.
Je länger solche Manipulationen unentdeckt bleiben, desto größer kann der Aufwand werden, die Website technisch zu bereinigen und anschließend auch ihre Sichtbarkeit wiederherzustellen.
Eingeschleuste Spam-Inhalte können die Sichtbarkeit beschädigen
Google bezeichnet Inhalte, die ohne Zustimmung des Website-Betreibers aufgrund einer Sicherheitslücke eingefügt wurden, als gehackte Inhalte. Dazu gehören unter anderem eingeschleuste Seiten, versteckte Links, fremde Inhalte und unerwünschte Weiterleitungen. Solche Manipulationen können zu schlechteren Rankings oder zum Ausschluss einzelner Seiten aus der Google-Suche führen.
Typische Folgen eines WordPress-Hacks sind:
- unbekannte Spam-URLs werden indexiert
- bestehende Seitentitel und Beschreibungen verändern sich
- fremdsprachige Inhalte erscheinen in den Suchergebnissen
- Besucher werden von Google auf externe Spam-Seiten weitergeleitet
- Browser oder Suchergebnisse zeigen Sicherheitswarnungen
- wichtige Seiten verlieren Rankings
- Werbeanzeigen werden abgelehnt
- oder Teile der Website verschwinden vorübergehend aus den Suchergebnissen
Besonders problematisch ist sogenannter Hacked Spam. Dabei nutzen Angreifer die bestehende Domain, ihre Reputation und ihre bisherigen Rankings, um fremde Inhalte in den Suchergebnissen zu platzieren.
Das können beispielsweise sein:
- Casino- und Glücksspielseiten
- Medikamentenangebote
- gefälschte Onlineshops
- fremdsprachige Produktseiten
- Download-Seiten
- Phishing-Inhalte
- oder Tausende automatisch erzeugte URLs
Die neuen Seiten müssen im WordPress-Backend nicht als normale Beiträge sichtbar sein. Sie können dynamisch erzeugt, in der Datenbank versteckt oder nur gegenüber dem Googlebot beziehungsweise bestimmten Besuchergruppen ausgespielt werden.
Auch Weiterleitungen können selektiv erfolgen. Google beschreibt Fälle, bei denen nur Besucher aus Suchmaschinen oder Nutzer mit mobilen Geräten auf fremde Seiten umgeleitet werden. Beim direkten Aufruf durch den Betreiber funktioniert dieselbe Website scheinbar normal.
Sicherheitswarnung, Spam-Problem oder manuelle Maßnahme?
Nicht jede gehackte Website erhält automatisch dieselbe Art von Google-Warnung. Deshalb sollten mehrere Bereiche getrennt geprüft werden.
Sicherheitsproblem
Im Bericht „Sicherheitsprobleme“ der Google Search Console werden Hinweise auf gehackte Inhalte, Malware, unerwünschte Software, Phishing oder Social Engineering angezeigt.
Je nach Art des Problems kann Google:
- eine Warnung im Suchergebnis darstellen
- Besucher vor dem Aufruf der Website warnen
- im Browser eine rote Sicherheitsseite anzeigen
- oder einzelne betroffene URLs kennzeichnen
Google nennt den Bericht „Sicherheitsprobleme“ in der Google Search Console ausdrücklich als zentrale Stelle, um Hinweise auf gehackte oder für Besucher gefährliche Inhalte zu kontrollieren.
Manuelle Maßnahme
Eine manuelle Maßnahme ist davon zu unterscheiden. Sie entsteht, wenn ein menschlicher Prüfer bei Google feststellt, dass Seiten gegen die Spam-Richtlinien verstoßen.
Nicht jeder WordPress-Hack führt automatisch zu einer manuellen Maßnahme. Der Bericht sollte trotzdem geprüft werden, weil eingeschleuste Spam-Inhalte oder manipulative Weiterleitungen Auswirkungen auf die Darstellung und Sichtbarkeit der Website haben können.
Normale Indexierungsprobleme
Auch ohne sichtbare Sicherheitswarnung oder manuelle Maßnahme kann ein Hack erhebliche SEO-Schäden verursachen.
Google kann beispielsweise:
- Spam-URLs crawlen und indexieren
- bisherige Inhalte neu bewerten
- falsche Seitentitel übernehmen
- Crawl-Ressourcen für automatisch erzeugte Seiten verwenden
- oder wichtige URLs seltener aufrufen
Deshalb reicht es nicht, ausschließlich nach einer roten Warnmeldung in der Search Console zu suchen.
Diese Bereiche sollten nach einem Hack geprüft werden
Nach der technischen Bereinigung sollte die Google-Prüfung systematisch erfolgen.
Search Console: Sicherheitsprobleme
Kontrollieren Sie, ob Google:
- gehackte Inhalte
- Malware
- unerwünschte Software
- Phishing
- Social Engineering
- oder schädliche Downloads
erkannt hat.
Die dort angeführten Beispiel-URLs zeigen nicht zwangsläufig alle betroffenen Seiten. Sie dienen in erster Linie als Hinweise auf die Art des Problems.
Search Console: Manuelle Maßnahmen
Prüfen Sie, ob gegen einzelne Bereiche oder die gesamte Website eine manuelle Maßnahme besteht.
Ist keine manuelle Maßnahme vorhanden, bedeutet das nicht automatisch, dass keine gehackten Inhalte indexiert wurden. Sicherheitsprobleme und manuelle Maßnahmen werden in der Search Console getrennt behandelt.
Indexierte Seiten
Kontrollieren Sie, ob Google plötzlich ungewöhnlich viele Seiten kennt.
Warnsignale sind beispielsweise:
- ein unerklärlicher Anstieg indexierter URLs
- fremde Verzeichnisse
- kryptische URL-Strukturen
- Parameterseiten
- fremdsprachige Inhalte
- oder Seiten zu Themen, die nichts mit dem Unternehmen zu tun haben
Google-Suche mit site:
Eine einfache erste Kontrolle ist eine Suche nach:
site:ihre-domain.at- Zusätzlich können verdächtige Begriffe kombiniert werden, beispielsweise:
site:ihre-domain.atcasinosite:ihre-domain.atpharmacysite:ihre-domain.atviagrasite:ihre-domain.at日本
Eine site:-Abfrage liefert keine vollständige oder exakt sortierte Liste aller indexierten Seiten. Sie kann aber schnell auffällige Inhalte sichtbar machen.
Seitentitel und Meta Descriptions
Prüfen Sie, ob bekannte Unternehmensseiten plötzlich fremde Titel oder Beschreibungen zeigen.
Angreifer können bestehende URLs verwenden und nur die Inhalte verändern, die Google ausgeliefert werden. Dadurch kann eine vertraute URL mit einem völlig fremden Suchergebnis erscheinen.
Fremde Sprachversionen
Plötzlich auftauchende japanische, chinesische, russische oder englische Produktseiten sind ein häufiges Warnsignal.
Dabei sollten auch folgende Elemente kontrolliert werden:
hreflang-Angaben- Sprachverzeichnisse
- XML-Sitemaps
- Canonical-Tags
- Weiterleitungen
- und automatisch erzeugte Unterseiten
XML-Sitemaps
Manipulierte oder neu angelegte Sitemaps können Google gezielt auf Spam-URLs führen.
Prüfen Sie daher:
- welche Sitemaps in der Search Console eingereicht wurden
- ob unbekannte Sitemap-Dateien existieren
- welche URLs darin enthalten sind
- und ob Plugins oder Schadcode neue Sitemaps erzeugen
URL-Prüfung
Mit der URL-Prüfung in der Search Console lässt sich für einzelne Seiten nachvollziehen:
- ob die URL indexiert ist
- welche Version Google zuletzt verarbeitet hat
- ob Crawling möglich ist
- und ob die Seite grundsätzlich für die Indexierung vorgesehen ist
Bei bedingten Manipulationen sollte zusätzlich geprüft werden, ob sich die mobile und die Desktop-Version unterschiedlich verhalten. Google empfiehlt die URL-Prüfung auch zur Untersuchung auffälliger Seiten aus dem Bericht zu Sicherheitsproblemen.
Spam-Seiten nach der Bereinigung richtig behandeln
Es genügt nicht, den Schadcode zu entfernen, wenn Tausende eingeschleuste URLs bereits von Google indexiert wurden.
Für jede Art von Spam-URL muss entschieden werden, welche technische Antwort korrekt ist.
Nicht mehr vorhandene, erfundene Seiten sollten in der Regel einen passenden Fehlerstatus wie 404 Not Found oder 410 Gone zurückgeben. Sie sollten nicht pauschal auf die Startseite weitergeleitet werden. Solche Massenweiterleitungen können die Bereinigung unnötig erschweren und liefern Google kein klares Signal, dass die unerwünschten Inhalte tatsächlich entfernt wurden.
Zusätzlich sollten:
- manipulierte Sitemaps entfernt werden
- interne Links zu Spam-Seiten verschwinden
- schädliche Weiterleitungen beseitigt werden
- Cache- und CDN-Versionen gelöscht werden
- Canonical-Tags kontrolliert werden
- und neu erzeugte Spam-URLs technisch verhindert werden
Bei sehr vielen URLs kann es dauern, bis Google alle Änderungen erneut gecrawlt und verarbeitet hat. Dass einzelne Spam-Treffer noch kurzzeitig erscheinen, bedeutet daher nicht automatisch, dass die Website weiterhin infiziert ist. Trotzdem sollte kontrolliert werden, ob die betreffenden URLs inzwischen korrekt antworten.
Nach der Bereinigung eine Sicherheitsüberprüfung beantragen
Eine Überprüfung sollte erst beantragt werden, wenn das Sicherheitsproblem tatsächlich vollständig behoben wurde.
Vorher muss sichergestellt sein, dass:
- Malware und eingeschleuster Schadcode entfernt wurden
- versteckte Backdoors beseitigt sind
- unbekannte Administratoren entfernt wurden
- die ursprüngliche Sicherheitslücke geschlossen wurde
- kompromittierte Zugangsdaten erneuert wurden
- Spam-Seiten entfernt oder technisch korrekt beantwortet werden
- weitere Websites im selben Hosting kontrolliert wurden
- und die Website erneut auf verdächtiges Verhalten geprüft wurde
Anschließend kann im Bericht „Sicherheitsprobleme“ der Google Search Console eine Überprüfung beantragt werden. Google verlangt dabei eine Beschreibung der vorgenommenen Bereinigung und empfiehlt, erst nach vollständiger Behebung aller Probleme eine Prüfung einzureichen.
In der Beschreibung sollten Sie knapp und nachvollziehbar erklären:
- wodurch die Website vermutlich kompromittiert wurde
- welche betroffenen Bereiche gefunden wurden
- wie der Schadcode entfernt wurde
- welche Sicherheitslücke geschlossen wurde
- welche Zugänge erneuert wurden
- und welche Maßnahmen eine erneute Infektion verhindern sollen
Allgemeine Angaben wie „Wir haben alles gelöscht“ oder „Das Security-Plugin zeigt keine Probleme mehr“ sind wenig aussagekräftig.
Wie lange dauert die Google-Überprüfung?
Die Bearbeitungsdauer hängt von der Art des Sicherheitsproblems ab.
Bei Malware kann die Prüfung laut Google einige Tage dauern. Bei gehackten Spam-Inhalten kann eine Überprüfung mehrere Wochen benötigen, weil dafür möglicherweise eine manuelle Untersuchung oder eine erneute Verarbeitung zahlreicher gehackter Seiten erforderlich ist.
Auch nach einer erfolgreichen Überprüfung können einzelne Spam-URLs, veraltete Snippets oder falsche Seitentitel noch eine Zeit lang in der Suche sichtbar bleiben. Google muss die betroffenen Seiten erneut crawlen und den Suchindex aktualisieren.
Die Rückkehr bisheriger Rankings ist ebenfalls nicht garantiert und erfolgt nicht immer sofort. Sie hängt unter anderem davon ab:
- wie lange die Website kompromittiert war
- wie viele Spam-Seiten indexiert wurden
- ob bestehende Inhalte verändert wurden
- wie lange wichtige Seiten nicht erreichbar waren
- und ob nach der Bereinigung weiterhin technische SEO-Probleme bestehen
Deshalb sollte die Entwicklung nach der Freigabe weiter beobachtet werden.
Relevant sind insbesondere:
- Impressionen und Klicks
- Rankings wichtiger Suchbegriffe
- Anzahl indexierter Seiten
- Crawl-Aktivität
- ungewöhnliche Suchanfragen
- Sicherheitsmeldungen
- und erneut auftauchende Spam-URLs
Die technische Bereinigung stoppt den Angriff. Die SEO-Nachbearbeitung sorgt dafür, dass Google die saubere Website wieder richtig versteht.
Warum gehackte Websites nach einer Bereinigung erneut infiziert werden
Wenn dieselbe Website zweimal auf dieselbe Art gehackt wird, war die erste Bereinigung meistens keine Bereinigung. Es war Kosmetik.
Eine WordPress-Website kann nach dem Entfernen sichtbarer Malware zunächst wieder völlig normal funktionieren. Wenn jedoch die ursprüngliche Sicherheitslücke, versteckte Zugriffsmöglichkeiten oder kompromittierte Zugangsdaten bestehen bleiben, kann der Schadcode kurze Zeit später erneut auftauchen.
Das bedeutet nicht immer, dass ein neuer Angriff stattgefunden hat. Häufig wurde die erste Infektion schlicht nie vollständig entfernt.
Es wurde nur der sichtbare Schadcode gelöscht
Eine Weiterleitung verschwindet, nachdem eine verdächtige JavaScript-Zeile oder PHP-Datei entfernt wurde. Damit scheint das Problem gelöst.
Der gefundene Code kann jedoch lediglich der sichtbare Teil einer größeren Infektion gewesen sein. An anderer Stelle können weiterhin Dateien, Datenbankeinträge oder Skripte bestehen, die denselben Schadcode erneut einfügen.
Besonders bei verschleiertem Code ist häufig nicht sofort erkennbar:
- woher er geladen wird
- wodurch er aktiviert wird
- welche Dateien zusammenarbeiten
- und ob weitere Kopien vorhanden sind
Das Löschen des ersten Fundes beseitigt dann zwar das Symptom, nicht aber den Mechanismus dahinter.
Eine versteckte Backdoor blieb bestehen
Backdoors ermöglichen Angreifern einen späteren Zugriff auf die Website, ohne erneut dieselbe Sicherheitslücke ausnutzen zu müssen.
Sie können sich beispielsweise befinden in:
- unauffälligen PHP-Dateien
- Theme- oder Plugin-Verzeichnissen
- Must-use-Plugins
- dem Upload-Ordner
- manipulierten Core-Dateien
- der Datenbank
- oder scheinbar legitimen Benutzerkonten
Manche Backdoors bestehen nur aus wenigen Codezeilen und werden erst aktiviert, wenn ein bestimmter Parameter, Cookie oder Request gesendet wird.
Wird die sichtbare Malware entfernt, die Backdoor jedoch übersehen, kann der Angreifer jederzeit neuen Schadcode hochladen oder bestehende Dateien erneut verändern.
Das unsichere Plugin oder Theme blieb installiert
Eine häufige Ursache für WordPress-Angriffe sind veraltete, verwundbare oder nicht mehr gepflegte Erweiterungen.
Wird nach der Bereinigung lediglich der Schadcode gelöscht, aber das betroffene Plugin unverändert weiterverwendet, bleibt der ursprüngliche Angriffsweg offen.
Besonders kritisch sind:
- Plugins ohne aktuelle Sicherheitsupdates
- verlassene Erweiterungen
- Themes aus unbekannten Quellen
- sogenannte Nulled-Plugins oder Nulled-Themes
- alte Test-Plugins
- sowie deaktivierte Erweiterungen, deren Dateien weiterhin auf dem Server liegen
Eine deaktivierte Erweiterung ist nicht automatisch ungefährlich. Sind verwundbare Dateien weiterhin direkt erreichbar, können sie unter Umständen auch ohne aktive WordPress-Funktion ausgenutzt werden.
Zugangsdaten wurden nicht vollständig erneuert
Wenn ein Angreifer Zugangsdaten besitzt, hilft selbst eine technisch saubere Bereinigung nur vorübergehend.
Betroffen sein können nicht nur WordPress-Passwörter, sondern auch:
- Hosting-Konto
- Plesk oder cPanel
- SFTP und SSH
- Datenbank
- verbundene E-Mail-Konten
- Cloudflare oder CDN
- externe Backup-Systeme
- API-Schlüssel
- sowie Staging- und Deployment-Zugänge
Wird nur das Passwort eines einzelnen WordPress-Administrators geändert, während der Hosting- oder E-Mail-Zugang kompromittiert bleibt, kann der Angreifer weiterhin neue Benutzer erstellen, Dateien hochladen oder Passwörter zurücksetzen.
Auch aktive Sitzungen sollten beendet und die WordPress-Security-Keys beziehungsweise Salts erneuert werden.
Eine andere Website im selben Hosting ist noch infiziert
Befinden sich mehrere Websites im selben Hosting-Paket, kann eine weiterhin kompromittierte Installation andere Projekte erneut gefährden.
Das betrifft besonders:
- Reseller-Hosting
- gemeinsam genutzte SFTP-Zugänge
- alte Staging-Websites
- vergessene Testinstallationen
- Unterverzeichnisse mit früheren WordPress-Versionen
- und mehrere Websites unter demselben Benutzerkonto
Die offensichtlich betroffene Website kann sauber sein, während der eigentliche Ausgangspunkt des Angriffs in einer anderen Installation liegt.
Wird nur eine einzelne Website geprüft, kann der Schadcode über die benachbarte Installation erneut eingeschleust werden.
Ein Cronjob stellt die Malware automatisch wieder her
Cronjobs führen Aufgaben zeitgesteuert oder regelmäßig aus. In WordPress werden sie normalerweise für legitime Funktionen wie geplante Beiträge, Backups oder automatische Prozesse verwendet.
Angreifer können jedoch eigene Cronjobs anlegen oder bestehende Aufgaben manipulieren. Diese können beispielsweise:
- gelöschte Dateien erneut erzeugen
- externen Schadcode herunterladen
- Spam-Seiten generieren
- Administratoren anlegen
- oder Datenbankeinträge wiederherstellen
Dadurch erscheint der Schadcode möglicherweise erst Stunden oder Tage nach der vermeintlichen Bereinigung erneut.
Wird nur die neu erzeugte Datei gelöscht, der auslösende Cronjob aber nicht entfernt, beginnt der Vorgang von vorne.
Ein Datenbankeintrag lädt den Schadcode erneut nach
Nicht jede Infektion befindet sich ausschließlich im Dateisystem.
Schadcode kann auch in der WordPress-Datenbank gespeichert sein, beispielsweise in:
- Optionen
- Widgets
- Beiträgen
- Theme-Einstellungen
- Page-Builder-Inhalten
- Custom Fields
- oder Plugin-Konfigurationen
Ein manipulierter Eintrag kann externes JavaScript nachladen oder bei jedem Seitenaufruf erneut in den HTML-Code einfügen.
Wer nur Dateien kontrolliert, kann diese Form der Infektion vollständig übersehen. Die Website wirkt nach dem Ersetzen von WordPress-Core und Plugins zunächst sauber, lädt beim nächsten Aufruf aber erneut schädlichen Code aus der Datenbank.
Ein unbekannter Administrator wurde übersehen
Angreifer legen häufig eigene Benutzerkonten an oder verändern bestehende Konten.
Solche Administratoren können unauffällige Namen verwenden, sich zwischen legitimen Benutzern verstecken oder eine E-Mail-Adresse hinterlegen, die auf den ersten Blick plausibel wirkt.
Bleibt ein solches Konto bestehen, kann darüber jederzeit:
- ein neues Plugin installiert
- ein Theme verändert
- Schadcode hochgeladen
- ein weiterer Administrator erstellt
- oder die Website erneut manipuliert werden
Deshalb müssen nicht nur unbekannte Benutzer gelöscht werden. Auch bestehende Rollen, E-Mail-Adressen, letzte Aktivitäten und frühere Dienstleister sollten kontrolliert werden.
Der verwendete Computer ist kompromittiert
Manchmal liegt die Ursache nicht direkt in WordPress oder beim Hosting.
Befindet sich auf dem Computer eines Administrators, Mitarbeiters oder Dienstleisters Schadsoftware, können neue Passwörter, SFTP-Zugänge oder Browser-Sitzungen erneut abgegriffen werden.
Mögliche Hinweise sind:
- wiederholte Kompromittierungen trotz Passwortänderung
- unbekannte Logins kurz nach der Bereinigung
- mehrere betroffene Websites desselben Benutzers
- oder verdächtige Browser-Erweiterungen und gespeicherte Zugangsdaten
Neue Passwörter sollten deshalb nur von einem vertrauenswürdigen und überprüften Gerät aus vergeben werden.
Ein sauberes Backup wurde in eine unsichere Umgebung eingespielt
Auch ein tatsächlich sauberes Backup kann unmittelbar erneut kompromittiert werden, wenn es in dieselbe unsichere Umgebung zurückgespielt wird.
Das passiert beispielsweise, wenn:
- das verwundbare Plugin weiterhin installiert ist
- kompromittierte Hosting-Zugänge bestehen
- eine andere Website im Account infiziert bleibt
- unsichere Dateirechte nicht korrigiert wurden
- oder ein Angreifer noch über eine aktive Sitzung verfügt
Die wiederhergestellte Website war dann zunächst sauber. Sie wurde jedoch über denselben offenen Zugang sofort wieder infiziert.
Deshalb müssen Wiederherstellung und Absicherung gemeinsam erfolgen.
Woran Sie eine unvollständige Bereinigung erkennen
Typische Warnsignale sind:
- gelöschte Dateien tauchen erneut auf
- Weiterleitungen beginnen nach einigen Stunden wieder
- neue Administratoren werden angelegt
- Google findet weiterhin neue Spam-URLs
- der Hosting-Anbieter meldet erneut Malware
- dieselben Dateien werden wieder verändert
- oder die Serverlast steigt nach kurzer Zeit erneut an
In solchen Fällen sollte nicht einfach derselbe Reinigungsschritt wiederholt werden. Stattdessen muss geprüft werden, welcher Mechanismus die Infektion wiederherstellt.
Eine erfolgreiche Bereinigung entfernt nicht nur den Schadcode. Sie nimmt dem Angreifer auch den Weg zurück.
So schützen Sie WordPress nach einem Hack dauerhaft
Nach einer erfolgreichen Bereinigung sollte die Website nicht einfach in den vorherigen Zustand zurückkehren. Häufig waren genau dort veraltete Erweiterungen, zu viele Zugänge, fehlende Backups oder unbemerkte Veränderungen möglich.
Das Ziel ist nicht, jedes theoretische Risiko auszuschließen. Eine hundertprozentig unangreifbare Website gibt es nicht. Entscheidend ist, die Angriffsfläche zu verkleinern, Veränderungen früh zu erkennen und im Ernstfall schnell auf eine saubere Wiederherstellung zurückgreifen zu können.
WordPress, Plugins und Themes aktuell halten
Veraltete Software gehört zu den häufigsten vermeidbaren Risiken bei WordPress-Websites. Sicherheitslücken in WordPress-Core, Plugins oder Themes werden nach ihrer Veröffentlichung häufig automatisiert gesucht und ausgenutzt. Die offiziellen Sicherheitsempfehlungen von WordPress betonen deshalb, dass Website-Sicherheit laufende Planung, Überwachung und regelmäßige Wartung erfordert.
Updates sollten deshalb regelmäßig und nicht erst dann durchgeführt werden, wenn bereits ein Problem aufgetreten ist.
Aktuell gehalten werden müssen:
- WordPress-Core
- aktive Plugins
- aktive Themes
- eingesetzte Premium-Erweiterungen
- sowie die PHP-Version und weitere Komponenten der Hosting-Umgebung
Dabei reicht es nicht aus, nur gelegentlich im Backend nach roten Update-Hinweisen zu suchen. Manche Erweiterungen benötigen eine gültige Lizenz, um Sicherheitsupdates zu erhalten. Andere werden nicht mehr weiterentwickelt oder verschwinden vollständig aus dem offiziellen Verzeichnis.
Prüfen Sie deshalb regelmäßig:
- Wann wurde die Erweiterung zuletzt aktualisiert?
- Ist sie mit der aktuellen WordPress-Version kompatibel?
- Werden bekannte Sicherheitsprobleme zeitnah behoben?
- Ist die Lizenz für Premium-Updates aktiv?
- Gibt es eine besser gepflegte Alternative?
Welche Folgen ausbleibende Updates haben können, erklären wir ausführlich in unserem Beitrag „Was passiert, wenn WordPress nicht aktualisiert wird?“
Nicht verwendete Erweiterungen vollständig entfernen
Ein deaktiviertes Plugin ist nicht automatisch ungefährlich.
Auch wenn es im WordPress-Backend nicht aktiv ist, liegen seine Dateien weiterhin auf dem Server. Enthält eine dieser Dateien eine direkt erreichbare Sicherheitslücke, kann sie unter Umständen trotzdem ausgenutzt werden.
Entfernen Sie daher:
- nicht mehr benötigte Plugins
- alte Themes
- Test-Erweiterungen
- vergessene Page Builder
- frühere Backup-Plugins
- ungenutzte Import- und Migrationswerkzeuge
- sowie Erweiterungen, deren Zweck nicht mehr nachvollziehbar ist
Für Themes gilt dasselbe. Neben dem aktiven Theme sollte höchstens ein aktuelles Standard-Theme als technische Rückfallebene vorhanden sein. Alte oder nicht mehr verwendete Themes sollten gelöscht werden.
Weniger Erweiterungen bedeuten:
- weniger potenzielle Sicherheitslücken
- weniger Updates
- weniger Konflikte
- geringeren Wartungsaufwand
- und eine übersichtlichere technische Umgebung
Jede installierte Erweiterung sollte eine klare Aufgabe erfüllen. „Vielleicht brauchen wir sie irgendwann wieder“ ist kein besonders gutes Sicherheitskonzept.
Externe und getestete Backups einrichten
Ein Backup schützt nicht vor einem Angriff. Es entscheidet aber häufig darüber, ob eine Website kontrolliert wiederhergestellt werden kann.
Wichtig ist, dass die Sicherungen nicht ausschließlich auf demselben Server wie die Website gespeichert werden. Wird das gesamte Hosting kompromittiert, gelöscht oder gesperrt, können dort abgelegte Backups ebenfalls betroffen sein.
Eine verlässliche Backup-Strategie umfasst:
- vollständige Sicherungen von Dateien und Datenbank
- externe Speicherung
- mehrere Aufbewahrungsstände
- eine zum Änderungsvolumen passende Häufigkeit
- verschlüsselte und geschützte Backup-Zugänge
- sowie regelmäßige Wiederherstellungstests
Gerade bei Onlineshops oder häufig aktualisierten Websites reicht ein einzelnes wöchentliches Backup möglicherweise nicht aus. Zwischen zwei Sicherungen können Bestellungen, Kontaktanfragen, Kundenkonten und Inhaltsänderungen verloren gehen.
Ebenso wichtig ist eine ausreichende Aufbewahrungsdauer. Bleibt eine Infektion mehrere Wochen unentdeckt, sind nur wenige kurzfristig gespeicherte Sicherungen möglicherweise bereits alle betroffen.
Mehr dazu erfahren Sie in unserem Leitfaden, wie häufig WordPress-Backups erstellt und getestet werden sollten.
Ein Backup, das nie wiederhergestellt wurde, ist zunächst nur eine Hoffnung mit Dateiendung.
Administratoren und Berechtigungen reduzieren
Administratorrechte sollten nur Personen besitzen, die sie für ihre Arbeit tatsächlich benötigen.
Ein Administrator kann unter anderem:
- Plugins installieren
- Themes verändern
- Benutzer anlegen
- Einstellungen bearbeiten
- Code hinzufügen
- und sicherheitsrelevante Funktionen deaktivieren
Je mehr Administratoren bestehen, desto größer ist die Zahl möglicher Zugänge.
Prüfen Sie regelmäßig:
- Welche Benutzer haben Administratorrechte?
- Werden diese Rechte noch benötigt?
- Sind ehemalige Mitarbeiter oder Dienstleister weiterhin angelegt?
- Stimmen die hinterlegten E-Mail-Adressen?
- Gibt es inaktive oder unbekannte Benutzer?
- Werden Konten gemeinsam verwendet?
Jede Person sollte ein eigenes Benutzerkonto erhalten. Gemeinsame Logins wie „admin“, „office“ oder „agentur“ erschweren die Nachvollziehbarkeit und führen häufig dazu, dass Passwörter über unsichere Kanäle weitergegeben werden.
Vergeben Sie stattdessen nur die erforderlichen Rollen:
- Redakteure für die Inhaltspflege
- Shop-Manager für WooCommerce-Aufgaben
- Administratoren nur für technische Verantwortliche
- und zeitlich begrenzte Zugänge für externe Dienstleister
Nach Abschluss einer Zusammenarbeit sollten nicht mehr benötigte Konten entfernt oder herabgestuft werden.
Zwei-Faktor-Authentifizierung verwenden
Ein starkes Passwort allein schützt nicht, wenn es durch Phishing, Schadsoftware oder ein Datenleck bekannt wird.
Bei der Zwei-Faktor-Authentifizierung für WordPress reicht das Passwort nicht für die Anmeldung aus. Zusätzlich wird ein zweiter Faktor benötigt, beispielsweise ein zeitlich begrenzter Code aus einer Authenticator-App.
Zwei-Faktor-Authentifizierung sollte besonders für folgende Konten aktiviert werden:
- WordPress-Administratoren
- Hosting-Konto
- Plesk oder cPanel
- geschäftliche E-Mail-Konten
- Cloudflare oder andere CDN-Dienste
- externe Backup-Systeme
- Passwortmanager
- und gegebenenfalls verbundene Entwicklerplattformen
Besonders wichtig ist das E-Mail-Konto. Wer Zugriff darauf erhält, kann häufig Passwörter anderer Systeme zurücksetzen und dadurch mehrere Schutzmechanismen umgehen.
Zusätzlich sollten Wiederherstellungscodes sicher gespeichert und alte Geräte aus den Kontoeinstellungen entfernt werden.
Änderungen und Erreichbarkeit überwachen
Viele WordPress-Infektionen bleiben lange unentdeckt, weil niemand aktiv kontrolliert, ob sich Dateien, Benutzer oder Serververhalten ungewöhnlich verändern.
Ein sinnvolles Monitoring kann unter anderem erfassen:
- Ausfälle und Erreichbarkeit
- Veränderungen wichtiger Dateien
- Malware-Funde
- fehlgeschlagene Login-Versuche
- neu angelegte Administratoren
- ungewöhnlichen E-Mail-Versand
- auffällige Serverlast
- unerwartete Änderungen an DNS oder SSL
- sowie Sicherheitsmeldungen in der Google Search Console
Dabei geht es nicht darum, bei jeder kleinen Änderung Alarm auszulösen. Updates, Cache-Dateien und normale Systemprozesse verändern ebenfalls Dateien.
Ein gutes Monitoring unterscheidet deshalb möglichst zwischen erwartbaren technischen Änderungen und Auffälligkeiten, die tatsächlich geprüft werden sollten.
Je früher ein Problem entdeckt wird, desto kleiner sind häufig:
- der betroffene Zeitraum
- die Zahl manipulierter Dateien
- mögliche SEO-Schäden
- Ausfallzeiten
- und der Aufwand der Wiederherstellung
Updates nicht blind auf der Live-Website durchführen
Regelmäßige Updates sind wichtig. Sie sollten jedoch kontrolliert durchgeführt werden.
Ein automatisches „Alles aktualisieren“ auf einer geschäftskritischen Live-Website kann zu:
- Darstellungsfehlern
- Konflikten zwischen Plugins
- nicht mehr funktionierenden Formularen
- Checkout-Problemen
- fehlerhaftem Tracking
- oder einem vollständigen Website-Ausfall
führen.
Je nach Größe und Bedeutung der Website sollte der Update-Prozess deshalb umfassen:
- aktuelles Backup erstellen
- verfügbare Updates und Änderungen prüfen
- bei komplexeren Websites eine Staging-Umgebung verwenden
- Updates kontrolliert durchführen
- Cache leeren
- wichtige Funktionen testen
Ergebnis dokumentieren.
Nach dem Update sollten mindestens folgende Bereiche kontrolliert werden:
- Startseite und wichtige Unterseiten
- mobile Darstellung
- Kontaktformulare
- E-Mail-Versand
- Login
- WooCommerce-Warenkorb und Checkout
- Zahlungsanbieter
- Tracking und Consent-Management
- sowie externe Schnittstellen
Ein Update ist erst abgeschlossen, wenn die Website danach weiterhin korrekt funktioniert.
Einen festen technischen Ansprechpartner haben
Viele Sicherheitsprobleme entstehen nicht, weil niemand helfen könnte, sondern weil sich über Monate niemand verantwortlich fühlt.
Der Hoster verweist auf WordPress. Der Plugin-Anbieter verweist auf das Theme. Die frühere Agentur ist nicht mehr zuständig. Und interne Mitarbeiter möchten verständlicherweise keine sicherheitskritischen Updates auf der Live-Website ausprobieren.
Ein fester technischer Ansprechpartner schafft klare Zuständigkeiten.
Diese Person beziehungsweise dieses Team sollte:
- Updates planen und durchführen
- Backups kontrollieren
- Sicherheitsmeldungen bewerten
- Ausfälle und Auffälligkeiten überwachen
- technische Änderungen dokumentieren
- und bei einem akuten Problem schnell reagieren können
Mit unserer laufenden WordPress-Wartung und Website-Betreuung kümmern wir uns um regelmäßige Updates, Backups, Sicherheitsprüfungen und Monitoring. Gleichzeitig haben Sie einen persönlichen Ansprechpartner, der Ihre Website kennt und im Problemfall nicht erst die gesamte technische Umgebung verstehen muss.
Gute Website-Sicherheit beginnt nicht mit dem nächsten Alarm.
Sie beginnt mit jemandem, der auch dazwischen hinsieht.
Häufige Fragen zu gehackten WordPress-Websites
01Woran erkenne ich, ob meine WordPress-Website gehackt wurde?
Typische Anzeichen sind unerwünschte Weiterleitungen, unbekannte Seiten in den Google-Suchergebnissen, Browser- oder Hosting-Warnungen, neue Administratoren, ungewöhnliche Dateien, Spam-Versand oder eine plötzlich langsame Website. Manche Manipulationen treten nur auf Mobilgeräten, beim ersten Besuch oder nach einem Klick aus Google auf.
02Was soll ich zuerst tun, wenn WordPress gehackt wurde?
Isolieren Sie die Website zunächst möglichst auf Hosting- oder Serverebene. Sichern Sie anschließend Dateien, Datenbank und vorhandene Logs, bevor Sie Änderungen vornehmen. Danach sollten alle relevanten Zugänge abgesichert und der Umfang der Infektion geprüft werden.
03Kann ich Malware mit einem WordPress-Plugin selbst entfernen?
Ein Security-Plugin kann verdächtige Dateien erkennen und erste Hinweise liefern. Es ersetzt jedoch keine vollständige Analyse von Dateien, Datenbank, Benutzerkonten, Cronjobs, Zugängen und Serverumgebung. Wird nur der sichtbare Schadcode gelöscht, können Backdoors oder die ursprüngliche Sicherheitslücke bestehen bleiben.
04Reicht es, ein altes Backup einzuspielen?
Nur wenn das Backup nachweislich aus der Zeit vor der Infektion stammt und vollständig sauber ist. Zusätzlich müssen die ursprüngliche Sicherheitslücke geschlossen, sämtliche relevanten Zugangsdaten erneuert und die wiederhergestellte Website erneut geprüft werden. Andernfalls kann sie unmittelbar wieder kompromittiert werden.
05Wie lange dauert eine WordPress-Malware-Bereinigung?
Die Dauer hängt vom Umfang der Infektion, der Größe der Website, den verfügbaren Zugängen, der Backup-Situation und möglichen Google-Warnungen ab. Eine klar begrenzte Manipulation kann schneller behoben werden als ein WooCommerce-Shop mit kompromittierter Datenbank, mehreren Backdoors oder Tausenden Spam-URLs.
06Was kostet die Bereinigung einer gehackten Website?
Die Kosten richten sich nach dem tatsächlichen Schadensbild. Relevant sind unter anderem die Art der Malware, betroffene Dateien und Datenbankeinträge, vorhandene Backups, weitere Websites im Hosting, mögliche Google-Probleme und der notwendige Funktionsumfang nach der Wiederherstellung. Nach einer ersten technischen Prüfung erhalten Sie eine klare Einschätzung und ein transparentes Angebot.
07Muss ein WordPress-Hack der Datenschutzbehörde gemeldet werden?
Nicht automatisch. Entscheidend ist, ob personenbezogene Daten möglicherweise eingesehen, verändert, gelöscht, offengelegt oder unzugänglich gemacht wurden und welches Risiko daraus für die betroffenen Personen entsteht. Bei einer möglichen Datenschutzverletzung sollte zusätzlich eine qualifizierte Datenschutz- oder Rechtsberatung beigezogen werden.
08Kann Google eine gehackte Website aus den Suchergebnissen entfernen?
Ja. Malware, eingeschleuste Spam-Inhalte und unerwünschte Weiterleitungen können zu Sicherheitswarnungen, Rankingverlusten oder zur Entfernung einzelner Seiten aus der Google-Suche führen. Nach der vollständigen Bereinigung kann in der Google Search Console eine erneute Sicherheitsüberprüfung beantragt werden.
09Kann eine Website nach der Bereinigung erneut gehackt werden?
Ja, wenn die erste Bereinigung unvollständig war. Häufige Ursachen sind verbliebene Backdoors, kompromittierte Zugangsdaten, unsichere Plugins, manipulierte Cronjobs, infizierte Datenbankeinträge oder eine weitere kompromittierte Website im selben Hosting.
10Hilft Evario auch bei Websites, die von einer anderen Agentur erstellt wurden?
Ja. Wir analysieren und bereinigen auch WordPress-Websites, die nicht von Evario erstellt oder bisher betreut wurden. Wichtig ist lediglich, dass die notwendigen Zugänge zu WordPress, Hosting und gegebenenfalls Datenbank oder SFTP verfügbar sind.
