Microsoft 365-phishing trots MFA: så kapas sessioner

Microsoft 365-phishing handlar om mer än dåliga e-postmeddelanden och förfalskade inloggningssidor. Angrepp börjar i ett komprometterat företagskonto, leder till övertygande eller legitima Microsoft-sidor och slutar trots MFA i postlådan, SharePoint eller Teams.

Halvårsrapporten 2026/1 från det schweiziska federala cybersäkerhetskontoret berör schweiziska företag. Under första halvåret 2026 ökade rapporterna om komprometterade Microsoft 365-konton. De användes för phishing och bedrägeri. Angripare utgav sig för att vara IT-support eller chefer och kringgick kontroller med sessionstoken, Device Code Phishing eller reverse proxy-servrar.

MFA är fortfarande oumbärligt. Alla metoder är inte phishing-resistenta. En bekräftad session kan bli målet för ett angrepp. Microsoft 365 måste skyddas som en identitetsplattform, inte bara som en e-posttjänst.

Så fungerar Microsoft 365-phishing trots MFA

Efter kontroll av lösenord, andra faktor, enhetsstatus och villkor utfärdar Entra ID token eller sessionscookies. Precis som med ett besökskort är det därefter framför allt giltigheten som räknas. Om de hamnar hos någon annan behöver personen i vissa fall inte genomgå kontrollen igen.

Olika typer av token i Microsoft Entra ID har olika uppgifter och livslängd. Det avgörande är att en stulen token eller en token som gjorts tillgänglig för angriparen kan representera en autentiserad session.

Adversary-in-the-Middle-phishing med reverse proxy

Vid Adversary-in-the-Middle (AiTM) placerar sig phishing-infrastrukturen mellan webbläsaren och Microsoft och vidarebefordrar den riktiga inloggningen i realtid:

1. Ett e-postmeddelande hänvisar exempelvis till ett SharePoint-dokument, ett röstmeddelande, en faktura eller en signatur.
2. Länken leder via angriparens reverse proxy till Microsoft-inloggningen.
3. Användarnamn, lösenord och MFA-svar vidarebefordras till Microsoft.
4. Microsoft godkänner den bekräftade inloggningen och skapar sessionen.
5. Proxyservern fångar upp sessionscookien eller token. Åtkomsten upphör först när de löper ut, återkallas eller blockeras.

MFA har inte knäckts. Användaren bekräftade en session som avlyssnades. TOTP-koder och pushbekräftelser förhindrar inte i grunden denna vidarebefordran. FIDO2-nycklar, Windows Hello for Business och korrekt använda passkeys binder däremot inloggningen kryptografiskt till den legitima tjänsten. Inte heller de skyddar mot skadlig kod på en inloggad enhet eller all stöld av sessioner.

Device Code Phishing via en riktig Microsoft-sida

Device Code Flow är avsett för enheter där textinmatning är besvärlig. En konferensrumsenhet eller ett kommandoradsprogram visar en kod som bekräftas via Microsoft på en andra enhet.

Angripare startar själva processen och skickar koden under falska förespeglingar. När den matas in på den riktiga Microsoft-sidan hamnar token i deras session. Domänen och certifikatet är korrekta, men en främmande inloggning auktoriseras. Microsoft klassar flödet som riskfyllt och rekommenderar att det blockeras när det saknas ett dokumenterat behov.

E-postflod, falsk IT-support och phishing i flera led

En angreppskedja börjar med hundratals nyhetsbrev, registreringsmeddelanden och aviseringar. De skapar stress och döljer riktiga varningar. Därefter kräver en påstådd IT-support via Teams eller telefon åtkomst med Quick Assist eller ett fjärradministrationsverktyg. Därmed kan angriparen köra kommandon, installera skadlig kod, läsa webbläsardata och stjäla inloggningsuppgifter. Det är arbetsstationen som övertas, inte inloggningen.

Efter övertagandet använder angriparen äkta korrespondens, kända leverantörer och konversationstrådar för manipulerade fakturor, ytterligare phishing och nya kontoövertaganden. SPF, DKIM och DMARC räcker inte när meddelandet kommer från en legitim Microsoft 365-tenant.

Vad MFA klarar och var gränsen går

MFA förhindrar många kontoövertaganden eftersom ett lösenord inte längre räcker. Metoderna skiljer sig åt:

• Lösenord plus SMS, telefonsamtal eller enkel pushbekräftelse: bättre än enbart lösenord, men sårbart för social engineering, SIM-swapping, MFA-fatigue och phishing i realtid.
• TOTP eller Authenticator med Number Matching: mer robust mot oavsiktliga bekräftelser, men en kod kan vidarebefordras direkt via en AiTM-sida.
• Phishing-resistent autentisering: FIDO2, Windows Hello for Business, certifikatbaserad autentisering och passkeys verifierar den legitima tjänsten kryptografiskt och minskar AiTM-inloggningar avsevärt.

Risker kvarstår: en infekterad endpoint kan läsa sessioner, en OAuth-app kan få bestående rättigheter och en användare kan bekräfta främmande enhetskoder eller fjärråtkomst. Phishing-resistent MFA är central, men inte ett komplett säkerhetskoncept.

Härda Microsoft Entra ID på ett genomtänkt sätt

Conditional Access och Token Protection kräver lämpliga Entra-licenser, och enhetsvillkor kräver en bas av hanterade enheter. Policyer bör först testas i Report-only-läge med en pilotgrupp.

Prioritera phishing-resistent inloggning

Den första utrullningen bör omfatta administratörer, ekonomiansvariga, företagsledning och helpdesk. Conditional Access Authentication Strengths kan kräva Windows Hello for Business, FIDO2-nycklar, passkeys eller certifikatbaserad autentisering för dessa grupper.

Det kräver en återställningsprocess med minst två registrerade metoder, kontrollerade reservenheter och separat övervakade nödkonton. En förlorad nyckel får varken orsaka långa avbrott eller undantag som lätt kan manipuleras via helpdesk. Passkeys lämpar sig även för inloggning i Sophos Central, men även där måste återställning och enhetsbyte planeras.

Kontrollera och blockera om möjligt Device Code Flow

Användningen kan inventeras i Entra Sign-in Logs via Authentication protocol > Device code. Konferensrumsenheter, äldre verktyg eller kommandoradsprogram kan vara beroende av flödet. Om det saknas ett motiverat behov skapas en policy under Entra ID > Conditional Access > Policies:

1. Välj ordinarie användare eller grupper.
2. Undanta nödkonton och motiverade tekniska undantag.
3. Välj om möjligt All resources under Target resources, och använd snävare mål endast när det är motiverat.
4. Aktivera Device code flow under Conditions > Authentication flows.
5. Blockera åtkomst under Grant.
6. Använd först Report-only, granska loggarna och aktivera policyn därefter.

Undantag bör vara snävt avgränsade, dokumenterade och kopplade till specifika konton eller resurser.

Knyt åtkomst till hanterade enheter

Conditional Access kan kräva en kompatibel eller Microsoft Entra-ansluten enhet för känsliga appar. Det försvårar tokenmissbruk på okända enheter, men påverkar BYOD, gäster, mobila enheter och specialklienter. Därför måste enhetsbestånd, operativsystem och appar vara kända. Inaktuella poster, svag registrering eller generösa undantag undergräver kontrollen.

Testa Token Protection målinriktat

Token Protection binder kompatibla sign-in-session-token kryptografiskt till den utfärdande enheten och försvårar replay på andra system. Funktionen kräver Entra ID P1 och omfattar endast vissa plattformar, appar och resurser. I Windows skyddar den framför allt kompatibla inbyggda Microsoft 365-appar. Apple-enheter kräver hantering och Microsoft Enterprise SSO Plug-in. Apples appar Mail och Kalender stöder för närvarande inte Token Protection.

Införandet börjar snävt avgränsat i Report-only. Därefter granskas Token Protection Status Details, klienter och resurser i Sign-in Logs. Kravet aktiveras först när kompatibiliteten har bekräftats. Webbläsare, äldre programvara och specialenheter bedöms separat.

Kontrollera Teams och fjärradministration

Det måste fastställas vilka externa domäner eller tenants som användare får kontakta via Teams och hur externa deltagare identifieras. För support gäller följande:

• Fjärradministration startas endast med ett ärende eller ett verifierat återuppringningssamtal till ett känt nummer.
• Oväntade Quick Assist-sessioner från chattar eller telefonsamtal godkänns inte.
• Tillåtna fjärradministrationsverktyg dokumenteras och övervakas.
• Okända RMM-verktyg blockeras eller utlöser larm via Application Control, AppLocker, Windows Defender Application Control eller motsvarande kontroller.
• En ovanlig e-postflod rapporteras till IT eller Security och behandlas inte enbart som spam.

Awareness-utbildning måste återspegla dessa processer. Sophos Phish Threat blir effektivare med tydliga rapporteringsvägar, Teams-scenarier och ett realistiskt helpdesk-runbook.

Vilka spår administratörer bör granska

En lyckad MFA-händelse bevisar inte att inloggningen var legitim. Vid AiTM eller Device Code kan faktorn ha bekräftats av användaren själv. Identitet, postlåda, endpoint och kommunikation måste undersökas tillsammans.

Microsoft Entra Sign-in Logs

Loggarna finns under Entra ID > Monitoring & health > Sign-in logs och kan läsas med minst rollen Reports Reader. Beroende på misstanken bör interaktiva och icke-interaktiva inloggningar, Service Principals och Managed Identities ingå i analysen. Relevant är:

• okända eller inkompatibla enheter samt ovanliga IP-adresser, regioner, appar och klienter,
• Device code som Authentication Protocol,
• nya kombinationer av webbläsare eller enheter efter en normal inloggning,
• ovanlig åtkomst till Exchange Online, SharePoint eller Microsoft Graph,
• resultatet från Conditional Access, uppfyllda autentiseringskrav och
• lyckad åtkomst utan förväntad användarinteraktion via befintliga token.

En enda signal räcker inte. En schweizisk IP-adress kan tillhöra mobilnät eller VPN, och en inloggning från utlandet kan vara affärsmässigt motiverad. Det är kombinationen av användare, enhet, tidpunkt, app och efterföljande aktivitet som avgör.

Exchange Online, Audit och endpoint

Efter ett övertagande söker angripare ofta efter fakturor och konversationstrådar. Kontrollera interna och externa vidarebefordringar, synliga och dolda Inbox Rules, delegeringar och Send-as-rättigheter, ovanliga sök-, läs-, nedladdnings- och sändningsaktiviteter, nya OAuth-medgivanden och Enterprise Applications, ändrade autentiseringsmetoder samt alla skickade meddelanden under tidsperioden.

Vid falsk IT-support finns spår på endpointen: fjärradministrationsprogram, nedladdningar, PowerShell, MSHTA, schemalagda aktiviteter, webbläsaråtkomst och misstänkta processer. E-postsäkerhet, Endpoint Protection samt XDR eller MDR kan blockera och korrelera dem om datakällorna är licensierade, integrerade och övervakade. Sophos Fusion-strategin bidrar till detta, men ersätter varken Conditional Access eller incidentprocessen.

Lagringstid och detaljnivå för auditdata beror på licens och konfiguration. Båda måste klarläggas i förväg, eftersom loggning som aktiveras i efterhand inte skapar någon historik.

Incidentplan för ett komprometterat Microsoft 365-konto

Ett lösenordsbyte räcker inte. Sessioner, främmande MFA-metoder, OAuth-medgivanden och postlåderegler kan finnas kvar.

1. Använd en ren administrationsenhet

Vid möjlig endpoint-kompromettering utförs lösenordsbytet och administrationen från en annan enhet. Det berörda systemet isoleras utan att spår raderas förhastat. Vid ett pågående angrepp eller ett privilegierat konto kan en tillfällig avaktivering vara lämplig.

2. Återkalla aktiva sessioner

Sessionerna kan återkallas i Entra Admin Center eller med Microsoft Graph PowerShell:

Connect-MgGraph -Scopes User.RevokeSessions.All
Revoke-MgUserSignInSession -UserId user@example.com

User Principal Name anpassas. Beroende på app, tokentyp och Continuous Access Evaluation kan åtkomsten finnas kvar en kort tid. Resultatet måste därför kontrolleras i loggar och appar.

3. Rensa lösenord och autentisering

Lösenordet ändras i den primära identitetskällan, och för synkroniserade eller federerade konton i lokala Active Directory eller Identity Provider. Därefter granskas MFA-metoder, passkeys, telefonnummer, enheter och Temporary Access Passes, och främmande poster tas bort. Vid skadlig kod eller fjärråtkomst undersöks endpointen parallellt och ominstalleras vid behov.

4. Granska OAuth-medgivanden och roller

Användarmedgivanden, Enterprise Applications och misstänkta Service Principals kan ge bestående åtkomst. För privilegierade konton kontrolleras även roller i Entra, Azure och Microsoft 365.

5. Granska vidarebefordringar och Inbox Rules

Exchange Online PowerShell visar centrala postlådeinställningar:

Get-Mailbox -Identity user@example.com |
  Format-List Forwarding*Address,DeliverTo*

Get-InboxRule -Mailbox user@example.com -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity

Misstänkta regler dokumenteras och tas bort. Delegeringar, Send-as-rättigheter och administrativa transportregler granskas separat.

6. Identifiera och informera följdoffer

Message Trace och auditdata visar skickade meddelanden. Interna och externa mottagare informeras innan länkar, betalningar eller fler konton påverkas. Vid manipulerade betalningar kontaktas banken, ekonomiavdelningen och affärspartner via kända kanaler. Fler steg finns i artikeln om omedelbara åtgärder vid phishing och hacking.

7. Fastställ orsak och omfattning

Slutligen klarläggs om AiTM, Device Code, bekräftad MFA eller fjärradministration var inblandad, vilka SharePoint- eller OneDrive-filer som läckte, om fler konton, appar eller enheter registrerades och om personuppgifter eller affärshemligheter berördes. Utan en orsaksanalys förblir luckan öppen.

Praktisk checklista för Microsoft 365-administratörer

• Prioritera phishing-resistent inloggning för administratörer, ekonomi, företagsledning och helpdesk.
• Håll nödkonton separerade, övervaka dem och testa dem regelbundet.
• Inventera användningen av Device Code, blockera den eller dokumentera motiverade undantag.
• Testa Conditional Access i Report-only med en pilotgrupp.
• Kräv hanterade enheter för känsliga resurser och inför Token Protection endast med kompatibla klienter.
• Fastställ bindande regler för extern Teams-kommunikation, fjärradministrationsverktyg, återuppringning från helpdesk och identitetskontroll.
• Larma om e-postfloder, ovanliga inloggningar, OAuth-medgivanden och vidarebefordringar.
• Testa återkallning av sessioner, rensning av MFA, Inbox Rules, sändningsspår och endpoint-isolering.
• Klarlägg lagringstid för auditdata och ansvar före en incident.

Min rekommendation

MFA är fortfarande obligatoriskt, men lösenord plus pushapp tar för liten hänsyn till moderna angrepp. Privilegierade och ekonomiskt kritiska konton bör först få phishing-resistent autentisering. Därefter följer kontroll av Device Code, hanterade enheter och Conditional Access. Token Protection kräver en kontrollerad utrullning på grund av sina begränsningar. Samtidigt behöver helpdesk säkra processer för oväntade Teams-kontakter.

Avgörande är samspelet mellan en stark identitet, en betrodd enhet, en kontrollerad session, övervakad kommunikation och en incidentplan för aktiva token och dold persistens.

FAQ