Live response: sikring af en kørende computer eller server

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

Live response er sikring af oplysninger fra et system, mens det kører: hvilke processer der er aktive, hvilke netforbindelser der er åbne, hvem der er logget på, og hvilke volumener der er monteret og låst op. Oplysningerne forsvinder, når systemet slukkes eller genstartes. Til gengæld ændrer hver kommando, du kører, systemet en smule, og derfor skal hver handling logges, så påvirkningen kan forklares bagefter.

Haster det? Processer, netforbindelser og oplåste volumener er væk ved første genstart eller geninstallation, så indsamlingen skal ske, før nogen rydder op. Se Akut forensisk sikring; hastesager koster ekstra.

Live response er ikke det samme som hukommelsessikring. En RAM-kopi fanger hele arbejdshukommelsen og analyseres senere. Live response henter udvalgte, strukturerede oplysninger direkte fra styresystemet. De to supplerer hinanden. RAM-sikringen er beskrevet i Hukommelsessikring (RAM), og beslutningen om at lade systemet køre i Sluk, isolér eller lad den køre?.

Hvad der indsamles

Indholdet af en live response afhænger af spørgsmålet, men omfatter typisk:

Processer · Kørende processer, forældreproces, kommandolinje, starttid, bruger
Netværk · Åbne forbindelser og lyttende porte med proces-id, ARP- og DNS-cache, routingtabel
Brugere · Aktive sessioner, fjernskrivebordssessioner, senest loggede brugere
Lagring · Monterede volumener, netværksdrev, krypteringsstatus, skyggekopier
Konfiguration · Systemtid og tidszone, planlagte opgaver, tjenester, autostart
Ressourcer · Åbne filer og håndtag, indlæste moduler

Systemtid og tidszone hører altid med. Afvigelsen mellem systemets ur og en pålidelig tidskilde noteres, så alle tidsstempler senere kan korrigeres.

Krypteringsstatus er særlig vigtig. Er disken krypteret og låst op, kan en logisk kopi af den monterede volumen være den eneste mulighed for at få adgang til data uden nøglen. Gendannelsesnøglen bør i givet fald også sikres ad lovlig vej. → BitLocker og FileVault i bevissikring

Rækkefølgen

Indsaml det mest flygtige først. Netforbindelser og processer ændrer sig på sekunder, mens planlagte opgaver og tjenester er stabile. Skal der tages en RAM-kopi, tages den normalt før de øvrige kommandoer, fordi hver kommando optager hukommelse og kan overskrive spor. Den fulde rækkefølge fra netværk til backup er beskrevet i Flygtighedsorden.

Værktøjer og påvirkning

Live response kan udføres med styresystemets egne kommandoer, med samlede indsamlingsscripts eller med en agent fra et EDR-system. Uanset værktøj gælder:

Kør fra et eksternt medie eller en kendt placering, ikke fra programmer, der allerede ligger på systemet. Er systemet kompromitteret, kan dets egne værktøjer være ændret.
Skriv output til et eksternt medie eller et netværksmål, ikke til systemets egen disk. Hver fil, der skrives lokalt, kan overskrive slettede data.
Brug så få og så kendte kommandoer som muligt. Hver proces, du starter, efterlader spor i fx Prefetch, hændelseslogs og hukommelsen.
Kend dit værktøjs fodaftryk. Afprøv scriptet på et testsystem, og notér, hvilke artefakter det selv skaber. Så kan dine egne spor skilles fra brugerens.

Det sidste punkt er det, der oftest mangler. En modpart kan med rette spørge, om en bestemt Prefetch-fil eller en bestemt hændelse i loggen stammer fra brugeren eller fra den, der sikrede. Svaret skal kunne findes i din egen log.

Log over egne kommandoer

Live response uden en log over egne handlinger er svær at forsvare. Loggen bør for hver handling angive:

tidspunkt med tidszone, fra et ur du kontrollerer, ikke kun systemets eget,
den præcise kommando eller handling, inklusive parametre,
hvor output blev gemt, og hashværdien af outputfilen,
uventede reaktioner, fejlmeddelelser eller dialogbokse,
hvem der udførte handlingen.

Mange indsamlingsscripts skriver selv en log. Den erstatter ikke en manuel notits om det, der skete uden for scriptet, fx at en skærmlås blev låst op med brugerens kode efter aftale, eller at et netværkskabel blev trukket ud. Ved incident response, hvor flere personer arbejder på samme system, samles handlingerne i en fælles log. → Log over indgreb under incident response

Linux og macOS

Principperne er de samme på Linux og macOS, men kilderne er andre. På Linux kan meget af systemets tilstand læses direkte fra procfs: kommandolinje, åbne filer, netværkssokler og miljøvariabler pr. proces. Det er nyttigt, fordi en proces, hvis eksekverbare fil er slettet fra disken, stadig kan ses og ofte kopieres herfra, så længe den kører. På macOS begrænser systemets sikkerhedsfunktioner, hvad selv en administrator kan læse uden særlige tilladelser, og nogle oplysninger kræver, at værktøjet har fået fuld diskadgang, enten af en administrator på maskinen eller via en MDM-profil. Hvilke data der er beskyttet, kan ændre sig med nye macOS-versioner. Notér de tilladelser, der blev givet, for de er selv en ændring af systemet.

Når systemet allerede er rørt

I mange sager er der gået tid, før sikringen begynder. IT har måske kigget i Jobliste, kørt en antivirusscanning eller genstartet en tjeneste. Det gør ikke live response meningsløs, men det skal med i loggen som kendte handlinger før indsamlingen, med tidspunkt og person så præcist, som det kan oplyses. Spørg konkret ind til, hvad der er gjort, og skriv svaret ned ordret. Et ærligt “vi ved det ikke” er bedre end en rekonstruktion, der senere viser sig forkert.

Servere og virtuelle maskiner

På servere er live response ofte den eneste realistiske mulighed, fordi en nedlukning har forretningsmæssige konsekvenser. Virtuelle maskiner giver en fordel: Hypervisoren kan tage et snapshot med hukommelse, der fanger maskinens tilstand uden at køre kommandoer inde i den. Snapshottet ændrer dog selve den virtuelle maskines filer og skal dokumenteres som en handling, og hypervisorens egne logs viser bagefter, hvem der tog det; se Hypervisorlogs i ESXi og Hyper-V. → Virtuelle maskiner og servere

For databaser og andre tjenester med åbne filer giver en almindelig filkopi ofte en inkonsistent kopi. Her bruges tjenestens egen eksport eller et snapshot. Live response kan dokumentere tjenestens tilstand, men erstatter ikke en konsistent sikring af data.

Fejlkilder i fortolkningen

Øjebliksbillede: Live response viser tilstanden i det sekund, kommandoen kørte. En forbindelse, der ikke var åben på det tidspunkt, kan have været åben et minut før.
Skjulte processer: Er systemet kompromitteret på kerneniveau, kan styresystemets egne svar være manipuleret. Uoverensstemmelse mellem live response og en senere RAM-analyse kan være et tegn på det, men det kræver analyse, før det konkluderes; se Memory forensics: hvad en RAM-kopi kan vise.
Tid: Output fra forskellige kommandoer har ikke samme tidsstempel. Notér tidspunktet for hver.
Egne spor: Uden en log over egne handlinger kan dine artefakter forveksles med brugerens.
Tolkning af navne: Et procesnavn siger ikke, hvad programmet er. Sti, hashværdi og signatur skal med.

Hvad live response kan og ikke kan bevise

Live response kan vise, at en proces kørte, at en forbindelse til en bestemt adresse var åben, eller at en bestemt bruger var logget på på et givet tidspunkt. Det kan ikke vise, hvad der skete før indsamlingen, og det kan ikke i sig selv vise, hvem der betjente systemet. Oplysningerne skal kobles med hændelseslogs, loginlogs og filsystemets tidsstempler fra den efterfølgende kopi.

Dokumentation, der holder

Til rapporten skal der foreligge: begrundelsen for live response frem for nedlukning, systemets identifikation, tidsafvigelse, værktøjer og versioner, den fulde kommandolog, hashværdier for alle outputfiler og en beskrivelse af kendte ændringer, som indsamlingen selv har forårsaget. Hvordan en virksomhed praktisk forholder sig til en tændt maskine i de første minutter, er beskrevet på Luk adgangene med det samme, eller vent?.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Målrettet indsamling af filer, mapper og postkasser · Fjernindsamling via agent eller netværk

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