AiTM‑phishing: kendetegn på stjålne sessioner i loginloggen

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

Ved AiTM-phishing (adversary-in-the-middle) logger brugeren ind på en falsk side, der i realtid videresender alt til den rigtige tjeneste. Brugeren gennemfører totrinsgodkendelsen helt korrekt, men den sessionscookie, tjenesten udsteder, opsnappes og genbruges et andet sted. I loginloggen ser det derfor ud, som om totrinskravet er opfyldt. Kendetegnene ligger ikke i ét felt, men i mønstret: en session, der skifter IP-adresse, klient eller land på kort tid, og et login, hvis adresse ikke passer med brugerens.

Haster det? Både interaktive og ikke-interaktive logins gemmes i Entra ID kun 7 dage uden premiumlicens og 30 dage med, så mønstret kan være væk efter en uge. Se akut forensisk sikring; hastesager koster ekstra.

Artiklen handler om at genkende og dokumentere mønstret i Microsoft Entra ID og lignende identitetsudbydere. Den beskriver ikke, hvordan sådanne angreb udføres. Mekanikken bag sessioner og tokens er forklaret i Sessioner og tokens: når adgangen fortsætter, og loggens felter i Entra ID sign-in logs.

Hvorfor totrinsgodkendelse ikke stopper det

Almindelig totrinsgodkendelse beskytter adgangskoden: Den, der kun har koden, kommer ikke ind. Den beskytter ikke en session, der allerede er etableret. Ved AiTM er det brugerens egen godkendelse, der etablerer sessionen, og cookien, der beviser sessionen, er det, der stjæles. Metoder, der binder godkendelsen til det rigtige domæne, som passkeys og FIDO2-nøgler, er langt mindre sårbare, fordi de ikke vil godkende over for et falsk domæne. Det er derfor relevant at dokumentere, hvilken godkendelsesmetode brugeren faktisk anvendte.

Mønstret i loginloggen

Et typisk forløb set fra loggen har to faser.

Fase 1: Det videresendte login. Et interaktivt login med adgangskode og totrinsgodkendelse, der lykkes. IP-adressen er ikke brugerens, men den falske sides server, ofte hos en hosting- eller cloududbyder. Brugeragenten kan ligne en almindelig browser, fordi den falske side videresender brugerens egen. Tidspunktet ligger typisk få sekunder efter, at brugeren klikkede på linket i mailen.

Fase 2: Genbrug af sessionen. Kort efter dukker logins eller tokenfornyelser op fra en anden IP-adresse, ofte i et andet land eller netværk, hvor totrinskravet står som opfyldt af et krav i det eksisterende token frem for en ny godkendelse. Identifikatorer fra fase 1 kan gå igen. I Entra-loggen er det bl.a. korrelations-id (correlationId) og den unikke tokenidentifikator, og afhængigt af eksportmetoden også et sessions-id. Microsoft angiver selv, at korrelations-id bygger på oplysninger fra klienten og ikke kan garanteres, så et sammenfald bør understøttes af andre felter.

Kendetegn, der tilsammen peger mod AiTM:

et vellykket interaktivt login med totrinsgodkendelse fra en adresse, brugeren ikke har brugt før,
samme session brugt fra to eller flere adresser inden for minutter eller timer,
skift i operativsystem eller browser midt i en session,
logins fra en enhed, der ikke er registreret eller ikke overholder virksomhedens politikker, selv om brugeren normalt kun bruger administrerede enheder,
en risikovurdering fra identitetsudbyderen, fx for usædvanligt token eller anonym IP-adresse, hvis den funktion er tilgængelig,
umiddelbart efterfølgende ændringer: nye indbakkeregler, ny godkendelsesmetode eller app-samtykke.

Ingen af punkterne er afgørende alene. Det er kombinationen og rækkefølgen, der gør mønstret genkendeligt.

Den anden side: mailen og klikket

Loginloggen viser kun halvdelen. Den anden halvdel er mailen, der førte brugeren til den falske side, og klikket:

Message trace og selve mailen viser afsender, tidspunkt og det link, der blev brugt.
Linkbeskyttelse (fx Safe Links) og proxy- eller DNS-logs kan vise, at brugeren besøgte det falske domæne, og hvornår. → Proxy- og webfilterlogs
Browserhistorik på brugerens enhed kan bekræfte besøget og vise den fulde adresse.

Når tidspunktet for klikket ligger få sekunder før fase 1-loginet, er sammenhængen stærk. Sikring af selve mailen og den falske side er beskrevet i Phishing-analyse: sikring af mail, link og landingsside.

Skel fra andre forklaringer

Et login med opfyldt totrinskrav fra en fremmed adresse har flere mulige forklaringer, og rapporten bør vise, at de er overvejet:

AiTM-phishing · Klik på et link lige før, interaktivt login fra en serveradresse, derefter genbrug fra en anden adresse
Stjålne cookies fra brugerens enhed · Ingen phishingmail eller klik; sessionen er etableret fra brugerens egen enhed og adresse og dukker senere op et andet sted; spor af skadelig software på enheden
Træthedsangreb på godkendelser · Mange godkendelsesanmodninger, som brugeren til sidst accepterer; adgangskoden var kendt i forvejen
Brugerens egen rejse eller VPN · Klient og enhed er de kendte; ingen ændringer i regler eller metoder bagefter
Delt eller udlånt konto · Kendt enhed hos en anden person; ingen phishingspor

Stjålne cookies fra en inficeret enhed ligner AiTM i fase 2, men ikke i fase 1. Skelnen er vigtig, fordi den peger på forskellige indgangsveje og dermed på forskellige spørgsmål om ansvar og om, hvilke enheder der skal undersøges. Mistanke om skadelig software betyder, at brugerens enhed skal sikres, før den renses. → EDR-telemetri som bevis

Sikring

Eksportér interaktive og ikke-interaktive loginlogs for den berørte bruger i en periode, der begynder før mailen blev modtaget.
Eksportér risikohændelser og risikable logins, hvis de findes i tenantens licens.
Eksportér auditloggen for samme periode, så ændringer efter loginet kommer med.
Sikr phishingmailen med header og det fulde link, og relevante proxy- eller DNS-logs.
Tilbagekald sessioner, og eksportér loggene igen bagefter for at vise, at den stjålne session er afbrudt.

Brug eksporter i rå form frem for portalens visning. Portalen kan gruppere eller skjule felter, som er nødvendige for at følge en session på tværs af adresser. → Eksport af Entra ID-loginlogs

Hvis brugeren har klikket, men intet ses

Et klik på et AiTM-link betyder ikke nødvendigvis, at sessionen blev stjålet. Hvis brugeren afbrød, før totrinsgodkendelsen blev gennemført, eller hvis en politik for betinget adgang afviste loginet, står det i loggen som et mislykket eller afbrudt forsøg. Dokumentér også det: Et afvist login fra den falske sides adresse er et positivt fund, der viser, at forsøget fandt sted, og at det blev stoppet.

Fejlkilder

Brugerens egen VPN eller mobilnet kan give skift i IP-adresse midt i en session. Mobile enheder skifter mellem Wi-Fi og mobilnet hele tiden.
Virksomhedens egne proxyer og sikkerhedstjenester kan stå som kildeadresse og skjule brugerens reelle adresse.
Geolokation er en database over netværksregistreringer. Den kan placere en dansk mobilbruger i et andet land. → IP-adresser som bevis
Linkscannere åbner links i mails automatisk og kan stå som besøg på det falske domæne, uden at brugeren har klikket.
Udløbne logs. Ikke-interaktive logins fylder meget og har samme begrænsede opbevaring som de interaktive: på tidspunktet for gennemgangen (oktober 2026) 7 dage uden premiumlicens til Entra ID og 30 dage med.

Hvad det kan og ikke kan bevise

Mønstret kan underbygge, at en session blev etableret via en mellemmand og genbrugt fra en anden adresse, og dermed at adgangen ikke krævede, at brugeren afgav sin kode og sin godkendelse to gange. Det kan forklare, hvorfor totrinsgodkendelse ikke forhindrede adgangen. Det kan ikke identificere, hvem der stod bag de fremmede adresser. Det kan heller ikke alene vise, om virksomhedens opsætning var forsvarlig. Det er en vurdering, der kræver kendskab til de politikker, der var gældende.

Dokumentation

Rapporten bør vise de to faser side om side med tidspunkter i UTC, IP-adresser, klientoplysninger, godkendelsesdetaljer og de felter, der knytter sessionerne sammen. Forklar kort, hvad et sessionstoken er, og hvorfor totrinskravet kan stå som opfyldt uden ny godkendelse. Henvis fra hvert punkt til den rå eksport, og beskriv alternative forklaringer, du har overvejet og udelukket.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: OAuth-apps og samtykke-phishing: ukendte app-tilladelser · Password spray og brute force: mønstre i loginloggen

→ 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