Wie geht man vor, wenn man feststellt, dass eine Website gehackt wurde? In einem früheren Artikel haben wir bereits den grundlegenden Ablauf in sechs Schritten beschrieben. In diesem Artikel möchten wir anhand eines konkreten Beispiels zeigen, wie das in der Praxis aussieht.
Wie man einen Hacker-Angriff erkennt
Als unsere Kundin auf ihrer Website gut 150 Beiträge entdeckte, die sie nicht selbst erstellt hatte, war ihr auf Anhieb klar, dass hier etwas nicht stimmte. Und da sich alle diese Beiträge um Glücksspiele drehten, gab es nur eine logische Erklärung: Die Website war gehackt worden mit dem Ziel, Werbung für dubiose Angebote zu machen. Solcher Spam-Content soll insbesondere die Platzierung der beworbenen Websites in Suchmaschinen positiv beeinflussen – eine bekannte Methode des Black Hat SEO, also der nicht legitimen Suchmaschinen-Optimierung.
Als wir uns die Website genauer angeschaut haben, fanden wir verschiedene weitere Indizien für einen Hacker-Angriff:
In der Benutzerverwaltung wurde ein einziges Konto mit dem Benutzernamen unserer Kundin angezeigt. Wenn man allerdings genau hinschaute, wurde die Anzahl der Administratoren mit 5 angegeben. Wir hatten deshalb den Verdacht, dass sich die Hacker Administratoren-Konten angelegt, diese aber in der Benutzerverwaltung ausgeblendet haben, um unentdeckt zu bleiben.
In der Plug-in-Verwaltung war ein Plug-in namens «WP-System-Core» aufgeführt. Der Name sollte wohl den Eindruck erwecken, es handle sich dabei um eine zwingend benötigte Systemkomponente. Für unerfahrene Benutzer klingt das vertrauenswürdig, und sie würden ein solches Plug-in wohl kaum löschen. Wer sich allerdings mit WordPress auskennt, schöpft sofort Verdacht, denn der Core ist ja eben genau kein Plug-in. Ausserdem existiert das Plug-in nicht im offiziellen Plug-in-Verzeichnis auf wordpress.org.
Wenn man dann in den Plugin-Datei-Editor wechselte, wurden rund doppelt so viele Plug-ins aufgelistet wie in der Plug-in-Verwaltung. Die zusätzlichen Plug-ins trugen Namen wie «WP Defence», «WP Security Helper» oder «WP Compatibility Patch». Hier drängte sich die Frage auf: Warum wurden diese nicht in der Plug-in-Verwaltung angezeigt, wenn sie doch nur für Sicherheit und Stabilität der Website besorgt waren?
Ein Blick in den Quellcode der genannten Plug-ins bestärkte uns in unserem Verdacht. Und eine kurze Prüfung durch Claude bestätigte schliesslich in allen drei Fällen, dass diese Plug-ins von Hackern installiert worden waren:
Das ist kein Sicherheits-Plugin, sondern Malware – konkret ein Black-Hat-SEO-/Cloaking-Schädling mit eingebauter Backdoor, getarnt als Brute-Force-Schutz.
Das ist ein Doorway-/Spam-Content-Generator (Black-Hat-SEO), kein legitimes Plugin. Die Klasse erzeugt aus vorbereiteten Textbausteinen automatisch «einzigartige» Fake-Artikel und Download-Seiten.
Das ist kein Security-Plugin, sondern eine Backdoor-Tarnung. Es versteckt alle Benutzerkonten ausser dem eigenen und versteckt sich selbst aus der Plugin-Liste.
Wie man eine gehackte Website bereinigt
Leider existierte in diesem Fall kein Backup, aus dem wir die Website hätten restaurieren können. Es blieb somit nur die aufwändige Methode, die Website abzusichern und dann manuell zu bereinigen.
Bevor wir irgendetwas an der Website veränderten, erstellten wir mit All-in-One WP Migration and Backup eine Sicherheitskopie der gesamten Website. Dieses Plug-in bewältigt nach unserer Erfahrung auch schwierige Fälle (z.B. sehr grosse oder korrupte Websites), an denen andere Backup-Plug-ins gelegentlich scheitern. Diese Sicherheitskopie hätte es uns erlaubt, notfalls nochmals von vorne zu beginnen, falls uns bei der Bereinigung ein Fehler unterlaufen wäre. Zudem konnten wir damit den Hack dokumentieren.
Als ersten Schritt der Bereinigung löschten wir alle uns nicht bekannten Plug-ins – insbesondere natürlich diejenigen, die wir zuvor als Malware identifiziert hatten. Da die meisten nicht in der Plug-in-Verwaltung auftauchten, nutzten wir dafür einen FTP-Client, um das Verzeichnis /wp-content/plugins/ zu säubern. Zusätzlich haben wir das Verzeichnis /wp-content/mu-plugins/ bereinigt, wo die sogenannten Must Use Plug-ins liegen: Diese sind bei Hackern besonders beliebt, weil sie in der Plug-in-Verwaltung nicht ohne weiteres sichtbar sind und von dort aus nicht gelöscht werden können.
Auch bei den Themes – die bekanntlich ebenfalls Schadcode enthalten könnten – haben wir vorsichtshalber aufgeräumt, obwohl es hier keinen konkreten Verdacht gab. Von den rund 20 installierten Themes haben wir nur gerade das aktive behalten und alle anderen gelöscht.
Anschliessend haben wir alle illegitimen Benutzerkonten entfernt, die jetzt wieder ganz normal in der Benutzerverwaltung angezeigt wurden. Um allfällige bereits eingeloggte Hacker auszusperren, haben wir zudem die WordPress Keys/Salts in wp-config.php neu generiert. Dann haben wir das Passwort unserer Kundin neu gesetzt und Plug-ins für die 2-Faktor-Authentifzierung (Two Factor) sowie für die Beschränkung der Anmeldeversuche (WP Cerber) installiert.
Um ganz sicher zu gehen, führten auch noch einen Integritätstest mit WP Cerber durch. Dabei wird der Quellcode von WordPress Core, Themes und Plug-ins mit der Originalversion verglichen, um Manipulationen aufzuspüren. Alle Dateien mit Abweichungen werden aufgelistet, und man kann sie per Mausklick in die Quarantäne verschieben, wo sie keinen Schaden mehr anrichten können. In unserem Fall hat sich diese Massnahme gelohnt: In den Verzeichnissen /wp-includes/, /wp-admin/ und /wp-content/uploads/ wurden nochmals ein Dutzend PHP-Dateien gefunden, die da nicht hingehörten.
Als letzten Schritt behoben wir das Problem, das ursprünglich zur Aufdeckung des Hacker-Angriffs geführt hatte: Wir löschten die 150 Spam-Beiträge.
War es das? Leider nein. Kurz nachdem wir die Website bereinigt hatten, tauchte ein neuer Benutzer «root» mit Administratorrechten in der Benutzerverwaltung auf. Wir wandten uns deshalb der WordPress-Datenbank zu, die ebenfalls Schadcode enthalten kann, allerdings deutlich schwerer zu überprüfen ist als das Dateisystem. Wir machten einen weiteren Scan mit dem Plug-in Anti-Malware Security and Brute-Force Firewall, und dieses meldete uns eine Database Injection auf einer einzelnen Seite, die wir bisher übersehen hatten.
Ob wir damit am Ziel sind? Die Zukunft wird es zeigen…
Warum die Hacker erfolgreich waren
Natürlich haben wir uns gefragt, wie die Hacker überhaupt in die Website eingedrungen waren. Zweifelsfrei nachweisen konnten wir es nicht, aber es gibt drei naheliegende Erklärungen.
- Erstens nutzte unsere Kundin ein höchst unsicheres Passwort, das so ziemlich alle Empfehlungen für sichere Passwörter missachtete. Bei Bedarf teilte sie ihre Anmeldedaten zudem per E-Mail mit anderen Personen.
- Zweitens war das WordPress-Login nicht ausreichend gegen Brute-Force-Angriffe abgesichert: Zwar gab es einen CAPTCHA, aber die Website erlaubte beliebig viele Anmeldeversuche. Dass dies nicht standardmässig unterbunden wird, haben wir schon früher als das Sicherheitsrisiko Nr. 1 von WordPress bezeichnet.
- Drittens stammten die rund 20 Themes aus verschiedensten Quellen und waren zudem schon länger nicht mehr aktualisiert worden. Es ist gut möglich, dass eines dieser Themes eine Sicherheitslücke oder gar eine bewusst eingebaute Backdoor aufwies und es den Hackern so erlaubte, auch ohne Login auf die Website zuzugreifen.
Uns hat ferner interessiert, wann der Hack begonnen hatte. Auf der Website war leider kein Plug-in installiert, das alle Vorgänge protokolliert wie beispielsweise Simple History. Damit hätte man leicht nachvollziehen können, wann Benutzerkonten angelegt und Plug-ins installiert wurden. Die Publikationsdaten der gelöschten Spam-Beiträge verteilten sich auf mehrere Jahre. Doch weil man dieses Datum beliebig setzen und somit Beiträge rückdatieren kann, wollten wir uns nicht allein darauf verlassen. Deshalb haben wir uns in der WordPress-Datenbank die Tabelle wp_posts angeschaut und dort das Feld post_modified der Spam-Beiträge analysiert. Dabei hat sich bestätigt, dass die Hacker offenbar seit Jahren Zugang zur Website hatten und immer wieder einzelne Beiträge publizierten.
Warum wurde der Hack nicht früher entdeckt? Zum einen, weil es sich um eine einfache Website einer Kulturschaffenden handelte, an der nur selten gearbeitet wurde und bei der man auch nicht annehmen würde, dass sie Ziel eines Hacker-Angriffs werden könnte. Zum andern, weil es auf dieser Website weder einen Blog noch eine News-Sektion gab: Unsere Kundin nutzte deshalb ausschliesslich Seiten und hatte gar keinen Anlass, einen Blick in die Beiträge zu werfen. Und im Frontend waren die Spam-Beiträge nicht direkt sichtbar.