Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
En indgrebslog er en løbende, tidsstemplet optegnelse over alle handlinger, som forsvarerne foretager på systemer under en hændelse: hvem gjorde hvad, på hvilket system, hvornår, med hvilket værktøj og hvorfor. Den er nødvendig, fordi forsvarernes handlinger efterlader spor i de samme logs og artefakter som angriberens. Uden indgrebsloggen kan ingen bagefter afgøre, om en slettet konto, en ny planlagt opgave eller et kørt PowerShell-script stammer fra angriberen eller fra IT-afdelingen.
Hvorfor det er et teknisk problem
Næsten alle IR-handlinger skriver til de kilder, en senere analyse bygger på:
- Login med en administratorkonto giver logonhændelser, i Windows typisk Event ID
4624og4672på målsystemet. - Fjernkommandoer via EDR eller PowerShell Remoting giver procesoprettelser, scriptblok-logning og netværksforbindelser.
- Nulstilling af adgangskoder, deaktivering af konti og ændring af gruppemedlemskaber skriver til domænecontrollerens log og til Entra ID’s auditlog.
- Kørsel af indsamlingsværktøjer opretter Prefetch-filer, Amcache-poster og filer på disken.
- Sletning af ondsindede filer og planlagte opgaver fjerner selve artefakterne.
En analytiker, der senere bygger en tidslinje, ser kun hændelserne. Konteksten skal komme fra indgrebsloggen. Se Logkorrelation for, hvordan hændelser kobles på tværs af kilder.
Felterne
En brugbar indgrebslog har mindst disse felter for hver handling:
- Tidspunkt · Dato og klokkeslæt med tidszone og tidskilde
- Udført af · Navn og den konto, der blev brugt
- System · Værtsnavn, IP-adresse, tenant eller konto-id
- Handling · Hvad der konkret blev gjort, fx kommando eller ændring
- Værktøj · Program og version, fx EDR-konsol eller script
- Formål · Hvorfor handlingen blev foretaget
- Resultat · Hvad der kom ud af det, fx filnavn og hashværdi
- Godkendt af · Ved større indgreb: hvem der besluttede det
Det vigtigste felt er den konto, der blev brugt. Bruger IR-teamet en dedikeret konto til indgreb, kan alle dens hændelser filtreres fra eller markeres i analysen. Bruger alle den samme domæneadministrator, som angriberen måske også har misbrugt, er adskillelsen næsten umulig. En dedikeret, navngiven konto pr. person er derfor den mest effektive enkeltforanstaltning.
En skabelon med felterne ligger på Skabelon: handlingslog.
Tid er den svage led
Indgrebsloggen skal kunne lægges oven på systemernes egne logs. Det kræver, at tidspunkterne passer. Tre ting går ofte galt:
- Tidspunkter skrives efter hukommelsen eller afrundes til nærmeste kvarter.
- Personen bruger sit ur eller telefonens tid, mens systemerne bruger UTC.
- Handlinger udført via en central konsol registreres med konsollens tid, ikke målsystemets.
Notér derfor tidskilden i loggens hoved, fx “lokal dansk tid fra arbejdsstationens NTP-synkroniserede ur”, og angiv tidspunkter til minuttet. Ved vigtige handlinger kan tidspunktet bekræftes bagefter mod systemets egen hændelse, og koblingen kan noteres.
Hvad der logges, og hvad der ikke behøver
Alt, der ændrer et system eller henter data fra det, skal med. Det omfatter også de handlinger, der virker harmløse, som at åbne en mappe via fjernskrivebord eller køre en enkelt kommando for at se kørende processer. Et RDP-login alene ændrer allerede registreringsdatabasen, opretter en profil, hvis den ikke findes, og skriver til flere logs.
Rene læsehandlinger i en central konsol, fx søgninger i SIEM, behøver ikke registreres som indgreb på systemerne, men det er god praksis at notere de søgninger, der førte til en beslutning. Så kan beslutningsgrundlaget rekonstrueres.
Værktøjernes egne auditlogs som støtte
Mange af de værktøjer, IR-teamet bruger, fører selv en auditlog: EDR-konsollen registrerer, hvem der isolerede en maskine eller startede en live response-session, identitetsplatformen registrerer nulstillinger, og fjernsupportværktøjer registrerer sessioner. Disse logs erstatter ikke indgrebsloggen, fordi de ikke indeholder formålet med handlingen, og fordi de sjældent dækker alle systemer. Men de er en uafhængig kontrol af den.
Eksportér derfor værktøjernes auditlogs ved hændelsens afslutning, før opbevaringen udløber, og gem dem med hashværdi. Ved gennemgangen bagefter sammenholdes de med indgrebsloggen post for post. Handlinger, der står i værktøjets log, men ikke i indgrebsloggen, skal forklares. Det er ofte her, de glemte automatiske indgreb dukker op.
Beslutninger og indgreb er to forskellige logs
Ledelsens beslutninger, fx at betale, at lukke ned eller at underrette kunder, hører til i en beslutningslog. Indgrebsloggen er teknisk og handler om handlinger på systemer. De to bør krydshenvise, men holdes adskilt. Den ledelsesmæssige side er beskrevet i Skabelon: ledelsens beslutningslog.
Flere hold og eksterne leverandører
Ved større hændelser arbejder flere hold samtidig: intern IT, en driftsleverandør, et eksternt IR-firma og måske cloududbyderens support. Hvert hold fører ofte sin egen log, og det er uproblematisk, så længe der er én samlet log, der henviser til de andre, og så længe tidskilderne er kendte. Aftal tidligt:
- hvem der fører den samlede log,
- hvordan de enkelte hold rapporterer deres handlinger ind,
- hvilke konti hvert hold bruger,
- hvor ofte loggen samles og låses.
Den eksterne leverandørs log er en del af dokumentationen. Bed om den i et format, der kan arkiveres, ikke kun som et uddrag i den endelige rapport.
Integritet
Indgrebsloggen er selv et bevis og skal behandles som et. Før den i et system, der registrerer, hvem der skriver hvad og hvornår, fx et ticketsystem eller et delt dokument med versionshistorik. Lås loggen ved hændelsens afslutning, beregn en hashværdi af den eksporterede version, og opbevar den sammen med de øvrige beviser. Rettelser foretages som nye poster, ikke ved at overskrive gamle. Kæden fra loggen til beviserne følger de samme principper som kæden af ansvar (chain of custody), og feltniveauet for bevislogs er beskrevet i Chain of custody-loggen.
Typiske huller
- De første timer mangler, fordi loggen først blev startet, da hændelsen var erkendt som alvorlig.
- Handlinger udført af leverandørens automatik, fx en playbook, der isolerer maskiner, er ikke registreret.
- Kommandoer er beskrevet i ord, men ikke ordret.
- Filer hentet til analyse står uden hashværdi og uden angivelse af, hvor de blev gemt.
Er de første timer gået tabt, så rekonstruér dem hurtigst muligt fra chatbeskeder, tickets og konsollernes egne auditlogs, og markér posterne som rekonstruerede. Angiv for hver rekonstrueret post, hvilken kilde den bygger på. Det er langt bedre end et hul, og det er ærligt over for den, der senere skal vurdere loggen.
Hvad indgrebsloggen kan bevise
Loggen viser, hvad forsvarerne mener, de gjorde. Dens styrke kommer af, at den kan sammenholdes med systemernes egne logs, så hver post bekræftes af en uafhængig kilde. Ved uoverensstemmelser er systemlogen som regel den mest pålidelige, men uoverensstemmelsen skal forklares i rapporten. En indgrebslog, der passer med systemlogs på de vigtige punkter, er en af de stærkeste måder at vise, at analysen har skilt angriberens spor fra forsvarernes. Hvordan den spiller sammen med resten af hændelseshåndteringen, er beskrevet i Forensic eller incident response?
Kilder og versioner
- NIST SP 800-61 Rev. 3: Incident Response Recommendations
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
- Microsoft Learn: Event 4672, special privileges assigned to new logon
Senest gennemgået: oktober 2026.
Næste skridt
- Indgangsvejen: sådan underbygges konklusionen
- Dataudtræk før kryptering: spor efter eksfiltration
- Cyberforsikringen: de tekniske leverancer, forsikringsselskabet beder om
Del af: Undersøgelse efter et hackerangreb
Læs også: Forensic eller incident response? Forskellen og samspillet · Isolering og genopsætning: hvad sker der med artefakterne?
→ 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
