DigitalForensics

70 13 63 23

Kontaminering: når undersøgelsen selv efterlader spor

Kontaminering: når undersøgelsen selv efterlader spor

Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen

Enhver håndtering af en tændt enhed eller en aktiv konto ændrer data. Når IT-afdelingen logger på en computer for at “lige se efter”, når en leder åbner en medarbejders postkasse, eller når en sagkyndig laver en live-sikring, opstår der nye spor, som blandes med dem, der skal undersøges. Kontaminering kan sjældent undgås helt, men den kan begrænses, identificeres og dokumenteres, så de egne spor kan skilles fra resten i analysen.

Det afgørende er ikke, om der er sket kontaminering, men om den kan afgrænses. En håndtering, der er tidsfæstet og beskrevet, er et mindre problem end en ukendt. Risikoen er størst, når IT-afdelingen selv bliver bedt om at kigge; se Når IT bliver bedt om at undersøge en kollega.

Typiske kilder til kontaminering

  • Logon på brugerens computer · Logon-hændelser, profilændringer, nye artefakter i registreringsdatabasen
  • Gennemsyn af filer og mapper · LNK-filer, jump lists, shellbags, ændrede adgangstider
  • Tilslutning af USB-drev · USB-registreringer, mounted devices, drevbogstaver
  • Kørsel af værktøjer · Prefetch, Amcache, nye filer, procesdata
  • Fjernadgang med supportværktøj · Forbindelseslogs hos værktøjet og på maskinen; se TeamViewer- og AnyDesk-logs
  • Login i brugerens cloudkonto · Loginposter, poster i auditloggen, ændret læsestatus
  • Nulstilling af adgangskode · Kontoændringer, afsluttede sessioner
  • Sluk og genstart · Tab af hukommelse, nye opstartsposter, overskrevne logs

Den hyppigste situation er, at IT-afdelingen eller en IT-leverandør har undersøgt enheden, før det blev klart, at der kunne blive en sag. Det er forståeligt, men det betyder, at sagkyndige skal kunne skille IT-afdelingens handlinger fra den undersøgte persons. Fra virksomhedens side er valget mellem egen IT og en uvildig sagkyndig beskrevet her: → Egen IT, IT-leverandør eller uvildig IT-sagkyndig?

Hvorfor kontaminering er et bevisproblem

Kontaminering har to konsekvenser. For det første kan egne handlinger overskrive spor. Logs med fast størrelse roterer, nye LNK-filer kan erstatte gamle, og en genstart kan slette data, der kun fandtes i hukommelsen. For det andet kan egne handlinger forveksles med den undersøgte persons. En LNK-fil, der er skabt af IT-medarbejderens gennemsyn, kan i en tidslinje ligne en brugerhandling, hvis tidspunktet ikke er kendt.

Den anden konsekvens er ofte den alvorligste, fordi den kan føre til forkerte konklusioner. Den første betyder tab af information, den anden betyder fejlagtig information.

Begrænsning før og under sikringen

De vigtigste værn er velkendte:

  • Undgå at logge på enheden. Sikr den som den er, eller sluk den efter en vurdering af flygtige data.
  • Brug skrivebeskyttelse ved sikring af medier, så sikringen ikke ændrer kilden. → Skrivebeskyttere (write blockers)
  • Brug egne konti ved adgang til cloudtjenester, fx administratorkonti med eDiscovery-rettigheder, i stedet for at logge ind som brugeren.
  • Minimer live-handlinger. Hvis en live-sikring er nødvendig, så planlæg værktøjer og rækkefølge, og kør dem fra et eksternt medie.
  • Analysér aldrig originalen. Arbejd på en verificeret kopi. → Arbejdskopier og masterkopi

Når kontaminering allerede er sket

Ofte modtager den sagkyndige en enhed, som andre har håndteret. Så er opgaven at rekonstruere håndteringen:

  1. Indhent en forklaring. Spørg skriftligt, hvem der har haft enheden eller kontoen, hvad der er gjort, og hvornår. Notér svarene ordret.
  2. Find håndteringen i data. Logon-hændelser for IT-konti, USB-enheder, der tilhører IT, kørte værktøjer og tidspunkter for gennemsyn kan typisk findes i de samme kilder, som undersøges.
  3. Fastlæg et skæringstidspunkt. Bestem det tidspunkt, hvorefter data er påvirket af håndteringen, så analysen kan skelne mellem før og efter.
  4. Vurder tabet. Undersøg, om håndteringen kan have overskrevet spor fra den relevante periode, fx ved logrotation eller nye artefakter i begrænsede lister.
  5. Beskriv det i rapporten. Uanset om håndteringen har betydning for konklusionen.

Det er en fordel, hvis forklaringen indhentes, før den sagkyndige ser data. Så kan forklaringen efterprøves mod sporene i stedet for at blive formet af dem.

Egne spor fra den sagkyndige

Også den sagkyndige efterlader spor ved live-sikring, logisk sikring af telefoner og indsamling fra cloudtjenester. Mobiludtræk kræver ofte, at telefonen låses op og forbindes til en computer, og cloudindsamling registreres i auditloggen. Det er ikke en fejl, men det skal dokumenteres med tidspunkt, værktøj, version og konto, så det senere kan identificeres i data. → Live response: sikring af en kørende computer

En god praksis er at notere tidspunktet for hver handling med reference til et kendt ur og at sammenholde det med enhedens ur. Så kan de egne spor findes præcist i tidslinjen.

Analysens egen adgang

Kontaminering kan også ske på kopien. Hvis en arbejdskopi monteres skrivbart, eller hvis et analyseværktøj ændrer en database ved åbning, kan den kopi, der analyseres, afvige fra masterkopien. Kontrollér hashværdien af masterkopien før og efter analysen, og arbejd kun skrivebeskyttet eller på en kopi af kopien. SQLite-databaser er et kendt eksempel: Åbning med et almindeligt program kan flette WAL-filen ind i hoveddatabasen og dermed ændre indholdet og fjerne slettede rækker, der ellers kunne være gendannet. Det samme gælder PST-filer, som et mailprogram kan reparere eller omorganisere ved åbning, og Office-dokumenter, hvor et program kan opdatere metadata ved blot at åbne og lukke filen. Analyseværktøjer bør derfor åbne kildedata skrivebeskyttet, og analytikerens egen adgang til beviskopierne bør logges, så det senere kan vises, hvem der har arbejdet med hvilken kopi og hvornår.

Kontaminering i cloudkonti

I cloudtjenester er kontamineringen sværere at se, fordi den sker på leverandørens servere. Logger en leder ind i en medarbejders postkasse, ændres læsestatus, mapper kan blive synkroniseret til en ny enhed, og loginloggen får poster fra en ny IP-adresse og en ny enhed, som kan forveksles med uautoriseret adgang. Nulstilles en adgangskode, afsluttes sessioner, og det kan skjule, hvilke enheder der var forbundet. Den sikreste fremgangsmåde er at bruge administrative værktøjer som eDiscovery og auditlogs, der ikke ændrer brugerens data, og at notere tidspunktet for hver administrativ handling, så den kan genfindes i loggene.

Hvad det betyder for konklusionen

Kontaminering ugyldiggør sjældent en hel undersøgelse. Den svækker typisk kun de konklusioner, der bygger på spor fra tidsrummet omkring håndteringen eller fra kilder, der er påvirket. Det er derfor vigtigt at afgrænse den præcist: Hvilke kilder er påvirket, fra hvilket tidspunkt, og hvilke konklusioner bygger på dem?

En modpart vil ofte bruge kontaminering som argument mod hele undersøgelsen. Det argument står svagest, når rapporten selv har identificeret og afgrænset håndteringen.

Dokumentation

Rapporten bør indeholde:

  • en oversigt over alle kendte håndteringer af enheden eller kontoen før sikringen, med tidspunkt, person og formål,
  • de spor, håndteringen har efterladt, og hvordan de er identificeret,
  • skæringstidspunktet og de kilder, der er påvirket,
  • en vurdering af, om spor fra den relevante periode kan være tabt,
  • den sagkyndiges egne handlinger med tidspunkt, værktøj og version.

Den samlede kæde af håndteringer hører også til i loggen over kæde af ansvar (chain of custody), så den kan følges fra første berøring til den endelige rapport. Hvis oplysningerne om en tidligere håndtering er usikre eller modstridende, skal det også fremgå, fordi usikkerheden kan have betydning for, hvor meget de berørte spor kan bære.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Analyse og fortolkning

Læs også: Analyseplan og hypoteser før analysen starter · Hvem slettede filen? Spor på fil-, server- og cloudniveau · Teknisk ordbog

→ Digital forensics-undersøgelse · For sagkyndige · 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

John Nielsen, IT-sagkyndig

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.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.