Microsoft 365 token-tyveri: Hvorfor MFA alene ikke stopper token spraying

Et eksperiment viser, at MFA ikke forhindrer stjålne sessioner: mere end 200.000 mislykkede loginforsøg, 497 vellykkede logins og e-mails om løn og bonusser, der forsvinder ind i skjulte regler. Fokus er på, hvordan man genkender denne form for Microsoft 365 token-tyveri, hvorfor platformens store udbredelse gør angrebet lønsomt, og hvad man bør gøre først i en nødsituation.

Hvad token spraying handler om

Token spraying i Microsoft 365 er navnet på en teknik, som sikkerhedsleverandøren Huntress har observeret i en kampagne. Angriberne gætter ikke adgangskoder. De stjæler sessionstokens, efter at en medarbejder har logget korrekt ind med adgangskode og multifaktorgodkendelse (MFA), og afspiller kort efter disse tokens fra deres egen infrastruktur. Navnet er en reference til password spraying, hvor én adgangskode afprøves mod mange konti. Her spredes og genbruges stjålne loginoplysninger bredt.

Oplysningerne om kampagnen stammer fra Huntress og fra en rapport fra The Hacker News. De bygger på observationer hos kunderne hos én sikkerhedsleverandør og siger intet om alle tenants.

Microsoft 365 token-tyveri: hvad Huntress observerede

Huntress beskriver kampagnen i rapporten Token Replay and Spray. Rapportens præcise udgivelsesdato er ikke sikker; dokumenteret er observationsperioden fra 14. juli 2026 til 22. september 2026. I den periode så Huntress angreb på 79 organisationer, mere end 200.000 mislykkede loginforsøg og 497 vellykkede logins. Der blev oprettet mindst 48 falske enheder i Entra-kataloger. I 19 organisationer blev eksisterende MFA-metoder fjernet og erstattet af en ny.

Så vidt vides rapporteres tallet 97 kompromitterede konti kun af The Hacker News. Det kunne ikke bekræftes i Huntress-rapporten og angives derfor her som et tal fra den rapport. Tallene for de enkelte angrebsbølger afviger desuden lidt fra hinanden inden for Huntress' fremstilling. Til forståelsen er størrelsesordenen nok: med 79 berørte organisationer, 497 vellykkede logins og flere angrebsbølger over cirka ti uger var der ikke tale om et enkeltstående tilfælde, men om en serie.

Sådan adskiller token spraying sig fra password spraying

Password spraying giver mange mislykkede forsøg, fordi de fleste adgangskoder er forkerte. Ved token spraying er loginoplysningerne gyldige. Ifølge Huntress kom de mislykkede forsøg i kampagnen fra angribernes netværk, en stor del af dem fra en hostingudbyder i Tyskland. Det siger intet om udbyderens øvrige kunder. Det hjælper heller ikke meget at blokere enkelte adresser, fordi angriberne skiftede adresser i bølger med en til to ugers ro mellem bølgerne.

Sådan underminerer token replay MFA

Teknikken kaldes også token replay, altså at et stjålet token afspilles igen. Forløbet kan beskrives i fire trin.

1. Lokkemad: En medarbejder modtager en phishing-e-mail eller ledes via social engineering hen til et tredjepartswebsted. Hvordan sådanne e-mails vinder tillid, beskrives i artiklen om elektroniske beskeders ægthed.
2. Opsnapning: Et adversary-in-the-middle-relæ (AiTM) sidder mellem medarbejderen og Microsofts rigtige loginside. Adgangskoden og MFA-anmodningen passerer gennem relæet, som derefter gemmer tokenet. Ved device code phishing bliver offeret i stedet narret til at indtaste en kode på Microsofts rigtige side, som angriberen bruger til at få et token.
3. Afspilning: Få minutter til cirka en time senere bruger angriberen tokenet fra sine egne servere. Hverken adgangskode eller en ny MFA-anmodning er nødvendig.
4. Persistens: Angriberen registrerer sin egen authenticator-app, fjerner eksisterende MFA-metoder eller opretter en falsk enhed. Begge dele overlever en adgangskodeændring.

Pointen er denne: MFA blev ikke brudt. Medarbejderen gennemførte den korrekt. Det, der stjæles, er resultatet, tokenet. MFA kan derfor kun omgås her, hvis tokenet også fungerer uden for medarbejderens enhed. Koder, SMS og push-godkendelser hjælper mod gætning af adgangskoder, men ikke mod denne form for tyveri.

Huntress fandt to familier af værktøjer. Det ene er et script, der identificerer sig med user agent "node" og anmoder om tokens via programmerne Office og Authentication Broker. Det andet afspiller browsersessioner. Logins af den anden slags ligner almindelig browseradgang og er tilsvarende mindre iøjnefaldende.

Microsoft-monokultur: hvorfor Microsoft 365 er det mest lønsomme mål

Microsoft 365 bruges i utallige virksomheder i Tyskland og i resten af verden. Set fra angribernes side er det et økonomisk argument: Et angreb, der er bygget én gang, kan gentages mod et meget stort antal tenants. Loginsiderne ser ens ud overalt, applikations-id'erne er de samme, og det samme gælder fejlkoderne. Det, der virker i én virksomhed, virker med små justeringer i mange andre.

Kampagnen viser denne skalering. Stjålne tokens blev brugt automatisk og inden for få minutter, spredt over 79 organisationer. Ifølge Huntress prioriterede angriberne ikke efter antallet af mislykkede forsøg, men efter hvor der fandtes gyldige loginoplysninger. Sådan fungerer en masseforretning, ikke en målrettet operation mod en enkelt virksomhed.

Udbredelsen er forstærkeren, ikke den eneste årsag

Dette er ikke en generel fordømmelse. Microsoft leverer selv modforanstaltningerne: Conditional Access, Security Defaults og Token Protection. Risikoen opstår, når disse værktøjer ikke bruges eller kun bruges delvist. Angribere tilpasser deres automatisering til standardindstillingerne, fordi de gælder for de fleste tenants. Hver afvigelse, for eksempel et enhedsbundet login eller et blokeret device code flow, koster angriberne arbejde og fjerner grundlaget for masseudnyttelse.

Udbredelsen af Copilot og andre tjenester bag de samme konti øger også gearingen ved en kompromitteret konto. En kritisk vurdering findes i artiklen Copilot under lup. I Microsoft 365 åbner én enkelt konto for e-mail, filer, kalender og chat på samme tid.

Lønsvindel som mål: hvad der sker efter overtagelsen

Efter overtagelsen oprettede angriberne i kampagnen skjulte indbakkeregler. De flyttede eller slettede e-mails med betalingsrelaterede ord som løn, indskud eller bonus. Målmapperne havde uskyldige navne som "RSS Feeds" eller "Conversation History". I ét tilfælde blev en e-mail om løn sendt videre til en ekstern skatterådgiver. Svar blev markeret som læst og flyttet væk, så offeret ikke skulle opdage dem.

Bag dette ligger business email compromise (BEC): Målet er at omdirigere overførsler eller få lønkonti ændret. I et andet tilfælde blev en postkasse misbrugt til at sende spam til hundredvis af eksterne modtagere, indtil Entra ID Protection klassificerede kontoen som højrisiko.

For små virksomheder er det særligt følsomt. Ofte arbejder kun få personer med regnskab og HR. En ændret konto opdages sent, og lønadministrationen ligger ofte hos tredjepart. Ledelsen beslutter da, om betalinger skal kaldes tilbage, og om banken, skatterådgiveren og lønkontoret skal informeres. Det hører hjemme i nødplanen, ikke først i krisen.

Typiske spor: ny authenticator-app, ukendte Entra-enheder, indbakkeregler

Kampagnen efterlader spor i Microsoft Entra ID, brugeradministrationen bag Microsoft 365, som kan kontrolleres uden specialværktøj. Følgende tabel opsummerer de vigtigste. Navnemønstrene stammer fra Huntress-rapporten og kan ændre sig.

Fejlkode 53003 fortjener opmærksomhed. En blokering fra Conditional Access opfattes normalt som en succes for politikken. Men den viser også, at en person uden for virksomheden har gyldige loginoplysninger eller et gyldigt token. En sådan post er en grund til at undersøge kontoen. Indbakkeregler, der er oprettet via et API, vises ikke altid i brugerfladen. De bliver synlige via Exchange admin center eller PowerShell.

Små virksomheder uden logovervågning ser ofte kun tingene bagefter. Hvor længe login-logs opbevares, afhænger af licensen og bør afklares på forhånd, for uden logs forbliver omfanget af en hændelse ukendt.

Conditional Access: bloker device code flow og kræv MFA for alle klienttyper

Device code flow er en loginmetode til enheder uden tastatur eller browser. Angribere misbruger den ved device code phishing, hvor brugere får til at indtaste en kode på en anden enhed. I sin dokumentation om blokering af godkendelsesflows anbefaler Microsoft at komme så tæt på en fuldstændig blokering som muligt og kun tillade flowet i veldokumenterede undtagelser, for eksempel ældre værktøjer, der ikke kan opdateres.

Politikken oprettes i Entra admin center under Entra ID, Conditional Access, Policies. Betingelsen er "Authentication flows" med valget "Device code flow", og adgangskontrollen er "Block access". Microsoft anbefaler først at køre politikken i tilstanden "Report-only" og først derefter aktivere den. To nødadgangskonti udelades, og deres liste bør gennemgås regelmæssigt.

Licens: Conditional Access eller Security Defaults

Ifølge Microsoft Learn kræver Conditional Access mindst Microsoft Entra ID P1 (forudsætning ifølge dokumentationen om godkendelsesstyrker). Virksomheder uden denne licens har Security Defaults, som ifølge Microsoft ikke kræver nogen licens. De beskyttelsesforanstaltninger, der er opført dér, omfatter MFA-registrering for alle brugere, blokering af ældre protokoller og blokering af device code flow. Microsoft oplyser også, at alle nye Entra-tenants fra 1. juli 2026 blokerer device code flow som en del af Security Defaults. Ifølge Microsoft kan Security Defaults ikke tilpasses, kun slås til eller fra. Den, der har brug for undtagelser eller mere detaljerede regler, har brug for Conditional Access.

MFA til alle, uden undtagelser for apps eller klienter

En basispolitik bør kræve MFA for alle brugere, alle ressourcer og alle klienttyper eller blokere adgangen. Det er netop det krav, der stilles i Huntress-rapporten, og huller opstår ofte på grund af velmente undtagelser som "kun adminportaler" eller "kun browser". Ældre protokoller som IMAP, POP3 og SMTP-godkendelse understøtter ikke MFA og bør blokeres.

Phishing-resistente metoder som FIDO2-sikkerhedsnøgler eller Windows Hello for Business beskytter langt bedre mod AiTM-opsnapning end koder, SMS eller push-godkendelser. Microsoft nævner et samspil mellem godkendelsesmetoden og loginfladen som kendetegn ved styrken "Phishing-resistant MFA" (godkendelsesstyrker). Denne side indeholder ingen eksplicit udtalelse om AiTM, så vurderingen er forfatterens egen konklusion. Hvordan man opretter en basispolitik med godkendelsesstyrke, beskrives på siden MFA for alle brugere. Det giver mening at starte med administratorer.

Token Protection og dets grænser

Token Protection er en sessionskontrol i Conditional Access. Den accepterer kun login-tokens, der er kryptografisk bundet til en registreret enhed. Et stjålet token virker så ikke på en anden enhed. Ifølge Microsoft Learn (siden pr. august 2026) er funktionen generelt tilgængelig for native applikationer på Windows, iOS, iPadOS og macOS og gælder for Exchange Online, SharePoint Online og Teams. På Windows kommer Windows 365 og Azure Virtual Desktop til. Siden indeholder ingen separate licensoplysninger, så licenskravet må afklares særskilt. Som en Conditional Access-funktion kræver Token Protection mindst Entra ID P1, ifølge forfatterens egen slutning. Det er ikke et citat fra Microsoft.

Grænserne er klart angivet. Browserbaserede applikationer understøttes kun i preview og kun for udvalgte webapps, der bruger Azure Resource Manager. Outlook på nettet er derfor ikke dækket. Desuden skal enheder være Entra-registrerede, -joinede eller hybrid-joinede. Apple-enheder skal være administrerede enheder med single sign-on-udvidelsen. For virksomheder med private enheder er det en reel hindring.

Token Protection reducerer token replay, men fjerner ikke risikoen. Microsoft anbefaler en pilotgruppe, tilstanden "Report-only" og en evaluering af login-logs før en bred udrulning. En kompatibel enhed som adgangsbetingelse, begrænsning af samtykke til nye apps og regelmæssig gennemgang af nye enterprise-applikationer hjælper også. Phishing-resistent MFA og enhedsbaseret adgang reducerer risikoen; overvågning opdager det, der alligevel slipper igennem.

Nødprocedure: tilbagekald sessioner, ryd op i enheder og MFA-metoder

Den følgende rækkefølge er forfatterens anbefaling, afledt af Microsofts dokumentation om tilbagekaldelse af adgang og Huntress-rapporten. Det er ikke et officielt krav. Den generelle fremgangsmåde efter et vellykket angreb beskrives i artiklen Ransomware: handlingsplan for de første 60 minutter, og dele af den kan bruges her.

1. Bloker kontoen og tilbagekald sessioner: I Entra admin center under Brugere fravælges "Account enabled" og "Revoke sessions" vælges, eller via PowerShell med Revoke-MgUserSignInSession. Det forhindrer nye tokens.
2. Nulstil adgangskoden: I hybride miljøer anbefaler Microsoft at nulstille adgangskoden to gange i den lokale Active Directory. Sessioner tilbagekaldes derefter igen.
3. Kontroller MFA-metoder: Ukendte metoder, især en ny authenticator-app, fjernes. Den rigtige bruger opsætter først derefter sine metoder, helst med en bekræftende tilbagekaldelse pr. telefon.
4. Kontroller enheder: Ukendte registrerede enheder deaktiveres og slettes. De er et tegn på persistens.
5. Ryd op i postkassen: Regler, videresendelser, delegeringer og transportregler kontrolleres og fjernes. Sendte og slettede elementer gennemgås for alt usædvanligt.
6. Kontroller apps: Ukendte enterprise-applikationer og app-samtykker fjernes.
7. Fastslå omfanget: Login-logs fra det tidligste mistænkelige tidspunkt evalueres. Andre konti i samme afdeling bør også overvejes, da kampagnen ofte ramte flere konti pr. organisation.
8. Vurder de forretningsmæssige konsekvenser: Er bankoplysninger, lønoplysninger eller fakturaer blevet ændret? Banken, skatterådgiveren og lønkontoret informeres, betalinger stoppes, og ændringsanmodninger bekræftes pr. telefon. Ledelsen træffer denne beslutning.
9. Vurder anmeldelsespligten: Om en anmeldelse til tilsynsmyndigheden er påkrævet, afhænger af risikoen. Fristen er 72 timer efter, at man er blevet bekendt med bruddet (artikel 33 i GDPR). Dette er ikke juridisk rådgivning.

Hvorfor tilbagekaldelsen ikke virker med det samme

Ifølge Microsoft er adgangstokens som standard gyldige i en time. Tilbagekaldelse blokerer nye tokens og gør refresh tokens ugyldige, men adgangstokens, der allerede er udstedt, forbliver gyldige, til de udløber. For applikationer med egne sessionscookies skal applikationen selv afslutte adgangen. Continuous Access Evaluation (CAE) forkorter denne tid til få minutter for Exchange Online, SharePoint Online og Teams, ifølge Microsoft med en forsinkelse på op til 15 minutter. Huntress rapporterer, at adgangstokens forblev gyldige i op til omkring 90 minutter, og at en nulstilling af adgangskoden alene hverken fjerner falske enheder eller MFA-metoder. Begge dele hører sammen: Et klik på "Revoke sessions" er en begyndelse, ikke enden.

Hvad administratorer og direktører kan kontrollere i denne uge

• Er device code flow blokeret, eller er Security Defaults aktiveret?
• Kræver en politik MFA for alle brugere, ressourcer og klienttyper uden app-undtagelser?
• Er ældre protokoller som IMAP, POP3 og SMTP-godkendelse blokeret?
• Findes der to nødadgangskonti, som er udelukket fra politikker og sikret særskilt?
• Er godkendelsesmetoder, enheder og indbakkeregler i regnskab og HR gennemgået?
• Er det klart, hvem der beslutter ved mistanke, og hvilken serviceudbyder der kan kontaktes uden for åbningstiden?

Hos IT-serviceudbyderen kommer det an på reaktionstid, adgang til logs, kendskab til politikkerne og skriftlig dokumentation af undtagelser. Et eksternt blik på konfigurationen kan være nyttigt, for eksempel gennem sikkerhedstjek. Virksomhedens egen hjemmeside og mail-domæne er også en del af angrebsfladen. Webstedstjekket ser på hjemmesiden udefra, men kontrollerer ikke Entra-indstillinger.

Den store udbredelse gør Microsoft 365 til det oplagte mål. Den, der strammer standardindstillingerne, holder øje med enheder og metoder og gennemgår nødsituationen på forhånd, fjerner grundlaget for automatisering. Nøgternt set handler det mindre om panik end om konfiguration og rutine.