Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
Dwell time er perioden fra angriberens første adgang til miljøet til hændelsen blev opdaget. Starttidspunktet fastlægges ud fra det tidligste spor, der med rimelig sikkerhed kan knyttes til angrebet, men det er altid et “senest”-tidspunkt: Angriberen var inde senest da, men kan have været det før. Hvor meget før afhænger af, hvor langt tilbage kilderne rækker. Det skal fremgå tydeligt af enhver konklusion om dwell time.
Haster det? Hver dag uden sikring flytter den ældste bevarede logpost frem, og Entra ID-loginlogs rækker kun 7 eller 30 dage tilbage efter licens. Se akut forensisk sikring; hastesager koster ekstra.
Hvorfor tidspunktet betyder noget
Starttidspunktet har praktiske konsekvenser uden for den tekniske analyse:
- Forsikring. Dækningen kan afhænge af, hvornår skaden indtrådte i forhold til policens periode og eventuelle ændringer i betingelser. Et starttidspunkt før policens begyndelse kan blive et stridspunkt.
- Persondatabrud. Omfanget af berørte data og perioden for mulig adgang afhænger af, hvor længe angriberen var inde.
- Leverandøransvar. Hvis en leverandør overtog driften på et bestemt tidspunkt, kan det blive afgørende, om kompromitteringen begyndte før eller efter.
- Backup. Gendannelse fra et tidspunkt, hvor angriberen allerede var inde, kan genindføre bagdøre.
Den juridiske vægtning af tidspunktet hører ikke til i den tekniske analyse. Men analysen skal være præcis nok til, at andre kan foretage den.
Metoden
1. Fastlæg ankerpunkter
Start med de hændelser, der med sikkerhed er ondsindede: krypteringen, et kendt ondsindet værktøj, et login fra en adresse, der er knyttet til angrebet. De giver en første tidslinje. Se Tidslinjeanalyse.
2. Udled indikatorer
Fra ankerpunkterne udledes indikatorer: kontonavne, IP-adresser, værktøjers hashværdier og filnavne, navne på planlagte opgaver og tjenester, domæner og brugeragenter. Det er dem, der søges efter bagud i tid.
3. Søg baglæns i alle kilder
Søg i alle tilgængelige kilder efter indikatorerne, så langt tilbage som kilderne rækker. Typiske kilder og deres rækkevidde:
- Centrale logs (SIEM) · Den opbevaring, der er sat op, ofte måneder
- Cloudlogs · Afhænger af tjeneste og licens
- Lokale hændelseslogs · Timer til uger, afhængigt af logstørrelse og aktivitet
- Filsystem og registreringsdatabase · Kan række år tilbage
- Backup · Så langt tilbage som gendannelsespunkterne
Entra ID-loginlogs er et vigtigt eksempel. De har en begrænset opbevaring i portalen, på tidspunktet for gennemgangen (oktober 2026) 7 dage uden betalt Entra-licens og 30 dage med P1 eller P2, og et login med en kompromitteret konto, der ligger uden for den, kan ikke findes, medmindre logs er sendt videre. Se Entra ID-loginlogs.
4. Brug backuppen som tidsmaskine
Gamle gendannelsespunkter kan bruges til at undersøge, om et ondsindet værktøj, en planlagt opgave eller en uautoriseret konto fandtes på et bestemt tidspunkt. Ved at gendanne en server fra flere tidspunkter til et isoleret miljø og undersøge, hvornår artefakterne første gang optræder, kan starttidspunktet ofte indsnævres, også selv om logs er væk. Metoden er beskrevet i Gendannelse fra backup til forensisk brug.
5. Angiv intervallet
Resultatet er ikke ét tidspunkt, men et interval: det seneste tidspunkt, hvor der med rimelighed kan siges at være tegn på, at miljøet ikke var kompromitteret, og det tidligste tidspunkt, hvor der er et spor efter angrebet. Kan det første ikke fastlægges, siger konklusionen kun “senest”, og det skal stå sådan.
Fejlkilder
Logrotation som falsk startpunkt
Det hyppigste problem er, at det tidligste spor ligger lige ved grænsen for logopbevaringen. Så er det ikke et starttidspunkt, men en kildegrænse. Sammenhold altid det tidligste spor med kildens rækkevidde. Ligger de tæt, er det en indikation af, at forløbet kan være ældre. Se Logfiler og logrotation.
Initial adgang og hands-on aktivitet er to ting
Mange angreb har en første fase, hvor der opnås adgang, fx via en phishingmail eller en sårbarhed, og en senere fase, hvor nogen aktivt bevæger sig rundt. Imellem kan der gå uger, og den første adgang kan være solgt videre. Skeln mellem tidspunktet for første adgang og tidspunktet for første aktive handling.
Ikke-relaterede hændelser
En gammel infektion med anden malware, en tidligere phishingkampagne eller en sårbarhedsscanning kan ligge tidligere end angrebet uden at have noget med det at gøre. Kræv en konkret forbindelse, fx samme konto, samme værktøj eller samme infrastruktur, før en tidlig hændelse indgår i forløbet.
Ure og tidszoner
Tidsstempler fra servere med forkerte ure kan flytte et spor dage. Kontrollér urene på de systemer, der leverer de tidligste spor, og notér afvigelser.
Tidsstempler, som angriberen kan påvirke
Filsystemets tidsstempler kan ændres, og angribere gør det nogle gange for at få værktøjer til at ligne gamle systemfiler. Et tidligt oprettelsestidspunkt på en ondsindet fil er derfor ikke et starttidspunkt i sig selv. Det skal bekræftes af en kilde, angriberen ikke kunne ændre, fx $UsnJrnl, Amcache, en central log eller backuppen.
Flere adgange og flere aktører
Et miljø kan være kompromitteret flere gange. Én aktør kan have haft adgang i lang tid via en gammel bagdør, mens en anden kom ind for nylig og krypterede. Eller samme aktør kan have mistet adgangen, fordi en adgangskode blev skiftet, og senere fået den igen ad en anden vej. Det betyder, at tidslinjen kan have flere begyndelser.
Vær derfor varsom med at forbinde alle tidlige fund i ét forløb. Gruppér sporene efter infrastruktur, værktøjer og konti, og vurder for hver gruppe, om den hører til den hændelse, der undersøges. Hvis to forløb overlapper, kan det have stor betydning for både forsikring og ansvar, og det bør fremgå af rapporten, også selv om det kun er en mulighed.
Opdagelsestidspunktet er også en kilde til tvivl
Dwell time har to ender. Opdagelsestidspunktet virker enkelt, men er det sjældent. Var det, da den første alarm blev udløst i EDR, da en bruger ringede til supporten, eller da IT-afdelingen erkendte, at der var tale om et angreb? Alle tre kan være relevante i forskellige sammenhænge. Notér dem hver for sig med kilde, så læseren selv kan se, hvilket der er brugt.
Hvordan konklusionen formuleres
En god formulering indeholder tre ting: det tidligste spor med kilde og tidspunkt, kildernes rækkevidde, og en vurdering af, om forløbet kan være begyndt før. For eksempel: Det tidligste spor er et login med kontoen X fra adressen Y på et bestemt tidspunkt i loginloggen. Loggen rækker kun to dage længere tilbage. Det kan derfor ikke udelukkes, at kontoen var kompromitteret før. Backup fra en måned tidligere viser ingen af de kendte artefakter på serveren Z.
Brug en fast skala for sikkerhed, og forklar den. Se Konklusionsgrader i forensik.
Sammenhæng med indgangsvejen
Dwell time og indgangsvej hænger tæt sammen. Det tidligste spor er ofte også det, der peger på indgangen. Men de skal behandles hver for sig, fordi et sikkert tidspunkt kan foreligge uden en sikker indgang og omvendt. Se Indgangsvejen: sådan underbygges konklusionen.
Dokumentation
Rapporten bør indeholde en tabel over de undersøgte kilder med rækkevidde og resultat, de anvendte indikatorer, de tidligste fund i hver kilde, eventuelle gendannelser fra backup med tidspunkt og resultat, og den samlede vurdering af intervallet med tydelig angivelse af usikkerheden. Beskriv også, hvilke indikatorer der blev søgt efter uden resultat. Fraværet af et spor i en kilde, der dækker perioden, er et lige så vigtigt resultat som et fund.
Kilder og versioner
- Microsoft Learn: opbevaring af data i Microsoft Entra
- NIST SP 800-92: vejledning i logstyring
- NIST SP 800-61 Rev. 3: håndtering af sikkerhedshændelser
Senest gennemgået: oktober 2026.
Næste skridt
- NIS2: varsling og rapporter set fra logkilderne
- Overdragelse fra IR-team til sagkyndig
- Bevissikringstrin i jeres IR-playbooks
Del af: Undersøgelse efter et hackerangreb
Læs også: Backup-logs: hvornår blev backuppen slettet eller ændret? · Cyberforsikringen: de tekniske leverancer, forsikringsselskabet beder om
→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
