Forside › E-mail forensics · Gennemgået oktober 2026 · Af John Nielsen
Når en falsk mail ser ud til at komme fra jeres organisation eller fra en kendt samarbejdspartner, er der fire tekniske forklaringer: Afsendernavnet er forfalsket, afsenderadressen er forfalsket (spoofing), mailen er sendt fra et domæne, der ligner det rigtige (lookalike), eller den er sendt fra en ægte konto, som en uvedkommende har haft adgang til. De fire efterlader forskellige spor, og de kan normalt skelnes ved at se på tre ting: modtagerens headere, afsenderorganisationens Sendt post og afsenderorganisationens transportspor. Svaret har stor betydning, fordi det afgør, hvis systemer der var kompromitteret, og hvilke spor der skal sikres videre.
Haster det? Transportsporet kan kun søges en begrænset periode tilbage, og kontoens loginlog og auditlog udløber også, så eksporten skal ske inden for dage, ikke uger. Se Akut forensisk sikring; hastesager koster ekstra.
Hvad ledelsen bør gøre, når kunder modtager falske fakturaer i virksomhedens navn, er beskrevet på bevissikring-digitalt.dk. Her gennemgås den tekniske skelnen. Om selve mailen er ægte, vurderes efter den samlede metode i Er mailen ægte?.
De fire scenarier
- Visningsnavn · Hvad der er forfalsket: Kun navnet foran adressen · Typiske spor: Adressen er en helt anden, ofte en gratis mailtjeneste
- Spoofing · Hvad der er forfalsket: From-adressen i det rigtige domæne · Typiske spor: Mailen kommer fra en server, der ikke hører til domænet. SPF, DKIM eller DMARC fejler typisk
- Lookalike · Hvad der er forfalsket: Domænet ligner det rigtige · Typiske spor: Mailen består ofte alle kontroller, men for et andet domæne
- Kompromitteret konto · Hvad der er forfalsket: Intet: mailen er sendt fra den ægte konto · Typiske spor: Mailen består kontrollerne for det rigtige domæne og findes i afsenderens systemer
Trin 0: Se på adressen, ikke navnet
Mange mailklienter, især på telefoner, viser kun afsenderens navn og skjuler adressen. En mail, der står som fra “Økonomichefen”, kan komme fra en vilkårlig adresse hos en gratis mailtjeneste. Det er den simpleste variant, og den kræver hverken adgang til jeres systemer eller et særligt domæne. Første skridt er derfor altid at få den fulde afsenderadresse og Reply-To-adressen frem i den rå mail. Er Reply-To en anden adresse end From, er det et væsentligt fund, fordi svar så går til en anden end den tilsyneladende afsender. Er adressen tydeligt fremmed, er spørgsmålet afklaret for denne mail, men det kan stadig være relevant at undersøge, hvor afsenderen fik kendskab til navne, roller og igangværende sager.
Trin 1: Læs modtagerens headere
Udgangspunktet er mailen i rå form fra modtagerens postkasse. Den tekniske gennemgang af headerne findes i Analyse af mail-headere. Til skelnen mellem scenarierne er tre spørgsmål centrale:
- Hvad står der præcist i From? Sammenlign domænet tegn for tegn med det rigtige. Byttede bogstaver, ekstra bindestreger, et andet topdomæne eller tegn fra andre alfabeter, der ligner latinske bogstaver, peger på lookalike.
- Hvad siger modtagerens
Authentication-Results? Fejler DMARC for det rigtige domæne, er spoofing sandsynlig. Består DMARC for det rigtige domæne, er mailen afleveret af en server med ret til at sende for domænet. - Hvilken IP-adresse afleverede mailen? Den afgørende
Received-linje viser, om mailen kom fra afsenderdomænets mailudbyder eller fra en helt anden server.
Hvis From-domænet er det rigtige, og DMARC består med DKIM-signatur fra det rigtige domæne, kan spoofing i praksis udelukkes, og spørgsmålet bliver, om kontoen var kompromitteret, eller om mailen er ægte.
Trin 2: Søg i afsenderens Sendt post
Hvis mailen påstås sendt fra jeres egen konto, søges der i kontoens postkasse efter mailen. Søg på emne, modtager, tidspunkt og Message-ID. Tre udfald er mulige:
- Mailen findes i Sendt post. Den er sendt fra kontoen. Spørgsmålet er nu, om ejeren sendte den.
- Mailen findes ikke, men transportsporet viser afsendelse. Den er sendt fra kontoen og derefter slettet, eller sendt via en vej, der ikke gemmer i Sendt post, fx en API eller en app med egne indstillinger. Begge dele er stærke tegn på kompromittering.
- Mailen findes hverken i postkassen eller i transportsporet. Den er ikke sendt gennem jeres system, og spoofing eller lookalike er forklaringen.
Husk, at en uvedkommende med adgang ofte sletter sendte mails og svar. Søg derfor også i Slettet post og i postkassens gendannelsesmapper, og se på auditloggen for sletninger.
Trin 3: Kontrollér transportsporet
Afsenderorganisationens transportspor er den mest objektive kilde, fordi det registrerer alt, der forlod systemet. Søg efter afsendelser fra kontoen til den pågældende modtager i tidsrummet. Kobl hændelsen til modtagerens eksemplar via Message-ID og tid. Søgevinduet er begrænset, så det skal ske hurtigt; se Message trace og transportlogs. Kører mailen på en lokal Exchange-server eller hos et webhotel, ligger sporene andre steder; se Exchange Server lokalt og hybrid og IMAP-postkasser hos webhoteller.
Trin 4: Ved tegn på kompromittering
Peger trin 2 og 3 på, at mailen er sendt fra kontoen, skifter undersøgelsen karakter til en undersøgelse af kontoen:
- loginlog for kontoen med IP-adresser, enheder og klientapps i perioden,
- indbakkeregler, der flytter eller sletter svar, og videresendelser; se Indbakkeregler og videresendelse,
- nye MFA-metoder, registrerede enheder, aktive sessioner og app-tilladelser; se Hvem er logget ind på kontoen?,
- auditlog for postkassehandlinger, herunder sletning og flytning.
Den samlede fremgangsmåde i Microsoft 365 er beskrevet i BEC-undersøgelse i Microsoft 365 trin for trin. De typiske tegn i loginlog, regler og sendt post er samlet i Er mailen hacket?.
Trin 5: Ved tegn på lookalike
Er domænet et andet end det rigtige, skal lookalike-domænet dokumenteres: registreringsdata, oprettelsesdato, navneservere, MX-poster og eventuelle certifikater. Det kan vise, hvornår domænet blev taget i brug, og om det er brugt mod flere. Fremgangsmåden er beskrevet i Lookalike-domæner. Bemærk, at lookalike-mails ofte indgår i en tråd, hvor de første mails var ægte. Det kan tyde på, at modparten eller en tredjemand har haft adgang til korrespondancen, og så skal kompromittering af en postkasse et andet sted overvejes.
Når to parter er involveret
Ved fakturasvindel mellem to virksomheder er spørgsmålet ofte, hvis postkasse der var kompromitteret. Den uvedkommende kan have læst med hos leverandøren, hos kunden eller hos begge. Samme metode anvendes på begge parters materiale, og resultatet sammenholdes. Fremgangsmåden er uddybet i Fakturasvindel: hvilken af parterne var kompromitteret?.
Typiske fejlslutninger
- “SPF bestod, så mailen er ægte.” SPF gælder konvolutdomænet, ikke nødvendigvis det synlige From. Se på DMARC og alignment.
- “Mailen er ikke i Sendt post, så kontoen er ikke hacket.” Sendte mails kan være slettet, og visse afsendelsesveje gemmer ikke i Sendt post.
- “Domænet er vores, så det er spoofing.” Hvis DMARC består for jeres domæne, er spoofing usandsynlig. Forklaringen ligger så i jeres egne systemer eller hos en tjeneste, der må sende på jeres vegne.
- “Det er et lookalike-domæne, så vi er ikke kompromitteret.” Viden om igangværende tråde og beløb kan stamme fra en kompromitteret postkasse, enten hos jer eller hos modparten.
- Tredjepartstjenester. Nyhedsbrevs-, fakturerings- og CRM-systemer sender ofte på domænets vegne. En konto i en sådan tjeneste kan være kompromitteret, uden at mailsystemet er.
Dokumentation
Sikr undervejs de rå mails fra modtagerne, eksporten af transportsporet, søgeresultaterne fra afsenderens postkasse og, ved kompromittering, loginlog og auditlog for kontoen. Notér for hver eksport tidspunkt, konto, søgeparametre og hashværdi, så hvert trin i beslutningstræet kan efterprøves.
Rapporten bør vise beslutningsvejen: hvilke headere der er læst, hvilke søgninger der er foretaget i postkasse og transportspor, med hvilket tidsrum og hvilket resultat, og hvilke scenarier der dermed er udelukket. Det er lige så vigtigt at dokumentere de søgninger, der ikke gav noget, som dem, der gjorde, fordi konklusionen ofte hviler på fravær af spor i en kilde, der burde have registreret det.
Kilder og versioner
Senest gennemgået: oktober 2026.
Næste skridt
Del af: E-mail forensics
Læs også: Er mailen ægte? En samlet metode ud over headerne · Redigerede mails: tegn på efterfølgende ændring i postkasse eller PST
→ E-mail forensics · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
