Dreimal bereinigt, dreimal zurück: ein Hack aus unserer Praxis

Eine Website kommt nach der Bereinigung zurück, weil aufgeräumt wurde, was gemeldet war, und nicht, was da war. In dem Fall, den wir im August 2026 übernommen haben, meldete der Hoster 278 Schaddateien. Tatsächlich lagen 5.706 davon im Webbereich, verteilt auf 1.268 Verzeichnisse, dazu eine zweite Hintertür, die kein Dateiscanner finden konnte. Dreimal war vorher bereinigt worden, dreimal kam die Seite zurück.

Der Kunde bleibt anonym, die Zahlen sind echt. Was wir daraus gelernt haben, ist übertragbar, egal ob deine Seite auf WordPress, Joomla oder etwas anderem läuft. Die allgemeine Anleitung für den Ernstfall steht im Beitrag WordPress gehackt: was jetzt zu tun ist. Hier geht es um den Grund, warum der erste und der zweite Versuch scheitern.

Was war passiert?

Eine Vereinswebsite auf Joomla, bei einem großen Massenhoster, gewachsen über Jahre. Daneben lag auf derselben Domain ein Newsletter-Werkzeug auf einer eigenen Subdomain und ein alter, abgeschalteter Seitenbaum von 2020, der nie gelöscht wurde. Insgesamt rund 19.000 Dateien.

Der Angreifer war über eine veraltete Erweiterung hereingekommen. Danach hatte er zwei völlig getrennte Werkzeuge hinterlassen: einen lauten Baukasten, der Schadcode überall verteilte, und eine leise Hintertür, die Geld verdiente. Wer nur eines der beiden findet, hat nichts gewonnen.

Warum hat der Hoster nur 278 Dateien gefunden?

Weil der Baukasten genau darauf ausgelegt ist, nicht gefunden zu werden. Er legt in jedem befallenen Verzeichnis dasselbe Dreigespann an:

• eine .htaccess mit 226 Byte,
• eine index.php mit rund 430 Byte,
• eine cache.php mit rund 380 Byte,
• dazu eine ZIP-Datei mit einem Namen, der nach Mediendatei aussieht.

Der eigentliche Schadcode steht nicht in den PHP-Dateien. Er steht in der ZIP-Datei und wird von dort geladen. Ein Signaturscanner sucht in PHP-Dateien nach bekannten Mustern und findet in diesen drei Dateien nichts Auffälliges. Das Archiv daneben sieht aus wie ein Medienarchiv.

Das zweite Tarnmerkmal: Die Verzeichnisse heißen immer wie ihr übergeordnetes Verzeichnis. So entstehen Pfade wie services/services oder de-DE/de-DE/de-DE, die in einer langen Dateiliste nicht auffallen.

Gefunden haben wir sie über die Dateigröße. Die Sperrdateien des Hosters waren alle exakt 127 Byte groß. Jede .htaccess mit einer anderen Größe stammte vom Angreifer. Das ist die zuverlässigste Marke, die wir kennen: nicht der Inhalt, die Größe.

Warum half die Sperre des Hosters nicht?

Das ist der Teil, der uns am meisten überrascht hat. Der Hoster hatte eine Sperrdatei ausgerollt, die den Zugriff auf die befallenen Verzeichnisse verbietet. Der Angreifer hatte sie kopiert, in sein eigenes Verzeichnis gelegt und unten zwei Zeilen angehängt: Zugriff erlaubt für genau index.php und cache.php.

Die Sperre stand also da und sah richtig aus. Sie ließ nur die beiden Dateien durch, auf die es ankam.

Daraus folgt der wichtigste Handgriff bei einem Wiederholungsfall: Eindämmen vor Aufräumen. Wir haben zuerst die Angreifer-Sperrdateien entfernt und die zentrale Sperrdatei ersetzt. Ab diesem Moment antworteten alle Shells mit „403 Zugriff verweigert“, ohne dass eine einzige Datei gelöscht war. Nachprüfbar, weil diese Shells auf einen bestimmten Aufruf mit einer festen Kennung antworten. Erst danach haben wir aufgeräumt.

Die zweite Hintertür, die kein Scanner findet

Neben dem Baukasten lag eine Erweiterung mit unauffälligem Namen, ordentlich in der Datenbank registriert, dort wo Erweiterungen nun einmal liegen. Ihr Code war sauber und gut lesbar: keine Verschleierung, kein eval, keine seltsame Dateigröße.

Sie hängte sich an die Ausgabe der Seite und schrieb bei jedem Aufruf 144 unsichtbare Verweise auf Glücksspielseiten in den Quelltext, geholt von einem fremden Server. Für die Besucher unsichtbar, für Suchmaschinen nicht.

Gefunden haben wir sie nicht im Dateisystem, sondern in der Erweiterungstabelle der Datenbank. Zwei Signale waren eindeutig:

1. Dieselbe Erweiterung war zweimal registriert. Das erzeugt kein Installationsprogramm, das entsteht nur, wenn jemand die Zeile von Hand einfügt.
2. Im Aktionsprotokoll stand für den Zeitraum nichts. Jede Installation über die Oberfläche wird protokolliert. Fehlt der Eintrag, kam die Erweiterung direkt über Dateisystem und Datenbank herein. Das datiert zugleich den ersten Einbruch.

Die Lehre daraus gilt für jedes System. Nach der Bereinigung reicht es nicht, die Dateien mit dem Originalpaket zu vergleichen. Auch die Liste der installierten Erweiterungen gehört geprüft, gegen die Liste derer, die jemand bewusst installiert hat.

Warum half kein Backup?

Weil keines sauber war. Der Hoster hielt drei Wochen vor, die ältesten Schaddateien waren deutlich älter. Von den drei eigenen Sicherungsarchiven auf dem Server war nur eines frei von Schadcode, und das war über ein Jahr alt.

Das ist der Punkt, an dem die meisten Bereinigungen kippen. Eine Sicherung ist nur dann sauber, wenn sie vor der ältesten Hintertür liegt, nicht vor dem letzten sichtbaren Vorfall. Und wann die älteste Hintertür entstand, weiß man erst, wenn man sie gefunden hat.

Das BSI schreibt in seiner Handreichung Erste Hilfe bei Webseiten-Kompromittierung denselben Satz in der Sprache der Behörde: Man solle den kompletten Webspace löschen und „Ihr aktuellstes Backup vor Auftreten der Manipulation“ einspielen. Der entscheidende Halbsatz ist „vor Auftreten der Manipulation“, und der setzt voraus, dass man diesen Zeitpunkt kennt. Zwei Sätze weiter steht die Regel, an der es bei uns fast immer scheitert: Backups müssen „regelmäßig auf ihre Nutzbarkeit hin überprüft werden“.

Praktisch heißt das: Ein Backup, das du nie zurückgespielt und nie geprüft hast, ist eine Hoffnung, kein Plan. Wie oft so etwas unbemerkt bleibt, haben wir an 46 Websites gemessen: Was passiert mit einer Website ohne Wartung?

Und dann war da noch die dritte Shell

18 Tage nach der Bereinigung fanden wir bei einer Nachkontrolle eine weitere Datei in einem Bilderordner, zurückdatiert auf März. Sie hatte unseren Scan über 18.819 Dateien überlebt, und in ihrem eigenen Quelltext stand auch warum: Die Funktionsnamen waren Zeichen für Zeichen zusammengesetzt, ausdrücklich, um Signaturscanner zu umgehen.

Schaden hat sie keinen angerichtet. Sie war nie aufrufbar, weil eine Regel die Ausführung von PHP in Bilderordnern grundsätzlich verbietet. Über HTTP kam durchgängig „403“ zurück.

Das ist die eigentliche Lehre dieses Falls: Mustersuche und Ausführungssperre fangen verschiedene Dinge. Die Suche findet, was sie kennt. Die Sperre fängt, was sie nicht kennt. Wer nur eines von beidem macht, verlässt sich auf Glück.

Was am Ende gemacht wurde

• 5.706 Schaddateien entfernt, darunter 18 Webshells und die getarnte Erweiterung.
• Alle 9.839 Dateien des Systemkerns gegen das Originalpaket geprüft, Ergebnis: identisch.
• 2,4 GB Altbestand aus dem Webbereich ausgelagert, darunter der abgeschaltete Seitenbaum von 2020. Das sind 1.664 PHP-Dateien weniger, die überhaupt angreifbar sein können. Das BSI nennt diesen Schritt in derselben Handreichung ausdrücklich: „Deinstallieren Sie nicht benötigte Software, Plugins bzw. Erweiterungen.“
• Dateirechte von 777 und 666 auf 755 und 644 gesetzt.
• Alle Zugänge gewechselt, Ablageordner für die Ausführung von PHP gesperrt.
• Zwei Abschlussprüfungen, zwölf Einzelkontrollen, kein Befund.

Die Seite läuft seitdem. Der Kunde hat danach einen Wartungsvertrag abgeschlossen, und das ist ehrlich gesagt der einzige Teil, der den nächsten Fall verhindert: Updates, die eingespielt werden, bevor eine Lücke öffentlich ausgenutzt wird. Woran man vorher erkennt, ob eine Erweiterung gepflegt wird, steht hier: Plugins prüfen, bevor du sie installierst.

Die vier Gründe, warum ein Hack zurückkommt

Wenn du nur vier Sätze mitnimmst, dann diese:

1. Es wurde die Meldung abgearbeitet, nicht der Server. Die Liste des Hosters ist ein Anfang, nie das Ergebnis.
2. Es wurde nur im Dateisystem gesucht. Die zweite Hintertür steckt oft in der Datenbank.
3. Das Backup war schon befallen. Sauber ist nur, was vor der ältesten Hintertür liegt.
4. Die Lücke blieb offen. Ohne Update, ohne Ausführungssperre, ohne neue Zugangsdaten ist die Seite nach der Bereinigung genauso verwundbar wie vorher.

Wenn deine Seite schon einmal bereinigt wurde und trotzdem wieder auffällig ist, dann ist das kein Zufall und auch kein Pech. Dann ist noch etwas da. Unsere Wartung beginnt bei 39 € netto im Monat, eine Bereinigung nennen wir nach einem Blick auf die Seite, am selben Werktag.