Es beginnt selten mit einer Fehlermeldung. Meistens ruft ein Kunde an, weil auf Ihrer Seite etwas steht, das Sie dort nicht hingeschrieben haben. Oder Google zeigt eine Warnung vor Ihrer Website. Oder ein Mitarbeiter wundert sich, dass eine Unterseite auf eine fremde Adresse weiterleitet. In diesem Moment zählt, was in den nächsten sechzig Minuten passiert – und vor allem, was nicht passiert.
Dieser Beitrag ist als Ablauf geschrieben. Wenn es gerade passiert: Lesen Sie die drei Reflexe, dann Minute 0 bis 10, und rufen Sie an.
Die drei Reflexe, die den Schaden vergrößern
„Schnell wieder sauber machen." Der verständlichste und teuerste. Wer die fremden Inhalte entfernt, die verdächtige Datei löscht und die Seite wieder freigibt, hat nichts behoben – die Lücke ist noch da, der Zugang meist auch. Und die Spuren, mit denen sich beides finden ließe, sind weg.
„Erst mal neu starten." Ein Neustart leert den Arbeitsspeicher. Damit verschwinden laufende Prozesse, offene Verbindungen und oft auch die Hinweise darauf, was gerade getan wurde.
„Sicherung einspielen, dann läuft es wieder." Wenn der Zugang vor der Sicherung entstand, holen Sie ihn damit zurück. Welche Sicherung sauber ist, weiß man erst nach Minute 30.
Minute 0 bis 10: Lage feststellen
Was ist der Auslöser? Notieren Sie wörtlich, was Sie gesehen oder gehört haben, mit Uhrzeit. Fremde Inhalte auf der Seite? Eine Warnung im Browser? Eine Mail von einem Kunden? Das bestimmt, wie dringend es ist – eine sichtbar manipulierte Seite ist etwas anderes als ein Verdacht aus den Protokollen.
Wer ist zuständig? Ihr Dienstleister, Ihre interne IT, Ihr Hoster. Schreiben Sie auf, wen Sie wann erreicht haben. Klingt bürokratisch, ist aber in zwei Stunden Gold wert, wenn mehrere Leute parallel arbeiten.
Was betrifft es? Nur die Website, oder auch Postfächer, Shop, Kundenbereich? Die Antwort entscheidet über den Umfang.
Nicht machen in diesen zehn Minuten: Nichts löschen, nichts neu starten, keine Passwörter ändern. Das klingt falsch, ist aber richtig – dazu gleich mehr.
Minute 10 bis 20: Beweise sichern
Bevor irgendetwas verändert wird:
- Protokolle von Webserver und PHP herunterladen, nicht nur ansehen
- Vollständige Kopie des Website-Verzeichnisses
- Datenbankabzug
- Bei einer virtuellen Maschine: Schnappschuss
Alles außerhalb des betroffenen Servers ablegen. Dieser Schritt dauert Minuten und ist der einzige, den Sie später nicht nachholen können. Protokolle werden überschrieben, Angreifer räumen auf, und beides geschieht ohne Vorwarnung.
Warum jetzt noch keine Passwörter ändern? Weil die Änderung dem Angreifer zeigt, dass er entdeckt wurde – und weil Sie noch nicht wissen, welche Zugänge überhaupt betroffen sind. Nach der Beweissicherung ist das der richtige Schritt, vorher nicht.
Minute 20 bis 30: Vom Netz nehmen
Jetzt, nicht vorher. Mit gesicherten Beweisen können Sie den Dienst abschalten, ohne etwas zu verlieren.
Abschalten heißt: aus dem Internet nehmen. Nicht löschen, nicht formatieren, nicht neu aufsetzen. Das System bleibt, wie es ist.
Setzen Sie eine Hinweisseite: „Wir arbeiten an einem Sicherheitsupdate und sind in Kürze wieder erreichbar." Das ist besser als eine Fehlermeldung und ehrlicher als Schweigen. Nennen Sie eine Telefonnummer, unter der Sie erreichbar sind.
Wenn Abschalten nicht geht – weil der Shop läuft oder ein Kundenbereich gebraucht wird –, ist das eine Geschäftsentscheidung, keine technische. Dann gehört sie der Geschäftsführung vorgelegt, mit der Information, dass der Zugriff währenddessen weiterläuft.
Minute 30 bis 45: Umfang eingrenzen
Zwei Fragen, in dieser Reihenfolge.
Seit wann? Aus den Protokollen und dem Dateibestand lässt sich ein Zeitraum eingrenzen. Bei PHP2Shell beginnt das Fenster am 20. Oktober 2026. Das Ergebnis ist ein Datum, ab dem nichts mehr als vertrauenswürdig gilt – und damit zugleich die Antwort auf die Frage, welche Sicherung noch brauchbar ist.
Wie weit? Hatte der Webserver Verbindung ins Firmennetz? Lagen dort Zugangsdaten für andere Systeme? Konnte von dort Mail verschickt werden? Was daraus folgt, steht in Vom Webserver ins Firmennetz.
Diese Viertelstunde entscheidet darüber, ob Sie es mit einem Website-Vorfall oder einem Unternehmensvorfall zu tun haben.
Minute 45 bis 60: Entscheiden und melden
Zugänge erneuern – jetzt ist der Zeitpunkt. Alles, was auf dem Server lesbar war: Datenbank, Schnittstellenschlüssel, Mailversand, Administratorkonten.
Datenschutz prüfen. Waren personenbezogene Daten betroffen, gilt Art. 33 DSGVO: Meldung an die Aufsichtsbehörde grundsätzlich binnen 72 Stunden ab Kenntnis. Die Uhr läuft ab jetzt. Ob eine Meldung nötig ist, entscheidet nicht die IT – holen Sie Ihren Datenschutzbeauftragten oder Ihre Rechtsberatung dazu.
Anzeige erwägen. Das BSI empfiehlt, Vorfälle zu melden und Anzeige zu erstatten. Für Versicherungsfälle ist das oft ohnehin Voraussetzung.
Entscheiden, wie es weitergeht: bereinigen oder neu aufbauen. Die Grundlage dafür steht in Webshell gefunden – und jetzt?, den geordneten Weg zurück beschreibt Website vom Netz genommen.
Wer in dieser Stunde was tut
Bei den meisten Unternehmen mit 10 bis 500 Arbeitsplätzen sind drei Rollen nötig, und sie liegen selten bei einer Person:
- Entscheiden: Geschäftsführung. Abschalten ja oder nein, externe Hilfe ja oder nein, Kunden informieren ja oder nein.
- Technisch handeln: interne IT oder Dienstleister. Sichern, abschalten, eingrenzen.
- Dokumentieren: irgendjemand, der mitschreibt. Uhrzeit, Beobachtung, Maßnahme. Ohne das lässt sich hinterher nicht rekonstruieren, was wann geschah – und genau danach fragen Versicherung und Aufsicht.
Wenn diese drei Rollen nicht vorher festgelegt sind, kostet die Klärung in der ersten Stunde zwanzig Minuten. Das ist der Grund, warum sich eine Krisenübung am Tisch rechnet.
Checkliste: erste Schritte
- Auslöser mit Uhrzeit wörtlich notieren, Mitschrift beginnen
- Protokolle, Dateibestand und Datenbank außerhalb des Servers sichern
- Erst danach: Seite vom Internet nehmen, Hinweisseite mit Telefonnummer setzen
- Nichts löschen, nicht neu starten, Sicherung noch nicht einspielen
- Zeitraum eingrenzen, ab dem nichts mehr vertrauenswürdig ist
- Prüfen, ob der Server Verbindung zu anderen Systemen hatte
- Alle auf dem Server lesbaren Zugänge erneuern
- Datenschutzbeauftragten einbeziehen, 72-Stunden-Frist im Blick behalten
Wie DAVINCI unterstützt
Wir übernehmen die erste Stunde, wenn bei Ihnen niemand verfügbar ist: Beweise sichern, Umfang eingrenzen, Entscheidungsgrundlage schaffen. Danach arbeitet unser Incident Response den Fall auf und sagt Ihnen schriftlich, was belegt ist und was offen bleibt. Wenn es jetzt passiert: IT-Notfall, 0621 877 55 990, rund um die Uhr. Ohne akuten Vorfall hilft der Quick-Check.
Häufige Fragen
Unsere Seite zeigt fremde Werbung. Ist das schlimm?
Es ist der sichtbare Teil. Wer Inhalte einfügen kann, hat Schreibzugriff – und damit meist mehr Möglichkeiten als Werbung. Behandeln Sie es wie jeden anderen Zugriff.
Google warnt vor unserer Website. Was zuerst?
Dieselbe Reihenfolge. Die Warnung verschwindet erst nach einer erfolgreichen Überprüfung, und die beantragt man sinnvollerweise nach der Bereinigung, nicht davor – sonst wird sie abgelehnt und der Vorgang dauert länger.
Müssen wir unsere Kunden informieren?
Wenn deren personenbezogene Daten betroffen sind, kann eine Benachrichtigung verpflichtend sein. Das hängt vom Risiko ab und ist eine rechtliche Bewertung, keine technische. Klären Sie es, bevor Sie etwas verschicken – eine voreilige Mail ist schwer zurückzuholen.
Wie teuer wird das?
Das hängt fast vollständig davon ab, wie weit der Zugriff reichte und wie gut die Protokolle sind. Ein eingegrenzter Website-Vorfall mit brauchbaren Protokollen ist in ein bis zwei Tagen aufgearbeitet. Ohne Protokolle wird aus der Klärung eine Schätzung, und dann wird neu aufgebaut.
Wir haben schon aufgeräumt, bevor wir das hier gelesen haben.
Dann fehlt Ihnen Material, aber nicht alles. Serverprotokolle sind oft noch da, Sicherungen auch. Wichtig ist, ab jetzt nichts mehr zu verändern und die Protokolle vor dem Überschreiben zu retten.
Verwandte Themen: Wer hier weiterdenkt, liest bei Webshell, Google-Warnung und Angreifer Geschäftsmodell weiter.
