Es gibt Momente im Leben eines IT-Forensikers, da fühlt man sich weniger wie ein Experte und mehr wie ein Tatortreiniger in einem digitalen Schlachthaus. Der Anruf, der diese Geschichte in Gang setzte, kam nicht vom Kunden selbst. Der befand sich zu diesem Zeitpunkt noch im Zustand glückseliger, beinahe beneidenswerter Unwissenheit. Stattdessen war es die betreuende Agentur, für die ich seit Jahren als technischer Ghostwriter die Kastanien aus dem Feuer hole, wenn es brennt. Die Nachricht vom Hosting-Anbieter Hostpoint war so kurz wie beunruhigend: „Euer Server verteilt Malware. Bereinigen, oder wir ziehen den Stecker.“
Als ich mich zum ersten Mal in das Backend einloggte, fühlte ich mich wie ein Archäologe, der eine Grabkammer öffnet, die seit der Erfindung des Feuers nicht mehr gelüftet wurde. Was ich sah, war kein modernes Redaktionssystem, sondern ein Abenteuerspielplatz für automatisierte Botnetze. Das Gehäuse der Website war morsch: Ein völlig veralteter WordPress-Core, umzingelt von zwölf Plugins, die ihre besten Tage in einer Ära hatten, als man Webdesign noch mit Tabellen-Layouts assoziierte. Absoluter Blindflug ohne Radar. Vier Administrator-Konten für eine Ein-Mann-Show, keine Sicherheits-Plugins, keine Search Console, nichts, was den Namen „Überwachung“ verdient hätte.
Der erste Tag: Die Entdeckung der Chamäleons
Ich begann meine Arbeit mit einer tiefen Analyse des Filesystems. Wenn ein Haus brennt, fängt man nicht an, die Fenster zu putzen, man sucht den Brandherd. Es dauerte nicht lange, bis ich auf das erste Nest stieß. Es war eine Datei, die sich optisch perfekt in die Umgebung einfügte, aber einen verheerenden Inhalt hatte. In ihrem Inneren fand ich Code-Fragmente, die sich wie ein hämisches Grinsen lasen. Ein klassisches PHP-Skript, das durch Verschleierungstechniken wie goto-Sprünge und hexadezimale Kodierung versuchte, jeden Virenscanner ins Leere laufen zu lassen.
Besonders perfide war eine Datei, die sich als „404 Not Found“-Seite ausgab. Ein Meilenstein der digitalen Mimikry. Für jeden normalen Besucher und sogar für einfache Bots sah sie aus wie ein toter Link. Doch für jemanden, der das Passwort kannte, war sie ein voll ausgestattetes Cockpit. In den PHP-Eingeweiden dieser Datei war eine Abfrage versteckt, die auf den HTTP-Header X-Requested-With: XMLHttpRequest reagierte. Das war die Einladung zum Tanz. Wer diese Hürde nahm, dem offenbarte sich ein Hacker-Interface, mit dem man Dateien hochladen, Datenbanken auslesen und sogar Systemrechte manipulieren konnte. Ich änderte sofort alle Passwörter, erzwang die Zwei-Faktor-Authentifizierung (2FA) und löschte die verdächtigen Administrator-Konten. Am Abend des ersten Tages fühlte ich mich sicher. Ich dachte, die Schotten seien dicht.
Die Mitternachts-Gänsehaut: Wenn die Medusa erwacht
Punkt Mitternacht, genau um 00:01 Uhr, passierte das Unmögliche. Mein frisch installiertes Monitoring-System schlug Alarm. Ein Benutzer namens medusa hatte sich erfolgreich angemeldet. Während ich fassungslos auf den Bildschirm starrte, begann dieser Account seelenruhig damit, neue Plugins zu installieren. Die Verzweiflung stieg in mir auf: Ich hatte doch die User gelöscht! Ich hatte die Passwörter geändert! Woher kam dieses digitale Gespenst?
Ich loggte mich per SSH auf den Server ein. Es war Zeit für die schweren Geschütze. Ich brauchte die Prozessliste, um zu verstehen, was hier im Verborgenen geschah. Und da sah ich ihn, den unsichtbaren Wachhund. Ein PHP-Prozess mit der ID 90208, der im Status nanslp verharrte. Der Prozess nutzte eine Technik, die man „Persistence through RAM“ nennt. Durch die Funktion ignore_user_abort(true) hatte sich das Skript vom Dateisystem entkoppelt. Es lebte im Arbeitsspeicher des Servers weiter, völlig losgelöst davon, ob die physische Datei auf der Festplatte noch existierte.
In einer endlosen Schleife prüfte dieser Prozess jede Millisekunde, ob seine Dateien noch da waren. Sobald ich die Backdoor auf der Festplatte löschte, schrieb der Prozess im RAM sie einfach wieder zurück. Er war wie ein Zombie, der sich weigert zu sterben, solange man nicht das Gehirn, in diesem Fall den Prozess im Arbeitsspeicher zerstört. Der Code dahinter war so simpel wie bösartig: Eine Kombination aus usleep und file_put_contents, die das System in Geiselhaft nahm. Erst die „heilige Schrotflinte“ in Form des Befehls pkill -u [User] -9 php brachte die ersehnte Stille. Ich feuerte die Breitseite ab, terminierte alle laufenden Prozesse des Nutzers und erst dann blieben die Dateien gelöscht.
Der japanische SEO-Schock: Handtaschen statt Dienstleistungen
Doch der wahre Horror offenbarte sich erst am nächsten Morgen. Wir hatten zwar die Kontrolle über den Server zurückerlangt, aber die Hacker hatten bereits geerntet. Ich warf einen Blick in die Google-Suchergebnisse und was ich sah, war das digitale Äquivalent zu einem vandalisierten Firmengebäude. Überall prangten japanische Schriftzeichen. Wir waren Opfer einer Neuauflage des berüchtigten Japan SEO Hacks geworden. Die Hacker hatten unsere Domain genutzt, um hunderte Unterseiten für Designer-Handtaschen und dubiose Pillen in den Index zu drücken.
Glücklicherweise hatten wir am Vortag so gründlich aufgeräumt, dass jeder dieser Links bereits ins Leere lief. Die Inhalte waren weg, aber die Narben in den SERPs (Search Engine Result Pages) waren tief. Hier kam der bittere Moment der Wahrheit: Der Kunde, der vor einem Jahr das Sicherheitsabo mit den Worten „Brauchen wir nicht“ abgelehnt hatte, sah nun sein eigenes Logo neben japanischen Reklamen für Luxus-Imitate. In diesem Moment wurde aus dem „Brauchen wir nicht“ ein verzweifeltes „Können Sie das bitte sofort abstellen?“. Es ist erstaunlich, wie schnell das Budget für Sicherheit wächst, wenn die eigene Reputation bei Google gerade öffentlich hingerichtet wird.
Tag 3: Der Klopfgeist und das Erbe der Nachlässigkeit
Am dritten Tag, wieder pünktlich um Mitternacht, registrierten die Logfiles erneut Angriffsversuche. Doch diesmal bissen sich die Angreifer die Zähne an der 2FA aus. Das Backend war sauber, die Zombie-Prozesse waren tot, aber es wurde trotzdem „geklopft“. Das deutete darauf hin, dass die Infektion tiefer saß, als wir anfangs vermuteten. Wir fanden Spuren des XMAN_Replicators, eines Wurms, der darauf programmiert war, sich horizontal über das gesamte Hosting-Paket auf andere Domains zu kopieren. Jedes Verzeichnis war mit manipulierten .htaccess-Dateien gespickt, die wie Stolperdrähte funktionierten. Sie enthielten Anweisungen wie
Wir mussten radikal werden. Wir stellten den gesamten Zugang von FTP auf rein schlüsselbasiertes SFTP um, deaktivierten unsichere PHP-Funktionen und ließen den Hoster einen Full-Scan auf binärer Ebene durchführen. Das Fazit dieser Woche ist so alt wie die IT selbst: Wer bei der Wartung spart, zahlt am Ende den Exorzisten. Der Kunde ist nun in der permanenten Überwachung und hat das Sicherheitsabo schneller unterschrieben, als ich „Backup“ sagen konnte. Ein harter Weg, um zu lernen, dass ein Server kein statisches Objekt ist, sondern ein lebendiger Organismus, der Schutz braucht. Wer die Tür offen lässt, darf sich nicht wundern, wenn am nächsten Morgen japanische Handtaschenverkäufer im Wohnzimmer sitzen.
Status: Das System ist unter Quarantäne und stabil. Der Hacker-Wachhund ist arbeitslos. Die Japaner ziehen langsam aus dem Index aus.
Lektion: Vertraue niemals einem Prozess, den du nicht selbst gekillt hast und spare niemals an der Haustür, wenn dein gesamtes Geschäft dahinter liegt.