Website gehackt — die ersten Schritte in den nächsten 60 Minuten

Anzeichen erkennen, bevor der Schaden wächst

Nicht jeder Hack ist auf den ersten Blick sichtbar — manche Angriffe laufen monatelang unbemerkt im Hintergrund. Typische Warnzeichen: unbekannte Inhalte wie Spam-Links, fremde Texte oder Werbung in einer anderen Sprache; Weiterleitungen auf fremde Domains, die oft nur für mobile Nutzer oder bestimmte Suchmaschinen-Referrer aktiv sind; Warnmeldungen im Browser oder in der Google Search Console mit dem Hinweis, die Website sei möglicherweise gehackt.

Weitere Symptome sind ein nicht mehr zugänglicher Admin-Bereich, weil das Passwort geändert oder ein fremder Admin-Account angelegt wurde, unbekannte Dateien im Hosting-Verzeichnis — besonders in Upload-Ordnern — sowie ungewöhnliche Server-Auslastung, die auf einen Missbrauch als Spam-Relay oder Teil eines Botnetzes hindeuten kann. Im Zweifel gilt: lieber einen Hack zu früh vermuten und ausschließen, als ihn zu spät erkennen.

Was man in den ersten Minuten nicht tun sollte

Nicht sofort alles löschen: Wer in Panik alle Dateien entfernt, vernichtet wichtige Beweise und macht eine saubere Ursachenanalyse unmöglich. Kein Handeln ohne Backup: Niemals Bereinigungsversuche starten, ohne vorher den aktuellen — auch kompromittierten — Zustand zu sichern. Und nicht einfach ignorieren: Wer den Hack totschweigt und die Website weiterlaufen lässt, gefährdet Besucher und riskiert eine Google-Blacklist sowie DSGVO-Konsequenzen.

Die Sofortmaßnahmen in den ersten 60 Minuten

1. Website sofort offline nehmen — Wartungsmodus oder Webserver stoppen, damit sich Schadcode nicht weiter ausbreitet und keine Besucher mehr betroffen sind. 2. Hosting-Provider informieren — viele Provider haben Incident-Response-Teams, die Zugangsprotokolle bereitstellen und infizierte Dateien identifizieren können. Access- und Error-Logs sofort sichern, sie werden oft nur kurz aufbewahrt. 3. Alle Passwörter sofort ändern — FTP, SSH, Datenbank, CMS-Admin und verknüpfte E-Mail-Konten. Zwei-Faktor-Authentifizierung aktivieren, wo möglich, alle aktiven CMS-Sessions beenden. 4. Den kompromittierten Zustand als Backup sichern — Dateien per FTP, Datenbank per Dump. Dieses Backup dient nicht der Wiederherstellung, sondern der forensischen Analyse. 5. Schadcode lokalisieren — geänderte Dateien der letzten Tage identifizieren, nach Mustern wie `eval(base64_decode())` oder unbekannten PHP-Dateien in Upload-Verzeichnissen suchen, Server-Logs auf verdächtige Anfragen prüfen. 6. Bereinigung durchführen — saubere Dateien aus einem unbelasteten Backup einspielen, CMS und Plugins aktualisieren, injizierten Code in der Datenbank entfernen und danach erneut vollständig scannen, da Angreifer oft mehrere Backdoors hinterlassen. 7. Ursache klären und schließen — der wichtigste und am häufigsten übersprungene Schritt. Veraltetes Plugin, schwaches Passwort, kompromittierter FTP-Zugang oder eine SQL-Injection-Lücke? Ohne diese Analyse wird dieselbe Lücke oft innerhalb weniger Tage erneut ausgenutzt. 8. DSGVO-Meldepflicht prüfen — waren personenbezogene Daten betroffen oder könnten betroffen gewesen sein, besteht nach Art. 33 DSGVO in der Regel eine Meldepflicht gegenüber der Aufsichtsbehörde innerhalb von 72 Stunden nach Kenntnisnahme.

Sofortzugang, den man in dieser Stunde braucht

• Hosting-Control-Panel (Plesk, cPanel oder vergleichbar) mit bereitliegenden Zugangsdaten
• FTP-Zugang für direkten Dateizugriff unabhängig vom CMS
• Datenbank-Zugriff, etwa phpMyAdmin, für Analyse und Bereinigung
• CMS-Adminbereich, falls noch zugänglich, um Sessions zu beenden und das Passwort zu ändern
• SSH-Zugang für serverseitige Analyse und Log-Auswertung, falls beim Provider verfügbar
• Zugang zum letzten sauberen Backup, lokal oder beim Provider

Wann ein Fachmann hinzugezogen werden sollte

Sofort, wenn die Datenbank betroffen ist, Kundendaten betroffen sein könnten, sich der Angriff wiederholt, die Ursache nicht eindeutig geklärt werden kann oder DSGVO-Meldepflichten im Raum stehen. Ein erfahrener Sicherheitsdienstleister bereinigt gründlicher und schließt Lücken, die im Eigenversuch leicht übersehen werden.

Wie man sich künftig schützt

Der beste Umgang mit einem Hack ist, ihn zu verhindern. CMS und alle installierten Erweiterungen gehören immer auf dem aktuellen Stand — veraltete Plugins sind der häufigste Einfallsweg. Zwei-Faktor-Authentifizierung sollte für alle Admin-Zugänge aktiv sein, für CMS, FTP und Hosting-Panel gleichermaßen, ergänzt um starke, einzigartige Passwörter aus einem Passwort-Manager. Tägliche automatisierte Backups an einem vom Webserver getrennten Ort sind Pflicht, damit im Ernstfall ein sauberer Stand vor dem Angriff verfügbar ist. Eine Web Application Firewall filtert gängige Angriffsmuster vor dem Server heraus, und File-Integrity-Monitoring schlägt Alarm, sobald kritische Dateien verändert werden.