Ein echter WordPress‑Rettungsfall aus der Praxis

Eine WordPress‑Installation, die gestern noch normal lief, ist plötzlich komplett tot – weder Frontend noch Backend reagieren. Nach der ersten Wiederherstellung zeigt sich schnell, dass das Backend zwar wieder erreichbar ist, das Frontend jedoch weiterhin ausfällt. Ein Blick per FTP bringt die eigentliche Ursache ans Licht: Die Seite ist kompromittiert. Die Art der Infektion sorgt für massive Systemlast, selbstreparierende Core‑Dateien und ein Root‑Verzeichnis, das sich nicht mehr bereinigen lässt. Besonders heikel: Das Ganze läuft auf einem klassischen Webspace ohne SSH‑Zugriff, also ohne jede Möglichkeit, tiefer in das System einzugreifen.

Parallel dazu berichtet Golem über aufgekaufte WordPress‑Plugins, die gezielt mit Backdoors versehen wurden. Cloudflare wiederum bewirbt sein neues EmDash‑System als robustere Alternative. Doch was bedeutet das alles in der Praxis – und was lässt sich aus dieser Melange wirklich lernen?

WordPress ist nach wie vor eines der beliebtesten CMS unserer Zeit. Kein Wunder: schnell eingerichtet, flexibel erweiterbar und dank unzähliger Plugins lässt sich damit gefühlt alles umsetzen – zumindest vermeintlich. Und für alle, die es besonders bequem mögen, gibt es Hostingangebote, bei denen WordPress entweder direkt vorinstalliert ist oder sich per „One‑Click“ aktivieren lässt. Eine scheinbar einfache Welt: zusammengeklickt, veröffentlicht, fertig

Das Ganze hat aber natürlich auch eine gewisse Dramatik: Viele Plugins bedeuten nicht automatisch viel Klasse – manchmal ist es wirklich eher viel Masse. 😉
Cloudflare hat es in seinem EmDash‑Artikel ja selbst betont: Zum Zeitpunkt der Veröffentlichung lagen über 800 Plugins in der Prüfwarteschlange von WordPress. Bitte nicht falsch verstehen – es ist gut, dass geprüft wird. Aber seien wir ehrlich: Was wird geprüft? Wie gründlich? Wie oft? Und wie viele Nachprüfungen gibt es wirklich? Ein mulmiges Gefühl bleibt.

Und damit sind wir noch nicht am Ende. Durch das extrem einfache „Zusammenklicken“ schafft man sich nicht nur Performanceprobleme. Es entsteht auch ein ganz anderes Risiko: Komplexität, die niemand mehr überblickt.

Denn selbst erfahrene Admins wissen naturgemäß nicht, was jedes einzelne Plugin im Detail macht. Wie auch?
Golem hat es kürzlich gezeigt: 30 aufgekaufte Plugins wurden nach der Übernahme gezielt mit Backdoors versehen. Das kann niemand vorhersehen, niemand erkennen, niemand verhindern. Dass es überhaupt aufgeflogen ist, grenzt fast an ein Wunder – vermutlich, weil jemand die Backdoor im aktiven, also ausgenutzten Zustand erwischt hat.

Warum lässt sich so etwas so schwer eingrenzen?
Weil man realistisch davon ausgeht, dass ein Update eines regulär angebotenen Plugins erst einmal nichts Böses mitbringt. Schließlich wurde es ja geprüft.
Spoiler: Ja, am Anfang. Aber sicher nicht fortlaufend. (Dazu gleich mehr.)

Das Problem an der Sache: Man kann zwar über bestimmte Konfigurationen einiges erkennen, aber es gibt eben auch False Positives. Und wie soll man jetzt auseinanderhalten, was „nach Hause telefonieren“ darf – und was nicht? Beispiele für völlig legitime Kommunikation nach außen gibt es genug: Google Analytics, Social‑Media‑Posting‑Plugins, Newsletter‑Integrationen oder im Extremfall sogar ein Elasticsearch‑Cluster. All das ist möglich und oft sogar gewollt.

Genauso gibt es Plugins, die bewusst externe Inhalte nachladen: YouTube‑Videos, OpenStreetMap‑Karten (um nicht schon wieder Google zu nennen 😉) oder Schnittstellen, die News oder andere Daten von zentralen Anbietern beziehen. Und der klassische WordPress‑Betreiber hat WordPress vermutlich genau deswegen gewählt: weil es so einfach und intuitiv nutzbar ist.

Kurzum: Ja, es gibt Plugins wie WP Cerber, die hervorragend funktionieren und wertvolle Hinweise liefern. Aber wenn – nicht böse gemeint – der WordPress‑Nutzer eher aus der „Word for President“-Welt kommt, steht er vor einem Wald voller Bäume und erkennt trotzdem keinen Stamm.

Ein realer Fall: Wenn WordPress plötzlich komplett kompromittiert ist

Deswegen war es auch nicht verwunderlich, dass wir mal wieder einen Hilferuf bekamen: Eine komplette WordPress‑Installation war befallen. Besonders dramatisch: Sie lag auf einem klassischen Shared‑Hosting‑Account – also einem Webspace, der praktisch nichts zulässt. Keine Shell, kein eigener Rootzugriff, nicht einmal ein „Neustart“. Was also konnten wir tun?

Zunächst haben wir die gesamte Installation per FTP heruntergeladen und lokal über verschiedene PowerShell‑Befehle bereinigt. Natürlich nicht alles – das wäre gar nicht möglich gewesen. Stattdessen haben wir den WordPress‑Core frisch heruntergeladen, eine Sicherung des Plugin‑Ordners aus der Zeit vor dem Befall genutzt und dann gezielt im wp-content mit PowerShell die verdächtigen Dateien entfernt.

Leider half das nicht so wie erhofft. Der Befall betraf offenbar auch das Hintergrundsystem – und möglicherweise stammte er sogar von dort. Einige Core‑Files ließen sich schlicht nicht bereinigen, darunter ausgerechnet die zentrale index.php. Am Ende blieb nur eine Lösung: den DocumentRoot auf ein neues, sauberes Verzeichnis legen und dort das bereinigte Material komplett neu hochladen.

Jetzt stellt sich natürlich die spannende Frage: Kann EmDash dagegen wirken?
Hm – nicht wirklich. Ja, es mag sein, dass einiges isoliert läuft. Aber seien wir ehrlich: Wie viele Plugins brauchen keine Schreibrechte auf die Datenbank? Wie viele Entwickler gehen wirklich sorgsam mit Berechtigungen um? Und wie viele Admins solcher CMS sind sich dessen bewusst und vergeben nicht einfach großzügig „alle Rechte“? Man merkt schnell: Die Luft wird dünn, besonders wenn man all diese Faktoren kombiniert.

Und jetzt kommt der eigentliche Knaller: Wenn der Befall aus dem Hintergrund kommt – also aus dem System selbst – dann bringt es wenig, wenn das System sich isoliert betrachtet. Eine Backdoor unterhalb der WordPress‑Ebene kümmert sich nicht darum, wie sauber das CMS intern organisiert ist.

Unsere konkreten Empfehlungen

und Dinge, die wir selbst immer umsetzen

• WP Cerber nutzen.
  Verhindert nicht alles, aber erkennt vieles und liefert wertvolle Hinweise.
• Zwei‑Faktor‑Authentifizierung aktivieren.
  Schützt zwar nicht vor dem Befall selbst, aber verhindert, dass Angreifer Admin‑Konten übernehmen und dich aussperren.
• Standardpfade und Standardnamen vermeiden.
  Viele Angriffe setzen darauf, dass alles „wie immer“ heißt.
• Für produktive Systeme: Finger weg von Shared Hosting.
  Es mag günstig wirken, aber im Ernstfall ist man komplett abhängig vom Hoster – und ein erfahrener Admin kann ohne Shell schlicht nichts ausrichten.
• Regelmäßige Backups.
  Klingt banal, wird aber oft vernachlässigt. Für produktive Systeme mindestens täglich, bei sehr dynamischen Seiten gern häufiger.