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 wachtwoorden. Hij onderschept geen MFA-codes. 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 "verlaagt het de drempel, en geeft minder technische aanvallers toegang tot door AI gegenereerde phishinglokkertjes, geautomatiseerde campagnesjablonen, realtime trackingdashboards van individuen/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, settopboxen 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 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 er is 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 voorgevulde variant van de link, dus het slachtoffer moet de code met de hand typen. Die handmatige stap is precies wat een door AI geschreven lokkertje met hoge conversie 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, met respect voor hetinterval(5 seconden) en deauthorization_pending-antwoorden opvangend, 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 echt, MFA inbegrepen, tegen het echte endpoint van Microsoft. Dus de login wordt 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-voldane 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 slecht. Het refresh-token is de echte buit, en Microsofts tokenmodel maakt het erger dan de compromittering van één 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 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, hoewel die bijna realtime intrekbaar zijn 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 apps 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, 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 zien. Ze eindigen allemaal met een geldig token na authenticatie, maar ze raken verschillende delen van het aanvalsoppervlak, en dat verandert zowel hoe ze controles ontwijken als waar je ze nog kunt vangen.
| 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 en 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 richt. - 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, wat het teken van de PRT-escalatie is.
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 echt 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 100 browser-, device- 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, automatisering- 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 op de bredere verschuiving in waarom de browsersessie nu een security control plane is.
cside monitort 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 echt wordt beslist. Voor waar dit in een bredere accountovername-stack past, 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.
