Gehackte Website erkennen: Die Spuren eines stillen Angriffs

Worum es geht

Eine gehackte Website hat kein Interesse daran, aufzufallen. Wer einen fremden Server übernommen hat, will ihn nutzen: für Spam-Seiten, die Suchmaschinen füttern, für Weiterleitungen auf dubiose Shops, für den Versand von Phishing-Mails oder als Sprungbrett für den nächsten Angriff. All das funktioniert umso länger, je weniger der Betreiber merkt. Die Startseite bleibt deshalb meist, wie sie war. Das Logo sitzt, das Kontaktformular funktioniert, der Redakteur pflegt seine Termine ein.

Wie lange Angriffe auf Unternehmensnetze unentdeckt bleiben können, untersucht Mandiant seit Jahren. In den Ermittlungen des Jahres 2025 vergingen zwischen Einbruch und Entdeckung im Median 14 Tage, bei Spionage-Kampagnen waren es 122 (1). In 14 Prozent der Fälle erfuhren die Betroffenen vom Angriff erst durch die Angreifer selbst, meist in Form einer Lösegeldforderung. Besonders dringlich wird die Frage nach unbemerkten Zugriffen durch die jüngst bekannt gewordenen PHP2Shell-Lücken: Wer eine verwundbare PHP-Version öffentlich erreichbar betrieben hat, sollte neben dem Update auch prüfen, ob jemand die Gelegenheit genutzt hat. Ein Update schließt die Tür, es wirft niemanden hinaus, der schon drin ist.

Oft weiß Google früher Bescheid als der Betreiber. Die Search Console führt einen eigenen Bericht namens „Sicherheitsprobleme“, in dem Google gehackte Inhalte, Malware und Phishing-Seiten meldet, jeweils mit Beispiel-URLs (2). Wer seine Website dort noch nicht registriert hat, sollte das nachholen, denn die Warnung kommt sonst erst über die Suchergebnisse, wo Besucher den Hinweis lesen, die Seite sei möglicherweise gehackt. Ein schneller Selbsttest ist die Google-Suche nach site:ihredomain.de in Kombination mit typischen Spam-Begriffen aus Pharma, Glücksspiel oder Markenware. Tauchen dabei Seiten auf, die nie jemand angelegt hat, ist das ein ernstes Warnsignal.

Dass der Betreiber selbst nichts sieht, hat einen Namen: Cloaking. Die manipulierte Website zeigt Suchmaschinen andere Inhalte als Menschen, oder sie leitet nur Besucher um, die über Google kommen, mit dem Smartphone surfen oder nicht angemeldet sind (3). Wer als eingeloggter Administrator vom Büro-PC aus die Startseite aufruft, bekommt die Manipulation unter Umständen gar nicht zu sehen. Aufschlussreicher ist es, die eigene Seite über die Google-Suche auf dem Smartphone anzusteuern, im privaten Modus und ohne WLAN, oder das URL-Prüftool der Search Console zu nutzen, das die Seite so zeigt, wie Google sie sieht.

Angreifer, die Code ausführen können, hinterlassen häufig Spuren im Dateisystem. Ein Klassiker sind PHP-Skripte im Upload-Verzeichnis, wo eigentlich nur Bilder und PDFs liegen sollten; in WordPress wäre das wp-content/uploads. Ebenso verdächtig sind Dateien mit kryptischen oder fast richtigen Namen, die einer echten Systemdatei bis auf einen Buchstaben gleichen, und Code, der mit Funktionen wie eval oder langen Base64-Zeichenketten arbeitet, um seinen Zweck zu verschleiern. Auch eine veränderte .htaccess gehört auf die Liste, denn dort lassen sich Weiterleitungen einrichten, ohne eine einzige PHP-Datei anzufassen.

Verlässlicher als das Suchen nach Auffälligem ist der Abgleich mit dem Original, solange man seine Grenzen kennt. Der WP-CLI-Befehl wp core verify-checksums vergleicht die Kerndateien von WordPress mit den offiziellen Prüfsummen, für Plugins aus dem offiziellen Verzeichnis gibt es ein Gegenstück; Themes, Uploads und eigener Code bleiben dabei außen vor. Wer über Git ausrollt, erkennt Abweichungen im versionierten Code, nicht aber in Dateien, die von der Versionierung ausgenommen sind. Ein auffälliges Änderungsdatum kann ein Ansatzpunkt sein; ein unauffälliges gibt keine Entwarnung, denn Zeitstempel lassen sich mit wenig Aufwand fälschen.

Auch die Datenbank gehört zur Prüfung. Eingeschleuste Links, versteckte Skripte oder ganze Spam-Seiten können in gespeicherten Inhalten, Widgets oder Einstellungen liegen, ohne dass sich eine einzige Programmdatei verändert hat. Ein unauffälliger Dateiabgleich reicht deshalb nicht für eine Entwarnung.

Neben Dateien hinterlassen Angreifer gern einen zweiten Weg zurück. Dazu gehören zusätzliche Administrator-Konten, oft mit unverdächtigen Namen, oder bestehende Konten, deren E-Mail-Adresse sich still geändert hat. Auf Serverebene lohnt ein Blick auf geplante Aufgaben, also Cronjobs, die regelmäßig Schadcode nachladen, und auf hinterlegte SSH-Schlüssel, über die sich jemand ohne Passwort anmelden kann. Ein weiteres Indiz kommt oft von außen: Wenn der Hoster sich wegen ungewöhnlichen Mailversands meldet oder eigene Mails plötzlich im Spam landen, steht die Domain womöglich bereits auf einer Sperrliste.

Eine wichtige Quelle sind die Logdateien des Webservers, auch wenn sie unvollständig sein oder von Angreifern bereinigt werden können. Sie zeigen Anfragen an Dateien, die es nicht geben sollte, POST-Anfragen an Skripte im Upload-Ordner oder erfolgreiche Anmeldungen an Administrationszugängen zu ungewohnten Zeiten und von unbekannten Adressen.

Für PHP2Shell nennt Wiz Research konkrete Signale: ungewöhnliche Multipart-Anfragen, auf die Speicherlimit-Fehler oder gehäufte HTTP-500-Antworten folgen, auffällig große oder fehlerhafte PHPSESSID-Cookies in den Antworten des Servers und unerklärliche Abstürze oder Neustarts von PHP-Prozessen (4). Ob ein Versuch erfolgreich war, lässt sich daraus allein nicht ablesen, wohl aber, ob es sich lohnt, genauer hinzusehen.

Allen diesen Spuren ist gemein, dass sie sich erst zeigen, wenn jemand nach ihnen sucht. Ein Monitoring kann die Zeit bis zur Entdeckung verkürzen, wenn es neben Erreichbarkeit und Serverlast auch sicherheitsrelevante Veränderungen erfasst, etwa neue Administratorkonten oder unerwartete Änderungen an Systemdateien; ein Agent direkt auf dem Server sieht dabei mehr als jede Prüfung von außen. Ob aus einer Meldung rechtzeitig eine Reaktion wird, hängt allerdings davon ab, wer sie liest.

Bei PHP2Shell ist eine weitere Möglichkeit besonders wichtig: Über die Lücken lässt sich auch Arbeitsspeicher von PHP-Prozessen auslesen, ohne dass Schadcode ausgeführt oder eine Datei verändert wird. Darin können laut Wiz Passwörter, Tokens, API-Schlüssel und Zertifikate liegen, auch solche aus fremden Anfragen oder des Servers selbst. Eine Website kann also sauber aussehen und trotzdem Zugangsdaten verloren haben.

Zur Prüfung gehört deshalb die Frage, welche Zugangsdaten die Anwendung überhaupt erreichen konnte, typischerweise Datenbankzugänge, Schlüssel externer Dienste und Sitzungen angemeldeter Nutzer. Bei einer bestätigten Kompromittierung müssen potenziell offengelegte Passwörter und Schlüssel erneuert und Sitzungen widerrufen werden, in WordPress etwa über neue Sicherheitsschlüssel in der wp-config.php. Lässt sich ein Zugriff nicht zuverlässig ausschließen, ist dieser Schritt auch vorsorglich sinnvoll. Wichtig ist die Reihenfolge: Neue Zugangsdaten auf einem System, das noch kompromittiert ist, sind schnell wieder in fremden Händen; WordPress empfiehlt deshalb, Passwörter nach der Bereinigung ein zweites Mal zu ändern.

Der erste Impuls ist meist, aufzuräumen: verdächtige Dateien löschen, das Backup von gestern einspielen, weitermachen. Beides ist zu früh. Gelöschte Dateien sind verlorene Hinweise auf den Angriffsweg, und ein Backup hilft nur, wenn es aus der Zeit vor dem Einbruch stammt und die Lücke danach geschlossen wird. Sinnvoller ist es, den Zustand zu sichern, die Seite bei Bedarf vom Netz zu nehmen und dann systematisch vorzugehen, wie es auch bei der Bereinigung gehackter Websites üblich ist.

Parallel dazu läuft eine zweite Frist. Waren personenbezogene Daten betroffen, muss der Verantwortliche die Verletzung unverzüglich und möglichst binnen 72 Stunden der Aufsichtsbehörde melden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen (5). Die Frist wartet nicht auf den Abschluss der technischen Untersuchung, Informationen dürfen schrittweise nachgereicht werden. Bleibt die Prüfung dagegen ohne Befund, ist das ein gutes Zeichen, aber keine Garantie: Die Abwesenheit von Spuren beweist nur, dass keine gefunden wurden.

Wer nur die Startseite betrachtet, sieht, was der Angreifer zeigen will.