Schritt 1: Diagnose – Was ist passiert und warum?
Bevor irgendetwas verändert wird, steht die Diagnose. Dieser Schritt wird von unerfahrenen Anbietern regelmäßig übersprungen – mit fatalen Folgen: Wer die Ursache nicht kennt, beseitigt sie nicht, und die Website wird innerhalb von Stunden erneut kompromittiert. Wir trennen deshalb strikt zwischen Analyse und Behebung. Erst wenn klar ist, was passiert ist, auf welchem Weg der Angreifer eingedrungen ist und welche Systeme betroffen sind, beginnen wir mit der Beseitigung.
Technischer Ausfall: Warum ist die Website nicht erreichbar?
- Abgelaufene Domain oder fehlgeleiteter DNS-Eintrag (typische Fehlermeldung: ERR_NAME_NOT_RESOLVED)
- Abgelaufenes SSL-Zertifikat (Fehlermeldung im Browser: NET::ERR_CERT_DATE_INVALID)
- Server-Überlastung oder Hoster-Ausfall (HTTP 503 Service Unavailable)
- Fehlerhafte Konfiguration nach einem Update, einem Serverumzug oder einem fehlgeschlagenen Deployment
- Blockierung durch den Hoster wegen Schadcode-Erkennung auf Infrastrukturebene – der Account wird in diesem Fall oft ohne Vorwarnung gesperrt
Kompromittierte Website: Typische Anzeichen
- Besucher werden auf fremde Seiten weitergeleitet (Redirect-Hack)
- Google Search Console zeigt Sicherheitswarnungen oder der Browser markiert die Seite als gefährlich
- Fremde Nutzerkonten im CMS-Backend, unbekannte oder veränderte Dateien auf dem Server
- Plötzlicher Einbruch im organischen Traffic – häufig durch SEO-Spam-Injektion in Seiteninhalte, die Suchmaschinen indizieren, ohne dass es auf der sichtbaren Seite auffällt
- Hosting-Provider hat den Account aus Sicherheitsgründen gesperrt und eine entsprechende Benachrichtigung geschickt
- Erpressungsnachricht auf der Website oder verschlüsselte Dateien auf dem Server (Ransomware-Szenario)
Wichtig: Bevor Sie selbst etwas verändern – keine Dateien löschen, keine Passwörter zurücksetzen, keine Updates einspielen. Jede unkontrollierte Aktion kann Beweise vernichten und die forensische Analyse unmöglich machen. Kontaktieren Sie uns zuerst über das Anfrageformular – wir leiten Sie durch die richtigen nächsten Schritte, ohne dass Spuren verloren gehen.
Schritt 2: Unser Incident-Response-Prozess im Detail
Unser Vorgehen orientiert sich an etablierten Frameworks der IT-Sicherheit: dem NIST SP 800-61 (Computer Security Incident Handling Guide) und dem SANS-PICERL-Modell (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned), ergänzt um die Anforderungen des BSI-Standards 200-4 für Notfallmanagement. Diese Frameworks definieren Incident Response als geordneten Phasenprozess – nicht als reaktives Flickwerk. Die vier operativen Phasen laufen strukturiert ab, damit keine Maßnahme vergessen wird und Sie zu jedem Zeitpunkt wissen, was als nächstes passiert.
- 1
Phase 1 – Eindämmung (erste 30–60 Minuten)
Website in den Wartungsmodus versetzen oder vom Netz nehmen, um weitere Besucher vor Schadsoftware zu schützen. Anschließend erstellen wir eine forensische Beweiskopie des kompromittierten Systems – schreibgeschützt und unveränderlich – bevor irgendetwas modifiziert wird. Alle Zugangsdaten (CMS-Admin, FTP/SFTP, Datenbank, Hosting-Panel, verknüpfte Drittdienste) werden sofort rotiert; unbekannte Admin-Accounts werden gesperrt. Dieser Schritt ist nicht optional: Eine Beweissicherung, die übersprungen wird, kann spätere rechtliche Schritte und die DSGVO-Dokumentation erheblich erschweren.
- 2
Phase 2 – Analyse (parallele Untersuchung)
Auswertung der Server-Logs auf unbekannte Uploads, Anmeldeversuche und verdächtige Zeitstempel. Identifikation des Angriffsvektors: veraltetes Plugin oder Theme, kompromittiertes Passwort, SQL-Injection, File-Inclusion-Schwachstelle, Brute-Force auf das CMS-Backend? Die Ursache muss bekannt sein, bevor irgendetwas repariert wird – andernfalls bleibt die Lücke offen und der nächste Angriff erfolgt innerhalb von Stunden. Schadensumfang: Welche Dateien wurden verändert oder hinzugefügt? Wurden Nutzerdaten abgerufen oder exfiltriert? Diese Frage ist unmittelbar DSGVO-relevant und bestimmt, ob eine Meldepflicht besteht.
- 3
Phase 3 – Wiederherstellung aus sauberem Stand
Wir spielen ein Backup ein, das nachweislich vor dem Angriff erstellt wurde. Das Backup wird zunächst in einer isolierten Testumgebung verifiziert – niemals direkt in die Produktion. Ein Restore ohne vorherigen Integritätstest ist ein klassischer Fehler: Das Backup kann bereits kompromittiert sein, wenn der Angriff länger als das Backup-Intervall unbemerkt blieb. Existiert kein sauberes Backup, reinstallieren wir CMS-Kerndateien aus verifizierten offiziellen Quellen, prüfen die Datenbank auf injizierte Inhalte und durchsuchen systematisch alle Verzeichnisse nach hinterlassenen Backdoors – eine aufwändigere, aber vollständig mögliche Alternative.
- 4
Phase 4 – Härtung und Nachbereitung
Nach der Wiederherstellung schließen wir die ursprüngliche Sicherheitslücke dauerhaft: Updates aller Komponenten, Konfigurationshärtung auf Serverebene, Einrichtung einer Web Application Firewall (WAF), Security-Header (Content Security Policy, HSTS, X-Frame-Options), Zwei-Faktor-Authentifizierung für alle privilegierten Accounts. Bei Google-Markierung stellen wir den Antrag auf Überprüfung in der Google Search Console und begleiten den Prozess bis zur Aufhebung der Warnung. Abschließend erhalten Sie einen schriftlichen Post-Incident-Report mit Ursache, Ablauf, Zeitleiste und dauerhaften Schutzempfehlungen – als Grundlage für interne Dokumentation und gegebenenfalls DSGVO-Nachweise.
Diese Leistung ist Teil unseres umfassenden Ansatzes für Website-Sicherheit. Wenn Sie über präventive Absicherung nachdenken, finden Sie die Gesamtübersicht auf unserer Seite /leistungen/website-sicherheit/. Verwandte Unterleistungen sind die laufende Malware-Überwachung sowie der Aufbau professioneller Backup-Strukturen.
Die richtige Backup-Strategie: Voraussetzung jeder erfolgreichen Wiederherstellung
Die häufigste Frage nach einem Sicherheitsvorfall lautet: 'Haben wir ein sauberes Backup?' Die ehrliche Antwort vieler Unternehmen ist: 'Wir dachten schon.' Backups, die nie getestet wurden, Backups, die auf demselben Server wie die Produktion liegen, Backups, die automatisch mitgesichert haben – inklusive der Schadsoftware. All das sind Situationen, die im Ernstfall zur Totalwiederherstellung von Grund auf zwingen. Die Backup-Strategie ist keine IT-Formalität, sondern die entscheidende Voraussetzung dafür, dass ein Wiederherstellungsprozess überhaupt greifen kann.
Die 3-2-1-1-0-Regel erklärt
- 3 Kopien Ihrer Daten (Produktion + 2 Backups)
- 2 verschiedene Speichermedien oder -technologien (z. B. lokales NAS + Cloud-Storage)
- 1 Kopie geografisch getrennt (Offsite, z. B. anderes Rechenzentrum oder geografisch separierter Cloud-Standort)
- 1 unveränderliche (immutable) Kopie, die auch nach einem Ransomware-Befall nicht nachträglich verschlüsselt oder überschrieben werden kann
- 0 Fehler bei regelmäßigen Restore-Tests – ein Backup, das nicht erfolgreich getestet wurde, ist kein Backup, sondern eine unbewiesene Hoffnung
RPO und RTO: Die zwei Schlüsselgrößen
Recovery Point Objective (RPO) beschreibt den maximalen tolerierbaren Datenverlust in Zeit: Wie alt darf das Backup sein, das Sie einspielen? Ein Online-Shop mit stündlichen Bestellungen und Lagerbewegungen hat einen grundlegend anderen RPO als eine Unternehmenswebsite, deren Inhalte monatlich gepflegt werden. Recovery Time Objective (RTO) beschreibt die maximale tolerierbare Ausfallzeit: Wie lange kann Ihr Unternehmen ohne die Website operieren, bevor wirtschaftlicher Schaden entsteht? Diese beiden Werte müssen vor einem Notfall schriftlich definiert sein – andernfalls fehlt im Krisenfall jede Priorisierungsgrundlage, und Entscheidungen werden unter Druck und mit unvollständigen Informationen getroffen.
RPO und RTO bestimmen direkt, wie häufig Backups erstellt werden müssen und welche Infrastruktur für die Wiederherstellung bereitgehalten werden muss. Ein RPO von einer Stunde erfordert stündliche inkrementelle Backups und eine Testinfrastruktur, die einen Restore in Minuten ermöglicht – das ist fundamental anders als ein wöchentliches Vollbackup auf einem externen Speicher.
Kritischer Fehler in der Praxis: Viele Unternehmen betrachten die automatischen Backups ihres Hosting-Providers als ausreichend. Diese Backups liegen jedoch oft im selben Netzwerksegment wie der Produktivserver – Ransomware kann beides gleichzeitig verschlüsseln. Und: Schlägt ein Backup-Job unbemerkt fehl, entdeckt man das erst im Notfall. Wir richten ein Monitoring für Backup-Jobs ein, das Sie aktiv informiert, wenn eine Sicherung fehlschlägt – bevor der Ernstfall eintritt.
DSGVO-Pflichten bei kompromittierter Website: Was Sie jetzt tun müssen
Ein Hackerangriff auf eine Website ist in vielen Fällen auch eine Datenschutzverletzung im Sinne der DSGVO – insbesondere, wenn personenbezogene Daten von Kunden, Mitarbeitern oder Nutzern betroffen sind. Die rechtlichen Konsequenzen werden von Unternehmen regelmäßig unterschätzt, und die 72-Stunden-Frist läuft schneller ab als die technische Analyse abgeschlossen ist.
Die 72-Stunden-Meldepflicht (Art. 33 DSGVO)
Sobald Sie Kenntnis von einer Datenpanne erhalten, beginnt die Frist: Die zuständige Datenschutzaufsichtsbehörde muss 'unverzüglich und möglichst binnen 72 Stunden' informiert werden, wenn die Verletzung voraussichtlich zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Diese Frist beginnt mit der Kenntniserlangung – nicht erst nach Abschluss der IT-Untersuchung. Die Meldung kann also auch als vorläufige Meldung erfolgen, während die Analyse noch läuft, und mit einem Nachtrag ergänzt werden, sobald weitere Details bekannt sind.
Betroffene informieren (Art. 34 DSGVO)
Bei einem hohen Risiko für die betroffenen Personen – etwa bei Abfluss von Passwörtern, Zahlungsdaten oder sensiblen persönlichen Informationen – müssen auch die Betroffenen selbst unverzüglich und in verständlicher Sprache informiert werden, mit konkreten Handlungsempfehlungen (z. B. Passwort sofort ändern, Kontoauszüge prüfen). Die Pflicht zur Benachrichtigung der Betroffenen besteht unabhängig davon, ob auch eine Behördenmeldung notwendig ist. Auch wenn keine der beiden Meldepflichten greift: Die interne Dokumentation der Panne ist gemäß Art. 33 Abs. 5 DSGVO immer verpflichtend.
Bußgelder bei Verstoß gegen die Meldepflicht: bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes (Art. 83 Abs. 4 DSGVO). Wir unterstützen Sie bei der korrekten Dokumentation und bei der Vorbereitung der Behördenmeldung – aber wir ersetzen keine Rechtsberatung. Für rechtliche Fragen empfehlen wir, parallel einen auf IT-Recht spezialisierten Anwalt einzubeziehen.
Krisenkommunikation: Was Kunden und Partner jetzt von Ihnen erwarten
Während Ihr technisches Team die Website wiederherstellt, müssen Sie nach außen kommunizieren. Schweigen ist keine Option: Jede Stunde ohne aktive Kommunikation verstärkt Unsicherheit und Vertrauensverlust bei Kunden, Partnern und Mitarbeitern. Gleichzeitig darf die Kommunikation keine falschen Versprechen machen oder Informationen preisgeben, die die forensische Untersuchung behindern oder den Angreifer über den Stand der Analyse informieren.
Grundprinzipien der Krisenkommunikation bei Website-Ausfall
- Schnell reagieren: Erste öffentliche Meldung möglichst innerhalb von ein bis zwei Stunden – auch wenn Sie noch keine vollständige Analyse haben
- Ehrlich und klar: Sagen Sie, was Sie wissen, und sagen Sie explizit, was Sie noch untersuchen – Spekulation und Verharmlosung vermeiden gleichermaßen
- Proaktiv aktualisieren: Richten Sie eine Statusseite ein (z. B. über Atlassian Statuspage oder einen einfachen statischen HTML-Stand), die Sie in definierten Abständen aktualisieren
- Stakeholder-Reihenfolge einhalten: Zuerst direkt betroffene Kunden (besonders bei Datenpanne), dann Mitarbeiter, dann Geschäftspartner und Lieferanten, zuletzt ggf. Medienanfragen
- Handlungsempfehlungen geben: Bei Datenpanne klar kommunizieren, was Betroffene konkret tun sollen – Passwort ändern, Zahlungen prüfen, verdächtige Aktivitäten melden
Praktisch bewährt: Halten Sie eine Vorlage für Krisenkommunikation bereits vor dem Notfall bereit – Absender, Tonalität, Kanalwahl (E-Mail, Social Media, Website-Banner). Im Krisenfall fehlt die Zeit für Konzeption von Grund auf. Wir erstellen solche Vorlagen auf Wunsch als Teil unseres IT-Notfallplan-Pakets.
Die teuersten Fehler bei der Website-Wiederherstellung
In der Praxis beobachten wir immer wieder dieselben Fehler, die einen Vorfall von einer beherrschbaren Krise zur existenziellen Gefahr machen. Die folgende Übersicht zeigt die häufigsten Probleme und ihre konkreten Folgen – jeder dieser Fehler ist in realen Wiederherstellungsprojekten aufgetreten.
| Fehler | Konkrete Folge |
|---|---|
| Nur die sichtbar schadhafte Datei löschen, ohne vollständige Bereinigung | Backdoor bleibt aktiv; Angreifer hat weiterhin Zugang, neuer Angriff innerhalb von Stunden |
| Passwörter nach dem Hack nicht vollständig rotieren | Angreifer behält dauerhaften Zugang über gespeicherte oder exfiltrierte Credentials |
| Backups wurden nie in einem echten Restore-Test geprüft | Im Ernstfall stellt sich heraus: Backup ist korrupt, unvollständig oder enthält selbst Schadsoftware |
| Backup liegt im selben Netzwerksegment wie der Produktivserver | Ransomware verschlüsselt Produktion und Backup gleichzeitig – beide Kopien unbrauchbar |
| Kompromittierten Stand direkt in die Produktion einspielen ohne Isoliertest | Schadsoftware oder Backdoor ist sofort wieder produktiv; das Problem wird lediglich neu gestartet |
| Notfallplan ausschließlich digital auf dem betroffenen System gespeichert | Bei IT-Totalausfall ist der Plan selbst nicht erreichbar – BSI 200-4 empfiehlt explizit eine Offline-Kopie |
| 72-Stunden-DSGVO-Frist verpasst | Bußgeld bis 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes (Art. 83 Abs. 4 DSGVO) |
| Plattform-eigene Cloud-Backups als vollwertigen Schutz betrachten | Aufbewahrungsfristen und Wiederherstellungsoptionen variieren je nach Anbieter, Datentyp und Konfiguration erheblich; kein Schutz gegen versehentliches Überschreiben durch kompromittierte Synchronisation oder gegen Ransomware, die Cloud-Credentials erbeutet hat |
Ihr persönlicher IT-Notfallplan: Was vor dem nächsten Vorfall getan werden muss
Der BSI-Standard 200-4 für Business Continuity Management (BCMS) empfiehlt Unternehmen jeder Größe, einen schriftlichen Notfallplan zu erstellen und regelmäßig zu testen. Dieser Plan muss auch dann verfügbar sein, wenn die gesamte IT ausgefallen ist – also als Offline-Kopie in Papierform oder auf einem isolierten, nicht ans Netzwerk angebundenen Gerät. Ein Plan, der nur digital vorliegt und auf einem kompromittierten System gespeichert ist, ist im Ernstfall wertlos.
Kerninhalte eines Website-Notfallplans
Wir erarbeiten diesen Notfallplan gemeinsam mit Ihnen – auf Basis einer Analyse Ihrer bestehenden Infrastruktur und Ihrer geschäftlichen Kritikalitätsanforderungen. Das Ergebnis ist ein praxistaugliches Dokument, das Ihr Team in einem echten Notfall direkt einsetzen kann – ohne lange zu suchen, zu improvisieren oder unter Zeitdruck Entscheidungen ohne Grundlage zu treffen. Der Plan wird in einem Format übergeben, das sowohl digital als auch als Ausdruck funktioniert. Weiterführende Informationen zu präventiven Sicherheitsmaßnahmen finden Sie auf unserer Seite /leistungen/website-sicherheit/.