Token theft i Microsoft 365: derfor er MFA ikke nok og situationen forværres med AI (Copilot, ChatGPT, Gemini mfl.)
En medarbejder består MFA. Alligevel får en angriber adgang til mail, Teams og SharePoint som “legitim bruger”. Det er typisk token theft: tyveri af selve sessionen efter login. I kan lukke hullet med enheds- og identitetskontrol i Microsoft Entra ID og Intune, så et stjålet token ikke virker uden jeres godkendte device.
- Skeln mellem password-tyveri og token theft: Auditér sign-ins for “MFA satisfied” + nye lokationer/enheder, og stop “session hijacking” med Conditional Access.
- Gør adgang enheds-bundet: Kræv “compliant device”/“hybrid joined” på M365, så stjålne sessions ikke kan flyttes til angriberens pc.
- Skift til phishing-resistent MFA: Udrul passkeys/FIDO2 (evt. certifikat-baseret) til roller med høj risiko og til admins.
- Begræns Shadow AI via “Sign in with Microsoft”: Stram consent/OAuth-apps, og gennemgå hvilke 3.-parts AI-tjenester der har adgang.
- Kortere “time-to-contain”: Slå løbende revurdering af adgang til (CAE) og dokumentér playbook: disable user, revoke sessions, block apps.
Hvad er token theft i Microsoft 365 (forklaret til ledelse)?
Tænk på jeres login som to dele: 1) adgangskode + MFA (døren) og 2) en session (adgangskortet), som browseren bruger bagefter. Ved token theft stjæler angriberen adgangskortet. Derfor ser det ud som en normal bruger, der allerede har logget ind.
Microsoft peger i deres Digital Defense Report (2024/2025) på, at angreb flytter sig fra “stjæl password” til “stjæl token”, fordi MFA er blevet standard. CISA’s anbefalinger om phishing-resistant MFA matcher samme problem: hvis en session kan overtages, er push-koder ikke nok.
Hvorfor stopper MFA ikke AiTM phishing og session hijacking?
Ved AiTM phishing (Adversary-in-the-Middle) får brugeren et login-link, der ligner Microsoft. Brugeren logger ind og godkender MFA. Angriberen “står i midten”, tager imod session-tokenet og bruger det til at logge ind som jer. Resultatet er en bypass MFA attack, selv om MFA teknisk set blev gennemført korrekt.
Før → Efter (mikro):
Før: “MFA er slået til, så vi er sikre.” Sign-ins med “MFA satisfied” bliver ikke prioriteret i overvågning.
Efter: I overvåger og blokerer session-anomali (ny device, ny lokation, umulig rejse), og I kræver godkendt enhed for M365. Et stjålet token bliver ubrugeligt uden en compliant pc.
Hvorfor gør Copilot en kompromitteret bruger farligere?
Når en angriber har en legitim session, handler det ikke længere kun om at “finde en fil”. Palo Alto Unit 42 beskriver, at angribere bruger AI til at automatisere dataindsamling i cloud. Med adgang til Microsoft 365 kan Copilot og søgning gøre det hurtigt at lokalisere og udtrække følsomme data via simple prompts som “find løn”, “kundekontrakt”, “adgangskoder” eller “bankoplysninger i e-mails”.
Praktisk konsekvens: Jeres reaktionstid skal ned. Hvis det før tog en angriber timer/dage at orientere sig, kan det nu tage minutter at finde de mest værdifulde dokumenter og mails.
Sådan vurderer I risikoen ved “Sign in with Microsoft” til AI-tjenester
“Log ind med Microsoft” er i praksis ofte en OAuth-aftale: en app får lov til at læse data eller handle på vegne af brugeren. CrowdStrike fremhæver misbrug af OAuth/consent som en voksende vej ind (illicit consent grants). Det er farligt med nye AI-værktøjer, fordi de typisk beder om brede tilladelser for at kunne “hjælpe”.
Beslutningsregler I kan bruge internt
- Hvis en app kræver adgang til mail, filer eller alle brugere → den skal gennem IT-godkendelse, ikke selvbetjent.
- Hvis I ikke kan forklare, hvor data behandles og logges → stop, til I har DPA og dataplacering afklaret.
- Hvis appen er “gratis” og ukendt → antag at “betalingen” kan være data, og kræv leverandørvurdering.
Tjekliste: Stop token theft med Entra ID, Conditional Access og Intune
Her er en konkret tjekliste, der typisk giver størst effekt i SMB-miljøer. Målet er at flytte jer fra “brugerkonto er perimeter” til “identitet og device er perimeter”.
| Kontrol | Hvad I sætter op | Hvad I kigger efter (acceptkriterie) | Typisk krav/licens |
|---|---|---|---|
| Conditional Access: kræv godkendt device | Politik for M365 apps: “Require device to be marked as compliant” (eller Hybrid join) + blokér øvrige | Login fra ukendt pc bliver afvist, selv med korrekt MFA og token | Entra ID P1 + Intune |
| Token Protection / token binding | Aktivér og test Entra token protection, hvor det er understøttet, så tokens binds til device | Stjålet session-token virker ikke på en anden maskine | Entra + korrekt device-setup |
| Phishing-resistent MFA | Udrul FIDO2/passkeys (min. admins, økonomi, HR). Begræns legacy MFA-metoder | Admins kan ikke logge ind med push/SMS alene | Entra ID (typisk P1/P2 afhængigt af politik) |
| Sessionstyring | Stram sign-in frequency hvor det giver mening, og brug CAE til hurtigere revurdering | Ved risiko/hændelse kan adgang afbrydes hurtigt uden at vente på token-expiry | Entra ID + CAE-support |
| Consent/OAuth governance | Begræns bruger-consent, kræv admin approval for apps, og gennemgå eksisterende app-consents | Ukendte AI-apps kan ikke få adgang uden log/approval | Entra ID |
| Logning og alarmer | Definér alarmer for “MFA satisfied” + ny device/lokation, og for nye OAuth grants | I opdager kompromis samme dag, ikke “når nogen ser en mærkelig mail” | Afhænger af platform/SIEM |
Før → Efter (mikro):
Før: I tillader adgang til M365 fra enhver privat pc og enhver browser, fordi “det er nemt”.
Efter: I tillader kun adgang fra Intune-compliant enheder (kryptering, PIN, opdateringer) og blokerer ukendte enheder. Brugeren mærker det primært ved første login på en ny pc.
Vil I lukke hullet for token theft uden at vælte driften?
Vi kan køre et målrettet Entra ID/Conditional Access-sikkerhedstjek: gennemgå jeres MFA-metoder, device-krav, session policies og app-consent. I får en prioriteret plan (hvad der kan indføres nu, og hvad der kræver Intune/licens-ændringer). Se også vores tilgang til IT-sikkerhed eller book en afklaring via kontakt.
Fejl der koster jer tid (og hvorfor de sker i SMB)
- Alle må bruge alle MFA-metoder: Push/SMS bliver hængende “for nemhed”. Skift til passkeys/FIDO2 for de vigtigste konti først.
- Intune bruges kun til “apps”: Hvis compliance ikke håndhæves på login, stopper det ikke token theft. Bind adgang til compliant device i Conditional Access.
- App-consent er selvbetjent: Så kan én bruger give en ukendt AI-app adgang til mail/filer. Slå admin approval til og review eksisterende grants.
- Ingen plan for session-revokering: Når I opdager et kompromis, skal I kunne afbryde sessioner med det samme (disable user, revoke sessions, reset auth methods).
FAQ om token theft, AiTM phishing og Copilot
Hvad betyder “token theft” i Microsoft 365?
Det betyder, at angriberen stjæler en aktiv session (token/cookie) og bruger den til at være logget ind som brugeren. Det kan ske, selv om brugeren har MFA, fordi tokenet typisk udstedes efter MFA.
Hvordan kan MFA blive bypasset?
Typisk via AiTM phishing, hvor brugeren gennemfører MFA på en falsk side, og angriberen opsnapper session-tokenet. Tommelfingerregel: Hvis I kun “tjekker MFA = ja”, overser I angrebet.
Hvilken MFA er phishing-resistent?
CISA peger på FIDO2/passkeys eller certifikat-baseret autentificering som phishing-resistente metoder. Praktisk prioritering: udrul det til admins, økonomi og HR først.
Hvad er Microsoft Entra token protection, og hjælper det mod session hijacking?
Token protection (token binding) kan binde sessionen til en bestemt enhed, så et stjålet token ikke kan genbruges fra en anden maskine. Effekten er størst, når det kombineres med Conditional Access og Intune-compliance.
Skal vi have Intune for at stoppe token theft?
Hvis I vil gøre “kun godkendte enheder må tilgå M365” til en fast regel, er Intune den mest direkte vej i Microsoft-setup. Minimum: brug Entra Conditional Access til at kræve compliant device på de vigtigste cloud-apps.
Hvordan kontrollerer vi “Sign in with Microsoft” til 3.-parts AI (Shadow AI)?
Stram bruger-consent, kræv admin approval for nye apps, og lav en månedlig review af OAuth grants. Beslutningsregel: apps med mail-/fil-adgang skal have en ejer, en forretningsbegrundelse og kunne afinstalleres hurtigt.
Hvad gør vi, hvis vi mistænker token theft her og nu?
Gør det i denne rækkefølge: 1) disable brugeren midlertidigt, 2) revoke sign-in sessions, 3) nulstil MFA-metoder og password, 4) fjern/disable mistænkelige OAuth apps, 5) gennemgå sign-in logs for device, lokation og tidslinje, 6) stram Conditional Access for de berørte apps.
Sådan kommer I i gang (konkrete skridt)
- Kortlæg jeres mest kritiske konti (admins, økonomi, HR, ledelse) og lav en “først på passkeys/FIDO2”-liste.
- Lav 2 Conditional Access-politikker: én der kræver compliant device for Microsoft 365, og én der stiller ekstra krav til admin-roller.
- Onboard firma-pc’er i Intune og definér compliance (BitLocker, opdateringer, PIN, skærmlås). Håndhæv derefter device-kravet i CA.
- Gennemgå OAuth app-consents: fjern ukendte AI-apps, og slå admin consent workflow til.
- Test hændelsesrespons: kan I revoke sessions og blokere adgang på 15 minutter? Dokumentér playbook og øv den.
- Mål og justér: track hvor mange logins der bliver blokeret pga. ukendte enheder, og finjustér undtagelser (fx break-glass konti).
Hvis I vil have det implementeret uden driftstab, kan vi hjælpe med design, udrulning og løbende drift via vores drift-setup, så policies bliver håndhævet og vedligeholdt.
