DigitalForensics

70 13 63 23

Downloads og Mark of the Web (Zone.Identifier)

Downloads og Mark of the Web (Zone.Identifier)

Forside › Windows-forensik · Gennemgået oktober 2026 · Af John Nielsen

Når Windows-programmer henter en fil fra internettet eller gemmer en vedhæftet fil, mærkes filen med en skjult datastrøm ved navn Zone.Identifier. Mærket, kaldet Mark of the Web, viser, at filen kom udefra, og indeholder ofte adressen, den blev hentet fra. Det kan besvare spørgsmålet “hvor kom filen fra?”, også når filen er omdøbt, og browserhistorikken er slettet. Sporet forsvinder dog let ved kopiering til andre filsystemer, ved udpakning med visse programmer og ved synkronisering, så fraværet af et mærke beviser intet.

Sådan virker det

NTFS tillader, at en fil har flere datastrømme. Hovedstrømmen er filens indhold. Ekstra strømme, alternate data streams (ADS), har et navn og eget indhold og vises ikke i Stifinder. Zone.Identifier er en sådan strøm med et lille tekstindhold i INI-format, typisk:

  • ZoneId: sikkerhedszonen, hvor 3 betyder internettet og 4 betyder zonen for begrænsede websteder. Lokale filer har ingen strøm.
  • ReferrerUrl: siden, brugeren kom fra, når browseren oplyser det.
  • HostUrl: den direkte adresse, filen blev hentet fra.

Felterne udfyldes af det program, der gemmer filen. Moderne browsere skriver typisk ZoneId og ofte begge adresser. Mailprogrammer markerer gemte vedhæftninger, men med færre detaljer. Kommandolinjeværktøjer, synkroniseringsklienter og mange tredjepartsprogrammer skriver slet ikke strømmen. Microsofts specifikation beskriver kun sektionen ZoneTransfer med ZoneId; de øvrige felter afhænger af det program og den version, der gemte filen, så programmet bør fastslås, før et manglende felt tolkes.

Windows bruger mærket til SmartScreen-advarsler og til Office’ beskyttede visning. Det er derfor et sikkerhedsmærke, ikke et forensisk spor, og det er designet til at kunne fjernes af brugeren med “Fjern blokering” i filens egenskaber.

Hvor sporet findes i en kopi

Zone.Identifier er en del af filens post i $MFT, så den bevares i en fuld forensisk kopi og i en logisk kopi, der understøtter alternate data streams. Forensiske værktøjer viser strømmen som en underfil eller et felt. Ud over selve strømmen kan andre kilder vise, at den har eksisteret:

  • $UsnJrnl registrerer oprettelse og ændring af navngivne datastrømme. Fjernes mærket senere, kan journalen vise, at strømmen blev ændret eller slettet, og hvornår, så længe posten ikke er overskrevet. → NTFS i dybden: MFT, $UsnJrnl og $LogFile
  • Browserens downloads-tabel har filsti, kilde-URL, start- og sluttid. Den er den naturlige parre-kilde. → Browserhistorik som bevis
  • SmartScreen- og Defender-data kan registrere, at en hentet fil blev vurderet eller blokeret.

Hvornår mærket forsvinder eller følger med

Mærket er knyttet til NTFS og til programmernes adfærd. Typiske situationer:

  • Flytning eller kopiering mellem NTFS-volumener med Stifinder · Typisk ja
  • Kopiering til FAT32 eller exFAT, fx en USB-nøgle · Nej, filsystemet har ingen ADS
  • Upload til og download fra cloudlager · Nej ved upload; ny strøm ved ny download
  • Synkronisering via OneDrive eller lignende klient · Normalt nej
  • Udpakning af et mærket zip-arkiv med Windows’ egen funktion · Mærket overføres typisk til de udpakkede filer
  • Udpakning med tredjepartsværktøj · Afhænger af værktøj og version
  • Vedhæftning til en mail og gemning hos modtageren · Ny strøm hos modtageren, oprindelig adresse tabt

Tabellen viser typisk adfærd, ikke en garanti. Flere arkivprogrammer kan overføre mærket, men ofte kun når en bestemt indstilling er slået til, og adfærden har ændret sig mellem versioner. Notér derfor program, version og indstilling, og afprøv på en testfil, hvis et manglende mærke bærer en konklusion.

Er en bestemt adfærd afgørende for konklusionen, bør den afprøves på et tilsvarende testsystem med samme version og program, og afprøvningen beskrives. → Hvad sker der med tidsstemplerne ved kopiering, zip, upload og mail?

Office, beskyttet visning og betroede dokumenter

Når et Office-dokument med Mark of the Web åbnes, vises det i beskyttet visning. I nuværende Office-versioner blokeres makroer i filer fra internettet som standard helt, og knappen til at aktivere dem vises ikke; makroerne kan kun køre, hvis mærket fjernes, placeringen er betroet, eller en politik tillader det. Klikker brugeren “Aktivér redigering” eller, i ældre versioner og andre opsætninger, “Aktivér indhold”, kan Office registrere dokumentet som betroet i brugerens del af registreringsdatabasen, under en nøgle med betroede dokumenter (TrustRecords) for det enkelte program. Posten indeholder dokumentets sti og et tidsstempel og kan dermed vise, at brugeren aktivt valgte at åbne en hentet fil med fuld funktionalitet. Det er et stærkt supplement til Zone.Identifier, fordi det knytter en handling i brugerens profil til den hentede fil. Nøglen ligger under Office-versionens og programmets sikkerhedsindstillinger i NTUSER.DAT. Microsoft dokumenterer ikke værdiernes binære format, så fortolkningen af tidsstempel og eventuel makrostatus bør kontrolleres med mere end ét værktøj.

Sporet er relevant ved spørgsmål om, hvordan en ondsindet vedhæftning blev aktiveret, men det skal læses forsigtigt. En post viser, at indholdet blev aktiveret i profilen, ikke at personen forstod, hvad der skete. → Ondsindede vedhæftninger: hvad der sikres på endpointet

Sådan bruges mærket i en undersøgelse

  1. Find kandidatfilerne i kopien, og udtræk alle Zone.Identifier-strømme med sti, MFT-post og indhold.
  2. Par med browserens downloads-tabel på filnavn, størrelse og tidspunkt. Stemmer adresserne overens, styrker kilderne hinanden.
  3. Kontrollér $UsnJrnl for oprettelse, omdøbning og ændring af strømmen i samme tidsrum.
  4. Se efter efterfølgende brug: programkørsel, LNK-filer og betroede dokumenter.
  5. Notér afvigelser, fx en fil med mærke, men uden post i browseren, og overvej de mulige forklaringer, før der konkluderes.

Sikring

  • Brug en metode, der bevarer ADS. En fuld kopi gør det altid. Ved målrettet indsamling skal værktøjet understøtte NTFS-strømme, ellers mistes sporet uden advarsel. Kopiering til et eksternt drev med exFAT fjerner strømmen.
  • Dokumentér strømmens indhold råt. Gengiv teksten, som den står, med filens fulde sti og MFT-postnummer.
  • Hash både fil og strøm, hvis strømmen indgår som bevis, så indholdet kan efterprøves.

Fejlkilder i fortolkningen

  • Fravær beviser intet. Mangler mærket, kan filen være hentet med et program, der ikke mærker, kopieret via USB, synkroniseret, udpakket eller have fået mærket fjernet. Der er mange uskyldige forklaringer. → Fravær af spor: hvad betyder det?
  • Adressen er ikke nødvendigvis den, brugeren så. HostUrl kan være en mellemstation, et CDN eller en midlertidig adresse fra en cloudtjeneste. ReferrerUrl kan være en søgeside.
  • Strømmen kan skrives manuelt. Indholdet er almindelig tekst og kan oprettes eller ændres. Mærket bør derfor bekræftes af en uafhængig kilde som browserens downloads-tabel eller proxyloggen.
  • Tidspunkt. Strømmen har ingen egen tidsangivelse. Tiden må udledes af filens tidsstempler, $UsnJrnl eller browserdata.
  • Arv ved udpakning. Når mærket overføres fra arkiv til indhold, angiver det arkivets oprindelse, ikke at hver enkelt fil er hentet særskilt.

Hvad mærket kan og ikke kan bevise

Zone.Identifier kan understøtte, at en fil på et NTFS-volumen stammer fra en ekstern kilde, og ofte fra hvilken adresse. Den kan ikke alene vise, hvem der hentede filen, om den blev åbnet, eller hvad der skete med den bagefter. Til det bruges programkørsel, LNK-filer, jump lists og browserdata. Spørgsmålet om filer, der er sendt ud af virksomheden, er en anden retning og belyses af proxy-, firewall- og cloudspor. → Upload til privat cloud: browser-, proxy- og firewallspor

Det tilsvarende spor på Mac

macOS har en parallel mekanisme: en udvidet attribut, der markerer hentede filer, og en database over downloadhændelser med kilde-URL og tidspunkt. Principperne er de samme, herunder at attributten kan fjernes og ikke altid følger med til andre filsystemer. Har en fil været på både Windows og Mac, kan sporene fra de to platforme sammenholdes. → macOS-artefakter

Dokumentation

Rapporten bør angive filens sti, MFT-post, strømmens rå indhold, hash, hvilke supplerende kilder der bekræfter oprindelsen, og hvilke forbehold der gælder for kopiering og arv. Er mærket fjernet, beskrives de spor, der viser det, sammen med de almindelige forklaringer på fjernelse.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: Print i Windows: spool-filer, PrintService-log og printserverens journal · Filserverrevision: hvem åbnede filen?

→ Forensisk undersøgelse af en computer · 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

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.