Tokenstöld i Microsoft 365: Därför räcker inte MFA ensamt mot token spraying

Ett experiment visar att MFA inte hindrar stulna sessioner: över 200 000 misslyckade inloggningsförsök, 497 lyckade inloggningar och e-postmeddelanden om löner och bonusar som försvinner i dolda regler. Fokus ligger på hur man känner igen tokenstöld i Microsoft 365, varför plattformens stora spridning gör attacken lönsam och vad man bör göra först i en nödsituation.

Vad token spraying handlar om

Token spraying i Microsoft 365 är namnet på en teknik som säkerhetsleverantören Huntress observerade i en kampanj. Angriparna gissar inte lösenord. De stjäl sessionstokens efter att en anställd har loggat in korrekt med lösenord och multifaktorautentisering (MFA), och spelar strax därefter upp dessa tokens igen från sin egen infrastruktur. Namnet anspelar på password spraying, där ett lösenord prövas mot många konton. Här sprids och återanvänds i stället stulna inloggningsuppgifter brett.

Uppgifterna om kampanjen kommer från Huntress och från en rapport av The Hacker News. De bygger på iakttagelser hos kunder till en enskild säkerhetsleverantör och säger ingenting om alla tenants.

Tokenstöld i Microsoft 365: vad Huntress observerade

Huntress beskriver kampanjen i rapporten Token Replay and Spray. Det exakta publiceringsdatumet för rapporten är osäkert; det som är dokumenterat är observationsperioden från 14 juli 2026 till 22 september 2026. Under den tiden såg Huntress attacker mot 79 organisationer, över 200 000 misslyckade inloggningsförsök och 497 lyckade inloggningar. Minst 48 falska enheter skapades i Entra-kataloger. I 19 organisationer togs befintliga MFA-metoder bort och ersattes med en ny.

Såvitt känt rapporteras siffran 97 komprometterade konton endast av The Hacker News. Den kunde inte bekräftas i Huntress-rapporten och anges därför här som en uppgift från den rapporten. Siffrorna för de enskilda attackvågorna skiljer sig också något inom Huntress egen redovisning. För sammanhanget räcker storleksordningen: med 79 drabbade organisationer, 497 lyckade inloggningar och flera attackvågor under ungefär tio veckor var detta inte ett enstaka fall utan en serie.

Så skiljer sig token spraying från password spraying

Password spraying ger många misslyckade försök, eftersom de flesta lösenord är fel. Vid token spraying är inloggningsuppgifterna giltiga. Enligt Huntress kom de misslyckade försöken i kampanjen från angriparnas nätverk, en stor del av dem från en hostingleverantör i Tyskland. Det säger ingenting om leverantörens övriga kunder. Att blockera enskilda adresser hjälper också föga, eftersom angriparna bytte adresser i vågor, med en till två veckors vila mellan vågorna.

Så underminerar token replay MFA

Tekniken kallas också token replay, vilket betyder att en stulen token spelas upp på nytt. Förloppet kan beskrivas i fyra steg.

1. Lockbete: En anställd får ett nätfiskemejl eller leds till en tredjepartssida genom social engineering. Hur sådana mejl vinner förtroende beskrivs i artikeln om äktheten hos elektroniska meddelanden.
2. Avlyssning: Ett adversary-in-the-middle-relä (AiTM) placerar sig mellan den anställda och Microsofts riktiga inloggningssida. Lösenordet och MFA-frågan passerar reläet, som sedan sparar token. Vid device code phishing luras offret i stället att ange en kod på Microsofts riktiga sida, och angriparen använder koden för att få en token.
3. Uppspelning: Några minuter till ungefär en timme senare använder angriparen token från sina egna servrar. Varken lösenord eller en ny MFA-fråga behövs.
4. Persistens: Angriparen registrerar sin egen autentiseringsapp, tar bort befintliga MFA-metoder eller skapar en falsk enhet. Båda överlever ett lösenordsbyte.

Poängen är denna: MFA knäcktes inte. Den anställda slutförde den korrekt. Det som stjäls är resultatet, token. MFA kan därför kringgås här bara om token också fungerar utanför den anställdas enhet. Koder, SMS och push-godkännanden hjälper mot lösenordsgissning, men inte mot den här typen av stöld.

Huntress hittade två familjer av verktyg. Det ena är ett skript som identifierar sig med user agent "node" och begär tokens via programmen Office och Authentication Broker. Det andra spelar upp webbläsarsessioner. Inloggningar av det andra slaget ser ut som vanlig webbläsaråtkomst och är motsvarande mindre iögonfallande.

Microsoft-monokultur: varför Microsoft 365 är det mest givande målet

Microsoft 365 används i otaliga företag i Tyskland och världen över. Ur angriparnas synvinkel är det ett ekonomiskt argument: en attack som byggts en gång kan upprepas mot ett mycket stort antal tenants. Inloggningssidorna ser likadana ut överallt, applikations-ID:na är desamma, och det gäller även felkoderna. Det som fungerar hos ett företag fungerar hos många andra med små justeringar.

Kampanjen visar den här skalningen. Stulna tokens användes automatiskt och inom några minuter, spridda över 79 organisationer. Enligt Huntress prioriterade angriparna inte efter antalet misslyckade försök, utan efter var giltiga inloggningsuppgifter fanns. Så drivs en massverksamhet, inte en riktad operation mot ett enskilt företag.

Spridningen är förstärkaren, inte den enda orsaken

Detta är ingen svepande fördömelse. Microsoft levererar själv motåtgärderna: Conditional Access, Security Defaults och Token Protection. Risken uppstår när de här verktygen inte används, eller bara delvis. Angriparna skräddarsyr sin automatisering efter standardinställningarna, eftersom de gäller för de flesta tenants. Varje avvikelse, till exempel en enhetsbunden inloggning eller ett blockerat device code-flöde, kostar angriparna möda och tar bort grunden för massutnyttjande.

Spridningen av Copilot och andra tjänster bakom samma konton ökar också hävstången hos ett komprometterat konto. En kritisk bedömning finns i artikeln Copilot under luppen. I Microsoft 365 öppnar ett enda konto e-post, filer, kalender och chatt på samma gång.

Lönebedrägeri som mål: vad som händer efter övertagandet

Efter övertagandet skapade angriparna i kampanjen dolda inkorgsregler. Dessa flyttade eller raderade e-post som innehöll betalningsrelaterade ord, till exempel lön, insättningar eller bonus. Målmapparna hade ospektakulära namn som "RSS Feeds" eller "Conversation History". I ett fall skickades ett lönemejl vidare till en extern skatterådgivare. Svar markerades som lästa och flyttades undan så att offret inte skulle märka dem.

Bakom detta ligger business email compromise (BEC): målet är att omdirigera överföringar eller få lönekonton ändrade. I ett annat fall missbrukades en brevlåda för att skicka skräppost till hundratals externa mottagare tills Entra ID Protection klassade kontot som högrisk.

För småföretag är detta särskilt känsligt. Ofta arbetar bara några få personer med ekonomi och HR. Ett ändrat konto upptäcks sent, och löneadministrationen sköts ofta av externa. Ledningen avgör då om betalningar ska återkallas och om banken, skatterådgivaren och lönebyrån ska informeras. Det hör hemma i beredskapsplanen, inte först i krisen.

Typiska spår: ny autentiseringsapp, okända Entra-enheter, inkorgsregler

Kampanjen lämnar spår i Microsoft Entra ID, användarhanteringen bakom Microsoft 365, som kan kontrolleras utan specialverktyg. Följande tabell sammanfattar de viktigaste. Namnmönstren kommer från Huntress-rapporten och kan ändras.

Felkod 53003 förtjänar uppmärksamhet. Ett block av Conditional Access ses oftast som en framgång för regeln. Men det visar också att någon utanför företaget har giltiga inloggningsuppgifter eller en giltig token. En sådan post är skäl att granska kontot. Inkorgsregler som skapats via ett API syns inte alltid i användargränssnittet. De blir synliga via Exchange admin center eller PowerShell.

Småföretag utan logövervakning ser ofta saker först i efterhand. Hur länge inloggningsloggar sparas beror på licensen och bör klargöras i förväg, eftersom omfattningen av en incident förblir okänd utan loggar.

Conditional Access: blockera device code-flödet och kräv MFA för alla klienttyper

Device code-flödet är en inloggningsmetod för enheter utan tangentbord eller webbläsare. Angriparna missbrukar det vid device code phishing genom att få användare att ange en kod på en annan enhet. I sin dokumentation om att blockera autentiseringsflöden rekommenderar Microsoft att man kommer så nära ett fullständigt block som möjligt och tillåter flödet endast i väldokumenterade undantag, till exempel äldre verktyg som inte kan uppdateras.

Regeln skapas i Entra admin center under Entra ID, Conditional Access, Policies. Villkoret är "Authentication flows" med valet "Device code flow", och åtkomstkontrollen är "Block access". Microsoft rekommenderar att först köra regeln i läget "Report-only" och först därefter aktivera den. Två nödåtkomstkonton undantas, och deras lista bör granskas regelbundet.

Licens: Conditional Access eller Security Defaults

Enligt Microsoft Learn kräver Conditional Access minst Microsoft Entra ID P1 (förutsättning enligt dokumentationen om autentiseringsstyrkor). Företag utan den licensen har Security Defaults, som enligt Microsoft inte kräver någon licens. Skyddsåtgärderna som anges där omfattar MFA-registrering för alla användare, blockering av äldre protokoll och blockering av device code-flödet. Microsoft uppger också att alla nya Entra-tenants från 1 juli 2026 blockerar device code-flödet som en del av Security Defaults. Enligt Microsoft kan Security Defaults inte anpassas, bara slås på eller av. Den som behöver undantag eller mer detaljerade regler behöver Conditional Access.

MFA för alla, utan undantag för appar eller klienter

En grundregel bör kräva MFA för alla användare, alla resurser och alla klienttyper, eller blockera åtkomst. Det är exakt det krav som ställs i Huntress-rapporten, och luckor uppstår ofta genom välment avsedda undantag som "bara adminportaler" eller "bara webbläsare". Äldre protokoll som IMAP, POP3 och SMTP-autentisering stöder inte MFA och bör blockeras.

Phishingresistenta metoder som FIDO2-säkerhetsnycklar eller Windows Hello for Business skyddar mycket bättre mot AiTM-avlyssning än koder, SMS eller push-godkännanden. Microsoft nämner ett samspel mellan autentiseringsmetoden och inloggningsytan som kännetecken för styrkan "Phishing-resistant MFA" (autentiseringsstyrkor). Den sidan innehåller inget uttryckligt påstående om AiTM, så den här bedömningen är författarens slutsats. Hur man skapar en grundregel med autentiseringsstyrka beskrivs på sidan MFA för alla användare. Det är rimligt att börja med administratörer.

Token Protection och dess gränser

Token Protection är en sessionskontroll i Conditional Access. Den accepterar bara inloggningstokens som är kryptografiskt bundna till en registrerad enhet. En stulen token fungerar då inte på en annan enhet. Enligt Microsoft Learn (sidan i läget augusti 2026) är funktionen allmänt tillgänglig för inbyggda program på Windows, iOS, iPadOS och macOS och gäller Exchange Online, SharePoint Online och Teams. Windows 365 och Azure Virtual Desktop tillkommer på Windows. Sidan innehåller ingen separat licensinformation, så licenskravet måste klargöras separat. Som en Conditional Access-funktion kräver Token Protection minst Entra ID P1, enligt författarens egen slutsats. Det är inte ett citat från Microsoft.

Begränsningarna är tydligt angivna. Webbläsarbaserade program stöds endast i förhandsversion och bara för utvalda webbappar som använder Azure Resource Manager. Outlook på webben omfattas alltså inte. Dessutom måste enheter vara Entra-registrerade, anslutna eller hybridanslutna. Apple-enheter måste vara hanterade enheter med single sign-on-tillägget. För företag med privata enheter är detta ett verkligt hinder.

Token Protection minskar token replay men eliminerar inte risken. Microsoft rekommenderar en pilotgrupp, läget "Report-only" och utvärdering av inloggningsloggarna före en bred utrullning. En kompatibel enhet som åtkomstvillkor, begränsat godkännande för nya appar och regelbunden granskning av nya företagsapplikationer hjälper också. Phishingresistent MFA och enhetsbaserad åtkomst minskar risken; övervakning upptäcker det som ändå tar sig igenom.

Nödrutin: återkalla sessioner, städa upp enheter och MFA-metoder

Följande ordning är författarens rekommendation, härledd ur Microsofts dokumentation om att återkalla åtkomst och Huntress-rapporten. Det är inget officiellt krav. Det allmänna tillvägagångssättet efter en lyckad attack beskrivs i artikeln Ransomware: åtgärdsplan för de första 60 minuterna, och delar av den kan tillämpas här.

1. Blockera kontot och återkalla sessioner: I Entra admin center under Users avmarkeras "Account enabled" och "Revoke sessions" väljs, eller via PowerShell med Revoke-MgUserSignInSession. Det förhindrar nya tokens.
2. Återställ lösenordet: I hybridmiljöer rekommenderar Microsoft att lösenordet återställs två gånger i den lokala Active Directory. Sessionerna återkallas sedan igen.
3. Kontrollera MFA-metoder: Okända metoder, särskilt en ny autentiseringsapp, tas bort. Den verkliga användaren ställer in sina metoder först därefter, helst med en bekräftelse via återuppringning per telefon.
4. Kontrollera enheter: Okända registrerade enheter inaktiveras och raderas. De är ett tecken på persistens.
5. Städa brevlådan: Regler, vidarebefordran, delegeringar och transportregler kontrolleras och tas bort. Skickade och raderade objekt granskas med avseende på allt ovanligt.
6. Kontrollera appar: Okända företagsapplikationer och app-godkännanden tas bort.
7. Fastställ omfattningen: Inloggningsloggar från den tidigaste misstänkta tidpunkten utvärderas. Även andra konton på samma avdelning bör beaktas, eftersom kampanjen ofta drabbade flera konton per organisation.
8. Bedöm verksamhetens konsekvenser: Har bankuppgifter, lönedata eller fakturor ändrats? Banken, skatterådgivaren och lönebyrån informeras, betalningar stoppas och ändringsönskemål bekräftas per telefon. Ledningen fattar det beslutet.
9. Bedöm anmälningsplikten: Om en anmälan till tillsynsmyndigheten krävs beror på risken. Fristen är 72 timmar efter att man fått kännedom (artikel 33 GDPR). Detta är ingen juridisk rådgivning.

Varför återkallelsen inte gäller omedelbart

Enligt Microsoft är åtkomsttokens giltiga i en timme som standard. Återkallelse blockerar nya tokens och gör uppdateringstokens ogiltiga, men åtkomsttokens som redan utfärdats förblir giltiga tills de löper ut. För program med egna sessionscookies måste programmet självt avsluta åtkomsten. Continuous Access Evaluation (CAE) förkortar den tiden till några minuter för Exchange Online, SharePoint Online och Teams, enligt Microsoft med en fördröjning på upp till 15 minuter. Huntress rapporterar att åtkomsttokens förblev giltiga i upp till ungefär 90 minuter och att enbart ett lösenordsbyte varken tar bort falska enheter eller MFA-metoder. Båda hör ihop: att klicka på "Revoke sessions" är en början, inte slutet.

Vad administratörer och verkställande direktörer kan kontrollera den här veckan

• Är device code-flödet blockerat, eller är Security Defaults aktiverade?
• Kräver en regel MFA för alla användare, resurser och klienttyper utan undantag för appar?
• Är äldre protokoll som IMAP, POP3 och SMTP-autentisering blockerade?
• Finns det två nödåtkomstkonton som är undantagna från regler och skyddade separat?
• Har autentiseringsmetoder, enheter och inkorgsregler på ekonomi och HR granskats?
• Är det klart vem som beslutar vid misstanke och vilken tjänsteleverantör som kan nås utanför kontorstid?

När det gäller IT-leverantören är det svarstid, åtkomst till loggar, kunskap om reglerna och skriftlig dokumentation av undantag som räknas. En extern blick på konfigurationen kan vara till nytta, till exempel genom säkerhetskontrollerna. Företagets egen webbplats och maildomän är också en del av angreppsytan. Webbplatskontrollen granskar webbplatsen utifrån men kontrollerar inte Entra-inställningar.

Den stora spridningen gör Microsoft 365 till standardmålet. Den som skärper standardinställningarna, håller koll på enheter och metoder och går igenom nödsituationen i förväg tar bort grunden för automatiseringen. Nyktert sett handlar det mindre om panik än om konfiguration och rutin.