BEC‑undersøgelse i Microsoft 365 trin for trin

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

En BEC-undersøgelse (business email compromise) i Microsoft 365 skal besvare fem spørgsmål: hvornår kontoen første gang blev brugt af en uvedkommende, hvordan adgangen blev opnået, hvordan den blev fastholdt, hvilke mails der blev læst, og hvilke der blev sendt. Svarene ligger i Entra ID’s loginlogs, i Purview-auditloggen og i postkassen selv, og flere af dem forsvinder eller ændres, så snart nogen rydder op. Rækkefølgen er derfor: sikr først, analysér bagefter.

Haster det? Entra ID-loginlogs gemmes kun 7 eller 30 dage efter licens, og regler, apps og videresendelse forsvinder, når kontoen ryddes op. Se akut forensisk sikring; hastesager koster ekstra.

Artiklen er metoden for den, der skal lave undersøgelsen. Hvad virksomheden skal gøre i de første minutter, står på Hacket mailkonto: sikr sporene, før I nulstiller. De enkelte trin er uddybet i Indbakkeregler og videresendelse og Entra ID sign-in logs, og den tilsvarende undersøgelse i Google står i Overtaget Google Workspace-konto.

Før du går i gang: undersøg uden at forurene

Undersøgelsen bør foregå fra en særskilt administratorkonto med de mindst nødvendige rettigheder, fx en rolle, der kan læse og eksportere auditlog, men ikke ændre postkasser. Så kan dine egne handlinger skilles fra angriberens i loggen. Log ikke ind som den berørte bruger for at “se, hvad der ligger der”. Det skaber nye logins fra din adresse, kan markere mails som læst og gør tidslinjen sværere at læse. Notér dine egne IP-adresser og tidspunkter i arbejdsnoterne, så de kan filtreres fra senere. Brug så vidt muligt eksporter frem for skærmbilleder, og skriv ned, hvilke kommandoer eller portalfunktioner der er brugt, med version og dato.

Trin 1: Sikr, før der ryddes op

Eksportér følgende for den berørte konto, og helst for hele tenanten i den relevante periode:

Entra ID-loginlogs, både interaktive og ikke-interaktive,
Entra-auditloggen (godkendelsesmetoder, app-samtykker, enhedsregistreringer, rolleændringer),
Purview-auditloggen (Unified Audit Log) for postkassehandlinger og administrative ændringer,
postkassens regler, videresendelsesindstillinger, delegeringer og tilknyttede mobilenheder,
message trace for sendte og modtagne mails i perioden.

Sæt postkassen på bevarelse (hold), så slettede elementer ikke renses ud under undersøgelsen. Registrér, hvem der eksporterede, med hvilken konto og hvornår, og beregn hashværdier af eksportfilerne. Opbevaringstiden for loginlogs og auditlog afhænger af licens, så eksporten haster. På tidspunktet for gennemgangen (oktober 2026) gemmer Entra ID login- og auditlogs i 7 dage uden premiumlicens og i 30 dage med. Purview-auditloggen gemmer som standard 180 dage, og længere med de udvidede auditlicenser. → Unified Audit Log i Microsoft 365

Trin 2: Find det første uvedkommende login

Start i loginloggen og arbejd baglæns fra den hændelse, der udløste sagen. Kig efter:

IP-adresser og autonome systemer, der ikke passer med brugerens normale mønster, fx hostingudbydere,
nye klienter og brugeragenter, især browsere eller værktøjer, brugeren ikke selv bruger,
en ændring i godkendelsesmetode, fx et login, der opfylder totrinskravet uden at brugeren har godkendt noget,
sessions- og korrelations-id’er, der går igen fra en mistænkelig adresse.

De ikke-interaktive logins viser tokenfornyelser og overses ofte. De kan vise, at en session har levet videre i dage efter det første login. Feltbetydninger og fejlkoder er gennemgået i Entra ID-loginlogs, og sessionernes mekanik i Sessioner og tokens.

Trin 3: Fastlæg indgangsvejen

De almindelige indgangsveje efterlader hver sine spor:

Phishing med falsk loginside · Phishingmailen i message trace, klik i proxy- eller Safe Links-data, første login kort efter
Stjålet session (AiTM) · Login fra ny adresse med gyldigt totrinskrav, uden registreret godkendelse fra brugeren
Gættet eller genbrugt kodeord · Mange mislykkede logins før det første vellykkede
Samtykke til en app · Hændelse om samtykke i auditloggen, app med brede mailrettigheder

Indgangsvejen er ofte den konklusion, der får størst betydning i en efterfølgende tvist. Den bør kun angives som fastlagt, når mindst to uafhængige spor peger samme vej. Ellers skrives den som den mest sandsynlige forklaring med angivelse af, hvad der mangler.

Trin 4: Find fastholdelsen

Angribere sikrer sig typisk adgang på flere måder. Gennemgå auditloggen for:

Indbakkeregler, der flytter, markerer som læst eller sletter mails med ord som “faktura”, “betaling” eller bestemte afsendere. Oprettelsen ses som hændelser for nye eller ændrede regler med tidspunkt og klient-IP. → Indbakkeregler og videresendelse
Videresendelse på postkasseniveau til en ekstern adresse.
Nye godkendelsesmetoder, fx en telefon eller authenticator-app, der er registreret til kontoen.
App-samtykker og nye app-registreringer.
Registrerede enheder og mobilenheder, der synkroniserer postkassen.
Delegeringer, fx fuld adgang eller “send som” til en anden konto.

Dokumentér hver af dem med navn, indhold, tidspunkt og den konto og IP-adresse, der oprettede dem, før de fjernes.

Trin 5: Hvad blev læst?

Hændelsen MailItemsAccessed kan vise, hvilke mails der er tilgået, og fra hvilken session. Den skelner mellem enkeltvis adgang og synkronisering af hele mapper, og ved synkronisering kan man ofte kun sige, at en mappe blev hentet, ikke hvilke mails der blev åbnet. Hændelsen var tidligere forbeholdt de udvidede auditlicenser, men hører nu til de handlinger, postkasse-auditeringen logger som standard. Det gælder dog kun, hvis postkassens standardsæt af audithandlinger ikke er ændret, og for ældre perioder kan hændelsen mangle. Er hændelsen ikke til stede, må omfanget vurderes ud fra sessionens varighed og klienttype, og det skal stå som en begrænsning. → MailItemsAccessed og mailbox-auditlog

Trin 6: Hvad blev sendt?

Brug message trace og postkassens mappe “Sendt” sammen. Angribere sletter ofte sendte mails, så auditloggens hændelser for sletning og flytning skal med. Saml en liste over modtagere, emner og tidspunkter for mails sendt fra den mistænkelige session, og sikr de originale mails med header fra modtagerne, hvis de selv er slettet hos afsenderen. Listen er grundlaget for at advare modtagere og for at afgrænse et eventuelt persondatabrud.

Trin 7: Andre berørte konti

En overtaget konto bruges ofte til at sende phishing internt eller til kunder og leverandører. Søg i loginloggen efter de samme IP-adresser, brugeragenter og sessionsmønstre på andre konti, og søg i message trace efter de mails, kontoen sendte internt. Et fund på én konto er en grund til at udvide undersøgelsen, ikke en grund til at lukke den.

Trin 8: Saml tidslinjen

Læg fundene fra trin 2 til 7 i én tidslinje i UTC: første uvedkommende login, indgangsvej, oprettelse af regler og metoder, læste mapper, sendte mails og tidspunktet for lukning. Sæt den økonomiske hændelse ind, fx hvornår en falsk betalingsanmodning blev sendt, og hvornår modtageren betalte. Tag til sidst en ny eksport af loginlog og auditlog efter lukningen. Den viser, om der er forsøg på adgang bagefter, og dermed om alle veje ind er fundet.

Typiske fejlkilder

Brugerens egne rejser og VPN kan give logins fra fremmede lande.
Mobilapps fornyer tokens løbende og kan fylde loggen med ikke-interaktive logins fra mobilnettets adresser.
Geolokation angiver netværkets registrering, ikke en fysisk placering.
Portalvisninger kan være i lokal tid, mens eksporter er i UTC.
Oprydning før eksport fjerner regler og apps, og auditloggen viser så kun, at de blev slettet.

Hvad undersøgelsen kan og ikke kan vise

En komplet undersøgelse kan typisk vise et forløb fra første login til lukning med tidspunkter, adresser, fastholdelse og sendte mails. Den kan sjældent identificere, hvem der stod bag, ud over netværksadresser og tekniske kendetegn. Hvor logs mangler eller er udløbet, skal konklusionen afgrænses tilsvarende.

Rapporten

Saml fundene i en tidslinje med kilde for hver post, angiv logkildernes periode og tidszone, og læg de rå eksporter med hashværdier i bilag. Beskriv tydeligt, hvilke spørgsmål der ikke kunne besvares, og hvorfor.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Sessioner og tokens: når adgangen fortsætter efter skift af adgangskode · OAuth-apps og samtykke-phishing: ukendte app-tilladelser

→ 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