WordPress-Website gehackt: Warum der Schaden oft lange unbemerkt bleibt
Eine kompromittierte WordPress-Website kann für Besucher völlig normal aussehen. Ein realer Fall zeigt, wie Webshells, Weiterleitungen und mehr als eine Million bei Google erfasste Seiten erst spät sichtbar wurden.
CA. 14 MIN LESEZEIT
Eine gehackte Website sieht nicht immer gehackt aus. Genau das macht erfolgreiche Angriffe auf WordPress für Unternehmen so problematisch.
Manchmal leitet ein Google-Suchergebnis plötzlich auf einen fremden Shop weiter. Im WordPress-Backend taucht ein unbekannter Administrator auf oder ein Sicherheitsscan meldet verdächtige PHP-Dateien. Das sind die offensichtlichen Fälle.
Gefährlicher ist häufig der Angriff, bei dem zunächst überhaupt nichts sichtbar passiert. Der Angreifer verschafft sich Zugriff, legt Hintertüren an und wartet. Die Website funktioniert weiter, während sie im Hintergrund bereits für Spam, Weiterleitungen oder weitere Manipulationen missbraucht werden kann.
Der folgende Beitrag basiert auf einem aktuellen Praxisfall. Die technischen Befunde zeigen, woran Websitebetreiber ähnliche Auffälligkeiten erkennen und wie sie deren Bedeutung richtig einordnen können.
Die wichtigsten Befunde auf einen Blick.
- Eine WordPress-Website kann lange kompromittiert sein, ohne sichtbar verändert zu wirken.
- site:deine-domain.de kann unerwartete Google-Ergebnisse sichtbar machen.
- Auffällige Dateien lagen in Webroot, wp-admin, wp-includes, wp-content und .well-known.
- 210.000 Seiten waren indexiert, weitere 840.000 nicht indexiert.
- Eine sichtbare Datei zu löschen stellt noch keinen vertrauenswürdigen Zustand her.
Warum auch eine normale Unternehmenswebsite zum Ziel wird.
Der Angreifer muss das Unternehmen nicht kennen und sich nicht für dessen Produkte interessieren. Viele Angriffe laufen automatisiert: Bots suchen nach erreichbaren WordPress-Installationen, schwachen Zugangsdaten und bekannten Schwachstellen in nicht gepflegten Komponenten.
Eine kompromittierte Website ist für Angreifer selbst dann wertvoll, wenn dort keine Geschäftsgeheimnisse veröffentlicht werden. Sie besitzt eine etablierte Domain, Speicherplatz, Rechenleistung und häufig bereits Vertrauen bei Suchmaschinen. Das kann für Spam-Seiten, versteckte Links, Weiterleitungen, Phishing oder als Ausgangspunkt für weitere Angriffe genutzt werden.
Entscheidend ist deshalb nicht, ob das Unternehmen interessant erscheint. Entscheidend ist, ob die Website eine nutzbare Schwachstelle oder einen bereits kompromittierten Zugang bietet.
Ein Google-Test, den jeder selbst durchführen kann.
Ein erster, unkomplizierter Hinweis ist eine auf die eigene Domain beschränkte Google-Suche. Dazu wird folgende Abfrage eingegeben:
site:deine-domain.de
Anschließend lohnt sich ein Blick auf Titel, Beschreibungen und URL-Pfade. Tauchen plötzlich fremde Produkte, Arzneimittel, Glücksspielangebote, zweifelhafte Shops oder Inhalte in einer unbekannten Sprache auf, ist eine technische Prüfung erforderlich.
Der site:-Operator ist kein vollständiges Verzeichnis aller indexierten URLs. Google weist selbst darauf hin, dass Ergebnisse nicht garantiert vollständig sind. Als schneller Sichtcheck ist die Abfrage trotzdem hilfreich. Ergänzend gehören die Berichte „Sicherheitsprobleme“, „Manuelle Maßnahmen“ und „Seitenindexierung“ in der Google Search Console in die Prüfung.
Wenn ein Google-Ergebnis auf eine fremde Infrastruktur führt.
Im untersuchten Fall führte der Klick auf eines der manipulierten Google-Ergebnisse nicht zuverlässig zur eigentlichen Unternehmenswebsite. Stattdessen erschien eine Adresse auf einer fremden Infrastruktur. Die fremde Adresse lautete in entschärfter Schreibweise: ns1[.]xavyi[.]site.
Die Adresse enthielt einen Parameter namens ss. Dessen Wert sah zunächst zufällig aus, war aber Base64-kodiert. Eine rein lokale Dekodierung – ohne die fremde Adresse aufzurufen – ergab:
w;58;1117996;deine-website.de;10;16;C_cdn.wordp
Das zeigt, dass Informationen wie eine Domain und weitere Steuerwerte in einem leicht transportierbaren Parameter mitgegeben wurden. Base64 ist dabei keine Verschlüsselung, sondern lediglich eine Kodierung. Aus dem dekodierten Wert allein lässt sich nicht das gesamte weitere Verhalten beweisen. Zusammen mit den Weiterleitungen, Spam-Ergebnissen und Serverfunden war er jedoch ein relevanter Untersuchungsbaustein.
Verdächtige Ziele sollten nicht im normalen Browser geöffnet werden. Google empfiehlt bei potenziell infizierten Seiten ebenfalls alternative Prüfwege, weil Inhalte abhängig von Browser, Besucher oder Suchmaschinen-Crawler unterschiedlich ausgeliefert werden können.
Die Webshell war kein einzelner Fremdkörper.
Bei der Analyse fanden sich zwei obfuskierte PHP-Webshells. Vereinfacht gesagt handelt es sich um passwortgeschützte Dateimanager-Backdoors. Nach erfolgreicher Anmeldung konnten sie Dateien auflisten, lesen, überschreiben, hochladen, löschen, umbenennen und Dateirechte verändern.
Eine Probe konnte zusätzlich Inhalte von einer entfernten Adresse nachladen und als Datei speichern. Beide Proben manipulierten Dateizeitstempel: einmal zufällig um 30 bis 300 Tage, einmal exakt um 100 Tage in die Vergangenheit. Das ist forensisch besonders relevant, weil das Änderungsdatum einer verdächtigen Datei dadurch keinen zuverlässigen Rückschluss mehr auf den tatsächlichen Zeitpunkt des Angriffs erlaubt.
Vom verschleierten Fund zur verständlichen Wirkung
Im Original wurden Funktionsnamen und Oberflächentexte aus langen, zusammengesetzten Zeichenketten aufgebaut. Ein kurzer, nicht ausführbarer Ausschnitt verdeutlicht das Prinzip:
$pic = 'b'.'A'.'S'.'e'.'6'.'4' …
$funktionen = explode('~', dekodierter_text …)
Entschlüsselt zeigen sich unter anderem folgende Funktionen:
[deaktiviert] Datei überschreiben[deaktiviert] Upload speichern[deaktiviert] Datei oder Verzeichnis löschen[deaktiviert] Zeitstempel zurückdatieren
Der Scanner meldete insgesamt 19 Ergebnisse. Das bedeutete nicht 19 verschiedene Schadcodedateien: Mehrere Dateien wurden sowohl als Malwaretreffer als auch als unbekannte Core-Datei gemeldet; hinzu kamen eine Plugin-Schwachstellenwarnung und ein Theme-Update. Nach dem Entfernen dieser Dubletten blieben mindestens zwölf unterschiedliche auffällige Dateien:
/wp-in[kennung].php/wp-comments.php/.well-known/main.php/wp-includes/lpoltd.php/wp-includes/.[kennung]/wp-includes/Text/Diff/Engine/index.php/wp-includes/css/dist/customize-widgets/index.php/wp-admin/options-mbuunk.php/wp-admin/maint/index.php/wp-content/mmlcmp.php/wp-content/maintenance/assets/fonts/xofjvg.php/wp-content/ngg/modules/photocrati-nextgen_pro_upgrade/index.php
Die Verteilung ist entscheidend: Auffälligkeiten lagen nicht nur in einem Pluginordner, sondern im Webroot, in Core-Verzeichnissen, unter wp-content und im eigentlich unauffälligen Verzeichnis .well-known. Der zusätzliche Hinweis auf eine Plugin-Schwachstelle ist ein Prüfpunkt, aber ohne passende Zugriffsprotokolle kein Beweis für den ursprünglichen Eintrittsweg.
Der Suchmaschinenschaden wurde erst in der Masse sichtbar.
Der sichtbarste Langzeitschaden zeigte sich in der Google Search Console. Dort waren 210.000 Seiten als indexiert und weitere 840.000 als nicht indexiert erfasst. Insgesamt kannte Google damit rund 1,05 Millionen Seitenzustände im Zusammenhang mit einer Website, die regulär nur einen Bruchteil dieser Menge benötigt hätte.
Das ist kein kosmetisches SEO-Problem. Suchmaschinen müssen massenhaft manipulierte URLs erneut crawlen und bewerten. Selbst wenn der Schadcode technisch entfernt ist, können alte Ergebnisse, Weiterleitungen und URL-Muster noch lange sichtbar bleiben.
Nach der Bereinigung müssen unerwünschte URLs dauerhaft sinnvolle Statuscodes liefern, Sitemaps und interne Verlinkungen müssen stimmen und die Search Console muss weiter beobachtet werden. Googles Sicherheitsbericht verlangt außerdem, alle betroffenen Bereiche zu bereinigen; eine teilweise Korrektur einzelner Beispiel-URLs genügt nicht.
Nach der Bereinigung: Spam-URLs wirklich beenden.
Nachdem Schadcode, Webshells und manipulierte Inhalte entfernt wurden, sollte deshalb auch das entstandene URL-Schema geprüft werden. Wiederholen sich eindeutige Präfixe, Verzeichnisse, Dateinamen oder Pfadmuster, dürfen diese URLs nicht weiterhin eine normale Seite mit Status 200 ausliefern oder pauschal auf die Startseite weiterleiten.
Gibt es für eine nachweislich manipulierte URL keinen passenden legitimen Ersatz, kann der Webserver sie gezielt mit 410 Gone beantworten. Bei einem Apache-Server lässt sich ein vorher exakt geprüftes Muster beispielsweise über die .htaccess abfangen:
RewriteEngine On
RewriteRule ^beispiel-spam-pfad(?:/.*)?$ - [G]
Das Apache-Flag [G] liefert den HTTP-Status 410 zurück. Google empfiehlt für dauerhaft entfernte Inhalte ohne passenden Ersatz einen echten Status 404 oder 410. Damit erhält die Suchmaschine beim erneuten Crawlen ein eindeutiges Signal, dass diese Ressource nicht mehr existiert.
Wichtig: Eine solche Regel wird erst nach einer vollständigen Bestandsaufnahme eingesetzt und muss so eng gefasst sein, dass sie keine legitimen Seiten trifft. Vorher wird die .htaccess gesichert; danach werden Beispiel-URLs und echte Seiten mit einem HTTP-Header-Test kontrolliert. Sitemaps, interne Links und die Search Console bleiben weiterhin Teil der Nachkontrolle. Ein 410-Status entfernt Treffer nicht augenblicklich, ist aber ein belastbares technisches Signal für die dauerhafte Bereinigung.
Google Search Central: Entfernte Seiten mit 404 oder 410 beantworten
Apache HTTP Server: RewriteRule-Flag G (Gone)
Zwei Scannerhinweise aus demselben Fall.
Die beiden Scannerhinweise zeigen typische Auffälligkeiten: eine fremde Include-Datei und verschleierten PHP-Code. Solche Treffer sind wichtige Ausgangspunkte, müssen aber immer im Zusammenhang mit Dateien, Konten, Protokollen und dem tatsächlichen Verhalten der Website bewertet werden.
Die eigene Domain bei Google prüfen.
Suche nach site:deine-domain.de und prüfe Titel, Beschreibungen und URL-Pfade auf völlig fremde Inhalte. Die Abfrage ist nur ein Sichtcheck und kein vollständiger Sicherheitsnachweis.
Bei Auffälligkeiten nicht auf verdächtige Ergebnisse klicken, sondern Search Console, Dateien und Protokolle strukturiert prüfen lassen.
- Fremde Titel und Beschreibungen notieren
- Ungewöhnliche URL-Pfade sichern
- Search Console und Serverbefunde gemeinsam auswerten
Warum „Datei gelöscht“ noch keine saubere Website bedeutet.
Der erste Schritt einer belastbaren Untersuchung ist nicht das hektische Löschen sichtbarer Treffer. Zuerst wird der vorhandene Zustand gesichert: Webspace, Datenbank und – soweit verfügbar – Server-, Zugriffs-, SFTP-/FTP-, Firewall- und Sicherheitsprotokolle.
Diese Sicherung ist kein sauberes Backup, sondern Beweismaterial. Ältere Sicherungsstände helfen beim Vergleich. Sie sind aber nicht automatisch vertrauenswürdig. Wenn der Angreifer bereits Monate unbemerkt Zugriff hatte, kann auch das Backup der vergangenen Woche Webshells oder manipulierte Inhalte enthalten.
Je nach Befund werden WordPress-Core, Plugins und Themes aus vertrauenswürdigen Originalquellen neu aufgebaut. Verbleibende Dateien, Uploads, Konfiguration, Weiterleitungsregeln, Benutzerkonten, Datenbankeinträge und geplante Aufgaben müssen separat geprüft werden. Bei einer stark kompromittierten Installation kann ein kontrollierter Neuaufbau belastbarer sein als der Versuch, jede Manipulation einzeln zu reparieren.
Enthält die WordPress-Datenbank personenbezogene oder vertrauliche Daten, gehört außerdem eine Datenschutzbewertung zum Vorfall. Die technische Möglichkeit eines Datenbankzugriffs beweist keinen Datenabfluss. Sie darf aber auch nicht ignoriert werden. Bei einer meldepflichtigen Datenschutzverletzung nennt Artikel 33 DSGVO grundsätzlich eine Frist von möglichst 72 Stunden nach Bekanntwerden; die rechtliche Bewertung gehört in fachkundige Hände.
Schutz entsteht aus mehreren Schichten.
Kein einzelnes Security-Plugin kann Updates, sichere Konten, Backups, Überwachung und einen funktionierenden Notfallablauf ersetzen. Für eine normale Unternehmenswebsite bilden folgende Maßnahmen die Grundlage:
- WordPress, Plugins und Themes zeitnah aktualisieren,
- nicht mehr benötigte Erweiterungen und Benutzerkonten entfernen,
- Administrationsrechte auf tatsächlich benötigte Konten beschränken,
- lange, einzigartige Passwörter aus einem Passwortmanager verwenden,
- Administratorzugänge mit Mehrfaktor-Authentifizierung schützen,
- vollständige Backups mit ausreichender Historie getrennt aufbewahren,
- Wiederherstellungen regelmäßig testen,
- Dateiveränderungen, neue Administratoren und ungewöhnliche Anmeldungen überwachen,
- Search Console und Erreichbarkeit kontinuierlich kontrollieren,
- Zuständigkeiten für einen Sicherheitsvorfall vorab festlegen.
WordPress empfiehlt aktuelle Software, vertrauenswürdige Quellen, Backups, Logging und Monitoring. Das BSI rät bei einem Vorfall ausdrücklich dazu, nicht übereilt zu handeln, Informationen zu sammeln und Verantwortlichkeiten festzulegen. NIST empfiehlt einzigartige Passwörter aus einem Passwortmanager und keinen anlasslosen periodischen Passwortwechsel; bei einem Verdacht auf Kompromittierung müssen die betroffenen Zugangsdaten selbstverständlich erneuert werden.
Die entscheidende Frage nach einem Angriff lautet nicht: „Ist der sichtbare Schadcode weg?“ Sie lautet: „Welche Belege sprechen dafür, dass diesem System wieder vertraut werden kann?“
Quellen und weiterführende Informationen
- WordPress.org: FAQ – My site was hacked
- WordPress Developer Handbook: Hardening WordPress
- Google Search Central: site:-Suchoperator
- Google Search Console: Bericht „Sicherheitsprobleme“
- BSI: Organisatorische Checkliste für IT-Sicherheitsvorfälle
- NIST SP 800-63B: Authentication and Lifecycle Management
- EUR-Lex: DSGVO, Artikel 33
WordPress-Vorfall vollständig untersuchen.
it-guenter.de unterstützt bei Bestandsaufnahme, Beweissicherung, Datei- und Datenbankprüfung, kontrollierter Bereinigung und dem sicheren Wiederanlauf. Dazu gehört auch der Blick auf Benutzerkonten, Backups und die langfristigen Folgen in der Google Search Console.
Unterstützung ist in Deggendorf und Niederbayern sowie deutschlandweit per Fernbetreuung möglich.
Von einzelnen Treffern zum belastbaren Gesamtbild.
Scannerfunde sind ein wichtiger Ausgangspunkt. Erst die gemeinsame Bewertung von Dateien, Datenbank, Konten, Protokollen, Backups und Suchmaschinenfolgen zeigt, wie weit ein Vorfall tatsächlich reicht.
Kurz geklärt.
Mögliche Hinweise sind unbekannte Administratoren, veränderte Inhalte, Weiterleitungen, fremde URLs in Google, Sicherheitswarnungen oder unerwartete PHP-Dateien. Eine kompromittierte Website kann allerdings längere Zeit normal aussehen. Deshalb sind regelmäßige Kontrollen und der Vergleich mit einem bekannten Sollzustand wichtig.
Die Abfrage begrenzt Google-Ergebnisse auf eine Domain. Fremde Produktnamen, ungewöhnliche Sprachen oder unerwartete URL-Pfade können einen ersten Hinweis auf SEO-Spam liefern. Google weist darauf hin, dass der site:-Operator keine garantiert vollständige Liste aller indexierten URLs ausgibt.
Nein. Ein Scanner kann Auffälligkeiten melden, aber Dateien, Benutzer, Datenbank, Weiterleitungen, Protokolle und Suchmaschinenfolgen müssen gemeinsam bewertet werden. Ein Treffer ist ein wichtiger Hinweis; ein unauffälliger Scan allein beweist umgekehrt keinen vollständig vertrauenswürdigen Zustand.
Nur wenn nachvollziehbar geprüft wurde, dass der Sicherungsstand noch vor der Kompromittierung liegt. Bei einem lange unbemerkten Angriff können auch aktuelle Backups bereits Webshells oder manipulierte Inhalte enthalten. Deshalb sind eine ausreichende Backup-Historie und ein Vergleich mehrerer Zeitstände wichtig.
Ja, wenn personenbezogene Daten betroffen sein könnten. Die Möglichkeit eines Zugriffs ist noch kein Beweis für einen Abfluss, erfordert aber eine strukturierte Bewertung. Ob Melde- oder Informationspflichten bestehen, hängt vom konkreten Vorfall und Risiko ab und sollte fachkundig beurteilt werden.
Ist die sichtbare Manipulation wirklich vollständig entfernt?
Eine strukturierte Untersuchung trennt einzelne Scannerfunde von der tatsächlichen Reichweite des Vorfalls. So entsteht ein nachvollziehbarer Bereinigungsstand statt eines unsicheren „sieht wieder normal aus“.
Die Rückmeldung erfolgt persönlich und verständlich.
Telefon
+49 (0) 991 / 991 331 81
E-Mail
info@it-guenter.de