Dataudtræk før kryptering: spor efter eksfiltration

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

De fleste ransomwareangreb i dag kombinerer kryptering med tyveri af data, så angriberen kan presse virksomheden med offentliggørelse. Spørgsmålet “blev data hentet ud, og i givet fald hvilke?” er derfor centralt for vurderingen af persondatabrud, for underretning af kunder og for forsikringssagen. Svaret findes sjældent ét sted. Det skal sammensættes af netværkslogs, artefakter på de maskiner, hvor data blev samlet, og logs fra de systemer, data blev hentet fra.

Haster det? Firewallens sessionslogs og flowdata roteres ofte efter dage, og de er tit den eneste kilde til, hvor meget data der forlod netværket. Se akut forensisk sikring; hastesager koster ekstra.

Artiklen handler om udtræk ved et angreb udefra. Den samlede undersøgelse efter angrebet er beskrevet under undersøgelse efter hackerangreb. Om en medarbejder har taget data med ved fratræden, undersøges efter undersøgelsesplanen ved fratræden.

Typisk forløb, set fra sporene

Dataudtræk efterlader spor i flere led:

Opsamling. Data findes og samles, ofte på en enkelt server eller klient. Det giver mange filadgange på kort tid.
Pakning. Data komprimeres til arkiver, ofte delt i flere dele. Det giver store nye filer og kørsel af arkiveringsprogrammer.
Overførsel. Arkiverne sendes ud, typisk til en cloudlagringstjeneste eller en server, angriberen kontrollerer. Det giver udgående trafik i en mængde, der skiller sig ud.
Oprydning. Arkiverne slettes, og værktøjerne fjernes.

Hvert led kan dokumenteres for sig, og en stærk konklusion bygger på flere led, der passer sammen i tid.

Netværket: mængde og destination

Den mest direkte indikation er usædvanligt store mængder udgående data fra én intern adresse til én eller få eksterne destinationer. Kilderne er firewallens sessionslogs med bytetællere, NetFlow eller tilsvarende flowdata, proxylogs og eventuelt EDR-telemetri over netværksforbindelser. Se Firewall-logs teknisk og Proxy- og webfilterlogs.

Vigtigt i fortolkningen:

Bytetællere viser mængde, ikke indhold. 40 GB til en ekstern adresse er et stærkt signal, men det beviser ikke, hvilke filer der var med.
Krypteret trafik (TLS) skjuler indholdet. Domænenavnet kan ofte ses i SNI eller DNS, men selve data kan ikke.
Firewallen logger måske kun sessionens start og ikke den samlede mængde, afhængigt af konfiguration. Kontrollér, hvad der faktisk logges.
Legitime processer som backup til cloud og synkronisering af filer kan give tilsvarende mængder. Sammenlign med normalbilledet for samme adresse.

Maskinen, hvor data blev samlet

På Windows-maskiner kan flere artefakter vise forløbet:

SRUM registrerer netværksforbrug pr. program og bruger i intervaller, også efter at programmet er slettet. Det kan vise, at et bestemt program sendte en bestemt mængde data i et bestemt tidsrum. Se SRUM-databasen.
Prefetch, Amcache og Shimcache kan vise, at arkiveringsprogrammer eller overførselsværktøjer har kørt, og hvornår. Se Prefetch, Amcache og Shimcache.
Filsystemet kan rumme rester af store arkiver i ikke-allokeret plads (unallocated) eller i ændringsjournalen, selv om filerne er slettet. Navne, størrelser og tidspunkter for oprettelse og sletning kan ofte findes i $UsnJrnl.
EDR-telemetri kan vise kommandolinjer, som afslører, hvilke mapper der blev pakket, og hvor arkivet blev sendt hen.

Ved kombinationen af en kommandolinje, der pakker en bestemt mappe, en stor arkivfil i journalen og SRUM-data, der viser udgående trafik fra overførselsværktøjet i samme tidsrum, er konklusionen langt stærkere end ved netværksdata alene.

Kildesystemerne

Hvilke data der blev hentet, ses bedst i de systemer, de blev hentet fra:

Filservere med objektadgangsauditering slået til logger læsning af filer, i Windows typisk Event ID 4663. Er auditeringen ikke slået til, findes sporet ikke.
SharePoint og OneDrive registrerer download og synkronisering i auditloggen. Se Filaktivitet i SharePoint og OneDrive.
Databaser kan have auditlogs over forespørgsler eller eksporter, men det er sjældent slået til som standard.

Uden adgangsrevision i kildesystemet må listen over berørte data ofte udledes indirekte: Hvilke mapper kunne den kompromitterede konto læse, og hvilke mapper optræder i kommandolinjer eller arkivnavne? Den slutning er svagere og skal beskrives som sådan.

Udtræk direkte fra cloud

Ikke alle udtræk går gennem virksomhedens eget netværk. Har angriberen overtaget en konto i Microsoft 365 eller Google Workspace, kan data hentes direkte fra cloudtjenesten til angriberens egen infrastruktur, uden at firewallen ser noget. Sporene ligger da i tjenestens auditlog: masser af download- eller synkroniseringshændelser fra en ukendt adresse eller klient, nye delingslinks, tilføjede apps med læseadgang eller regler, der videresender mail. Eksportér auditloggen for den kompromitterede konto og for hele perioden, og sammenhold kildeadresser og klient-id’er med loginloggen.

Det samme gælder udtræk via e-mail. Store vedhæftninger sendt til eksterne adresser fremgår af message trace og af postkassens sendte poster, hvis de ikke er slettet.

Tidsvinduet

Dataudtræk sker typisk dage eller timer før krypteringen, fordi krypteringen afslører angrebet. Tidsvinduet mellem første kompromittering og kryptering er derfor det relevante søgeområde. Afgræns det med de første og sidste kendte ondsindede handlinger, og søg efter afvigende trafik og filaktivitet i hele vinduet, ikke kun de sidste døgn før krypteringen. Store udtræk spredes nogle gange over flere nætter for at falde mindre i øjnene.

Angriberens egne påstande

Mange grupper offentliggør en liste over filer eller en prøve på en lækageside. Det kan bruges som et spor: Matcher filnavne, mappestrukturer og tidsstempler virksomhedens egne data? Hashværdier af offentliggjorte filer kan sammenholdes med originalerne. Men angriberens påstande om mængde og indhold er ikke pålidelige i sig selv og skal behandles som en påstand, der efterprøves. Det er også værd at være opmærksom på, at besøg på sådanne sider bør foretages kontrolleret, fra et isoleret miljø og dokumenteret, og efter aftale med ledelse og rådgivere.

Hvad der kan og ikke kan konkluderes

Sporene kan typisk vise:

at der var udgående trafik af en bestemt mængde til bestemte destinationer i et bestemt tidsrum,
at bestemte programmer kørte og sendte data,
at bestemte mapper blev pakket, hvis kommandolinjer eller arkivnavne er bevaret,
at bestemte filer blev læst, hvis adgangsrevision var slået til.

De kan sjældent vise præcist, hvilke filer der forlod netværket, medmindre arkivet selv eller en detaljeret fillog er bevaret. Fravær af spor er heller ikke bevis for, at intet blev hentet. Hvis firewallen ikke logger bytemængder, eller hvis de relevante logs er roteret, skal konklusionen sige, at spørgsmålet ikke kan besvares, ikke at der ikke skete noget.

Fra spor til berørte data

Når sporene er samlet, skal de oversættes til de kategorier, databeskyttelsesvurderingen bruger: hvilke registrerede, hvilke datatyper og hvor mange. Den oversættelse er en selvstændig opgave, der er beskrevet i Hvilke persondata blev berørt?. Den tekniske analyse bør levere en tydelig afgrænsning af tre mængder: det, der med sikkerhed er hentet, det, der sandsynligvis er hentet, og det, kontoen havde adgang til.

Dokumentation

Rapporten bør indeholde en tidslinje for de fire led med kilde for hver post, en oversigt over udgående datamængder pr. destination med sammenligning til normalbilledet, de artefakter, der viser pakning og overførsel, og en liste over de kildesystemer, hvor adgang kunne og ikke kunne dokumenteres. Angiv, hvilke logs der manglede, og hvilken betydning det har for konklusionen. Den juridiske betydning af dokumentationen i et erstatningskrav er beskrevet i Erstatning efter persondatabrud.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Indgangsvejen: sådan underbygges konklusionen · Krypterede servere og hypervisorer: hvad kan sikres?

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · 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