FBI waarschuwt: Kali365 omzeilt MFA via device code flow — zo bescherm je je tenant

De FBI waarschuwde 21 mei voor Kali365, een Phishing-as-a-Service kit die sinds april 2026 circuleert. Distributie loopt via Telegram. De truc is subtieler dan je denkt: Kali365 steelt geen wachtwoord. Het steelt OAuth tokens.

Niet de login, maar het token

Bij klassieke phishing onderschep je credentials en — als je pech hebt — een MFA-code. Kali365 werkt anders. De aanvaller stuurt een mail met een device code en een link naar een echte Microsoft-verificatiepagina. Het slachtoffer logt legitiem in, voert de code in, en autoriseert daarmee het apparaat van de aanvaller. Geen verdachte URL. Geen MFA-prompt om te onderscheppen. Gewoon een token alsof je zelf een nieuw apparaat koppelt.

Daarna heeft de aanvaller een geldig access én refresh token. Outlook, Teams, OneDrive — alles open. En dat blijft zo tot het token verloopt of actief wordt ingetrokken.

Dit is exact waarom ik bij klanten blijf hameren: MFA alleen is geen identity-strategie. Token-centric account takeover is een andere dreigingsklasse dan credential theft, en je bestaande SOC-playbooks zijn er waarschijnlijk niet op ingericht.

De attack chain in vier stappen

1. Aanvaller stuurt phishingmail — AI-gegenereerde lure, vermomd als cloud- of documentdienst
2. Slachtoffer voert device code in op een legitieme Microsoft-pagina
3. Aanvaller ontvangt OAuth access + refresh token
4. Persistent toegang tot Outlook, Teams, OneDrive — geen nieuwe MFA nodig

Het venijn zit in stap 2. Het slachtoffer zit op login.microsoftonline.com. De awareness-training "check de URL" faalt hier volledig.

Waarom dit nu ernstiger is dan vorig jaar

Kali365 combineert drie trends die los al zorgwekkend waren:

PhaaS-industrialisatie. Minder technische aanvallers krijgen toegang tot technieken die normaal bij volwassen intrusion sets horen. AI-gegenereerde lures, campagne-templates, real-time trackingdashboards — de drempel is verdampt.

Token theft is het nieuwe credential theft. Microsoft classificeert device code flow inmiddels als hoog-risico authenticatiemethode. Toch staat die bij de meeste tenants gewoon aan.

Agentic blast radius. Als organisaties Copilot, Graph API, Teams-bots of workflow agents aan Microsoft 365 koppelen, is een gestolen token niet alleen toegang tot data — het is toegang tot tools, acties en downstream-integraties. Een gecompromitteerde identiteit kan in moderne omgevingen acties triggeren, niet alleen data lezen.

Enterprise-impact

| Domein | Risico | |---|---| | Identity | Account takeover ondanks MFA | | Data | Exfiltratie via Outlook, OneDrive, SharePoint | | Collaboration | Misbruik van Teams, interne documenten, gedeelde links | | Lateral movement | Aanvallen vanuit vertrouwde mailbox of Teams-identiteit | | Compliance | Datalekmelding onder AVG — de klok tikt | | SOC | Detectie faalt; login loopt via legitieme Microsoft-flow |

Wat je nu moet doen (prioriteit 0–30 dagen)

1. Blokkeer device code flow (vandaag nog)

Dit is de primaire maatregel. Zet een Conditional Access policy die device code flow blokkeert voor alle gebruikers, behalve break-glass accounts en expliciet gedocumenteerde uitzonderingen. Eerst report-only, dan gefaseerd enforce.

Audit eerst bestaande afhankelijkheden. Device code flow wordt soms gebruikt voor CLI-tools, meeting room devices, shared devices of specifieke developer workflows. Je wil niet je eigen operatie platleggen.

2. Blokkeer authentication transfer

Microsoft staat authentication transfer standaard toe — een ingelogde status kan van het ene apparaat naar het andere worden overgedragen via QR-code. Blokkeer dit tenzij er een harde businesscase is, zeker bij BYOD en unmanaged devices.

3. Bouw SOC-detectie op token-gedrag

Je huidige playbook draait waarschijnlijk op failed logins, onbekende IP's, impossible travel. Bij token theft zie je die niet. Waar je wél op moet monitoren:

• Authentication flow = device code flow
• Nieuwe refresh-token activiteit op onbekend device
• Mailbox access kort na afwijkende auth-flow
• Nieuwe OAuth app consents of Graph API-toegang
• Teams/OneDrive/SharePoint access na device code login

4. Bij compromise: reset niet alleen het wachtwoord

Een klassieke IR-playbook doet wachtwoordreset + MFA-reset. Bij token theft moet je:

1. Refresh tokens en sign-in sessions revoken
2. Wachtwoord resetten
3. MFA herregistreren indien nodig
4. Onbekende devices en sessions verwijderen
5. Mailbox rules, forwarding, inbox rules controleren
6. OAuth app consents en enterprise applications nalopen
7. SharePoint, OneDrive en Teams access auditen

BIO2 / NIS2 raakvlak

Voor Nederlandse overheidsklanten raakt dit direct aan BIO2-controls rond identity en access management. Device code flow is een configureerbare instelling in de Microsoft 365-tenant — het niet uitzetten ervan terwijl de FBI en Microsoft zelf adviseren dit te blokkeren, is in een BIO2-audit lastig uit te leggen.

Onder NIS2 valt dit onder de zorgplicht voor state-of-the-art beveiligingsmaatregelen. De PSA is publiek, de aanbevelingen zijn concreet, en de mitigatie kost je een Conditional Access policy van vijf minuten. Een onnodig datalek dat hiervandaan komt is geen "sophisticated attack" — het is nalatigheid.

Strategisch oordeel

Hoog risico, direct mitigeren. Niet omdat Kali365 technisch revolutionair is, maar omdat de combinatie van OAuth-abuse, PhaaS-distributie en AI-gegenereerde lures een dreigingsklasse creëert waar de meeste organisaties geen verdediging tegen hebben ingericht.

De verschuiving is fundamenteel: van "herken de phishingmail" naar "bepaal welke authenticatiestromen überhaupt mogen bestaan." Van awareness-first naar identity control-plane hardening.

De grootste blinde vlek is dat device code flow een legitieme OAuth-flow is. Veel teams zien het niet als productierisico. Maar legitieme identity-flows zijn vaak krachtiger dan malware — ze opereren binnen de vertrouwensgrenzen van je tenant.

---

Dit is exact het type aanval waar Zero Trust voor bedoeld is: niet vertrouwen op het feit dat de loginpagina echt is, maar controleren of authenticatieflow, device context, sessie, locatie en token lifecycle legitiem zijn. Wie alleen naar de URL kijkt, is al verloren.