Fakturasvindel: hvilken af parterne var kompromitteret?

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

Når en kunde har betalt en faktura til et forkert kontonummer, kan den tekniske del af spørgsmålet ofte afgøres ved at følge den falske mail gennem begge parters mailsystemer. Headeren viser, hvilken organisation og hvilken server mailen faktisk blev afsendt fra. Afsenderens message trace og auditlog viser, om mailen blev sendt fra en rigtig konto. Modtagerens logs viser, om den kom udefra, og om postkassen selv var tilgået. Konklusionen kræver data fra begge sider, analyseret efter samme metode.

Haster det? Loginlogs hos begge parter kan være væk efter 7 til 30 dage, og regler og sendte mails slettes ofte, når kontoen ryddes op. Se akut forensisk sikring; hastesager koster ekstra.

Den juridiske ramme for, hvem der bærer tabet, er beskrevet på digital-bevissikring.dk, og de første timer for virksomheden på Vi har betalt en falsk faktura. Her er den tekniske metode. Analysen af den enkelte mail følger Er mailen ægte?, headerens felter er forklaret i SPF, DKIM og DMARC, og en ændret PDF-faktura i Ændret kontonummer i PDF-fakturaen. Denne artikel gentager ikke headeranalysen, men viser, hvordan den bruges på begge parters data.

De fire grundscenarier

Leverandørens konto er overtaget · Den falske mail er sendt fra leverandørens rigtige server og konto; den findes i leverandørens message trace
Kundens konto er overtaget · Mailen kom fra et lookalike-domæne eller blev ændret efter modtagelse; der er uvedkommende adgang til kundens postkasse
Ingen af kontiene er overtaget · Mailen kom fra et lookalike-domæne eller forfalsket afsender; ingen spor af adgang hos nogen af parterne
Begge er ramt · Spor af uvedkommende adgang begge steder; ofte samme indgangsvej

Det tredje scenarie overses ofte. Angriberen kan have fået kendskab til korrespondancen fra en tredje part, fx en revisor, et bogholderi eller en anden kunde, der var kompromitteret.

Trin 1: Sikr den falske mail i original form

Mailen skal sikres fra modtagerens postkasse som fil med fuld header, eller eksporteres via en administrativ eksport. En videresendt kopi er ikke nok, fordi headeren erstattes. Sikr også de øvrige mails i tråden, både rigtige og falske, så Message-ID og henvisninger til tidligere mails kan følges. → Mailtråde, Message-ID og familierelationer

Trin 2: Læs headeren

Headeren læses nedefra og op. For fakturasvindel er disse felter centrale:

Received-kæden: den første server uden for afsenderens kontrol er den mest pålidelige. Den viser, hvilken server mailen faktisk blev afleveret fra.
Authentication-Results: resultatet af SPF, DKIM og DMARC på modtagerens server. En gyldig DKIM-signatur fra leverandørens domæne betyder, at mailen er sendt gennem en server, der har leverandørens nøgle.
DKIM-signaturens domæne (d=): Er det leverandørens eget domæne, et lookalike-domæne eller en mailtjenestes domæne?
Message-ID: Domænet i Message-ID afspejler ofte det system, der skabte mailen.
Platformsspecifikke felter: I Microsoft 365 indeholder headeren felter, der begynder med X-MS-Exchange-CrossTenant, fx med tenant-id for afsenderorganisationen, ankomsttidspunkt og det netværksmeddelelses-id, som også kan søges på i message trace. Microsoft dokumenterer kun nogle af felterne, så de bør bruges som støtte og kontrolleres mod afsenderens message trace.

Bestået DKIM fra leverandørens domæne og leverandørens tenant-id i headeren peger stærkt mod, at mailen er sendt fra leverandørens eget system. Fejlet DMARC eller et andet domæne peger væk fra det. → Mail-headere, SPF, DKIM og DMARC

Trin 3: Leverandørens side

Bed leverandøren sikre og eksportere:

message trace for den periode, hvor den falske mail blev sendt, søgt på modtager og emne,
auditloggen for den afsendende konto: logins, oprettede regler, sendte og slettede elementer,
loginloggen for kontoen i en periode, der begynder i god tid før den falske mail.

Findes den falske mail i leverandørens message trace som sendt fra kontoen, er det leverandørens system, der har sendt den. Sammen med logins fra fremmede adresser og regler, der skjuler svar, er billedet typisk klart. Findes den ikke, og viser headeren et andet domæne, peger det væk fra leverandørens konto som afsender. Det udelukker ikke, at leverandørens postkasse blev læst. → Message trace og transportlogs

Trin 4: Kundens side

Bed kunden sikre de samme typer data. Her er spørgsmålene:

Kom den falske mail ind udefra, og fra hvilket domæne?
Var der uvedkommende logins eller nye regler på kundens konti, især dem, der modtager fakturaer?
Er den rigtige fakturamail ændret eller erstattet i kundens postkasse? Auditloggen kan vise opdatering, flytning eller sletning af elementer.

Trin 5: Hvem havde læst tråden?

Når den falske mail er et svar i en eksisterende tråd, eller citerer rigtige mails, har angriberen haft adgang til korrespondancen. Tråden ligger i begge parters postkasser, så tråden alene peger ikke på én side. Auditloggens oplysninger om tilgåede mails kan hjælpe: Viser én parts log, at en fremmed session har tilgået netop de mails, er det et stærkt spor. → MailItemsAccessed og mailbox-auditlog

Er den falske faktura en ændret kopi af en rigtig PDF, kan en teknisk sammenligning af filerne vise, hvilket program der har ændret den. Det er beskrevet i Ændret kontonummer i PDF-fakturaen.

Trin 6: Tredjeparter og forudgående hændelser

Peger hverken leverandørens eller kundens logs på uvedkommende adgang, skal kredsen udvides. Hvem andre havde kopi af korrespondancen? Typiske kandidater er en ekstern bogholder, et fakturasystem, der sender på leverandørens vegne, en revisor eller en kollega med delegeret adgang til postkassen. Spørg også, om nogen af parterne tidligere har haft en hændelse, der blev lukket uden undersøgelse. En regel, der blev slettet for et halvt år siden, kan forklare, hvordan angriberen kendte tonen og beløbene.

Tjek desuden, om andre kunder hos leverandøren har fået tilsvarende falske fakturaer. Har flere kunder, der ikke har noget med hinanden at gøre, modtaget samme type mail på samme tid, peger det mod leverandørens side som det fælles punkt. Har kun én kunde fået den, er billedet mere åbent.

Konklusion pr. hypotese

Opstil scenarierne fra tabellen som hypoteser, og vurdér hver af dem mod de fund, der støtter og taler imod. Skriv for hver hypotese, hvilke data der ville have kunnet afkræfte den, og om de data fandtes. Den struktur gør det let for en dommer, en voldgiftsret eller den anden parts sagkyndige at se, hvordan konklusionen er nået, og hvor den er svagest.

Samarbejde mellem to parter

Undersøgelsen kræver typisk data fra modparten. Det giver nogle praktiske krav:

Begge parter bør eksportere de samme felter for samme periode i UTC.
Eksporterne bør hashes og ledsages af en beskrivelse af, hvem der eksporterede og hvordan.
Kan parterne blive enige om én uvildig sagkyndig, eller om at to sagkyndige bruger samme metode, bliver resultaterne sammenlignelige.
Opbevaringstiden for logs løber for begge parter. Bed modparten bevare data tidligt og skriftligt.

Fejlkilder

Manglende logs hos den ene part kan få den anden til at se mere skyldig ud, fordi kun den ene har spor. Fravær af spor er ikke det samme som fravær af kompromittering.
Tidszoner mellem to tenants og eventuelt to platforme.
Mailtjenester og nyhedsbrevssystemer, der sender på vegne af domænet, kan give bestået SPF for mails, leverandøren ikke selv har skrevet.
Videresendte kopier som eneste materiale.

Hvad analysen kan og ikke kan vise

Analysen kan ofte vise, fra hvilket system den falske mail blev sendt, om en af parternes konti har haft uvedkommende adgang, og hvornår. Den kan ikke vise, hvem der stod bag, og den kan ikke vurdere, om en part burde have opdaget svindlen. Hvor logs mangler, skal konklusionen afgrænses til det, data dækker.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Lookalike-domæner: registreringsdata og certifikatlogs som dokumentation · CEO-svindel: analyse af mailtråden

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

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.

Eller kontakt os på