Die Website wurde gehackt, was jetzt?
Die Ausgangslage
Donnerstag, 14:20 Uhr, Anruf eines Geschäftsführers: „Unser Zahlungsdienstleister hat uns gemeldet, dass auf unserer Checkout-Seite ein fremdes JavaScript ausgeliefert wird. Können Sie das anschauen?" Der Shop läuft auf einer betagten PHP-Anwendung mit MySQL, Apache, rund 8.000 Bestellungen pro Monat. Ein klassischer Mid-Size-Onlineshop, gewartet von einer Agentur, die seit einem halben Jahr nicht mehr antwortet.
Bei der Erstanalyse fanden wir auf der Bestellabschluss-Seite ein 4 KB großes JavaScript, das Kreditkartendaten an eine Domain in Osteuropa ausleitete. Klassischer Magecart-Skimmer. Eingefügt war er als zusätzliche Zeile in einem Theme-Template. Der Zugriff erfolgte über eine veraltete Plugin-Installation mit bekannter Schwachstelle. Zugriffslogs zeigten POST-Requests auf wp-admin/admin-ajax.php mit Pattern, das zur CVE-Liste passte.
Der Angriff lief seit mindestens 19 Tagen. In diesem Zeitraum waren rund 4.700 Bestellungen verarbeitet worden. DSGVO-Meldepflicht: ja. Sofortmaßnahmen nötig: dringend.
Was wir gemacht haben
Stunde 0–2, Sofortmaßnahmen. Wartungsmodus eingeschaltet, Shop offline. Vollständiges Backup von Dateisystem und Datenbank in unveränderlicher Form gesichert (Cold Storage, schreibgeschützt). Forensik-Image gezogen. Alle Admin-Sessions invalidiert, alle Passwörter zurückgesetzt, API-Keys rotiert.
Stunde 2–8, Forensik und Eindämmung. Wir haben Access- und Error-Logs der letzten 90 Tage gesichtet und den Einfallsvektor identifiziert. Drei manipulierte Dateien gefunden: das Skimmer-Script, eine PHP-Webshell in /wp-content/uploads/2024/, und ein modifiziertes Theme-Functions-File mit Backdoor. Diff gegen sauberen Stand des CMS-Cores: zwei weitere modifizierte Core-Files.
Tag 1–2, Bereinigung. Statt das gehackte System zu „reinigen" haben wir neu aufgesetzt: frischer Server, frische CMS-Installation, frische Theme-Dateien aus dem Repository, Plugins nur in aktuellen Versionen. Datenbank wurde sauber kopiert, aber Admin-Accounts, Sessions, Tokens und Cron-Einträge wurden vorher manuell geprüft. Migration der Bestelldaten erst nach Freigabe.
Tag 2–3, Härtung. Web Application Firewall vorgeschaltet, fail2ban konfiguriert, Admin-Bereich auf IP-Whitelist gelegt, Zwei-Faktor-Authentifizierung erzwungen. Subresource-Integrity für alle externen Skripte. Content-Security-Policy auf strikt gestellt, getestet, ausgerollt. File-Integrity-Monitoring auf Theme- und Core-Verzeichnissen aktiviert.
Tag 3–4, Meldung und Kommunikation. Wir haben den Geschäftsführer bei der Meldung an die zuständige Aufsichtsbehörde unterstützt (Fristen, Inhalte, Belege), die Kommunikation an betroffene Kundinnen vorbereitet, den Zahlungsdienstleister informiert. Forensik-Bericht mit Zeitstempeln, Hashes und Maßnahmen wurde dokumentiert.
Das Ergebnis
Vier Tage offline, drei Tage davon mit transparent kommuniziertem „Sicherheitsupdate". Keine weiteren Vorfälle in den folgenden zwölf Monaten. Die Behörde akzeptierte die Meldung, ein Bußgeld blieb aus, weil Erstreaktion und Dokumentation sauber waren.
Der Shop hat heute monatliche Sicherheitsupdates, CVE-Monitoring, automatische Backups mit getestetem Restore, und eine Datei-Integritätsprüfung, die nächtlich läuft. Die Kosten der Bereinigung lagen bei rund 12.000 Euro. Der direkte Schaden des Angriffs allein durch Chargebacks und Vertrauensverlust dürfte ein Vielfaches gewesen sein.