Anatomie eines WordPress-Einbruchs

🌟 Geschätzte Lesezeit: 10 Minuten

Wichtigste Erkenntnisse

– Bei einem Einbruch müssen alle vier Ebenen gleichzeitig entfernt werden: Lader, Nutzlast, Laufzeitkopien und Datenbank.

– Verfügbarkeit der Seite bedeutet nicht, dass sie sicher ist.

– Sicherheitsmaßnahmen sollten verstärkt werden, um unbefugten Zugriff zu verhindern.

Inhaltsverzeichnis

1. Fünf Administratoren, die ich nicht angelegt habe
2. Vier Ebenen, die sich gegenseitig wiederherstellen
3. Was die Schadsoftware eigentlich tat
4. Der Moment, der die Sache real gemacht hat
5. Wie ich vorgegangen bin
6. Warum ich am Ende neu gebaut habe
7. Was ich mitnehme

Haupttext

Gefunden habe ich es durch Zufall. Nicht durch Überwachung, nicht durch eine Warnung, nicht weil irgendwo ein roter Punkt aufleuchtete. Sondern weil eine Automatisierung nicht mehr durchlief.

Ein Workflow, der Artikel in meinen Blog schreibt, brach mit einer nichtssagenden Meldung ab: Authorization failed. Anmeldedaten falsch. Ich habe zuerst an einen abgelaufenen Zugang gedacht, ein technisches Detail, zehn Minuten Arbeit.

Dann habe ich nachgesehen und festgestellt: Sämtliche Anwendungspasswörter waren weg. Bei allen Benutzern. Nicht abgelaufen — gelöscht.

Fünf Administratoren, die ich nicht angelegt habe

Der Blick in die Benutzerliste war der Moment, in dem aus einem technischen Ärgernis etwas anderes wurde.

Benutzer	E-Mail	Angelegt
wpsvc_…	Domain existiert nicht	19.07., 06:01
…_tiffd2	Wegwerfadresse	26.07., 09:44
…_midiaf5d5	Wegwerfadresse	26.07., 23:50
super	leer	28.07., 03:00
root	leer	28.07., 03:32

Zwei Dinge daran sind wichtig.

Benutzer ohne E-Mail-Adresse lassen sich über die Oberfläche nicht anlegen. WordPress verlangt sie. Wer trotzdem einen hat, ist an der Oberfläche vorbeigegangen — direkt in die Datenbank oder über eingeschleusten Code.

Und die Frequenz stieg. Einer am 19. Juli. Zwei am 26. Zwei in der Nacht auf den 28. Das ist kein Einbruch, das ist eine Einrichtung. Jemand baute sich Ersatzschlüssel für den Fall, dass ich einen finde.

Der erste Fremd-Admin datierte auf den 19. Juli, 6 Uhr morgens. Mein letzter erfolgreicher Workflow-Lauf war am selben Tag um 15:56. Ich hatte also neun Tage lang auf einer Seite gearbeitet, die nicht mehr mir gehörte.

Vier Ebenen, die sich gegenseitig wiederherstellen

Was ich dann fand, war kein hingerotztes Skript. Das war Handwerk.

Ebene eins: der Lader. Sieben Dateien in wp-content/mu-plugins, getarnt als „WP Core Update Helper”. Must-use-Plugins sind der ideale Ort dafür: Sie werden bei jedem Seitenaufruf geladen, tauchen in der Plugin-Liste nicht auf und lassen sich über die Oberfläche nicht abschalten. Das Dateidatum war auf Dezember zurückdatiert.

Ebene zwei: die Nutzlast. Über zehn PHP-Dateien in wp-content/uploads, mit Namen wie class-wp-post_33bb57e5.php — Nachahmungen von Kern-Dateien. Dort gehören niemals PHP-Dateien hin. Die Hex-Anhängsel der Lader entsprachen exakt denen der Nutzlasten, jedes Paar gehörte zusammen.

Ebene drei: Laufzeitkopien. Fünfzehn Dateien in /tmp, jede exakt 93.952 Bytes groß.

Ebene vier: die Datenbank. Ein getarnter Zwischenspeicher-Eintrag mit 125 KB Inhalt.

Und jetzt der Teil, der mich beeindruckt hat, so ungern ich das schreibe:

Der Lader prüft bei jedem Seitenaufruf, ob die Nutzlast noch da ist. Fehlt sie, stellt er sie wieder her. Fehlt auch die Kopie in uploads, liest er die Konfigurationsdatei aus, holt sich die Datenbank-Zugangsdaten und rekonstruiert alles aus der Datenbank.

Wer nur die Dateien löscht, hat nach dem nächsten Seitenaufruf wieder alles. Wer Dateien und Datenbank getrennt bereinigt, ebenfalls — die Reste bauen sich gegenseitig auf. Man muss alle vier Ebenen gleichzeitig entfernen, oder man kann es lassen.

Was die Schadsoftware eigentlich tat

Nicht Daten stehlen. Nicht verschlüsseln. Etwas Unauffälligeres.

Die manipulierte index.php lief bei jedem Aufruf und prüfte, wer da anklopft. Kam ein Suchmaschinen-Crawler — Google, Bing und ein paar andere — bekam er anderen Inhalt als ein normaler Besucher. Nachgeladen von einem fremden Server.

Meine Domain wurde also benutzt, um fremde Seiten in Suchmaschinen nach oben zu bringen. Für mich war die Seite völlig normal. Nur Google sah etwas anderes.

Die Adresse des Steuerungsservers stand zeichenweise verschoben in einer Konstante am Dateianfang — simpel, aber es reicht, um bei einer Textsuche durchzurutschen. Dazu passte eine hartkodierte Zeitzone und eine Marker-Datei im Web-Verzeichnis mit einem einzelnen Wort als Inhalt.

Es gab noch eine zweite, unabhängige Hintertür: eine Datei, die wp-login.php nachahmte, mit vertauschtem i und 1 im Namen. Passwortgeschützt. Falls der Rest auffliegt.

Der Moment, der die Sache real gemacht hat

Während ich das alles zusammentrug, schrieb sich die Marker-Datei im Web-Verzeichnis neu. Zeitstempel: 17:00 Uhr. Kopien der Nutzlast in /tmp: 11:06 Uhr desselben Tages.

Das lief nicht seit Juli vor sich hin. Das lief, während ich danach suchte.

An dem Punkt hört technisches Interesse auf und etwas anderes fängt an. Ich habe an dem Abend nicht mehr aufgehört, bevor die Seite abgeriegelt war.

Wie ich vorgegangen bin

Zuerst abriegeln, dann verstehen. PHP-Ausführung deaktiviert, den Cronjob der Schadsoftware abgeschaltet. Beides war nötig: Der Lader hatte sich zusätzlich in WordPress’ eigene Zeitsteuerung eingehängt, und die lief über die Kommandozeile am abgeschalteten PHP vorbei.

Beweise sichern, bevor etwas verschwindet. Datenbank-Abzug, Archive aller Schaddateien, Sicherungen der Konfigurationen. Nicht aus Ermittlereifer, sondern weil man beim Aufräumen zwangsläufig Spuren zerstört und danach nichts mehr nachsehen kann.

Dann der Kern ersetzt. Dabei zwei Widerstände: Das Web-Verzeichnis stand auf Nur-Lesen — die Schadsoftware hatte die Rechte geändert. Und die manipulierte index.php trug ein Dateiattribut, das Änderungen verhindert. Beides musste erst weg.

Über vierzig Schaddateien entfernt, in zwei Runden. Die zweite brachte vier weitere gefälschte Plugins zutage, jeweils mit erfundenem Autor „WordPress.org Community” und einer token-geschützten Kommandozeile darin.

Danach die Datenbank: fünf Fremd-Admins gelöscht, ihre Inhalte auf meinen Benutzer umgeschrieben, der getarnte Eintrag entfernt, der Cron-Hook gelöscht.

Zum Schluss die Zugangsdaten: Sicherheitsschlüssel rotiert, alle Sitzungen beendet, alle Anwendungspasswörter gelöscht, neue Passwörter vergeben.

Ein Punkt war mir dabei wichtig, und ich halte ihn für den unterschätztesten: Ich habe kein neues Anwendungspasswort in das kompromittierte System eingebaut, bevor es sauber war. Das wäre der bequeme Weg gewesen, um den kaputten Workflow schnell wieder ans Laufen zu bringen. Es hätte den Zugang direkt beim Angreifer abgeliefert — und den Einbruch als harmloses Konfigurationsproblem getarnt.

Warum ich am Ende neu gebaut habe

Die Bereinigung war erfolgreich. Prüfsummen des Kerns sauber, Cloaking-Test negativ, nur noch die zwei echten Administratoren.

Trotzdem blieb eine Frage offen, die ich nicht beantworten konnte: Wie kam der Angreifer überhaupt herein? Die Zugriffsprotokolle reichten sieben Tage zurück, der 19. Juli war längst herausrotiert. Alle Erweiterungen waren zum Zeitpunkt der Bereinigung aktuell. Ich konnte den Einstiegspunkt nicht benennen.

Und wer den Einstieg nicht kennt, hat ihn nicht geschlossen.

Also habe ich neu aufgebaut. Anderer Systembenutzer, andere Datenbank, frische Installation, nur Inhalte übertragen — keine Programmdateien. Schadcode steckt immer in Programmdateien. Wer nur Beiträge, Seiten und Bilder überträgt, kann nichts mitschleppen, unabhängig davon, wie gründlich die Bereinigung war.

Und dabei habe ich eine Entscheidung getroffen, die ich vorher für übertrieben gehalten hätte: keine einzige Erweiterung. Der Blog läuft heute mit null Plugins. Was ich brauche — Suchmaschinen-Auszeichnung, Bildoptimierung, Weiterleitungen — steht in eigenen, wenigen Zeilen Code, die ich selbst gelesen habe.

Die Angriffsfläche ist damit von über 9.000 PHP-Dateien auf knapp 1.500 gefallen.

Was ich mitnehme

Der Fund war Zufall. Das ist der Teil, der mich am meisten beschäftigt. Ohne den abgebrochenen Workflow hätte ich es womöglich Monate nicht bemerkt — die Seite sah für mich ja normal aus. Meine Überwachung prüfte, ob Dienste laufen. Sie prüfte nicht, ob sich Dateien verändern oder Benutzer dazukommen. Genau das läuft jetzt.

Verfügbarkeit ist kein Gesundheitszeichen. Eine Website, die einwandfrei antwortet, kann trotzdem seit Wochen jemand anderem gehören.

Und die Reihenfolge zählt. Abriegeln, sichern, verstehen, bereinigen — in dieser Folge. Wer zuerst aufräumt, verliert die Möglichkeit herauszufinden, was passiert ist. Wer zuerst versteht, gibt dem Angreifer Zeit.

Auf technische Details des Steuerungsservers und die IP-Adressen verzichte ich hier bewusst. Sie helfen niemandem beim Absichern und dem Falschen beim Nachbauen.

FAQ

Q: Wie erkenne ich einen WordPress-Einbruch?

A: Ungewöhnliche Benutzerkonten, Anmeldedaten, die fehlen oder falsch sind, und Veränderungen an Dateien sind eindeutige Anzeichen.

Q: Was soll ich tun, wenn meine Seite gehackt wurde?

A: Sofort abriegeln, Beweise sichern, dann den Kern ersetzen und alle Nutzer überprüfen.

Q: Wie kann ich meine WordPress-Seite schützen?

A: Halten Sie Ihre Plugins und Themes aktuell, verwenden Sie starke Passwörter und führen Sie regelmäßige Sicherungen durch.