Hukommelsessikring (RAM): hvad hukommelsen rummer, og hvordan den sikres

Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen

Når en computer slukkes, forsvinder indholdet af arbejdshukommelsen. Det kan være uden betydning, men det kan også være afgørende: Er disken krypteret og låst op, kan hukommelsen og den åbne session være den eneste lovlige vej til data, hvis gendannelsesnøglen ikke kan skaffes. Beslutningen om at sikre hukommelsen skal derfor træffes, før nogen trykker på afbryderen.

Om enheden overhovedet skal slukkes, isoleres eller køre videre, er beskrevet i Sluk, isolér eller lad den køre?. Denne artikel handler om selve sikringen af hukommelsen: hvornår den giver mening, hvordan værktøjerne arbejder på de forskellige platforme, hvad der kan gå galt, og hvordan forløbet dokumenteres. Analysen af en færdig RAM-kopi er beskrevet særskilt i Memory forensics: hvad en RAM-kopi kan vise, og nederst samles links til de øvrige specialartikler om sikring af tændte systemer.

Hvad ligger i hukommelsen?

Krypteringsnøgler · Nøgler til BitLocker, FileVault, VeraCrypt og andre åbne krypterede drev
Kørende processer · Programmer, der kører, også skjulte eller startet fra midlertidige mapper
Netværksforbindelser · Åbne forbindelser, IP-adresser, fjernskrivebord, VPN
Åbne dokumenter · Indhold, der ikke er gemt på disken
Beskeder og browsing · Dele af chats, websider og formularer, også fra private browservinduer
Udklipsholder · Seneste kopierede tekst eller filer
Kommandohistorik · Kommandoer i åbne terminalvinduer

Hvad der kan findes, afhænger af styresystem, version, sikkerhedsfunktioner og hvor længe data har ligget. Hukommelsen genbruges hele tiden, så gamle data overskrives i et tempo, der afhænger af belastningen. Nyere Windows-versioner komprimerer desuden dele af hukommelsen, så sider kan ligge i komprimeret form, som analyseværktøjet skal kunne pakke ud.

Hvornår skal RAM sikres?

Hukommelsessikring er særligt relevant, når:

disken er krypteret, og gendannelsesnøglen ikke er kendt eller tilgængelig via organisationens administration,
der er mistanke om aktive processer, fx fjernadgang eller en overførsel, der er i gang,
data kun findes i en åben session, fx en webmail, en cloudtjeneste eller en krypteret beholder, der er åben,
private browservinduer har været brugt, da de ikke skriver historik til disken. → Browserhistorik som bevis

Omvendt er hukommelsessikring sjældent nødvendig, når sagen handler om dokumenter, der ligger på disken, og disken enten er ukrypteret eller nøglen er kendt. Så kan en almindelig diskkopi efter kontrolleret nedlukning være tilstrækkelig.

Er computeren slukket, er hukommelsen tabt. Den skal ikke tændes for at sikre RAM, da det kun giver nyt indhold og ændrer disken.

Beslutningen i tabelform

Tændt, krypteret disk, nøgle ukendt · Sikr RAM, derefter logisk kopi af åbne drev, før der slukkes
Tændt, mistanke om aktiv fjernadgang · Sikr RAM og netværksoplysninger, isolér derefter efter aftale
Tændt, ukrypteret disk, sag om dokumenter · RAM er sjældent nødvendig; kontrolleret nedlukning og diskkopi
Slukket · Ingen RAM-sikring; diskkopi og eventuelt hukommelsesrester på disken
Virtuel maskine · Hukommelse via hypervisoren, uden værktøj i maskinen

Valget skal begrundes i dokumentationen. En sikring, der fravælges, er lige så meget en beslutning som en, der gennemføres.

Rækkefølgen: det mest flygtige først

Ved en tændt computer sikres data fra det mest flygtige mod det mindst flygtige:

Hukommelse
Netværksforbindelser og kørende processer (fremgår ofte af hukommelsen)
Logisk kopi af åbne, krypterede drev, mens de er låst op
Fuld diskkopi, typisk efter slukning

Princippet er beskrevet i flere standarder og retningslinjer på området. → ISO/IEC 27037 og NIST SP 800-86

RFC 3227 fra 2002 er stadig den mest citerede formulering. Den opstiller en rækkefølge, der begynder med registre og cache, går over routingtabel, ARP-cache, procestabel, kernestatistik og hukommelse, videre til midlertidige filsystemer og disk og slutter med fjernlogning, fysisk konfiguration og arkivmedier. RFC’en advarer også mod at lukke ned, før indsamlingen er færdig, mod at stole på systemets egne programmer og mod at afbryde netværket brat, hvis det kan udløse sletning. Den praktiske anvendelse er uddybet i Flygtighedsorden: hvad skal sikres først?.

Hvordan værktøjerne virker

Et hukommelsesværktøj læser den fysiske hukommelse gennem en driver eller et kernemodul, fordi almindelige programmer kun har adgang til deres eget adresserum. Det kræver administrator- eller root-rettigheder. Resultatet er en fil, der svarer til den fysiske hukommelse, typisk i rå form eller i et format med oplysninger om huller i adresserummet.

Windows · Programmer med signeret driver, fx open source-værktøjer som WinPmem
Linux · Kernemoduler eller værktøjer i brugerrum, fx LiME og AVML
macOS · Begrænset; på nyere Mac-computere med Apple-chip er fuld hukommelsessikring ofte ikke mulig med almindelige værktøjer
Virtuelle maskiner · Snapshot eller pause via hypervisoren, som gemmer hukommelsen til en fil

Begrænsningen på Mac skyldes blandt andet, at en Mac med Apple-chip kun indlæser tredjeparts kerneudvidelser, hvis sikkerhedsniveauet først sænkes, og det kræver genstart og ændrer i sig selv systemet. Ved Mac er en logisk sikring af den åbne session derfor ofte det realistiske; se Sikring af moderne Mac.

Windows

På Windows indlæser værktøjet en signeret driver, der giver adgang til den fysiske hukommelse. Sikkerhedsfunktioner som hukommelsesintegritet og Microsofts liste over blokerede, sårbare drivere kan forhindre ældre drivere i at blive indlæst. Det er en af grundene til, at værktøjet skal være testet på samme Windows-version som målet. Et værktøj, der ikke kan indlæses, giver en fejl; et værktøj, der indlæses, men ikke håndterer hardwaren korrekt, kan i værste fald få maskinen til at gå ned.

Linux

På Linux findes to veje. Et kernemodul som LiME skal være bygget til den præcise kerneversion, hvilket kræver forberedelse. Et værktøj i brugerrum som AVML læser via kernens egne grænseflader, fx /proc/kcore eller /dev/crash, og kræver ikke et modul. Ifølge AVML’s dokumentation kan værktøjet ikke sikre hukommelsen, hvis kernens lockdown-funktion er slået til. Uddata kan gemmes i LiME-formatet, som de fleste analyseværktøjer læser.

Virtuelle maskiner

Virtuelle maskiner er en fordel: Hypervisoren kan gemme hukommelsen udefra, uden at der køres noget inde i maskinen. Ved en pause eller et snapshot med hukommelse skriver hypervisoren tilstanden til filer ved siden af den virtuelle disk. De filer sikres og hashes sammen med disken. → Virtuelle maskiner og servere. Er hypervisoren selv krypteret eller ramt af en hændelse, gælder særlige forhold; se Krypterede servere og hypervisorer.

Analyseværktøjer

Analysen foregår med rammeværker, der genkender styresystemets datastrukturer, fx Volatility 3 eller MemProcFS. Understøttelsen af nye versioner af styresystemerne halter ofte lidt bagefter, så det skal dokumenteres, hvilken version og hvilke symboler der er brugt. Volatility 3 bruger symboltabeller, som for Windows typisk dannes ud fra Microsofts symbolfiler, mens Linux og macOS kræver en symboltabel bygget til den konkrete kerne.

Sådan gøres det i praksis

Kør værktøjet fra et eksternt medie, ikke fra computerens egen disk.
Gem resultatet på et eksternt medie med tilstrækkelig plads. Dumpet fylder omtrent det samme som den installerede RAM.
Notér tidspunkt, systemur, værktøj og version, og beregn hashværdien af dumpet straks. → Hashalgoritmer i forensic
Gem eventuelt dumpet i et format, der kan håndtere huller i adresserummet. → Forensiske diskformater
Kræver værktøjet administratorrettigheder, skal adgangen være lovligt tilvejebragt, fx via organisationens IT-administration eller samtykke. Den juridiske side er beskrevet i Ulovligt tilvejebragte beviser i civile sager.

Test værktøjet på tilsvarende hardware og styresystem inden brug i en sag. Et værktøj, der får maskinen til at fryse eller genstarte, kan ødelægge netop det, der skulle sikres. Hvordan værktøjer afprøves og valideres, er beskrevet i Verifikation af forensiske værktøjer.

Forløbet ved en tændt maskine

Observér før berøring. Fotografér skærmen, notér synlige programmer, vinduer og ur.
Hold maskinen vågen. Undgå dvale og pauseskærm, uden at åbne programmer.
Tilslut det eksterne medie med værktøjet og plads til dumpet, og notér tidspunktet.
Sikr hukommelsen, og gem værktøjets log.
Hash dumpet, og notér værdien med algoritme.
Supplerende flygtige oplysninger, fx netværksforbindelser og processer, hvis det er aftalt.
Logisk kopi af åbne krypterede drev, mens de stadig er låst op.
Nedlukning eller isolering efter den beslutning, der er truffet, og derefter diskkopi.

Når andre end den sagkyndige har adgang, fx et IR-team eller en MSP, bør trinene ligge i en playbook, så de kan udføres korrekt i det første kritiske døgn; se Bevissikringstrin i jeres IR-playbooks og Live response: sikring af en kørende computer eller server. Kan maskinen ikke nås fysisk, kan hukommelsen i nogle miljøer sikres via en agent; fordele og risici er beskrevet i Fjernindsamling via agent eller netværk.

Ændringer under sikringen

En hukommelsessikring kan ikke foretages uden at påvirke systemet. Værktøjet fylder selv i hukommelsen, og data ændrer sig, mens dumpet tages. Det er ikke et øjebliksbillede, men et udsnit taget over nogle minutter. Strukturer kan derfor være inkonsistente, fx en proces, der er afsluttet halvvejs gennem læsningen. Det er vigtigt at:

dokumentere hver handling og tidspunkt,
forklare i rapporten, at ændringer er uundgåelige, og hvilke de er,
undgå anden brug af computeren under sikringen.

En hukommelsessikring kan ikke gentages, og den kan ikke verificeres mod originalen bagefter. Hashværdien viser kun, at dumpet er uændret efter sikringen, ikke at det er en fuldstændig gengivelse. Dokumentationen er derfor ekstra vigtig. De spor, værktøjet selv efterlader, fx en indlæst driver eller en ny proces, skal kunne skelnes fra brugerens aktivitet; se Kontaminering: når undersøgelsen selv efterlader spor.

Fejlkilder

Under sikringen

Uprøvet værktøj: Et værktøj, der ikke er afprøvet på den aktuelle version, kan fejle eller få maskinen til at gå ned.
For lidt plads: Et dump, der løber tør for plads, er ufuldstændigt, og sikringen kan ikke gentages.
Skrivning til den undersøgte disk: Gemmes dumpet på maskinens egen disk, overskrives ledig plads, som kunne indeholde slettede data.
Sikkerhedsprogrammer: Antivirus eller EDR kan blokere eller ændre værktøjet, og det skal noteres. Er maskinen isoleret af en EDR-løsning, kan det påvirke både netværksoplysninger og processer; se Isolering og genopsætning.
Tidligere handlinger: Har nogen allerede logget ind, kørt scanninger eller genstartet, er hukommelsen påvirket. Det beskrives, ikke skjules; se Vi har allerede rørt maskinen.

I fortolkningen

Fragmenter uden kontekst: En tekststreng i hukommelsen siger ikke i sig selv, hvilken proces den tilhørte, eller hvornår den kom dertil.
Gamle data: Frigivet hukommelse kan indeholde rester fra tidligere sessioner. Tilstedeværelse betyder ikke nødvendigvis aktuel brug.
Profilfejl: Forkerte symboler for styresystemversionen giver forkerte eller manglende resultater.
Inkonsistente strukturer: Fordi dumpet tages over tid, kan en liste pege på et objekt, der ikke længere findes.

Det, hukommelsen kan vise, er at noget var til stede eller kørte på sikringstidspunktet. Den kan sjældent alene vise, hvem der startede det, eller hvorfor. Den sammenhæng skal findes ved at kombinere med disk, logs og øvrige spor.

Hukommelse på disken

Selvom RAM er tabt, kan dele af hukommelsen findes på disken:

pagefile.sys og swapfile.sys (Windows’ sidefiler)
hiberfil.sys (dvaletilstand og hurtig opstart i Windows)
swap-filer på macOS og Linux

Disse filer kan indeholde fragmenter af processer, dokumenter og i nogle tilfælde nøgler. På krypterede diske er de normalt også krypteret, og nyere Windows-versioner kan komprimere indholdet.

Hurtig opstart i Windows har en særlig betydning. Når funktionen er slået til, gemmer en almindelig nedlukning kernens tilstand i hiberfil.sys i stedet for at lukke helt ned. Filen kan derfor rumme oplysninger fra den seneste session, også på en maskine, der er “slukket”. Omvendt betyder det, at en maskine, der er lukket ned og tændt igen af en kollega, kan have overskrevet den fil. Rækkefølgen af handlinger før sikringen skal derfor afdækkes.

Sikkerhedsfunktioner

Funktioner som Credential Guard og virtualiseringsbaseret sikkerhed i Windows beskytter visse hemmeligheder mod udtræk fra hukommelsen. Kryptering af hukommelsen på nyere hardware kan også begrænse mulighederne. Man kan ikke gå ud fra, at nøgler altid kan findes, og det er ikke en fejl i sikringen, hvis de ikke kan.

Når nøglen til et krypteret drev ikke kan skaffes på anden måde, er de lovlige veje typisk organisationens administration af gendannelsesnøgler, ejerens medvirken eller en logisk kopi, mens drevet er åbent. Det er gennemgået i BitLocker og FileVault i bevissikring og Krypterede data i en undersøgelse: de lovlige adgangsveje.

Eksempel: krypteret bærbar ved fratræden

En bærbar computer står tændt og låst op på et skrivebord, og disken er krypteret. Organisationen har ikke gendannelsesnøglen registreret centralt. Slukkes maskinen, er data reelt utilgængelige. Den forsvarlige rækkefølge er her at sikre hukommelsen, derefter tage en logisk kopi af de relevante mapper og brugerprofilen, mens drevet er åbent, og først derefter tage stilling til nedlukning. Hvert trin dokumenteres med tidspunkt, værktøj og hashværdi, og rapporten forklarer, hvorfor en fuld fysisk kopi af den dekrypterede disk ikke var mulig. Hvis maskinen derimod står i en domæneopsætning med centralt opbevarede gendannelsesnøgler, er hukommelsessikringen ofte unødvendig for netop det formål.

Tjekliste

☐ Maskinens tilstand er fotograferet og noteret før berøring.
☐ Beslutningen om at sikre eller fravælge RAM er begrundet.
☐ Værktøjet er afprøvet på samme styresystemversion og køres fra eksternt medie.
☐ Der er plads nok på målmediet til hele hukommelsen.
☐ Adgang med administratorrettigheder er lovligt tilvejebragt og dokumenteret.
☐ Start- og sluttidspunkt, systemur, værktøj og version er noteret.
☐ Hashværdien er beregnet straks efter sikringen.
☐ Logisk kopi af åbne krypterede drev er overvejet, før der slukkes.
☐ Værktøjets egne spor er beskrevet, så de kan skelnes fra brugerens aktivitet.

Dokumentation, der holder

Rapporten bør for hver hukommelsessikring angive, hvorfor RAM blev sikret, hvem der udførte sikringen, maskinens tilstand ved ankomst (tændt, låst, hvilke programmer var synlige), værktøj og version, hvilket medie dumpet blev skrevet til, start- og sluttidspunkt, eventuelle fejlmeddelelser og hashværdien. Skærmbilleder eller fotos af skærmen før sikringen er nyttige, fordi de viser tilstanden, før noget blev rørt. Beskriv også, hvad der skete bagefter: om maskinen blev lukket ned, om der blev taget en logisk kopi af åbne drev, og i hvilken rækkefølge. Den, der læser rapporten, skal kunne forstå hvert trin uden at have været til stede. → Rapportskrivning

Er RAM sikret af et IR-team før den sagkyndige kom ind, skal overdragelsen dokumenteres med samme omhu som selve sikringen; se Overdragelse fra IR-team til sagkyndig.

Privatliv

Hukommelsen indeholder alt, hvad der er åbent, også private data og adgangskoder. Analysen bør afgrænses til sagens spørgsmål, og fund uden relevans bør ikke gengives i rapporten. → GDPR og bevisførelse

Specialartikler om tændte systemer

Beslutning: Sluk, isolér eller lad den køre?, Flygtighedsorden, Triage eller fuld kopi
Udførelse: Live response, Fjernindsamling, Bevissikringstrin i IR-playbooks
Analyse: Memory forensics: hvad en RAM-kopi kan vise
Når noget er sket: Vi har allerede rørt maskinen, Tjekliste før reinstallation, Isolering og genopsætning

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Skrivebeskyttere (write blockers): hvordan og hvorfor · Identifikation af datakilder: teknisk kortlægning før sikringen

→ Forensisk sikring · For IT-afdelingen · 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

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Eller kontakt os på