Ransomware: bevissikring parallelt med genopretning

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

Efter et ransomwareangreb skal driften tilbage, men de systemer, der genoprettes, er de samme, som indeholder sporene efter angrebet. Løsningen er ikke at vælge mellem de to, men at køre dem parallelt: Bevar de kompromitterede systemer eller kopier af dem, og genopret til nye eller rensede miljøer. Det kræver en prioriteret liste over, hvad der skal sikres før hvert genopretningsskridt, og en log over, hvad der faktisk blev gjort.

Haster det? Genopretning overskriver krypterede servere, hukommelsen går tabt ved genstart, og firewall- og VPN-logs roterer efter dage. Se akut forensisk sikring; hastesager koster ekstra.

Den ledelsesmæssige side, med roller, forsikring og kommunikation, er beskrevet i Vi er blevet hacket. Her handler det om den tekniske rækkefølge.

Grundprincippet: genopret ved siden af, ikke ovenpå

Den mest effektive enkeltbeslutning er at genoprette til nye diske, nye virtuelle maskiner eller et nyt datalager i stedet for at overskrive de krypterede. Så bevares de kompromitterede systemer som de er, og sikringen kan ske i det tempo, analysen kræver. Det koster lagerplads, men lagerplads er sjældent den begrænsende faktor sammenlignet med tabte beviser.

Kan det ikke lade sig gøre for alle systemer, så tag forensiske kopier eller eksporterede snapshots af de systemer, der skal overskrives, og beregn hashværdier, før genopretningen starter.

Prioriteret sikring

Rækkefølgen bestemmes af, hvor hurtigt data forsvinder:

Hukommelse på systemer, der stadig kører og kan være involveret, særligt domænecontrollere, filservere og den maskine, hvor angrebet blev opdaget. Angriberens værktøjer og eventuelle nøgler kan kun findes her. Se Hukommelsessikring.
Logs med kort opbevaring: firewall, VPN, EDR-telemetri, Entra ID-loginlogs og Microsoft 365-auditlog. Eksportér nu, ikke når genopretningen er overstået.
Backupsystemets logs og konfiguration, før backupsystemet bruges til genopretning. Angribere går ofte efter backuppen, og spørgsmålet om, hvornår den blev slettet eller ændret, er centralt for forsikring og leverandøransvar. Se Backup-logs.
Diske eller snapshots af nøglesystemer: den første kompromitterede maskine, domænecontrollere, systemer med fjernadgang udefra og filservere, hvor data kan være hentet.
Eksempler på krypterede filer og løsesumsbeskeden, med sti, tidsstempler og hashværdi.
Hypervisorer og lagersystemer, hvis de er ramt. Det kræver særlig håndtering, se Krypterede servere og hypervisorer.

Når der er mange maskiner, er det sjældent muligt at tage fulde kopier af alle. Målrettet indsamling af artefakter fra de mange og fulde kopier af de få er en forsvarlig metode, så længe valget er dokumenteret. Se Målrettet indsamling.

Det krypterede materiale

De krypterede filer er selv et bevis. Filnavneendelsen, løsesumsbeskeden og filernes struktur kan identificere, hvilken ransomwarefamilie der er tale om, og dermed hvilke kendte teknikker der skal ledes efter. Tidsstemplerne på de krypterede filer viser, hvornår krypteringen kørte på hvert system, og giver ofte det mest præcise billede af angrebets sidste fase.

Kør aldrig et dekrypteringsværktøj direkte på de originale data. Arbejd på en kopi, og bevar originalen. Hvis dekryptering lykkes, skal det dokumenteres, hvilket værktøj og hvilken version der blev brugt, og hashværdier af resultatet skal beregnes.

Spor, der typisk mangler

Ransomwareangreb sletter ofte bevidst spor: Volume Shadow Copies fjernes, hændelseslogs ryddes, og backupkataloger slettes. Det er i sig selv værd at dokumentere. Hændelser om rydning af logs og sletning af skyggekopier findes ofte i de logs, der er sendt til et centralt system, og i EDR-telemetrien, selv om de lokale logs er tomme.

Hvornår er et system sikret nok?

Under pres opstår spørgsmålet: Hvornår må dette system genoprettes? Et praktisk kriterium er, at følgende er på plads for systemet:

Hukommelsen er sikret, eller det er noteret, hvorfor det ikke skete, fx fordi systemet allerede var slukket.
Der findes en kopi af disken eller et eksporteret snapshot med hashværdi, eller en dokumenteret målrettet indsamling, hvis systemet er vurderet som perifert.
Systemets lokale logs er eksporteret, og det er kontrolleret, at de centrale logs dækker perioden.
Den, der har sikret, har bekræftet det i indgrebsloggen.

Kriteriet kan skrives ind i genopretningsplanen som en kontrolpost, så driftsfolkene ikke selv skal vurdere det i hvert enkelt tilfælde. Det fjerner meget af konflikten mellem de to spor.

Cloud og Microsoft 365 i samme hændelse

Mange ransomwareangreb begynder eller fortsætter i cloud: en overtaget konto i Entra ID, en synkroniseret administratorkonto eller adgang til SharePoint, hvorfra data hentes. Selv om krypteringen sker lokalt, skal cloudloggene derfor sikres med samme prioritet som de lokale. Eksportér loginlogs, auditlog og ændringer i roller og applikationer for hele den relevante periode, og vær opmærksom på, at opbevaringen afhænger af licens og konfiguration. På tidspunktet for gennemgangen (oktober 2026) gemmer Entra ID login- og revisionslogs i 7 dage uden premiumlicens og 30 dage med, mens Microsoft 365-revisionsloggen som standard gemmer 180 dage, og længere med udvidede licenser.

Glem heller ikke de konti, der bruges til genopretningen. Nye administratorkonti oprettet i cloud under hændelsen skal også fremgå af indgrebsloggen.

Genopretningen skaber selv spor

Gendannelse fra backup, nulstilling af konti, nye certifikater og ændrede firewallregler skriver til de samme logs, som analysen bruger. Før derfor en log over indgreb fra første time, med konto, system, tidspunkt og formål. Uden den kan ingen bagefter skille angriberens handlinger fra genopretningens. Se Log over indgreb under incident response.

Brug dedikerede konti til genopretningen. Det gør det langt nemmere at filtrere forsvarernes aktivitet fra i analysen og samtidig at vise, at angriberens adgang faktisk er lukket.

Rene og urene zoner

Sikrede data fra et kompromitteret miljø skal opbevares adskilt fra både det kompromitterede og det genoprettede miljø. Et lager, der kan nås fra det genoprettede netværk, kan i værste fald krypteres en gang til, hvis angriberen stadig har adgang. Brug et særskilt lager uden domænetilknytning, med adgang begrænset til de personer, der analyserer, og med registrering af adgang.

Fejl, der går igen

Reimage af den maskine, hvor angrebet blev opdaget, fordi den skulle hurtigt i drift igen.
Gendannelse af backup oven på de krypterede volumener.
Logs, der først eksporteres efter en uge, hvor de allerede er roteret.
Kopier uden hashværdi og uden notat om, hvem der tog dem.
Fjernadgang åbnet for en ekstern leverandør til et system, der endnu ikke er sikret.

Hvad det giver i analysen

Med hukommelse, logs, nøglesystemer og eksempler på krypterede filer sikret er det som regel muligt at besvare de spørgsmål, som forsikring, kunder og eventuelt en leverandørtvist drejer sig om: hvornår angriberen kom ind, hvordan, hvad der skete undervejs, og om data blev hentet ud. Hvordan indgangsvejen underbygges, er beskrevet i Indgangsvejen: sådan underbygges konklusionen. Uden sikringen bliver svarene gætværk, og gætværk holder sjældent, når en modpart eller et forsikringsselskab begynder at stille spørgsmål.

Dokumentation

Hold for hvert sikret element en post med system, type (hukommelse, disk, snapshot, logeksport, filprøve), tidspunkt, metode, værktøj og version, hashværdi, opbevaringssted og den person, der udførte sikringen. Notér også de systemer, der bevidst ikke blev sikret, og begrundelsen. Det er lige så vigtigt som listen over det, der blev sikret, fordi det viser, at udvælgelsen var en metode og ikke en tilfældighed.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Isolering og genopsætning: hvad sker der med artefakterne? · Indgangsvejen: sådan underbygges konklusionen

→ 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