Forside › Undersøgelse ved fratræden · Gennemgået oktober 2026 · Af John Nielsen
En upload til en privat cloudtjeneste kan sjældent ses direkte, fordi indholdet går krypteret til en tjeneste uden for virksomhedens kontrol. Men den efterlader spor flere steder: i browserens historik, i Windows’ lister over filer valgt i filvalgsdialoger, i statistik over programmers netværksforbrug, i proxy- og firewalllogs og i DNS-opslag. Hvert spor viser en lille del. Kombineret i tid kan de vise, at en bestemt computer sendte en bestemt mængde data til en bestemt tjeneste kort efter, at bestemte filer blev valgt. Den grundlæggende sikring af cloudlagre er beskrevet i Bevissikring af Dropbox og andre cloudlagre, og ledelsens tjekliste for filoverførsler i WeTransfer og filoverførsler. Her er de tekniske spor og deres grænser. Hvor sporene passer ind i den samlede undersøgelse ved fratræden, står i undersøgelsesplanen ved fratræden.
Haster det? Proxy-, firewall- og DNS-logs roteres ofte efter dage eller få uger, og så er netværkssiden af sporet væk. Se akut forensisk sikring; hastesager koster ekstra.
To veje: browser og klient
En upload sker typisk på én af to måder:
- Via browseren på tjenestens webside, hvor brugeren vælger filer i en dialog eller trækker dem ind.
- Via en synkroniseringsklient installeret på computeren, hvor filer lægges i en lokal mappe og sendes i baggrunden.
Sporene er forskellige. Browser-uploads efterlader spor i browserens data og i filvalgsdialogerne. Klient-uploads efterlader spor i klientens egne databaser, i programkørsel og i den lokale synkroniseringsmappe.
Spor på computeren
Browserhistorik
Historikken viser besøgte adresser med tidspunkt og sidetitel. Besøg på upload- eller delingssider hos en cloudtjeneste er et spor, men historikken registrerer typisk ikke selve uploaden eller filnavnene. Synkronisering af historik mellem enheder kan desuden betyde, at et besøg stammer fra en anden enhed med samme browserprofil. → Browserhistorik som bevis
Filvalgsdialoger
Når en fil vælges i Windows’ standarddialog til at åbne eller vedhæfte filer, gemmer registreringsdatabasen en liste over senest valgte filer og mapper pr. filtype og pr. program. Listerne ligger i brugerens del af registreringsdatabasen under nøglen ComDlg32 og er dårligt dokumenteret af Microsoft, så værktøjets tolkning skal være afprøvet. Browsere bruger normalt Windows’ dialog, når en fil vælges til upload. Filer, der trækkes direkte ind i browservinduet, går uden om dialogen og efterlader ikke denne post. En post, der viser, at en bestemt fil blev valgt af browserprocessen kort før en forbindelse til en cloudtjeneste, er et af de stærkeste spor på computeren. Den viser dog kun valget i dialogen, ikke at uploaden blev gennemført.
Programkørsel og netværksforbrug
Er en synkroniseringsklient brugt, kan installation og kørsel ses i de almindelige artefakter for programkørsel. Windows’ ressourcedatabase, SRUM, registrerer desuden netværksforbrug pr. program og bruger i intervaller, herunder sendte og modtagne bytes. En markant mængde sendte data fra browseren eller en klient i et bestemt tidsrum understøtter en upload. → SRUM: netværks- og programforbrug pr. bruger
Klientens egne data
Synkroniseringsklienter har typisk lokale databaser og konfigurationsfiler med kontooplysninger, den lokale mappe og nogle gange fil- eller hændelseslister. Formaterne ændres med versionerne og er ofte krypterede eller dårligt dokumenterede. Brug dem med forsigtighed og kun, hvor værktøjets tolkning er afprøvet.
Filsystemet
Kopier af arbejdsfiler i en lokal synkroniseringsmappe, zip-filer oprettet kort før og sletninger bagefter fremgår af filsystemets tidsstempler og ændringsjournal.
Spor i netværket
Proxy og webfilter
En proxy kan registrere værtsnavn, tidspunkt, HTTP-metode, bytes sendt og modtaget og, hvis der er login på proxyen, brugernavnet. Uden TLS-inspektion ses typisk kun værtsnavnet og datamængden, ikke stien eller filnavnet. Med TLS-inspektion kan stien og nogle gange formularfelter ses, men inspektion er ofte slået fra for netop de kategorier af tjenester, der er interessante, og den rejser sine egne spørgsmål om, hvad medarbejderne er orienteret om. Store udgående datamængder med metoder som POST eller PUT mod en tjenestes uploadadresser er et stærkt indicium. → Proxy- og webfilterlogs
Firewall
Firewallen registrerer sessioner med kilde, destination, port, varighed og bytes i hver retning. Ved NAT skal den interne adresse kobles til den eksterne, og ved dynamisk adressetildeling skal den interne adresse kobles til en bestemt computer via DHCP- eller NAC-logs. → Firewall-logs teknisk og DHCP, Wi-Fi og NAC
DNS
DNS-opslag viser, at en enhed har slået en tjenestes domæne op. Det understøtter, at tjenesten er kontaktet, men opslag sker også ved baggrundsaktivitet, forhåndsindlæsning og indlejret indhold på andre sider.
CASB og sikker webgateway
Har virksomheden en løsning, der inspicerer cloudtrafik, kan den registrere aktivitetstyper som upload, tjenestens kontonavn og nogle gange filnavne. Det er ofte den mest detaljerede kilde, men opbevaringsperioden kan være kort. → SASE, ZTNA og cloudproxy
EDR og DLP
Endpoint-værktøjer til detektion og beskyttelse mod datalæk kan registrere filhændelser, processer og netværksforbindelser med en detaljegrad, som styresystemet ikke selv gemmer, fx at en bestemt proces læste en bestemt fil umiddelbart før en forbindelse til en cloudtjeneste. En DLP-alarm kan også indeholde filnavn og politikmatch. Data ligger typisk i leverandørens konsol og skal eksporteres, før opbevaringsperioden udløber.
Sådan kombineres sporene
En upload underbygges bedst af en kæde, hvor hvert led er uafhængigt:
- En fil eller et arkiv med relevant indhold findes eller har fandtes på computeren.
- Filen er valgt i en dialog af browseren, eller lagt i en synkroniseringsmappe.
- Browseren har besøgt tjenestens side, eller klienten har kørt.
- SRUM viser udgående data fra det pågældende program i tidsrummet.
- Proxy eller firewall viser udgående data til tjenesten fra computerens adresse.
- Datamængden er forenelig med filens størrelse.
Ved punkt 6 skal der tages højde for komprimering, protokoloverhead, gentagne forsøg og anden samtidig trafik. Datamængden kan understøtte, men sjældent identificere en bestemt fil.
Typiske fejlfortolkninger
- Besøg er ikke upload. At en side er besøgt, viser ikke, at noget blev sendt.
- Delte domæner. Mange tjenester bruger fælles CDN- og infrastrukturdomæner, så en forbindelse kan tilhøre noget andet.
- Baggrundssynkronisering. En installeret klient sender data løbende, også uden brugerens aktive handling.
- Tidszoner og ure. Computer, proxy og firewall kan have forskellige ure og tidszoner, og rækkefølgen inden for få sekunder er usikker.
- Den forkerte computer. Uden DHCP- eller NAC-data kan en intern IP-adresse ikke sikkert knyttes til en enhed.
Hvad sporene kan og ikke kan vise
Sporene kan vise, at en computer i virksomheden har sendt data til en bestemt tjeneste på et bestemt tidspunkt, hvor meget og ofte fra hvilket program og hvilken brugerprofil. Kombineret med filvalg og filsystemspor kan de gøre det sandsynligt, at bestemte filer blev sendt. De kan ikke vise, hvad der ligger i den private cloudkonto i dag, om filerne er delt videre, eller hvem der sad ved computeren. Den private konto ligger uden for virksomhedens adgang, og den må ikke åbnes, heller ikke hvis den stadig er logget ind på computeren.
Husk også, at medarbejderen kan have brugt en privat telefon som mellemled, fx ved at åbne filer fra arbejdsmailen på telefonen og uploade derfra. Den vej efterlader ingen spor på arbejdscomputeren og kun begrænsede spor i virksomhedens netværk, hvis telefonen var på mobildata. Det er en begrænsning, der skal nævnes, når netværkssporene er negative.
Sikring i den rigtige rækkefølge
Netværkslogs roteres ofte hurtigst og sikres først med eksport og hashværdier. Derefter sikres computeren forensisk, så registreringsdatabase, SRUM, browserdata og ændringsjournal bevares samlet. Notér tidszone og urafvigelse for hver kilde ved sikringen.
Dokumentation i rapporten
Beskriv hvert led i kæden med kilde, tidspunkt i normaliseret tidszone og den oprindelige værdi. Angiv for netværkslogs, hvordan den interne adresse er knyttet til computeren, og for SRUM, hvilket interval posten dækker. Skriv tydeligt, hvilke led der mangler, og hvad det betyder for vurderingen.
Kilder og versioner
- Microsoft Learn: Common Item Dialog (Windows’ filvalgsdialog)
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
- SWGDE: dokumenter om digital bevissikring
Senest gennemgået: oktober 2026.
Næste skridt
- Kundelisten fra CRM: eksportlogs i SaaS-systemer
- Undersøgelse af en administrator, der kan slette loggen
- Bagdøre efter en administrator: opdagelse og dokumentation
Del af: Undersøgelse ved fratræden
Læs også: Data taget ved fratræden: den tekniske undersøgelsesplan · Mail til privat adresse: message trace, auditlog og vedhæftninger
→ Undersøgelse ved fratræden · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
