Die Zeitleiste eines Vorfalls erstellen

Kurz gesagt: Eine Zeitleiste eines IT-Vorfalls ordnet alle Beobachtungen, Entscheidungen und Maßnahmen chronologisch in einer einheitlichen Zeitzone, idealerweise UTC. Jede Zeile nennt Quelle, Beobachtung, Beleg und eine Bewertung als belegt, wahrscheinlich oder unbekannt. So entsteht ein nachvollziehbares Bild davon, wann der Angreifer im System war, was er erreichen konnte und wann Sie davon Kenntnis hatten.

Warum am Ende alle nach dem Wann fragen

Nach einem Vorfall kommen die Fragen aus allen Richtungen. Der Datenschutzbeauftragte will wissen, seit wann personenbezogene Daten erreichbar waren. Der Versicherer fragt, wann der Schaden entdeckt und gemeldet wurde. Die Geschäftsführung möchte wissen, ob die Lücke schon vor dem letzten Update offen war. Alle diese Fragen haben eine Gemeinsamkeit: Sie drehen sich um Zeitpunkte.

Ohne Zeitleiste beantwortet jeder diese Fragen aus der Erinnerung, und die Antworten widersprechen sich. Mit einer sauber geführten Zeitleiste gibt es eine gemeinsame Grundlage, auf die sich alle Beteiligten beziehen. Sie ist zugleich das Gerüst für den Abschlussbericht.

Bei PHP2Shell ist die Zeitleiste besonders aussagekräftig, weil die öffentlichen Eckdaten gut dokumentiert sind. Sie lassen sich als Ankerpunkte neben die eigenen Beobachtungen legen. Die vollständige Abfolge der öffentlichen Ereignisse beschreibt der Ratgeber PHP2Shell: Die Chronologie.

Der Aufbau: Welche Spalten eine Zeitleiste braucht

Eine Tabelle genügt, ob in einer Tabellenkalkulation oder einem gemeinsamen Dokument. Wichtig sind feste Spalten, die für jede Zeile ausgefüllt werden. Das folgende Muster zeigt die öffentlichen PHP2Shell-Eckdaten als Anker und darunter typische eigene Einträge in Platzhalterform:

Die Spalte Bewertung ist der wichtigste Teil. Sie trennt, was nachgewiesen ist, was plausibel erscheint und was offen bleibt. Spätere Leser sehen so sofort, wo die Zeitleiste trägt und wo Lücken bestehen.

Zeitleiste eines IT-Vorfalls: Quellen zusammenführen

Die Einträge stammen aus vielen Quellen, die jeweils eigene Formate und Zeitzonen haben. Gehen Sie in dieser Reihenfolge vor:

1. Zeitzone festlegen: Alles in UTC führen. Die Umstellung auf Winterzeit am 25.10.2026 verschiebt deutsche Ortszeiten mitten im Zeitraum um eine Stunde. Wer Ortszeiten mischt, verschiebt Ereignisse unbemerkt.
2. Uhren prüfen: Ging die Uhr des Servers richtig? Ein Vergleich mit einem bekannten Ereignis, etwa dem eigenen Login, zeigt Abweichungen.
3. Externe Quellen zuerst: Logs von CDN, WAF, Hoster oder Firewall liegen außerhalb des Servers und sind schwer zu manipulieren. Sie bilden das Gerüst.
4. Serverlogs ergänzen: Webserver, PHP-FPM, Anmeldungen, Systemjournal. Die Methodik dafür beschreibt Webserver-Logs nach einem Angriff auswerten.
5. Dateisystem einordnen: Zeitstempel neuer und geänderter Dateien als Hinweise ergänzen.
6. Interne Ereignisse eintragen: Wann wurde etwas bemerkt, wer wurde informiert, welche Entscheidung fiel wann?

Was Dateizeitstempel verraten und was nicht

Linux speichert für jede Datei mehrere Zeitpunkte, unter anderem die letzte Änderung des Inhalts (mtime) und die letzte Änderung der Metadaten (ctime). Beide lassen sich lesend ausgeben, hier als Liste der seit einem Stichtag geänderten PHP-Dateien, sortiert nach Zeit in UTC:

# Inhaltsänderungen seit dem 17.10.2026, sortiert, in UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort

# Alle Zeitstempel einer einzelnen Datei
TZ=UTC stat /var/www/ihre-website/verdaechtig.php

Arbeiten Sie dabei nur auf einer Kopie oder einem gesicherten Abbild, wie unter Beweise sichern, bevor Sie neu aufsetzen beschrieben. Bedenken Sie zwei Grenzen. Erstens kann ein Angreifer das Änderungsdatum einer Datei mit einfachen Mitteln zurücksetzen; eine unauffällige mtime ist kein Freispruch. Zweitens verändern Kopiervorgänge und manche Werkzeuge Zeitstempel. Deshalb gilt: Dateizeiten sind Hinweise, Logeinträge von außerhalb sind Belege.

Typische Fehler und wie Sie sie vermeiden

Die häufigsten Fehler sind unspektakulär. Die Zeitleiste wird erst am Ende aus dem Gedächtnis rekonstruiert, statt laufend geführt zu werden. Einträge enthalten Schlussfolgerungen statt Beobachtungen, etwa „Angreifer kam über das Formular“ statt „POST-Anfrage auf das Formular, danach neue Datei“. Und Belege fehlen, weil niemand notiert hat, aus welcher Logdatei und welcher Zeile ein Eintrag stammt.

Bestimmen Sie deshalb eine Person, die die Zeitleiste führt, und tragen Sie Ereignisse ein, sobald sie auftreten. Schlussfolgerungen gehören in eine eigene Spalte oder in den Bericht, nicht in die Beobachtung.

Behandeln Sie die Zeitleiste außerdem als vertrauliches Dokument. Sie enthält oft IP-Adressen, Benutzernamen und Hinweise auf Schwachstellen. Legen Sie fest, wer sie lesen und ändern darf, und bewahren Sie frühere Stände auf. Wenn sich eine Einschätzung ändert, etwa weil ein neuer Logauszug auftaucht, wird die alte Zeile nicht überschrieben, sondern ergänzt. So bleibt nachvollziehbar, was zu welchem Zeitpunkt bekannt war und auf welcher Grundlage entschieden wurde.

Wie hilft PHP SOS konkret?

• Wir führen die Zeitleiste ab dem ersten Kontakt laufend und in UTC, mit Quelle und Beleg zu jedem Eintrag.
• Wir werten externe Logs, Serverlogs und Dateisystem gemeinsam aus und kennzeichnen jede Aussage als belegt, wahrscheinlich oder unbekannt.
• Bei Bedarf übernehmen wir mit spezialisierten Partnern die IT-Forensik für eine gerichtsverwertbare Auswertung.
• Wir übergeben die Zeitleiste als Teil eines Berichts für Geschäftsführung, Datenschutz und Versicherung.

Häufige Fragen

Quellen

• php.net: Sicherheitsmeldungen zu PHP2Shell
• DSGVO Art. 33: Meldung an die Aufsichtsbehörde
• BSI: Hinweise zu IT-Sicherheitsvorfällen