Was in der ersten Stunde zählt
Die ersten 60 Minuten entscheiden oft darüber, wie vollständig sich ein Sicherheitsvorfall später rekonstruieren lässt. Ziel ist noch nicht die vollständige Bereinigung. Zuerst müssen weitere Schäden begrenzt und vorhandene Spuren erhalten werden.
Bevor Sie etwas löschen
Verdächtige Dateien, Datenbankeinträge oder Logs enthalten oft die einzigen Spuren, mit denen sich Eintrittsweg und mögliche Datenabflussindikatoren später noch rekonstruieren lassen. Ein vorschnelles Aufräumen macht diese Rekonstruktion häufig unmöglich.
Sichere Sofortmaßnahmen
- Screenshots von Warnmeldungen (Google, Hosting, Browser) sichern
- Vorhandene Backups NICHT überschreiben — auch wenn sie älter sind
- Zugriffs- und Fehlerprotokolle des Hostings, sofern zugänglich, exportieren
- Auffällige Administrator-Konten notieren, aber vorerst nicht löschen
- Kunden- oder Zahlungsdatenrisiko intern an Verantwortliche melden
- Eine strukturierte Ersteinschätzung anfordern, bevor eigenständig repariert wird
Was die Wiederherstellung gefährdet
- verdächtige Dateien vorschnell löschen
- die komplette Website vor einer Sicherung zurücksetzen
- ein zusätzliches Bereinigungs-Plugin installieren, ohne die Ursache zu kennen
- Zugangsdaten unverschlüsselt per E-Mail oder Messenger weiterreichen
- Datensicherungen überschreiben, bevor der Umfang des Vorfalls klar ist
Befund, Indiz und Grenze
Ein fehlender Logeintrag beweist keinen fehlenden Zugriff — er zeigt nur, dass an dieser Stelle keine Aufzeichnung vorliegt. Diese Unterscheidung ist zentral für eine ehrliche Einschätzung.
Eine vollständige Prüfung auf Datenabflussindikatoren ist ein eigener Schritt, der über die reine Bereinigung hinausgeht.
Wie sieht ein sinnvoller 60-Minuten-Ablauf aus?
Ein fester Ablauf verhindert, dass Zeitdruck zu widersprüchlichen Änderungen führt. Die Minutenangaben sind Orientierung, keine Garantie: Bei laufendem Zahlungsbetrug, aktiven Weiterleitungen oder erreichbaren Kundendaten hat die Eindämmung Vorrang.
Minute 0 bis 10: Lage und Zuständigkeit klären
Notieren Sie, wer den Sicherheitsvorfall entdeckt hat, wann das Symptom erstmals sichtbar war und welche Systeme betroffen sein könnten. Halten Sie fest, ob die Website nur Inhalte ausliefert oder auch Formulare, Shop-, Mitglieder- oder Zahlungsfunktionen verarbeitet. Bestimmen Sie eine Person, die Änderungen koordiniert. Mehrere Personen, die gleichzeitig Plugins löschen, Passwörter ändern und Datensicherungen einspielen, erschweren die Rekonstruktion.
Öffnen Sie verdächtige URLs nicht unnötig auf produktiven Arbeitsgeräten. Falls Browser oder Suchmaschinen eine Warnung zeigen, sichern Sie Screenshot, genaue URL, Uhrzeit und Meldung. Bewahren Sie Benachrichtigungen des Hosters und vorhandene Ticketverläufe auf.
Minute 10 bis 30: flüchtige und leicht verlierbare Spuren sichern
Exportieren Sie verfügbare Webserver-, PHP-, WAF-, CDN-, SFTP- und Authentifizierungslogs, bevor Aufbewahrungsfristen oder Rotationen sie überschreiben. Erstellen Sie eine unveränderte Kopie von Dateien und Datenbank, wenn das ohne weitere Gefährdung möglich ist. Diese Kopie ist kein „sauberes Backup“, sondern eine Momentaufnahme für die Analyse.
Dokumentieren Sie aktive Administratoren, Anwendungspasswörter, aktive Sitzungen, geplante Aufgaben und auffällige Weiterleitungen. Notieren Sie Dateizeitstempel, ohne sie als alleinigen Beweis zu behandeln: Angreifer oder Kopierprozesse können Zeitstempel verändern.
Minute 30 bis 60: kontrolliert eindämmen und Übergabe vorbereiten
Wählen Sie die kleinste Maßnahme, die den aktuellen Schaden wirksam begrenzt. Das kann eine Wartungsseite, eine WAF-Regel, das Sperren einer kompromittierten Identität oder die vorübergehende Deaktivierung einer gefährdeten Funktion sein. Ein pauschales Löschen der gesamten Installation ist selten der erste sinnvolle Schritt.
Erstellen Sie anschließend ein kurzes Übergabepaket: betroffene Domains und Systeme, Zeitlinie, beobachtete Symptome, bereits ausgeführte Änderungen, verfügbare Backups, gesicherte Logs und bekannte Ansprechpartner bei Hosting oder Datenschutz. Damit beginnt eine strukturierte Ersteinschätzung mit Fakten statt Vermutungen.
Wann sollte die Website offline gehen?
Eine sofortige Abschaltung ist sinnvoll, wenn die Website aktiv Malware verteilt, Besucher umleitet, Zahlungen manipuliert oder weitere Daten preisgibt und eine gezielte Eindämmung nicht rechtzeitig möglich ist. Sie ist nicht automatisch sinnvoll, wenn nur eine historische Warnung vorliegt oder wenn das Abschalten wichtige Spuren zerstören würde.
Die Entscheidung sollte vier Fragen beantworten:
| Frage | Bedeutung |
|---|---|
| Läuft der schädliche Effekt noch? | Aktiver Schaden erhöht die Dringlichkeit der Eindämmung. |
| Sind Nutzer- oder Zahlungsdaten erreichbar? | Mögliche Betroffenheit erfordert frühe interne Eskalation. |
| Kann eine engere Sperre den Effekt stoppen? | Eine gezielte Regel erhält mehr Beobachtbarkeit als ein Komplettausfall. |
| Sind Beweise bereits gesichert? | Vor größeren Änderungen sollten verfügbare Spuren kopiert werden. |
Nach einer Abschaltung bleiben Datenbank, Zugangsdaten, Hintergrundjobs und Serverkonfiguration prüfbedürftig. „Offline“ bedeutet nicht „bereinigt“.
Wann sollten Passwörter, Zugangsdaten und Schlüssel geändert werden?
Kompromittierte Zugänge müssen gesperrt werden, aber die Rotation braucht eine Reihenfolge. Wird nur das WordPress-Passwort geändert, während ein unbekannter Administrator, ein gestohlener Hosting-Zugang oder eine Webshell aktiv bleibt, kann der neue Wert erneut abgegriffen werden.
Beginnen Sie mit sicheren administrativen Identitäten außerhalb der kompromittierten Umgebung: Hosting, DNS, CDN und E-Mail. Danach folgen WordPress-Administratoren, Datenbankzugänge, Anwendungspasswörter, API-Schlüssel, Zahlungs- und Versandintegrationen sowie WordPress-Salts. Beenden Sie alte Sitzungen. Die ausführliche Reihenfolge steht im Beitrag zum Erneuern von Zugangsdaten und Sitzungen.
Sichere Übergabe
Versenden Sie keine Zugangsdaten im normalen Anfrageformular. Nutzen Sie ausschließlich den vereinbarten sicheren Übertragungsweg und vergeben Sie möglichst zeitlich begrenzte Zugänge.
Welche Informationen braucht eine belastbare Ersteinschätzung?
Eine gute Übergabe trennt Beobachtung und Interpretation. „Beim Aufruf von /angebot/ erfolgt seit 14:20 Uhr eine Weiterleitung“ ist überprüfbar. „Das Plugin X hat alle Kundendaten gestohlen“ ist ohne technische Belege eine Schlussfolgerung.
Hilfreich sind:
- genaue Symptome, URLs, Uhrzeiten und Zeitzone;
- Hosting-, CDN-, WAF- und WordPress-Zugänge über einen sicheren Kanal;
- Änderungen kurz vor dem Vorfall, etwa Updates oder neue Benutzer;
- Information, welche personenbezogenen oder zahlungsbezogenen Daten verarbeitet werden;
- vorhandene Backups mit Erstellungsdatum und Speicherort;
- alle bereits vorgenommenen Reparatur- oder Passwortmaßnahmen.
Wie Befunde und Grenzen im Ergebnis dokumentiert werden, zeigt der fiktive Musterbericht. Die Methodik erklärt außerdem, warum Ersteinschätzung, Bereinigung und eine beweissichere forensische Untersuchung unterschiedliche Leistungsumfänge sind.
Was passiert nach der ersten Stunde?
Nach der Ersteinschätzung folgen Ursachenanalyse, Bereinigung aus vertrauenswürdigen Quellen, Erneuerung betroffener Zugangsdaten, Funktionsprüfung und grundlegende Absicherung. Gefundene Anzeichen werden erneut gesucht; unbekannte oder nicht prüfbare Komponenten werden als Grenze dokumentiert.
Wenn personenbezogene Daten betroffen sein könnten, läuft parallel die indikatorenbasierte Datenabflussprüfung. Sie kann belastbare Hinweise und Lücken benennen, ersetzt aber keine rechtliche Bewertung und verspricht keinen Beweis, wenn relevante Logs fehlen.
