# Die Zeitleiste eines Vorfalls erstellen

> Zeitleiste eines IT-Vorfalls erstellen: Quellen und Zeitzonen richtig nutzen und jede Aussage als belegt, wahrscheinlich oder unbekannt kennzeichnen.

Quelle: https://phpsos.de/blog/zeitleiste-eines-vorfalls/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**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](https://phpsos.de/ratgeber/php2shell-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:

| Zeit (UTC) | Quelle | Beobachtung | Beleg | Bewertung |
|---|---|---|---|---|
| 17.10.2026 | Medienberichte | erster beobachteter Angriffsversuch auf PHP2Shell | Pressebericht | belegt als Medienbericht |
| 20.10.2026 | php.net | Vorankündigung der Sicherheitsupdates | Meldung auf php.net | belegt |
| 21.10.2026, 14:00 | php.net | Veröffentlichung von 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Meldung auf php.net | belegt |
| eigene Zeit | Access-Log | Häufung von Fehlern 500 auf normale Seiten | Logauszug, Zeilennummer | wahrscheinlich relevant |
| eigene Zeit | Dateisystem | neue PHP-Datei im Upload-Ordner | Kopie mit Prüfsumme | belegt, Zeitpunkt unsicher |
| eigene Zeit | intern | Vorfall bemerkt, Geschäftsführung informiert | Mail, Gesprächsnotiz | belegt |
| eigene Zeit | intern | Update eingespielt, alle Worker neu gestartet | Paketlog, Prozessliste | belegt |

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](https://phpsos.de/ratgeber/logfiles-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:

```bash
# 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](https://phpsos.de/blog/beweise-sichern-vor-neuinstallation/) 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.

> **Wichtig:**
> Tragen Sie den Zeitpunkt ein, an dem Ihr Unternehmen von einer möglichen Datenpanne erfahren hat. Nach Art. 33 DSGVO beginnt die 72-Stunden-Frist für eine Meldung grundsätzlich mit der Kenntnis. Die Bewertung gehört zu Ihrem Datenschutzbeauftragten oder einem Anwalt.

## 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](https://phpsos.de/leistungen/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

**Wozu brauche ich eine Zeitleiste nach einem Sicherheitsvorfall?**  
Sie ordnet alle Beobachtungen in eine Reihenfolge und zeigt, wann der Angreifer im System war, was er erreichen konnte und wann Sie davon erfahren haben. Diese Angaben brauchen Datenschutzbeauftragte, Versicherer, Behörden und die Geschäftsführung für ihre Entscheidungen.

**In welcher Zeitzone sollte ich die Zeitleiste führen?**  
Einheitlich in UTC. Server, Dienste und Meldungen verwenden unterschiedliche Zeitzonen, und die Umstellung auf Winterzeit Ende Oktober verschiebt Ortszeiten zusätzlich. Wer alles in UTC umrechnet und die Ortszeit nur ergänzt, vermeidet Fehler beim Abgleich.

**Kann ich mich auf die Zeitstempel von Dateien verlassen?**  
Nur eingeschränkt. Das Änderungsdatum einer Datei lässt sich mit einfachen Mitteln fälschen. Zuverlässiger sind Einträge in Logs, besonders in Logs außerhalb des betroffenen Servers. Dateizeitstempel sind Hinweise, die durch andere Quellen bestätigt werden sollten.

**Was gehört außer technischen Ereignissen in die Zeitleiste?**  
Auch Entscheidungen und Kommunikation: wann der Vorfall bemerkt wurde, wer informiert wurde, wann der Server vom Netz ging, wann gepatcht wurde. Gerade der Zeitpunkt der Kenntnis ist für Meldefristen wichtig.

## Quellen

- [php.net: Sicherheitsmeldungen zu PHP2Shell](https://www.php.net/)
- [DSGVO Art. 33: Meldung an die Aufsichtsbehörde](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [BSI: Hinweise zu IT-Sicherheitsvorfällen](https://www.bsi.bund.de/)