Kort samengevat: MFA-tokendiefstal en het vertrouwensmodel bij device code phishing
- Het gat: Elke bewustwordingspresentatie plaatst MFA nog steeds als de finishlijn, maar de Kali365-kit laat een operator met weinig vaardigheid access- en refresh-tokens verzamelen nadat het slachtoffer MFA voltooit op Microsofts echte pagina, waarbij Conditional Access de aanmelding als conform behandelt.
- Wat cside ziet: Eén buitgemaakt FOCI-refresh-token pivotteert door Outlook, Teams, SharePoint, OneDrive en Microsoft Graph binnen een standaard inactiviteitsvenster van 90 dagen; cside brengt live-sessieanomalieën aan het licht in echte gebruikersbrowsers, zodat token-replay tegen tenant-resources zichtbaar wordt in plaats van legitiem.
- De beslissing: Bepaal vóór je volgende Entra Conditional Access-review of device code flow en Authentication transfer overal waar mogelijk geblokkeerd zijn, en of uitzonderingen voor break-glass-accounts en de Device Registration Service gedocumenteerd zijn.
Weinig tijd? Bekijk cside accountovername-detectie. Dit dekt alles hieronder in één deployment.
Op 2026-05-21 bracht de FBI de public service announcement I-052126-PSA uit, met een waarschuwing voor een Phishing-as-a-Service-kit genaamd Kali365 die Microsoft 365-accounts kaapt. Hij steelt geen wachtwoord en onderschept geen MFA-code. Het slachtoffer logt in op de eigen pagina van Microsoft, voltooit multifactor-authenticatie, en de aanvaller loopt toch weg met persistente toegang. Kali365 doet dit door de OAuth 2.0 device authorization grant te misbruiken om de access- en refresh-tokens buit te maken die Microsoft uitgeeft na een volkomen legitieme login.
Dit is geen nieuwe techniek. In februari 2025 documenteerde Microsoft een device code phishing-campagne van Storm-2372, een actor die het inschat als gelieerd aan Russische staatsbelangen, actief tegen doelwitten in overheid, defensie, telecom en energie. Wat veranderde is de verpakking. Kali365 maakt van die tradecraft een abonnementskit met door AI gegenereerde lokkertjes, zodat een actor met weinig vaardigheid hem kan draaien. De login slaagt, de MFA-prompt slaagt, en de aanname onder beide faalt: dat een geslaagde authenticatiegebeurtenis je vertelt wie de sessie een minuut later in handen heeft.
Die aanname is het echte doelwit. "Gebruiker succesvol geauthenticeerd" is geen vertrouwensgrens meer. De actieve sessie, gedragen door een bearer-token dat aan niets gebonden is, is dat wel.
Wat Kali365 echt automatiseert
De FBI beschrijft Kali365 als een via Telegram verspreid PhaaS-platform, voor het eerst gezien in april 2026. Het bundelt door AI gegenereerde phishinglokkertjes, geautomatiseerde campagnesjablonen, realtime dashboards om gerichte personen te volgen, en het buitmaken van OAuth-tokens. In de woorden van de FBI: het "verlaagt de drempel, en geeft minder technische aanvallers toegang tot door AI gegenereerde phishinglokkertjes, geautomatiseerde campagnesjablonen, realtime dashboards voor het volgen van gerichte personen/entiteiten, en mogelijkheden om OAuth-tokens buit te maken."
Lees dat als een taakverdeling. De moeilijke delen van device code phishing waren vroeger het schrijven van een overtuigend lokkertje en het betrouwbaar draaien van de token-capture- en inwisselinfrastructuur binnen een venster van 15 minuten. AI schrijft het lokkertje. De kit draait het OAuth-loodgieterswerk. De operator kiest alleen doelen. Dat maakt dit een zuiverder voorbeeld van AI die fraude opschaalt dan de meeste: het verzint geen nieuwe aanval, het verwijdert de vaardigheid die de toegang tot een bestaande aanval bewaakte.
De device-code-flow, stap voor stap
De device authorization grant bestaat om een goede reden. Hij laat je inloggen op apparaten waarop typen onhandig is, zoals smart-tv's, streamingboxen en command-line tools. Je ziet een korte code, je voert die in op je telefoon, het apparaat is ingelogd. Het ontwerp is legitiem en wordt voortdurend gebruikt in heel Microsoft 365.
Hier is dezelfde flow, omgevormd tot een aanval:
- De aanvaller stuurt een
POSTnaarhttps://login.microsoftonline.com/common/oauth2/v2.0/devicecodemet een publieke first-partyclient_id, vaak Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c) of Azure CLI (04b07795-8ddb-461a-bbee-02f9e1bf7b46). Dit zijn vooraf toegestemde Microsoft-clients, dus is er geen eigen app-registratie of beheerderstoestemming nodig. - Microsoft geeft een
device_codeterug, een door een mens typbareuser_code, de verificatie-URLhttps://microsoft.com/deviceloginen eenexpires_invan 900 seconden. De aanvaller heeft nu een venster van 15 minuten. - De aanvaller verleidt het slachtoffer om
microsoft.com/deviceloginte openen en deuser_codein te voeren. Microsoft Entra ondersteunt geenverification_uri_complete, de vooraf ingevulde variant van de link, dus moet het slachtoffer de code met de hand typen. Die handmatige stap is precies wat een overtuigend, door AI geschreven lokkertje moet aandrijven. - Het slachtoffer authenticeert op de echte Microsoft-pagina, voltooit MFA en geeft toestemming. Elk element is echt: het domein is Microsoft, het certificaat is geldig, de MFA-prompt is degene die ze altijd krijgen.
- De aanvaller bevraagt
https://login.microsoftonline.com/common/oauth2/v2.0/tokenmetgrant_type=urn:ietf:params:oauth:grant-type:device_codeen dedevice_code, waarbij hij hetinterval(5 seconden) respecteert enauthorization_pending-antwoorden opvangt, tot het endpoint eenaccess_tokenen eenrefresh_tokenteruggeeft.
Er is geen vervalst domein om te markeren en geen payload op het endpoint om te detecteren. Het frauduleuze deel is een legitieme Microsoft-flow voltooid door de verkeerde persoon, en het token dat eruit komt is niet te onderscheiden van een token dat aan een echte sessie is uitgegeven.
Waarom MFA voldaan is en Conditional Access het doorlaat
Dit is het deel dat teams overrompelt. Het slachtoffer voltooide de interactieve login écht, MFA inbegrepen, tegen het echte endpoint van Microsoft. De login wordt dus vastgelegd als MFA-voldaan, weerspiegeld in het authenticatiedetail van de Entra-aanmeldingslog en, op v1.0-tokens, in het amr-claim met mfa. Conditional Access evalueert die login als een conforme, MFA-geslaagde interactieve login en geeft tokens dienovereenkomstig uit.
De aanvaller omzeilt MFA niet in de zin van het verslaan van de uitdaging. De uitdaging liep en slaagde. Wat het bearer-tokenmodel nooit doet, is het uitgegeven token binden aan het apparaat dat de uitdaging voltooide. MFA beantwoordde "authenticeert de juiste persoon zich op dit moment?". Het beantwoordde niet "is het het juiste apparaat dat dit token dertig seconden later vasthoudt?", en niets in de standaardflow doet dat.
De schade: FOCI-refresh-tokens en PRT-escalatie
Een buitgemaakt access-token is een uur lang schadelijk. Het refresh-token is de echte buit, en Microsofts tokenmodel maakt het erger dan de compromittering van één enkele app.
Refresh-tokens die aan Microsofts first-party-clients worden uitgegeven, zijn doorgaans FOCI-tokens (Family of Client IDs). Een family-refresh-token verkregen via één client kan worden ingewisseld voor access-tokens als andere clients in de familie, zodat een via Microsoft Office buitgemaakt token kan worden geruild voor toegang tot Exchange Online, Teams, SharePoint en OneDrive, en Microsoft Graph. Eén gestolen refresh-token is laterale beweging door de data van de hele tenant, geen voet aan de grond in één app.
De rekensom van de levensduur verergert het. Sinds januari 2021 zijn de levensduren van refresh-tokens niet meer instelbaar via tokenlevensduurbeleid; het standaard-inactiviteitsvenster van het refresh-token is 90 dagen en de maximale leeftijd is in de praktijk tot-intrekking. Waar de client en de resource Continuous Access Evaluation ondersteunen, kunnen access-tokens worden verlengd tot 24 à 28 uur, al zijn die bijna realtime intrekbaar bij kritieke gebeurtenissen. Om herauthenticatie af te dwingen leun je nu op de aanmeldingsfrequentie van Conditional Access, niet op tokenbeleid.
Het escalatieplafond ligt nog hoger. In de update van februari 2025 op zijn Storm-2372-rapportage zag Microsoft de actor overstappen op de Microsoft Authentication Broker-client (29d9ed98-a469-4536-ade2-f981bc1d605e) om een refresh-token te verkrijgen, een door de aanvaller beheerd apparaat in Entra ID te registreren en vervolgens een Primary Refresh Token te munten. Een PRT is duurzaam, apparaatgebonden identiteitsmateriaal dat brede single sign-on ontsluit. De device-code is het toegangspunt; de PRT is de tenant.
"Succesvol geauthenticeerd" is geen vertrouwensgrens meer
Jarenlang was het dominante model simpel: verifieer de gebruiker bij de login, vertrouw daarna het token tot het verloopt. Backends loggen de authenticatiegebeurtenis, identityproviders waarschuwen bij vreemde loginpatronen, en zodra de sessie bestaat stoppen de meeste applicaties met vragen wie er aan de andere kant zit.
Device code phishing is een heldere weerlegging van dat model. De logingebeurtenis is echt, het token is echt, en het enige wat fout is, is dat het token nu in handen is van iemand anders dan de persoon die zich authenticeerde. Een token uitgegeven voor een gebruiker op zijn laptop in het ene land kan worden ingewisseld en opnieuw afgespeeld vanaf aanvallersinfrastructuur in een ander land, en Entra ziet een geldige, MFA-voldane sessie omdat die het, op het moment van authenticatie, was.
Het helpt om de drie gangbare paden van tokendiefstal naast elkaar te zetten. Ze eindigen allemaal met een geldig token na authenticatie, maar ze raken verschillende delen van het aanvalsoppervlak, wat zowel verandert hoe ze controles ontwijken als waar je ze nog kunt betrappen.
| Aanval | Buitgemaakt token | Wat het slachtoffer raakt | Waar het kwaadaardige gebruik gebeurt | Belangrijkste telemetriegat |
|---|---|---|---|---|
| Device code phishing (Kali365) | OAuth access en refresh (vaak FOCI) | Een phishingbericht plus de echte microsoft.com/devicelogin-pagina | Inwisseling en hergebruik van het token vanaf aanvallersinfrastructuur | De login is de echte MFA-login van het slachtoffer; de inwisseling wordt eraan toegeschreven |
| Adversary-in-the-middle phishing | Sessietoken of cookie onderweg onderschept | Een via reverse-proxy nagemaakte inlogpagina | Opnieuw afgespeelde sessie vanaf aanvallersinfrastructuur | Er bestaat een lijkend domein, maar de sessie lijkt verderop geldig |
| Infostealer-malware | Sessiecookies van schijf gekopieerd | Malware die op het endpoint draait | Hervatte sessie vanuit het gestolen cookie | Endpointcompromittering, maar de hervatte sessie passeert serverzijdige controles |
De rode draad is de laatste kolom. In elk geval houdt de applicatie een geldig token vast en behandelt de houder als de geauthenticeerde gebruiker. Het apparaat dat zich authenticeerde en het apparaat dat nu het token gebruikt, zijn verschillend, en het standaardmodel heeft daar geen ingebouwde controle voor.
Detecteren en blokkeren
Er zijn hier twee taken: de flow sluiten, en vinden waar hij al is gebruikt.
Blokkeer de flow in Entra Conditional Access
Dit komt direct overeen met de belangrijkste aanbeveling van de FBI. Gebruik in Conditional Access de Authentication flows-conditie, zet device code flow op Blokkeren, en blokkeer authentication transfer in hetzelfde beleid. Microsofts eigen advies is om device code flow te blokkeren waar mogelijk.
- Richt het beleid op alle gebruikers en alle resources, en sluit dan break-glass- en noodtoegangsaccounts uit zodat een verkeerde configuratie je niet buitensluit.
- Als een legitiem proces apparaten registreert via device code flow, sluit dan de Device Registration Service (
01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) uit, aangezien authentication-flows-beleid daar wordt afgedwongen wanneer het beleid op alle resources gericht is. - Audit het huidige gebruik van device code voordat je afdwingt, zodat de echte uitzonderingen bekend zijn in plaats van geraden.
Jaag op eerder gebruik in de aanmeldingslogs
Device-code-aanmeldingen zijn zichtbaar in de Entra ID-aanmeldingslogs. Het breed gebruikte detectiefilter is het authenticatieprotocol:
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| summarize logins=count() by UserPrincipalName, AppDisplayName, IPAddress, tostring(LocationDetails.countryOrRegion)
Let ook op OriginalTransferMethod == "deviceCodeFlow" om protocol-getrackte sessies bij latere vernieuwingen te vangen, en markeer apparaatregistratiegebeurtenissen uitgevoerd door de Microsoft Authentication Broker-client waar je ze niet verwacht. Dat is het teken van PRT-escalatie.
De eerlijke beperking staat in de tabel hierboven. De authenticatiegebeurtenis die het token produceerde is de echte, MFA-voldane login van het slachtoffer, dus logbasisdetectie is sterk op de flow zelf maar zwak op de inwisseling en het hergebruik die volgen, die Entra toeschrijft aan die legitieme login.
Waar het device-code-gat écht sluit: de sessielaag
Een gestolen token moet ergens worden gebruikt, en die plek is bijna nooit het apparaat dat zich authenticeerde. Die mismatch is het signaal dat het bearer-tokenmodel weggooit, en het signaal dat cside is gebouwd om te behouden.
De geavanceerde device fingerprinting van cside verzamelt meer dan 250 browser-, apparaat- en netwerksignalen om een persistente identifier voor elke bezoeker te bouwen. Bij authenticatie leggen die signalen een basislijn voor de sessie vast. Wanneer een token later wordt aangeboden vanuit een andere omgeving, een andere TLS- en browser-fingerprint, een ander ASN of residentiële-proxy-uitgang, automatiserings- of headless-markers die er bij de login niet waren, komt de fingerprint niet overeen met de basislijn, en die mismatch kan tokenintrekking of een step-up-uitdaging activeren voordat de aanvaller de data bereikt. We gaan hier dieper op in bij hoe geavanceerde locatiedata onveilig hergebruik van tokens detecteert en bij de bredere verschuiving in waarom de browsersessie nu een security control plane is, inclusief wat Chrome's DBSC dekt en wat device fingerprinting aanvult.
cside bewaakt ook de client-side-omgeving op de kwaadaardige scripts en sessiekapingpayloads die volledig onder de authenticatielaag opereren. Dat is de zichtbaarheid op browserniveau die backendlogs niet kunnen bieden, en het is het deel van het aanvalsoppervlak waar tokendiefstal daadwerkelijk wordt beslist. Voor waar dit past in een bredere accountovername-stack brengt onze gids voor het vergelijken van ATO-preventieoplossingen in kaart waar MFA stopt en signalen op sessieniveau beginnen.
Boek een demo om te zien hoe cside gecompromitteerde sessies detecteert voordat de schade is aangericht.
De Microsoft 365-controles, het Entra-gedrag en de FBI-richtlijnen zijn correct per 2026-05-31. Leverancierflows, client-ID's en waarschuwingen veranderen; bevestig de huidige device-code-flow- en Conditional Access-opties van Microsoft voordat je op een specifieke instelling vertrouwt.
