Zum Inhalt springen
Proaktive Sicherheitsupdates
Wartung

Notfallplan: Was tun wenn die Website gehackt wurde

Notfallplan bei gehackter Website: Erkennung, Eindämmung, Forensik, Bereinigung, Härtung und Kommunikation -- Schritt für Schritt.

15 Min. Lesezeit NotfallGehacktIncident ResponseForensikPrävention

Eine gehackte Website ist der Albtraum jedes Shop-Betreibers -- und es passiert häufiger als viele denken. Im Jahr 2025 wurden 4,3 Millionen Websites durch Schwachstellen kompromittiert (Patchstack, 2025). Wenn es passiert, zählt jede Minute: Je schneller der Angriff erkannt und eingedämmt wird, desto geringer sind die Schäden. Dieser Notfallplan beschreibt den strukturierten Ablauf von der Erkennung über die Forensik bis zur vollständigen Bereinigung -- und zeigt, wie professionelle Prävention das Risiko minimiert.

Notfallplan: Website gehackt -- SofortmaßnahmenIncident Response: Erkennen - Eindämmen - Bereinigen - Härten1. ErkennungMonitoring-AlertMalware-ScanVerhaltensanalyseKundenmeldung2. EindämmungWebsite isolierenZugänge sperrenBeweise sichernWartungsseite aktiv3. ForensikEinfallstor findenSchadensumfangZeitlinie erstellenBackdoors suchen4. BereinigungSchadcode entfernenClean InstallPasswörter ändernDaten verifizieren5. Härtung nach VorfallSchwachstelle patchenWAF konfigurierenMonitoring verstärken2FA aktivieren6. KommunikationDSGVO-MeldepflichtKunden informierenIncident-ReportSearch ConsoleZeitkritische Maßnahmen (Goldene Stunde)0-60 Min: Eindämmung1-4 Std: Forensik4-24 Std: BereinigungErgebnis: Eindämmung in 60 Min | Forensik-Bericht | Vollständige Bereinigung | HärtungIncident Response | Malware-Entfernung | DSGVO-Meldung | Backup-Wiederherstellung | Post-Incident-Review

Angriff erkennen: Anzeichen einer Kompromittierung

Die Erkennung eines Hacks ist der kritischste Schritt -- je früher, desto besser. Professionelles Monitoring erkennt Kompromittierungen in Echtzeit. Ohne Monitoring bemerken Shop-Betreiber den Hack oft erst durch sekundäre Symptome: Google markiert die Website als unsicher ("Diese Website wurde möglicherweise gehackt"), Kunden melden verdächtige Weiterleitungen, die Suchmaschinenrankings brechen ein oder der Hosting-Provider sperrt den Account wegen Spam-Versand.

Typische Anzeichen einer Kompromittierung sind: unbekannte Dateien im Dateisystem (besonders PHP-Dateien im Upload-Verzeichnis), veränderte Core-Dateien (Checksummen stimmen nicht mehr), neue Administratorkonten, die niemand angelegt hat, verdächtige Datenbankeinträge (eingeschleuster JavaScript-Code in Seiteninhalt oder Metadaten), erhöhter ausgehender Traffic (Spam-Versand oder DDoS-Teilnahme) und Weiterleitungen auf externe Websites.

Laut einer Studie von IBM (2025) dauert es durchschnittlich 197 Tage, bis eine Kompromittierung erkannt wird -- und weitere 69 Tage bis zur Eindämmung. In dieser Zeit können Angreifer Kundendaten stehlen, Schadcode verbreiten und die Website für weitere Angriffe missbrauchen. Professionelles Security-Monitoring verkürzt die Erkennungszeit auf Minuten statt Monate.

Sofortige Eindämmung

Website isolieren, Zugänge sperren, Wartungsseite aktivieren. Innerhalb von 60 Minuten nach Erkennung abgeschlossen.

Forensische Analyse

Einfallstor identifizieren, Schadensumfang bestimmen, Zeitlinie rekonstruieren und versteckte Backdoors finden.

Vollständige Bereinigung

Schadcode entfernen, Clean Install der Software, alle Passwörter ändern und Datenintegrität verifizieren.

Post-Incident-Härtung

Schwachstelle patchen, WAF konfigurieren, Monitoring verstärken und Zugriffskontrollen verschärfen.

Kommunikation

DSGVO-Meldung, Kundeninformation, Search-Console-Bereinigung und Incident-Report für die Nachbereitung.

Post-Incident-Review

Lessons Learned dokumentieren, Prozesse anpassen und Präventionsmaßnahmen für die Zukunft implementieren.

Phase 1: Eindämmung in der goldenen Stunde

Sobald ein Hack erkannt wird, beginnt die goldene Stunde: die ersten 60 Minuten, in denen die Eindämmung oberste Priorität hat. Das Ziel ist nicht die Bereinigung (das kommt später), sondern die Begrenzung des Schadens. Die Website wird vom Netz genommen oder in einen Wartungsmodus versetzt, der keine dynamischen Inhalte mehr ausliefert. Alle Admin-Zugänge werden gesperrt, SSH-Schlüssel rotiert und Datenbankpasswörter geändert.

Gleichzeitig werden Beweise gesichert: ein vollständiges Image des kompromittierten Systems (Dateisystem und Datenbank) wird erstellt, bevor Änderungen vorgenommen werden. Serverlogs, Access-Logs und Error-Logs werden gesichert. Diese Beweise sind essenziell für die anschließende Forensik -- und möglicherweise für rechtliche Schritte. Ein vorschnelles Bereinigen ohne Beweissicherung macht es unmöglich, das Einfallstor zu identifizieren und die Schwachstelle zu schließen.

Die Eindämmung umfasst auch die Prüfung benachbarter Systeme: Wenn der kompromittierte Server weitere Websites hostet, könnten diese ebenfalls betroffen sein. Shared-Hosting-Umgebungen sind besonders anfällig für laterale Ausbreitung. Alle Systeme, die Netzwerkzugang zum kompromittierten Server haben, müssen geprüft werden.

Checkliste: Die ersten 60 Minuten nach Erkennung

  • Website in den Wartungsmodus versetzen oder vom Netz nehmen
  • Alle Admin-Passwörter sofort ändern (CMS, Datenbank, FTP, SSH)
  • SSH-Schlüssel rotieren und API-Tokens invalidieren
  • Vollständiges Image des kompromittierten Systems erstellen (Dateisystem + Datenbank)
  • Serverlogs, Access-Logs und Error-Logs der letzten 30 Tage sichern
  • Hosting-Provider über den Vorfall informieren
  • Prüfen, ob weitere Websites auf demselben Server betroffen sind
  • DSGVO-Verantwortlichen im Unternehmen benachrichtigen (72-Stunden-Frist beginnt)

Diese Sofortmaßnahmen müssen in den ersten 60 Minuten nach Erkennung abgeschlossen sein. Ein vorbereiteter Notfallplan mit dokumentierten Zugangsdaten und Ansprechpartnern reduziert die Reaktionszeit erheblich. Ohne Vorbereitung werden allein die Suche nach SSH-Zugangsdaten und Hosting-Provider-Kontaktdaten wertvolle Minuten kosten. Ein professioneller Notfall-Support stellt sicher, dass geschulte Techniker den Prozess sofort und strukturiert durchführen.

Phase 2: Forensische Analyse

Die forensische Analyse beantwortet drei Fragen: Wie ist der Angreifer eingedrungen? Wann hat die Kompromittierung begonnen? Und was hat der Angreifer getan? Die Analyse der Access-Logs, Dateiänderungszeitpunkte und Datenbankmanipulationen rekonstruiert eine Zeitlinie des Angriffs. Typische Einfallstore sind: ungepatchte Plugin-Schwachstellen, gestohlene Zugangsdaten, Brute-Force-Angriffe auf den Admin-Bereich und Datei-Upload-Schwachstellen.

Besonders wichtig ist die Suche nach Backdoors: Erfahrene Angreifer platzieren mehrere Hintertüren im System, um nach einer Bereinigung erneut zugreifen zu können. Typische Backdoor-Typen sind Web-Shells (PHP-Dateien, die Kommandoausführung ermöglichen), Cronjobs, die Schadcode nachladen, modifizierte Core-Dateien und versteckte Admin-Konten. Eine unvollständige Bereinigung, die eine einzige Backdoor übersieht, führt zur erneuten Kompromittierung -- oft innerhalb von Stunden.

Die Forensik bestimmt auch den Schadensumfang: Wurden Kundendaten zugegriffen oder exfiltriert? Wurde die Datenbank manipuliert (z.B. Zahlungsumleitungen eingeschleust)? Wurden Dateien verschlüsselt (Ransomware)? Wurde der Server für weitere Angriffe missbraucht (Spam-Versand, Cryptomining)? Der Schadensumfang bestimmt die notwendigen Kommunikationsmaßnahmen und eventuelle DSGVO-Meldepflichten.

Phase 3: Bereinigung und Wiederherstellung

Die Bereinigung erfolgt nicht durch selektives Entfernen von Schadcode, sondern idealerweise durch einen Clean Install: Neuinstallation der Software (WordPress, Shopware) aus vertrauenswürdigen Quellen, Neuinstallation aller Plugins in aktuellen Versionen und Wiederherstellung der Daten aus einem Backup, das vor der Kompromittierung erstellt wurde. Dieser Ansatz ist aufwendiger als eine selektive Bereinigung, stellt aber sicher, dass keine Backdoors übersehen werden.

Nach dem Clean Install werden alle Zugangsdaten geändert: Datenbank-Passwörter, Admin-Konten, FTP/SSH-Zugänge, API-Schlüssel und Authentication Keys/Salts. Alle bestehenden Sessions werden invalidiert, sodass eventuell aktive Angreifer-Sessions sofort enden. Zusätzlich wird Zwei-Faktor-Authentifizierung für alle Admin-Zugänge aktiviert, sofern noch nicht geschehen.

Die Wiederherstellung der Daten erfordert besondere Sorgfalt: Das Backup muss aus einem Zeitpunkt vor der Kompromittierung stammen. Da der Angriff möglicherweise Wochen vor der Entdeckung begann (IBM, 2025: durchschnittlich 197 Tage), reichen die Standard-Backups eventuell nicht aus. Die forensische Zeitlinie hilft, den frühesten sicheren Backup-Zeitpunkt zu bestimmen. Bestelldaten und Kundendaten zwischen Kompromittierung und Bereinigung müssen manuell geprüft und bei Bedarf aus dem kompromittierten System übernommen werden.

Phase 4: Härtung und Prävention

Nach der Bereinigung muss die Schwachstelle, die zum Einbruch geführt hat, geschlossen werden. Die forensische Analyse hat das Einfallstor identifiziert -- jetzt wird es gepatcht. Darüber hinaus werden zusätzliche Sicherheitsmaßnahmen implementiert: eine Web Application Firewall (WAF) mit Regeln gegen den spezifischen Angriffsvektor, verstärktes Monitoring mit Fokus auf die kompromittierten Bereiche und verschärfte Zugriffskontrollen.

Die Härtung umfasst auch die Überprüfung aller verbleibenden Plugins und Themes auf bekannte Schwachstellen, die Aktualisierung aller Komponenten auf die neueste Version und die Implementierung einer regelmäßigen Wartungsroutine, die sicherstellt, dass Sicherheitsupdates zeitnah eingespielt werden. Ein Hack, der auf einer ungepatchten Schwachstelle basiert, ist ein Symptom fehlender Wartung -- die Ursache muss langfristig adressiert werden.

Supply-Chain-Angriffe: Wenn vertrauenswürdige Quellen kompromittiert werden

Nicht jeder Hack beginnt mit einer Schwachstelle im eigenen System. Supply-Chain-Angriffe kompromittieren vertrauenswürdige Drittanbieter-Komponenten -- ein infiziertes Plugin-Update, ein manipuliertes CDN-Script oder eine kompromittierte Dependency in der Lieferkette. Diese Angriffe sind besonders gefährlich, weil sie die üblichen Sicherheitsmaßnahmen umgehen: Das Update kommt über den offiziellen Kanal, das Script von der vertrauten Domain. Die Erkennung erfordert zusätzliche Maßnahmen wie Subresource Integrity (SRI) für externe Scripts und Hash-Vergleiche bei Plugin-Updates.

Im Notfallplan muss das Szenario eines Supply-Chain-Angriffs separat behandelt werden. Die Sofortmaßnahme ist nicht die Bereinigung des eigenen Systems, sondern die Isolierung der kompromittierten Quelle: Externes Script deaktivieren, Plugin-Update rückgängig machen, CDN-Einbindung durch lokale Kopie ersetzen. Erst dann folgt die Analyse, ob der Schadcode bereits aktiv war und welche Daten betroffen sein könnten. Die professionelle Wartung überwacht Plugin-Quellen und CDN-Integrität kontinuierlich, um Supply-Chain-Angriffe frühzeitig zu erkennen.

Die Prävention von Supply-Chain-Angriffen beginnt bei der Auswahl der Abhängigkeiten: Jedes Plugin, jede externe Bibliothek und jedes eingebundene Script vergrößert die Angriffsfläche. Ein regelmäßiger Audit der externen Abhängigkeiten -- kombiniert mit dem Prinzip, nur das absolut Notwendige einzubinden -- reduziert das Risiko erheblich. Für kritische Online-Shops empfehlen sich zusätzlich Content Security Policies, die nur explizit freigegebene Quellen zulassen, und ein Monitoring, das Veränderungen an eingebundenen Ressourcen erkennt.

Post-Incident-Review: Aus dem Vorfall lernen

Nach der Bereinigung und Härtung steht der Post-Incident-Review an: Ein strukturiertes Meeting, in dem der gesamte Vorfall aufgearbeitet wird. Die Fragen lauten: Was war die Ursache? Wie lange dauerte die Erkennung? Wie lange dauerte die Eindämmung? Welche Maßnahmen waren effektiv, welche nicht? Was muss geändert werden, um einen ähnlichen Vorfall in Zukunft zu verhindern? Die Ergebnisse werden in einem Incident-Report dokumentiert und fließen in aktualisierte Prozesse, Monitoring-Regeln und Sicherheitsrichtlinien ein.

Der Post-Incident-Review ist keine Schuldfrage, sondern ein systematischer Verbesserungsprozess. Unternehmen mit regelmäßigen Post-Incident-Reviews reduzieren nach unserer Erfahrung die Häufigkeit wiederholter Vorfälle deutlich (Projekterfahrung). Der Review sollte innerhalb von 5 Arbeitstagen nach dem Vorfall stattfinden, solange die Erinnerungen frisch sind. Die dokumentierten Lessons Learned werden Teil des kontinuierlichen Verbesserungsprozesses und stärken die Widerstandsfähigkeit der gesamten Infrastruktur.

Kosten eines Hacks: Direkte und indirekte Schäden

Die finanziellen Auswirkungen eines Hacks gehen weit über die direkten Bereinigungskosten hinaus. Direkte Kosten umfassen die forensische Analyse und Bereinigung (5.000 bis 25.000 Euro, Projekterfahrung), den Umsatzverlust während der Downtime (durchschnittlich 5.600 Euro pro Stunde, Gartner, 2025) und mögliche DSGVO-Bußgelder. Indirekte Kosten -- oft unterschätzt -- beinhalten den Vertrauensverlust bei Kunden, den SEO-Ranking-Verlust durch die Google-Warnung (die Erholung kann Wochen dauern), erhöhte Kundenservice-Kosten und den internen Zeitaufwand für Krisenkommunikation und Dokumentation.

Die Gesamtkosten einer Datenschutzverletzung übersteigen die reinen Bereinigungskosten regelmäßig um ein Vielfaches, wenn Bußgelder, Umsatzausfälle und Folgeaufwand einberechnet werden (Projekterfahrung). Für Online-Shops mit Kundendaten und Zahlungsinformationen fällt dieser Betrag besonders hoch aus. Die Investition in professionelle Prävention und Wartung beträgt einen Bruchteil dieser Summe und reduziert das Risiko einer Kompromittierung drastisch.

Die langfristigen Kosten werden häufig unterschätzt: Nach einem öffentlich bekannt gewordenen Sicherheitsvorfall sinkt das Kundenvertrauen messbar. Bestandskunden hinterfragen die Datensicherheit, potenzielle Neukunden wählen alternative Anbieter. Dieser Vertrauensverlust lässt sich in entgangenen Umsätzen über Monate hinweg messen -- ein Effekt, der die unmittelbaren Bereinigungskosten um ein Vielfaches übersteigen kann. Die Investition in präventive Sicherheitsmaßnahmen ist daher nicht nur technisch, sondern auch betriebswirtschaftlich die bessere Strategie.

DSGVO-Meldepflicht und Kommunikation

Wenn bei einem Hack personenbezogene Daten betroffen sind -- Kundennamen, E-Mail-Adressen, Bestelldaten, Zahlungsinformationen --, besteht nach Art. 33 DSGVO eine Meldepflicht an die Aufsichtsbehörde innerhalb von 72 Stunden nach Bekanntwerden. Bei hohem Risiko für die betroffenen Personen (Art. 34 DSGVO) müssen zusätzlich die Betroffenen selbst informiert werden. Die Nichtmeldung kann Bußgelder von bis zu 10 Millionen Euro oder 2 Prozent des Jahresumsatzes nach sich ziehen.

Die Kommunikation gegenüber Kunden sollte transparent und sachlich erfolgen: Was ist passiert, welche Daten sind betroffen, welche Maßnahmen wurden ergriffen und was sollten die Kunden tun (z.B. Passwörter ändern). Offene Kommunikation schafft Vertrauen -- Vertuschungsversuche, die später auffliegen, zerstören es dauerhaft. Zusätzlich muss die Google Search Console bereinigt werden, falls Google die Website als "gehackt" markiert hat.

Der beste Notfallplan ist einer, der nie zum Einsatz kommen muss. Professionelle Prävention -- regelmäßige Updates, gehärtete Konfiguration, WAF, Monitoring und getestete Backups -- reduziert das Risiko einer Kompromittierung drastisch. Aber da absolute Sicherheit nicht existiert, ist ein vorbereiteter, getesteter Notfallplan die Versicherung, die den Unterschied zwischen einem beherrschbaren Vorfall und einer existenzbedrohenden Krise ausmacht. Die Investition in einen professionellen Notfall-Support stellt sicher, dass im Ernstfall erfahrene Experten innerhalb von Minuten reagieren.

Quellen und Studien

Dieser Artikel basiert auf Daten aus: Patchstack State of WordPress Security (2025), IBM Cost of a Data Breach Report (2025), DSGVO Art. 33/34 zur Meldepflicht. Die genannten Zahlen können je nach Branche und Angriffsszenario variieren.