Im November 2023 erreichte uns folgende Supportanfrage von einem Kunden:

“Ich kann mich nicht mehr in mein WordPress einloggen”.

Nun, das kann mehrere Gründe haben. Der User hat vielleicht sein Password vergessen. Im vorliegenden Fall lagen die Dinge jedoch etwas anders.

Wie sich schnell herausstellte, war es gar nicht mehr möglich, auf die wp-login.php bzw. wp-admin zuzugreifen. Bei dem Versuch landete (oder blieb) man auf der Startseite.

Ein kurzer Filecheck ergab, dass sowohl das Verzeichnis, als auch die Datei vorhanden waren und über ausreichende Rechte verfügten. Das war zu erwarten, denn WordPress funktioniert nicht ohne sie.

Wenn dennoch der Zugriff verweigert wurde, konnte dafür nur die .htaccess verantwortlich sein.

Es stellte sich allerdings schnell heraus, dass diese nicht editierbar, ja nicht einmal zu öffnen war, da sie die Rechte 444 besaß.

Nach dem Ändern der Rechte wurde offenbar, warum der Kunde sich nicht mehr einloggen konnte.

Sie enthielt den Eintrag:

<FilesMatch “^(wp-admin\.php|wp-admin(/.*)?)$”>
Order allow,deny
Deny from all
</FilesMatch>

Das bedeutet, dass niemandem der Zugang zur Datei wp-admin.php und zum Verzeichnis wp-admin gewährt wird.

Kein Wunder also, dass der Login nicht mehr aufrufbar war.

Nachdem der Block gelöscht wurde, war der Login wieder möglich. Es zeigte sich, dass zwei Adminkonten angelegt worden waren, die der Kunde nicht kannte. Diese wurden gelöscht.

Fall erledigt? Leider nein!

Der Kunde meldete seltsame Fehler, die wir hier einmal exemplarisch zusammenfassen wollen:

1. Der Medienbrowser zeigte die existierenden Medien nicht mehr an. 
2. Unter Design/Themes erfolgte eine Fehlermeldung. Es war nicht mehr möglich, den Themebrowser aufzurufen.
3. Elementor startete mit einem 500er Server Error (funktionierte danach aber problemlos).

Das machte einen ausführlichen Filecheck erforderlich. Es zeigte sich, dass bereits das Rootverzeichnis der Installation zahlreiche Dateien enthielt, die nicht zu WordPress gehörten. Das Plugin- Themes- und Uploadverzeichnis enthielten mehrere unbekannte Unterverzeichnisse mit zahlreichen html-Dateien darin. Hier lag der Grund für die Probleme mit dem Medien- und Themebrowser.

Zudem enthielten die index.php wie auch die wp-config.php zusätzlichen Schadcode.

Wir entschlossen uns, das Rootverzeichnis und das wp-content Verzeichnis manuell zu bereinigen und wp-adimn bzw. wp-includes frisch zu installieren. 

Letztere beiden Verzeichnisse enthalten weder Dateien noch Einstellungen des Nutzers und können einfach überschrieben werden. Dabei ist auf die richtige WordPress-Version zu achten, die man aus der wp-includes/versions.php auslesen kann.

Wichtig ist zudem, dass man die existierenden Verzeichnisse nicht einfach überschreibt, da hierbei zusätzlich hinzugefügte Schaddateien nicht angetastet werden.

Vielmehr benennt man die bestehenden Verzeichnisse um und installiert sie neu.

Nachdem wir das getan hatten, funktionierte WordPress wieder einwandfrei.

Zwei Tage später meldete sich der Kunde erneut und teilte mit, dass er sich erneut nicht anmelden konnte. Zudem seien auch alle Subdomains betroffen.

Der Kunde hatte 5 Subdomains angelegt. Auf dreien hatte er ebenfalls WordPress installiert, auf einer MediaWiki und eine enthielt nur Defaultdateien.

Alle WordPress-Installationen zeigten das gleiche Infektionsbild. Bei der MediaWiki-Installation waren die index.php und alle .htaccess-Dateien betroffen.

Nachdem wir einen kurzen Blick darauf geworfen hatten, war klar, dass die gesamte alte Infektionslage wieder vorhanden war und zwar vollständig. Daraus ergab sich der Verdacht, dass der unbekannte Hacker einen Zugang zum Dateisystem hatte, den wir noch nicht gesperrt hatten. Unser Kunde besaß keinen SSH-Zugang, jedoch die Möglichkeit, mehrere FTP-Zugänge anzulegen. Den Generalzugang hatte Plesk quasi automatisch angelegt und über diesen Zugang hatte sich unser Hacker einen Zugriff eingerichtet. Wie sich herausstellte, griff er automatisiert einmal am Tag via FTP auf das Dateisystem zu und tauschte bestimmte Dateien aus bzw. änderte Verzeichnisrechte. Da er den FTP-Generalzugang zu Kundenkonto besaß, konnte er alle Verzeichnisse beeinflussen, die sich darunter befanden. Somit betrafen die Veränderungen auch alle Subdomains.

Nachdem wir das Password dieses Zugangs geändert hatten, war nur noch eine einmalige Bereinigung der Dateien nötig und der Spuk hatte ein Ende.

Der Hack ist bekannt als “AnonymousFox-Hack”. Er kann in mehreren Versionen und auf unterschiedliche Weise erfolgen. Wenn sich der Hacker keinen Zugang via FTP verschaffen kann (etwa, weil dem Nutzer diese Berechtigung fehlt), installiert er meist eines oder mehrere Cron-Skripte, die er dann in regelmäßigen Abständen von außen triggert. Sie nehmen dann die gleichen Veränderungen vor, wie ein FTP-Zugriff.

Ziel des Hacks ist, die WordPress-Seite in eine SuMa-Spamming-Seite umzuwandeln. Im Hintergrund werden meist Seiten installiert, welche asiatische Texte und zahllose Links aufweisen. Sucht man daher in einer Suchmaschine gezielt nach allen Links zu seiner Website, wird man überraschen viele davon finden. Sie stellen zeitgleich der schnellste und sicherste Weg dar, um aus google & Co. herauszufliegen. Bereinigt man den Hack nicht binnen weniger Stunden, kann man die Domain praktisch wegwerfen, da sie bei nahezu allen Suchmaschinen geblacklistet wird.

Der WordPress-eigene Support ist bei der Lösung dieser Probleme übrigens keine große Hilfe. Zumindest der deutsche Ableger nicht. Die dortige “Hilfe” besteht im Wesentlichen aus einer “Ermahnung”, dass man die WordPress-Installation umgehend vom Netz nehmen soll und die Empfehlung, eine Bereinigung über ein Plugin (zumeist Wordfence) vornehmen zu lassen.

Nun… die Ermahnung, man solle die Seite sofort vom Netz nehmen, fußt im Wesentlichen darauf, dass in früheren Zeiten viele gehackte WordPress-Seiten Schadcode verteilten, der sich in den Browser der Besucher einnistete. Das ist bei AnonymousFox jedoch nicht der Fall und ist heutzutage auch nicht mehr üblich. Ein Hacker will die Seite lediglich für seine Zwecke nutzen.

Eine Bereinigung über ein Plugin funktioniert in der Regel nicht. Wenn ein solches Plugin überhaupt infizierte Seiten erkennt, so kann es diese mit an Sicherheit grenzender Wahrscheinlichkeit nicht automatisch bereinigen. Wordfence & Co. sind gut geeignet, um Hackerangriffe im Vorfeld abzuwehren, aber wenn es einem Hacker erst einmal gelungen ist, die Seite zu kapern, sind sie mehr oder weniger hilflos.