Hashlister og kendte filer: filtrering med referencesæt

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

En hashliste er en samling hashværdier for filer, man allerede kender. Den bruges på to måder i en undersøgelse: til at frasortere filer, der er uinteressante, fordi de stammer fra styresystemet eller standardprogrammer, og til at finde bestemte filer, fordi deres hashværdi er kendt på forhånd. Begge dele sparer tid og gør analysen mere præcis, men begge bygger på, at en hashværdi kun matcher bitidentiske filer. En fil, der er ændret med én byte, falder uden for listen.

To slags lister

Kendt god (known good) · Formål: Frasortering af uinteressante filer · Eksempel: Styresystemets og programmers egne filer
Kendt relevant (notable) · Formål: Søgning efter bestemte filer · Eksempel: Virksomhedens fortrolige dokumenter, kendt skadelig software

Mange værktøjer kalder den første kategori “ignorable” og den anden “alert” eller “notable”. Navnene varierer, men princippet er det samme.

NSRL: det store referencesæt

National Software Reference Library (NSRL) er et referencebibliotek, som det amerikanske standardiseringsinstitut NIST vedligeholder. Biblioteket indeholder hashværdier for filer fra et meget stort antal kommercielle programmer, styresystemer og spil, og det udgives som Reference Data Set (RDS). RDS indeholder hashværdier i flere algoritmer, herunder MD5 og SHA-1, samt oplysninger om, hvilket produkt filen stammer fra. RDS udgives i dag kun som SQLite-database (RDSv3) i nye versioner flere gange om året; det ældre tekstformat udgives ikke længere. Notér altid versionsnummeret på det sæt, der er brugt.

Det er vigtigt at forstå, hvad NSRL er, og hvad det ikke er:

NSRL siger, at filen findes i et kendt softwareprodukt, ikke at den er harmløs. Et fjernadgangsværktøj eller et slettesoftware kan sagtens være i biblioteket, fordi det er et lovligt produkt.
NSRL dækker ikke alt. Opdateringer, nyere versioner, nicheprogrammer og virksomhedens egne programmer mangler ofte.
NSRL er primært amerikansk og engelsksproget. Danske programmer og lokaliserede versioner kan mangle.

NSRL er derfor et filter til at reducere mængden, ikke en vurdering af filernes betydning.

Egne referencesæt i civile sager

I civile sager er de mest værdifulde lister ofte dem, man laver selv:

Virksomhedens egne filer: Hashværdier af tegninger, kundelister, prislister eller kildekode fra virksomhedens systemer kan bruges til at søge efter de samme filer på en privat USB-nøgle, i en privat cloudmappe eller på en ny arbejdsgivers systemer, når der er lovligt grundlag for at undersøge dem. Se den tekniske undersøgelsesplan i Data taget ved fratræden.
Standardinstallationen: Hashværdier af virksomhedens egen standardopsætning af en arbejdsstation filtrerer mere præcist end NSRL, fordi den matcher de faktisk installerede versioner.
Tidligere produktioner: Hashværdier af dokumenter, der allerede er udvekslet i sagen, gør det muligt at undgå at gennemgå dem igen.
Skadelig software: I sager om sikkerhedshændelser bruges hashværdier fra trusselsinformation til at finde kendte filer. De skal suppleres af andre metoder, fordi angribere let ændrer filer.

Referencesættet skal dannes ud fra en kilde, hvis oprindelse kan dokumenteres. Hashværdier af virksomhedens dokumenter bør komme fra en sikret kopi af virksomhedens system, med dato og placering, så det senere kan vises, hvor listen kommer fra.

Fremgangsmåde med et eget referencesæt

Når spørgsmålet er, om bestemte filer fra virksomheden findes et andet sted, kan forløbet se sådan ud:

Afgræns referencesættet sammen med den, der kender dataene: hvilke mapper, systemer og perioder er relevante?
Sikr kilden, før listen dannes, så referencesættet kan føres tilbage til en uændret kopi.
Dan listen med sti, størrelse, tidsstempler og mindst SHA-256 for hver fil, og hash selve listen.
Fjern trivielle filer fra listen: tomme filer, skabeloner, standardlogoer og filer, der også findes offentligt. De giver match uden betydning.
Kør listen mod den sikrede kopi af det medie eller den konto, der undersøges.
Bekræft hvert relevant match ved at sammenligne filerne direkte og ved at undersøge, hvor og hvornår filen er kommet på mediet.
Notér både match og manglende match, så rapporten viser, hvor stor en del af referencesættet der blev fundet.

Trin 4 er vigtigt. Et firmalogo eller en standardskabelon findes på mange medier af naturlige grunde, og et match på dem siger intet.

Hvordan filtreringen virker teknisk

Værktøjet beregner hashværdien af hver fil i kopien og slår den op i listen. Ved match markeres filen. Det kræver, at algoritmen er den samme. En liste med kun MD5 kan ikke bruges mod filer, der kun er hashet med SHA-256. Derfor beregner mange værktøjer flere algoritmer for alle filer.

Filtreringen virker kun på hele filer. Den finder ikke:

dele af en fil, fx et afsnit fra en kundeliste kopieret ind i et andet dokument,
filer, der er gemt igen, konverteret, komprimeret eller indlejret i et arkiv, der ikke er pakket ud,
billeder, der er skaleret, beskåret eller gemt i et andet format,
filer i fragmenter eller ledig plads, som ikke er gendannet som hele filer.

Til næsten ens filer bruges andre metoder. Se Fuzzy hashing.

Fejlkilder

Frasortering af det relevante: Et slette- eller krypteringsprogram, en fjernadgangsklient eller et skript-værktøj kan stå på en kendt god-liste og forsvinde fra visningen. Filtrér derfor visningen, men slet aldrig filer fra analysen, og gennemgå programmappen og spor efter programkørsel særskilt.
Omdøbte filer: En kendt god-fil, der ligger et usædvanligt sted eller under et andet navn, kan være interessant netop på grund af placeringen. Hashmatch fortæller kun indholdet, ikke hvorfor filen ligger der.
Forkert listeversion: Brug en nyere udgave af listen, og notér hvilken. Resultatet kan ikke gentages, hvis versionen ikke er kendt.
Kollisioner: For MD5 og SHA-1 kan der konstrueres filer med samme hashværdi. Det er sjældent relevant i praksis, men et match på en kendt relevant-liste bør bekræftes med SHA-256 eller ved byte-for-byte-sammenligning, før det bærer en konklusion. Se Hashalgoritmer i forensic.
Ingen match er ikke ingen fil: At ingen filer matcher virksomhedens liste, viser kun, at der ikke findes bitidentiske kopier i det undersøgte. Indholdet kan være kopieret i ændret form. Se Fravær af spor.

Brug i eDiscovery

I eDiscovery bruges NSRL-filtrering, typisk kaldet de-NISTing, tidligt i behandlingen for at fjerne systemfiler, før der søges og gennemgås. Det bør fremgå af behandlingsrapporten, at der er filtreret, med hvilken liste og hvor mange filer der blev fjernet. Se Behandling af data i eDiscovery.

Hvad et hashmatch kan og ikke kan bevise

Et match mellem en fil og en kendt hashværdi viser med meget stor sikkerhed, at filen har præcis samme indhold som referencefilen. Det viser ikke, hvordan filen kom på mediet, hvem der lagde den der, eller hvornår. Det kræver filsystemets metadata, artefakter og logs. Et match er altså et startpunkt for den videre analyse.

Dokumentation

Angiv i rapporten:

hvilke lister der er brugt, versioner og algoritmer,
hvordan egne lister er dannet, fra hvilken kilde og hvornår,
antal filer, der er frasorteret, og antal match på relevante lister,
at frasorterede filer er bevaret i kopien og kan gennemgås,
hvordan centrale match er bekræftet.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Hashmanifest for filsamlinger og produktioner · Fuzzy hashing: når en fil næsten er den samme

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