Kort sagt: En tidslinje for en it-hændelse ordner alle observationer, beslutninger og foranstaltninger kronologisk i en ensartet tidszone, ideelt UTC. Hver linje angiver kilde, observation, bevis og en vurdering som dokumenteret, sandsynligt eller ukendt. Sådan opstår et forståeligt billede af, hvornår angriberen var i systemet, hvad han kunne nå, og hvornår I havde kendskab til det.
Hvorfor alle til sidst spørger om hvornår
Efter en hændelse kommer spørgsmålene fra alle sider. Databeskyttelsesrådgiveren vil vide, siden hvornår personoplysninger var tilgængelige. Forsikringsselskabet spørger, hvornår skaden blev opdaget og anmeldt. Ledelsen vil vide, om sårbarheden allerede var åben før den sidste opdatering. Alle disse spørgsmål har noget til fælles: De handler om tidspunkter.
Uden tidslinje besvarer hver enkelt disse spørgsmål ud fra hukommelsen, og svarene modsiger hinanden. Med en ordentligt ført tidslinje findes der et fælles grundlag, som alle involverede kan henholde sig til. Den er samtidig skelettet til slutrapporten.
Ved PHP2Shell er tidslinjen særligt sigende, fordi de offentlige nøgledata er godt dokumenteret. De kan lægges som ankerpunkter ved siden af jeres egne observationer. Hele rækkefølgen af de offentlige begivenheder beskriver vejledningen PHP2Shell: Kronologien.
Opbygningen: Hvilke kolonner en tidslinje har brug for
En tabel er nok, uanset om det er i et regneark eller et fælles dokument. Vigtige er faste kolonner, der udfyldes for hver linje. Mønstret nedenfor viser de offentlige PHP2Shell-nøgledata som anker og derunder typiske egne poster i form af pladsholdere:
| Tid (UTC) | Kilde | Observation | Bevis | Vurdering |
|---|---|---|---|---|
| 17.10.2026 | Mediernes rapporter | første observerede angrebsforsøg på PHP2Shell | pressemeddelelse | dokumenteret som mediernes rapport |
| 20.10.2026 | php.net | forhåndsvarsling af sikkerhedsopdateringerne | meddelelse på php.net | dokumenteret |
| 21.10.2026, 14:00 | php.net | offentliggørelse af 8.5.12, 8.4.27, 8.3.36, 8.2.35 | meddelelse på php.net | dokumenteret |
| egen tid | access-log | ophobning af 500-fejl på normale sider | logudtræk, linjenummer | sandsynligvis relevant |
| egen tid | filsystem | ny PHP-fil i upload-mappen | kopi med kontrolsum | dokumenteret, tidspunkt usikkert |
| egen tid | internt | hændelse opdaget, ledelsen informeret | mail, samtalenotat | dokumenteret |
| egen tid | internt | opdatering indspillet, alle workers genstartet | pakkelog, procesliste | dokumenteret |
Kolonnen Vurdering er den vigtigste del. Den adskiller, hvad der er bevist, hvad der forekommer plausibelt, og hvad der forbliver åbent. Senere læsere ser dermed med det samme, hvor tidslinjen bærer, og hvor der er huller.
Tidslinje for en it-hændelse: Saml kilderne
Posterne stammer fra mange kilder, som hver har egne formater og tidszoner. Gå frem i denne rækkefølge:
- Fastlæg tidszonen: Før alt i UTC. Omstillingen til vintertid den 25.10.2026 forskyder tyske lokaltider midt i tidsrummet med en time. Den, der blander lokaltider, forskyder begivenheder uden at mærke det.
- Kontrollér urene: Gik serverens ur rigtigt? En sammenligning med en kendt begivenhed, f.eks. jeres eget login, viser afvigelser.
- Eksterne kilder først: Logs fra CDN, WAF, hostingudbyder eller firewall ligger uden for serveren og er svære at manipulere. De danner skelettet.
- Supplér med serverlogs: Webserver, PHP-FPM, logins, systemjournal. Metoden hertil beskriver Analysér webserverlogs efter et angreb.
- Placér filsystemet: Tilføj tidsstempler for nye og ændrede filer som fingerpeg.
- Indfør interne begivenheder: Hvornår blev noget opdaget, hvem blev informeret, hvilken beslutning faldt hvornår?
Hvad filernes tidsstempler afslører, og hvad ikke
Linux gemmer for hver fil flere tidspunkter, blandt andet den seneste ændring af indholdet (mtime) og den seneste ændring af metadata (ctime). Begge kan udlæses læsende, her som en liste over de PHP-filer, der er ændret siden en skæringsdato, sorteret efter tid i UTC:
# Indholdsændringer siden 17.10.2026, sorteret, i UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Alle tidsstempler for en enkelt fil
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Arbejd her kun på en kopi eller et sikret aftryk, som beskrevet under Sikr beviser, før I sætter serveren op påny. Hav to grænser i erindring. For det første kan en angriber med simple midler sætte en fils ændringsdato tilbage; en upåfaldende mtime er ikke nogen frifindelse. For det andet ændrer kopiering og nogle værktøjer tidsstempler. Derfor gælder: Filtider er fingerpeg, logposter udefra er beviser.
Indfør det tidspunkt, hvor jeres virksomhed fik kendskab til et muligt databrud. Efter art. 33 GDPR begynder 72-timersfristen for en anmeldelse som udgangspunkt med kendskabet. Vurderingen hører hjemme hos jeres databeskyttelsesrådgiver eller en advokat.
Typiske fejl, og hvordan I undgår dem
De hyppigste fejl er upåfaldende. Tidslinjen rekonstrueres først til sidst ud fra hukommelsen i stedet for at blive ført løbende. Posterne indeholder slutninger i stedet for observationer, f.eks. "angriberen kom ind via formularen" i stedet for "POST-forespørgsel til formularen, derefter ny fil". Og beviser mangler, fordi ingen har noteret, hvilken logfil og hvilken linje en post stammer fra.
Udpeg derfor en person, der fører tidslinjen, og indfør begivenheder, så snart de indtræffer. Slutninger hører hjemme i en egen kolonne eller i rapporten, ikke i observationen.
Behandl desuden tidslinjen som et fortroligt dokument. Den indeholder ofte IP-adresser, brugernavne og henvisninger til svagheder. Fastlæg, hvem der må læse og ændre den, og opbevar tidligere versioner. Hvis en vurdering ændrer sig, f.eks. fordi et nyt logudtræk dukker op, overskrives den gamle linje ikke, men suppleres. Så forbliver det forståeligt, hvad der var kendt hvornår, og på hvilket grundlag der blev besluttet.
Hvordan hjælper PHP SOS konkret?
- Vi fører tidslinjen løbende fra første kontakt og i UTC, med kilde og bevis for hver post.
- Vi analyserer eksterne logs, serverlogs og filsystem samlet og mærker hvert udsagn som dokumenteret, sandsynligt eller ukendt.
- Efter behov overtager vi sammen med specialiserede partnere it-forensikken til en analyse, der kan bruges i retten.
- Vi overdrager tidslinjen som en del af en rapport til ledelse, databeskyttelse og forsikring.
Ofte stillede spørgsmål
Hvorfor har jeg brug for en tidslinje efter en sikkerhedshændelse?
Den ordner alle observationer i en rækkefølge og viser, hvornår angriberen var i systemet, hvad han kunne nå, og hvornår I fik kendskab til det. Disse oplysninger har databeskyttelsesrådgivere, forsikringsselskaber, myndigheder og ledelsen brug for til deres beslutninger.
I hvilken tidszone skal jeg føre tidslinjen?
Ensartet i UTC. Servere, tjenester og meddelelser bruger forskellige tidszoner, og omstillingen til vintertid i slutningen af oktober forskyder desuden lokaltiderne. Den, der omregner alt til UTC og kun tilføjer lokaltiden som supplement, undgår fejl ved afstemningen.
Kan jeg stole på filernes tidsstempler?
Kun i begrænset omfang. En fils ændringsdato kan forfalskes med simple midler. Mere pålidelige er poster i logs, især i logs uden for den berørte server. Filtidsstempler er fingerpeg, som bør bekræftes af andre kilder.
Hvad hører ud over tekniske hændelser med i tidslinjen?
Også beslutninger og kommunikation: hvornår hændelsen blev opdaget, hvem der blev informeret, hvornår serveren gik af nettet, hvornår der blev patchet. Netop tidspunktet for kendskabet er vigtigt for anmeldelsesfrister.