Bevissikringstrin i jeres IR‑playbooks

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

De fleste IR-playbooks er skrevet for at stoppe en hændelse og genoprette driften. Bevissikring står ofte som én linje: “sikr relevante logs”. Det er for lidt. Hvis en hændelse kan ende i en tvist, et forsikringskrav eller en sag mod en leverandør, skal playbooken angive præcist, hvilke kilder der sikres før hvilke indgreb, hvem der gør det, og hvordan det dokumenteres. Det tager få minutter ekstra under hændelsen og kan være afgørende bagefter.

Forskellen på incident response og forensic, og hvor de mødes, er beskrevet i forensic eller incident response?. Denne artikel er den praktiske udmøntning: konkrete trin, der kan skrives direkte ind i eksisterende playbooks.

Fælles trin i alle playbooks

Uanset hændelsestype bør disse trin stå i starten af playbooken:

Start indgrebsloggen. Fra første minut: tidspunkt, system, handling, udførende, med en angivet tidskilde.
Afklar sagsrisikoen. Kan hændelsen føre til et krav, en tvist eller en personalesag? Hvis ja eller måske, aktivér de udvidede sikringstrin og overvej at koble en uvildig på.
Frys opbevaringen. Forlæng opbevaringen af relevante logs, eller eksportér dem, før de roterer.
Sikr før oprydning. Ingen sletning, nulstilling eller geninstallation, før tilstanden er dokumenteret, medmindre driftshensyn kræver det, og så med en notat om beslutningen.
Hash og opbevar. Alle eksporter hashes og lægges et sted med begrænset og logget adgang.

Rækkefølgen inden for sikringen følger flygtigheden: det, der forsvinder hurtigst, først. Princippet er gennemgået i flygtighedsorden.

Playbook: kompromitteret mailkonto og BEC

Ved overtagne mailkonti er det oprydningen, der oftest ødelægger sporene. Nulstilles adgangskoden, og fjernes reglerne, før de er dokumenteret, kan det bagefter være svært at vise, hvad angriberen gjorde.

Sikr før inddæmning:

loginloggen for kontoen for hele den relevante periode, eksporteret i fuldt format
indbakkeregler, videresendelse og delegeringer på postkassen
registrerede MFA-metoder, enheder og app-samtykker
auditposter for postkassen, herunder hvilke mails der er tilgået, hvis licensen giver det
message trace for udgående mails fra kontoen i perioden

Inddæm derefter: tilbagekald sessioner, nulstil adgangskode, fjern regler og ukendte metoder. Notér hvert trin med tidspunkt, så det kan genfindes i auditloggen. Den fulde undersøgelse er beskrevet i BEC-undersøgelse i Microsoft 365. På tidspunktet for gennemgangen (oktober 2026) er MailItemsAccessed en del af standardauditloggen og slået til som standard for brugere med E3- eller E5-licens, og standardauditposter gemmes i 180 dage.

Playbook: ransomware

Ved ransomware er presset for at genoprette størst, og det er også her, sikringen oftest springes over. Det behøver ikke ske, hvis trinnene er aftalt på forhånd.

Sikr før genopretning:

RAM fra mindst et par berørte maskiner, der stadig kører, hvis det kan nås
en disk- eller VM-kopi af repræsentative berørte systemer, herunder det formodede indgangspunkt
løsesumsnoten, en krypteret fil og dens filnavn
EDR-telemetri, firewall- og VPN-logs for perioden før krypteringen
backupsystemets logs, særligt sletninger og ændringer af opbevaring
logs fra domænecontrollere

Genopretning fra backup kan ske parallelt, når kopierne er taget. Krypterede servere skal ikke slettes, selv om de er ubrugelige; de kan rumme spor efter angriberens værktøjer og adgangsvej. Fremgangsmåden er beskrevet i ransomware: bevissikring parallelt med genopretning.

Playbook: insider og datatyveri

Ved mistanke om, at en medarbejder har taget data med, er playbooken en anden. Der er ingen angriber at stoppe, men der er en person, der kan slette spor, hvis vedkommende opdager undersøgelsen.

Sikr diskret og før konfrontation:

auditlogs for filaktivitet i SharePoint, OneDrive og filservere
message trace og vedhæftninger til private adresser
proxy-, DLP- og firewalllogs for uploads til private tjenester
USB-logs fra EDR, hvis de findes
en forensisk kopi af computeren, planlagt til et tidspunkt, hvor den kan tages uden varsel

Bloker ikke kontoen, før sikringen er afklaret med ledelsen, og læs ikke indhold uden mandat. Den tekniske undersøgelsesplan er beskrevet i data taget ved fratræden.

Playbook: lækket nøgle eller token

Når en API-nøgle, et adgangstoken eller en hemmelighed er lækket, er den naturlige reaktion at rotere den med det samme. Det er rigtigt, men før eller samtidig skal brugen af nøglen dokumenteres.

Sikr:

cloudplatformens auditlog for alle kald med nøglen, fx CloudTrail eller Azure Activity Log
hvor nøglen blev fundet: repository, commit, log eller fil, med tidspunkt og hashværdi
tidspunkt for oprettelse, sidste brug og rotation
faktureringsdata, hvis misbruget har skabt omkostninger

Rotér derefter, og notér den nye nøgles identifikator, så gamle og nye kald kan adskilles.

Playbook: kompromitteret endpoint og fjernadgang

Når en enkelt computer eller server viser tegn på ukendt fjernadgang eller skadelig kode, er den typiske reaktion at isolere og geninstallere. Isolering via EDR er som regel den bedste første handling, fordi maskinen forbliver tændt, og hukommelsen bevares.

Sikr efter isolering og før geninstallation:

RAM, mens maskinen stadig kører
en forensisk kopi af disken
EDR-alarmer og telemetri for maskinen, herunder procestræer og netværksforbindelser
logs fra fjernadgangsværktøjer og RMM, både lokalt og i leverandørens konsol
autostartpunkter, planlagte opgaver og tjenester, dokumenteret før de fjernes

Er maskinen allerede slukket, så lad den være slukket, og tag en diskkopi. Beslutningen mellem at slukke, isolere og lade køre er gennemgået i sluk, isolér eller lad den køre?.

Hvem sikrer?

Playbooken skal angive, hvem der udfører sikringen. I mindre organisationer er det ofte den samme person, der inddæmmer. Det går, så længe handlingerne logges. Men når der er risiko for, at egen IT eller MSP’en selv bliver part, fx fordi en kunde retter kritik mod driften, bør sikringen udføres af en, der ikke skal forklare egne handlinger. Skriv i playbooken, hvornår den beslutning skal træffes, og hvem der kontaktes.

Hvordan en uvildig arbejder ved siden af IR-teamet efter et angreb, er beskrevet under undersøgelse efter hackerangreb. Nielco IT har erfaring med incident response og hackerangreb og sikrer uvildigt ved siden af den IR-leverandør, organisationen allerede bruger.

Test playbooken

Et sikringstrin, der aldrig er afprøvet, virker sjældent første gang. Kør en øvelse, hvor de konkrete eksporter faktisk udføres:

Kan loginloggen eksporteres fuldt for 30 dage, og hvor lang tid tager det?
Har den, der skal sikre, de nødvendige rettigheder?
Findes der et sted at lægge eksporterne med begrænset adgang?
Ved alle, hvor indgrebsloggen ligger?

Notér resultatet og ret playbooken. Gentag, når licenser, værktøjer eller leverandører skifter.

Typiske mangler i playbooks

Bevissikring står efter inddæmning i stedet for før eller parallelt.
Der står “sikr logs” uden at angive hvilke, hvordan og hvor længe de findes.
Ingen indgrebslog, eller loggen føres i en chat, der ikke eksporteres.
Ingen beslutningspunkt for, hvornår en uvildig skal ind.
Ingen angivelse af, hvem der ejer de sikrede data bagefter.
Eksportvejene forudsætter rettigheder eller licenser, som organisationen ikke har.
Playbooken er skrevet til et værktøj, der siden er udskiftet, og ingen har opdateret sikringstrinnene.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Overdragelse fra IR-team til sagkyndig · Hvornår SOC’en skal kalde en uvildig ind

→ 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

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik