Filserverrevision: hvem åbnede filen?

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

En Windows-filserver kan registrere, hvilken konto der læste, ændrede eller slettede en bestemt fil, og fra hvilken klientadresse. Det kræver to ting, der skal være på plads før hændelsen: en auditpolitik, der slår objektadgang til, og en SACL på mappen, der angiver, hvilke handlinger der skal logges. Mangler en af dem, findes sporet ikke på serveren, og undersøgelsen må bygge på klientens artefakter, NTFS-rettigheder og andre indirekte kilder. Selv når loggen findes, betyder “læst” i loggen ikke nødvendigvis, at et menneske åbnede filen.

Haster det? På en travl filserver kan sikkerhedsloggen kun dække få timer eller dage, før de ældste hændelser overskrives. Se akut forensisk sikring; hastesager koster ekstra.

Sletning på filserveren er beskrevet i Hvem slettede filen?. Her er fokus på læsning og adgang, og hvordan sporene fortolkes.

To lag af konfiguration

Auditpolitikken bestemmer, om Windows overhovedet skriver objektadgang til sikkerhedsloggen. De relevante underkategorier i den avancerede auditpolitik er:

Audit File System · Hændelser: 4656, 4663, 4658, 4660 · Hvad den giver: Adgang til filer og mapper, styret af SACL
Audit Detailed File Share · Hændelser: 5145 · Hvad den giver: Hver adgang til filer via en netværksdeling, med klientens IP-adresse
Audit File Share · Hændelser: 5140 · Hvad den giver: Én hændelse pr. forbindelse til en deling

SACL’en er den del af en mappes sikkerhedsbeskrivelse, der siger, hvem og hvilke handlinger der skal revideres, fx læsning af data for gruppen Everyone. Uden SACL skriver Audit File System intet, selvom underkategorien er slået til. Detailed File Share bruger ikke SACL; den reviderer al adgang via delinger, når den er slået til, og giver derfor meget store mængder hændelser på en travl filserver.

Hvilke indstillinger en undersøgelse har brug for, er gennemgået i Windows audit policy.

Event 4663: adgang brugt

Event 4663 registreres, når en adgangsret faktisk er brugt på et objekt, i modsætning til 4656, der registrerer, at et handle blev anmodet. Hændelsen indeholder:

konto, SID og logon-id,
objektets type og fulde sti,
handle-id, som kobler til 4656 og 4658,
procesnavn og proces-id,
de brugte adgangsrettigheder og adgangsmasken.

Adgangsmasken er det centrale felt. ReadData (0x1) betyder læsning af filens indhold, WriteData (0x2) og AppendData (0x4) betyder skrivning, og DELETE (0x10000) betyder sletning. ReadAttributes (0x80) og READ_CONTROL (0x20000) betyder kun læsning af attributter eller sikkerhedsoplysninger og viser ikke, at indholdet blev læst.

Logon-id kobler hændelsen til en 4624-hændelse, hvor logontype og klientadresse fremgår; se Event 4624 og 4625. Ved netværksadgang er logontypen typisk 3.

Event 5145: adgang via deling

Event 5145 registreres for hver kontrol af adgang til en fil eller mappe via en netværksdeling. Den indeholder delingens navn og lokale sti, den relative sti til filen, de anmodede rettigheder og klientens IP-adresse og port. Det gør den til den bedste kilde til at koble en filadgang til en bestemt klientcomputer.

Hændelsen findes i både en succes- og en fejlvariant. Fejlhændelser er nyttige til at vise forsøg på adgang til mapper, en konto ikke havde ret til.

Hvorfor “læst” ikke altid er læst

ReadData i loggen viser, at en proces med kontoens rettigheder læste fra filen. Mange processer gør det, uden at en person åbner filen:

Stifinder læser filer for at vise miniaturer, forhåndsvisning og egenskaber.
Antivirus på klienten scanner filer, når en mappe åbnes.
Indeksering og synkronisering læser filer i baggrunden.
Backup læser alt, typisk under en tjenestekonto.
Kopiering af en hel mappe giver læsning af alle filer i den.

Mønsteret skelner. En person, der åbner én fil, giver få hændelser for den fil med et program, der passer til filtypen. En kopiering giver mange læsninger af mange filer inden for sekunder. En visning af en mappe i Stifinder giver korte læsninger af mange filer uden efterfølgende aktivitet. Fortolkningen bør beskrive mønsteret, ikke den enkelte post. Tidsrummet mellem første og sidste hændelse for samme handle kan også give et fingerpeg om, hvor længe filen var åben.

På filserveren er procesnavnet ved netværksadgang typisk serverens egen systemproces, ofte med proces-id 0x4, og ikke programmet på klienten. Feltet siger derfor intet om klientens program, og kontoen, logon-id og kildeadressen i 5145 er de pålidelige holdepunkter. Hvilket program der faktisk blev brugt, må derfor findes på klienten.

Spor på klienten

Klientcomputeren supplerer serveren. LNK-filer og jump lists viser filer, brugeren har åbnet, med netværkssti og tidspunkt. Shellbags viser mapper, der er vist i Stifinder. Programmernes egne lister over seneste filer kan vise, at et dokument blev åbnet i et bestemt program. Artefakterne er beskrevet i Windows-artefakter. Kombinationen af 5145 på serveren og en LNK-fil på klienten med samme sti og tidspunkt er stærk dokumentation for, at en bruger åbnede filen.

Uden revision: indirekte kilder

Var objektadgang ikke revideret, er der stadig spor at hente. Sikkerhedsloggens logonhændelser viser, hvilke konti og klienter der var forbundet til serveren i en periode. Filernes tidsstempler for sidste adgang er usikre. Opdateringen kan være slået fra for at spare ydelse, standardværdien har skiftet mellem Windows-versioner, og selv når den er slået til, kan NTFS udskyde skrivningen til disken i op til en time. Kør fsutil behavior query disablelastaccess på serveren, og dokumentér resultatet, før tidsstemplerne bruges. Skyggekopier og backup kan datere, hvornår en fil blev ændret. Filtjenestens egne driftslogs kan vise sessioner, men sjældent enkeltfiler. Konklusionerne bliver mere forsigtige, og rapporten skal sige det tydeligt.

NTFS-rettigheder: hvem kunne

Ud over hvem der gjorde noget, er det ofte relevant, hvem der havde mulighed for det. Eksportér NTFS-rettighederne (DACL) for de relevante mapper og delingsrettighederne for delingerne, og opløs grupper til medlemmer på tidspunktet. Gruppemedlemskaber ændrer sig, så historikken bør hentes fra Active Directorys logs eller tidligere eksporter, hvis perioden ligger tilbage.

Sikring

Eksportér sikkerhedsloggen fra filserveren med det samme. På en travl server med Detailed File Share kan loggen dække få timer eller dage. Se Eksport af Windows-hændelseslogs.
Hent hændelser fra SIEM, hvis loggen er videresendt; det er ofte den eneste kilde til ældre data.
Dokumentér den effektive auditpolitik og SACL’erne på de relevante mapper.
Eksportér DACL og delingsrettigheder.
Sikr klientcomputerne for de konti, der optræder, eller i det mindste deres LNK-filer, jump lists og shellbags.
Kopiér filerne selv, så tidsstempler bevares; se Kopiering af netværksdrev uden at ændre tidsstempler.

Er revisionen ikke slået til, kan den slås til nu for at fange fremtidig adgang. Notér tidspunktet, så det ikke senere fremstår, som om den altid har været slået til.

Hvad sporene kan og ikke kan bevise

Med revision og SACL på plads kan filserveren vise, at en bestemt konto fra en bestemt klientadresse brugte bestemte rettigheder på en bestemt fil på et bestemt tidspunkt. Den kan ikke vise, hvem der sad ved klienten, og den kan ikke skelne sikkert mellem menneskelig åbning og automatisk læsning uden mønsteranalyse og klientspor. Uden revision kan serveren kun vise, hvem der havde adgang.

Kilder og versioner

Microsofts referencesider er arkiveret, men beskriver fortsat hændelserne i aktuelle Windows Server-versioner.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: Downloads og Mark of the Web (Zone.Identifier) · Opstart, nedlukning, lås og dvale: Windows-events

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