Hvem slettede filen? Spor på fil-, server- og cloudniveau

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

Om det kan ses, hvem der slettede en fil, afhænger næsten helt af, hvor filen lå, og om auditing var slået til på forhånd. Filsystemet registrerer typisk, at en fil er slettet, og ofte hvornår, men ikke hvem. Identiteten kommer fra andre lag: papirkurvens placering i en brugerprofil, filserverens sikkerhedslog, hvis objektadgang blev logget, eller auditloggen i en cloudtjeneste. Uden et af disse lag kan sletningen ofte dateres, men ikke tilskrives en konto.

Haster det? Ændringsjournalen overskrives løbende, papirkurve tømmes, og auditlogs har begrænset opbevaring, så sporene efter en sletning kan være væk inden for dage eller uger. Se Akut forensisk sikring; hastesager koster ekstra.

Fra virksomhedens side er spørgsmålet om filservere og manglende logning beskrevet her: → Filserveren på kontoret: hvem åbnede mappen? Denne artikel går i dybden med sporene på hvert niveau.

Lokalt på en Windows-computer

Filsystemet

Når en fil slettes på NTFS, markeres MFT-posten som fri, og klyngerne frigives. Posten kan bestå, indtil den genbruges, og den kan stadig vise filnavn, størrelse og tidsstempler. Ændringsjournalen $UsnJrnl registrerer selve sletningen med tidspunkt og årsagskode, så længe journalen ikke er overskrevet. Ingen af disse strukturer gemmer, hvilken bruger der slettede filen. → NTFS i dybden: MFT, $UsnJrnl og $LogFile

Papirkurven

Sletning via Stifinder flytter normalt filen til papirkurven. På NTFS ligger papirkurven i $Recycle.Bin med en undermappe pr. bruger, navngivet efter brugerens SID. For hver slettet fil oprettes et par: en $I-fil med oprindelig sti, størrelse og slettetidspunkt og en $R-fil med indholdet. Fordi mappen er knyttet til et SID, viser placeringen, hvilken konto der flyttede filen til papirkurven. → Papirkurven i Windows: $Recycle.Bin

Begrænsningerne er vigtige. Shift+Delete, sletning fra kommandolinjen og mange programmer går uden om papirkurven. Filer på netværksdrev og mange flytbare medier kommer heller ikke i den lokale papirkurv. Og når papirkurven tømmes, forsvinder $I– og $R-filerne fra den aktive struktur, selv om de kan findes i MFT og ikke-allokeret plads (unallocated).

Andre spor

Hvis sletningen skete via skallen, kan der være spor i jump lists og LNK-filer for filen før sletningen. EDR-telemetri kan registrere processen, der slettede filen, og den bruger, processen kørte som. Det er ofte den mest direkte kilde, hvis den findes og stadig er opbevaret.

Skyggekopier kan vise, at filen fandtes på et bestemt tidspunkt og var væk ved det næste, og dermed afgrænse sletningen til et tidsvindue. Hvis computeren er domænetilsluttet, kan sikkerhedsloggen på selve klienten også indeholde objektadgangshændelser, men kun hvis auditpolitikken og en SACL på mappen har krævet det. Det er sjældent på almindelige arbejdsstationer.

På en Windows-filserver

En filserver registrerer kun sletning med bruger, hvis objektadgang er slået til, og den relevante mappe har en SACL, der logger sletning. Så kan sikkerhedsloggen indeholde:

• Event 4663 (forsøg på adgang til et objekt), hvor adgangsmasken viser sletning,
• Event 4660 (et objekt blev slettet), som skal kobles til en 4663 via handle-id,
• Event 5145 (detaljeret kontrol af netværksdeling), hvis den underkategori er slået til.

Posterne indeholder kontonavn, SID og logon-id. 4663 og 5145 indeholder også objektets sti, mens 4660 kun har handle-id og derfor ikke kan stå alene. Logon-id kan kobles til en 4624-hændelse og dermed til klientens adresse, og 5145 indeholder desuden selv klientens IP-adresse og port.

Uden auditing viser filserveren kun, at filen mangler. Backup og skyggekopier kan så datere sletningen til et tidsvindue, og serverens logon-hændelser kan vise, hvilke konti der var forbundet i det vindue. Det indsnævrer kredsen, men peger ikke på en bestemt konto. Opsætning og læsning af revisionen på filservere er beskrevet i Filserverrevision: hvem åbnede filen?.

NAS-enheder har egne logfunktioner, som ofte er slået fra som standard. Undersøg enhedens konfiguration og log, før den genstartes eller opdateres.

Microsoft 365: SharePoint og OneDrive

I SharePoint og OneDrive registrerer auditloggen sletning som egne handlinger: FileDeleted, når filen flyttes til webstedets papirkurv, og FileDeletedFirstStageRecycleBin og FileDeletedSecondStageRecycleBin, når den slettes fra første og anden fase af papirkurven. Posten indeholder bruger, tidspunkt, IP-adresse, klient og filens placering. Hvor længe posterne gemmes, afhænger af licens og organisationens opbevaringspolitikker for auditloggen, så perioden skal kontrolleres i den konkrete organisation.

Et vigtigt skel er synkronisering. Slettes en fil lokalt i en OneDrive-synkroniseret mappe, sletter klienten den i skyen, og posten i auditloggen viser brugeren og typisk en synkroniseringsklient som kilde. Slettes den i webgrænsefladen, ses en browser. Det kan afgøre, fra hvilken enhed sletningen kom. → Unified Audit Log i Microsoft 365

Webstedets papirkurv og versionshistorik kan desuden gøre det muligt at gendanne filen og vise, hvem der slettede den, direkte i grænsefladen. Hent dog oplysningerne fra auditloggen, så de kan dokumenteres. → Download og synkronisering i SharePoint og OneDrive

Google Workspace og andre cloudtjenester

Google Drive registrerer i Drive-loggen, når en fil flyttes til papirkurven og slettes permanent, med aktør og tidspunkt. Andre tjenester har tilsvarende logs med varierende detaljegrad og opbevaringstid. Det fælles princip er, at cloudtjenester ofte er bedre til at svare på “hvem” end lokale filsystemer, fordi identiteten er en del af hver forespørgsel.

Sådan kombineres lagene

I praksis kombineres kilderne til et samlet forløb. Et typisk spørgsmål kan undersøges i denne rækkefølge:

1. Fastlæg, hvor filen lå, og om den var lokal, på en filserver, i en synkroniseret mappe eller i skyen. Det afgør, hvilke kilder der overhovedet er relevante.
2. Datér sletningen ud fra $UsnJrnl, papirkurvens $I-fil, backup og skyggekopier eller cloudtjenestens auditlog.
3. Find de konti, der havde adgang i tidsvinduet, ud fra rettigheder og logon-hændelser.
4. Søg efter direkte tilskrivning i papirkurvens SID-mappe, filserverens sikkerhedslog, EDR-telemetri eller auditloggen.
5. Afprøv alternative forklaringer, især synkronisering, automatiske processer og flytning.

Rækkefølgen sikrer, at sletningen er dateret og placeret, før den tilskrives nogen. En tilskrivning uden datering er svag, fordi den ikke kan holdes op mod sessioner og fysiske spor.

Fejlkilder

• Synkroniseret sletning. En sletning i skyen kan vises som en lokal sletning på alle synkroniserede enheder, og omvendt.
• Automatiske processer. Antivirus, opbevaringspolitikker, scripts og synkroniseringskonflikter kan slette filer. Mange sletninger på kort tid er et mønster for sig; se Massesletning: tekniske tegn.
• Flytning frem for sletning. En fil, der mangler et sted, kan være flyttet. Søg efter filen andre steder via hashværdi eller navn.
• Delte konti og sessioner. En post i auditloggen viser kontoen, ikke personen. → Hvem sad ved tastaturet?
• Opbevaringstid. Auditlogs og journaler er begrænsede. En sletning uden for dækningsperioden kan ikke ses.

Hvad sporene kan bevise

Med auditing kan det typisk vises, at en bestemt konto slettede en bestemt fil på et bestemt tidspunkt fra en bestemt klient. Uden auditing kan det ofte vises, at og hvornår filen blev slettet, og hvilke konti der havde mulighed for det. Rapporten bør skelne tydeligt mellem de to situationer og angive for hver kilde, om auditing var slået til, og hvilken periode den dækker.

Dokumentation

Beskriv for hver kilde: hvor filen lå, hvilken auditing der var slået til, hvilke poster der er fundet, og hvordan de er koblet til en konto og en klient. Vedlæg de rå poster eller en eksport med hashværdi, så modparten kan efterprøve koblingen. Angiv også, hvilke alternative forklaringer der er afprøvet, og hvilke spor der afviste dem, så læseren kan se, hvorfor sletningen tilskrives netop denne konto.

Kilder og versioner

• Microsoft Learn: 4660(S) An object was deleted
• Microsoft Learn: 4663(S) An attempt was made to access an object
• Microsoft Learn: 5145(S, F) A network share object was checked
• Microsoft Learn: Audit log activities

Senest gennemgået: oktober 2026.

Næste skridt

• Systemet eller brugeren? Aktivitet, der ligner brugeradfærd
• Bias i forensisk analyse: bekræftelsesbias og kontekstinformation
• Memory forensics: hvad en RAM-kopi kan vise

Del af: Analyse og fortolkning

Læs også: Kontaminering: når undersøgelsen selv efterlader spor · Memory forensics: hvad en RAM-kopi kan vise · Teknisk ordbog

→ Digital forensics-undersøgelse · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT