EDR‑telemetri som bevis: opbevaring og eksport

Forside › Netværk og logs · Gennemgået oktober 2026 · Af John Nielsen

EDR-produkter (endpoint detection and response) registrerer løbende, hvad der sker på computere og servere: hvilke processer der startes, hvilke filer der skrives, hvilke netværksforbindelser der åbnes, og hvilke ændringer der sker i registreringsdatabasen. Telemetrien sendes til leverandørens cloud eller en central server og er derfor ofte tilgængelig, selv når endpointet er geninstalleret. Hvordan IR-teamet bedst overdrager sine udtræk, står i Overdragelse fra IR-team til sagkyndig og Bevissikringstrin i jeres IR-playbooks. Som bevis er den værdifuld, fordi den er opsamlet løbende og uden for maskinen, men den er også udvalgt, opbevaret i begrænset tid og formet af produktets egne valg. Den skal derfor sikres hurtigt og beskrives præcist.

Haster det? EDR-telemetri har en begrænset levetid i konsollen, og hændelser uden for opbevaringsperioden kan ikke hentes frem igen. Se akut forensisk sikring, og bemærk, at hastesager koster ekstra.

Hvad EDR-telemetri typisk indeholder

Processer · Start og stop, kommandolinje, forælderproces, bruger, hashværdi af den eksekverbare fil, signatur
Filer · Oprettelse, ændring, omdøbning og sletning, sti, hashværdi, den proces, der handlede
Netværk · Forbindelser med lokal og fjern IP-adresse, port, protokol, den proces, der åbnede forbindelsen, evt. DNS-opslag
Register · Ændringer af nøgler og værdier, især autostart og sikkerhedsindstillinger
Login · Lokale og netværkslogins med konto og logontype
Alarmer · Produktets egne detektioner med regel, alvorlighed og tilknyttede hændelser

Hvad der faktisk registreres, varierer mellem produkter, licensniveauer og konfigurationer. Mange produkter registrerer ikke alle filhandlinger, men udvalgte typer eller filer på bestemte steder, og netværksforbindelser kan være samplet eller sammenlagt. Det er afgørende for fortolkningen, fordi fravær af en hændelse i telemetrien ikke betyder, at handlingen ikke skete. DLP-alarmer er en beslægtet kilde med andre begrænsninger; se DLP-hændelser. Hvilke hændelsestyper der filtreres, står sjældent fuldt beskrevet, så dækningen bør afprøves på en testenhed med samme produkt og konfiguration, når et fravær skal bruges som argument.

Opbevaring

Telemetri opbevares typisk i en begrænset periode, som afhænger af produkt og licens. Ofte er perioden for fuldt søgbar rå telemetri kortere end for alarmer og hændelser, som produktet har markeret. I Microsoft Defender for Endpoint var data på tidspunktet for gennemgangen (oktober 2026) fx tilgængelige i portalen i 180 dage, men kun søgbare med avanceret jagt i 30 dage. Nogle organisationer sender telemetrien videre til et SIEM eller et datalager med længere opbevaring.

Det praktiske råd er, at opbevaringsperioden skal kendes, før der sker noget, og at telemetri skal eksporteres så hurtigt som muligt, når en sag opstår. Telemetri, der er udløbet, kan normalt ikke genskabes, heller ikke af leverandøren.

Telemetri og forensisk kopi supplerer hinanden

EDR-telemetri og en forensisk kopi af disken besvarer forskellige spørgsmål:

Telemetrien viser forløb over tid, også for handlinger, der ikke efterlader spor på disken, fx kommandoer i hukommelsen eller forbindelser, der ikke logges lokalt. Den dækker kun det, produktet har valgt at registrere.
Den forensiske kopi viser tilstanden på et tidspunkt med alle artefakter, også dem EDR ikke registrerer, men den kan mangle historik, som er overskrevet.

Når begge findes, kan de krydstjekke hinanden. En proces i telemetrien bør kunne genfindes i Prefetch, Amcache eller hændelseslogs, og omvendt. Hvis maskinen er isoleret eller renset af EDR-produktet, ændrer det artefakterne; se Isolering og genopsætning.

Eksport trin for trin

Afgræns: enheder, konti, tidsrum og hændelsestyper. Tag tidsrummet bredt, så forløbet før og efter er med.
Brug produktets mest komplette eksport. Det kan være en avanceret søgefunktion med eksport, en API eller en tidslinjeeksport pr. enhed. Visninger i brugerfladen er ofte afkortede.
Gem forespørgslerne. Søgesproget er produktspecifikt. Gem den præcise tekst, tidsrum og tidszone.
Kontrollér antal og grænser. Mange søgeflader har grænser for antal resultater pr. søgning. Del tidsrummet op, og kontrollér, at summen stemmer.
Eksportér alarmer separat med regel, beskrivelse og de tilknyttede rå hændelser.
Beregn hashværdier for hver eksportfil straks.
Gem konfigurationen: politikker, undtagelser, sensorversion pr. enhed og perioder, hvor sensoren var offline.
Notér den, der eksporterede, med konto og tidspunkt.

Bruges en API eller et script, gem scriptet, versionen og output. Fremgangsmåden er den samme som ved andre cloudeksporter; se Eksport via Microsoft Graph og PowerShell. For Microsofts egen platform, se Defender XDR som datakilde.

Live response gennem EDR

Mange EDR-produkter giver mulighed for at køre kommandoer på et endpoint eksternt, hente filer og samle artefaktpakker. Det kan være hurtigt og effektivt, men hver handling ændrer maskinen. Kommandoer, filer og tidspunkter skal logges i en indgrebslog. Metodiske krav er beskrevet i Live response.

Fortolkning og fejlkilder

Kommandolinjer kan være afkortede. Lange kommandolinjer kan være skåret af i telemetrien.
Forælderprocesser kan være misvisende. Nogle processer startes via mellemled, så den viste forælder ikke er den reelle initiativtager.
Tid. Tidsstempler kommer fra endpointets ur eller fra modtagelsen i cloud. Kontrollér, hvilken, og om endpointet har haft forkert ur.
Brugerkonto. En proces, der kører som en bestemt konto, er ikke ensbetydende med, at personen bag kontoen startede den. Systemprocesser, planlagte opgaver og fjernadministration kører også som konti.
Undtagelser. Mapper og processer, der er undtaget fra overvågning, giver blinde vinkler. Undtagelseslisten er en del af beviset.
Offline-perioder. En enhed uden forbindelse kan have en kø, der sendes senere, eller hændelser, der er tabt.

Hashværdier og filreputation

EDR-produkter registrerer ofte hashværdien af eksekverbare filer og nogle gange af andre filer, der berøres. Det er værdifuldt, fordi en hashværdi i telemetrien kan kobles til en fil, der senere findes på disken, i en mail eller på et USB-drev. Vær opmærksom på, hvilken algoritme produktet bruger, og om hashværdien er beregnet af agenten på endpointet eller slået op i en cloudtjeneste. Mange produkter viser også en vurdering af filens omdømme, fx kendt god, ukendt eller ondsindet. Den vurdering er et opslag på et givent tidspunkt og kan ændre sig. Den bør derfor gengives med dato og kilde og ikke præsenteres som et registreret faktum om filen.

Når enheden ikke længere findes

En af telemetriens største fordele viser sig, når endpointet er geninstalleret, udskiftet eller bortkommet. Den lokale disk er væk, men hændelserne ligger stadig i leverandørens cloud, så længe opbevaringsperioden ikke er udløbet. Notér i så fald tydeligt, at analysen bygger på telemetri alene, og at artefakter på disken ikke har kunnet efterprøve den. Konklusioner om handlinger, som produktet ikke registrerer, kan ikke drages, og rapporten bør sige det.

Leverandørens og MSP’ens rolle

Telemetrien ligger typisk i en leverandørs cloud og administreres ofte af en MSP eller en SOC-leverandør. Det har to konsekvenser. Den organisation, der har sagen, har ikke altid selv adgang til eksport, og det skal derfor aftales tidligt, hvem der eksporterer, og hvordan. Og leverandørens egne analyser kommer ofte som en rapport frem for rå data. En rapport er nyttig, men de underliggende hændelser skal også sikres, hvis konklusionerne skal kunne efterprøves.

Hvad telemetrien kan bevise

EDR-telemetri kan vise, at produktet på en bestemt enhed registrerede bestemte handlinger med bestemte egenskaber på et bestemt tidspunkt. Styrken er, at registreringen er sket løbende og uden for brugerens kontrol. Begrænsningerne er, at telemetrien er et udvalg, at den afhænger af konfigurationen, og at den viser konti og processer, ikke personer. Rapporten bør beskrive produkt, version, konfiguration, opbevaring og eksportmetode, så en anden kan vurdere, hvad der kunne og ikke kunne være registreret. Samspillet mellem hændelseshåndtering og forensisk dokumentation er beskrevet i Forensic eller incident response?.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Netværk og logs

Læs også: Logintegritet: sådan vises det, at en log ikke er ændret · DLP-hændelser: hvad en DLP-alarm dokumenterer

→ Logundersøgelse · 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