Direct naar de inhoud
Beveiligingsnieuws

Device code phishing: waarom het zo snel groeit

device code phishing

Device code phishing groeit in 2026 sneller dan veel organisaties hadden verwacht. In minder dan zes maanden is deze techniek verschoven van een niche-aanpak voor red-teams naar een volwassen, commercieel ecosysteem dat op grote schaal wordt misbruikt. De kern van het probleem: device code phishing focust niet op het moment dat iemand inlogt met een wachtwoord, maar op wat er gebeurt na die authenticatie—namelijk het verlenen van autorisatie.

In dit artikel zetten we de belangrijkste inzichten op een rij, zodat je beter kunt begrijpen waarom deze aanval werkt en waar je team in de verdediging op moet letten.

1) Het omzeilt MFA en zelfs passkeys

Wat device code phishing bijzonder gevaarlijk maakt, is dat het niet direct in de inlogstap grijpt. De aanval gebruikt de OAuth 2.0 device authorization grant om toegangstokens te stelen. In de praktijk komt het erop neer dat een slachtoffer een korte code kopieert en die invoert op een legitieme providerpagina. Vervolgens selecteert de gebruiker de juiste account-omschrijving in een dropdown en klikt op toestaan.

Omdat de phishing niet “tegen” de authenticatiemethode vecht, blijven veel controles ineffectief. Onderzoekers geven aan dat MFA van alle soorten, inclusief passkeys en zelfs phishing-resistente varianten, in deze aanpak geen doorslaggevende rol speelt. Veel beveiligingsmaatregelen beschermen vooral de authenticatie-laag, terwijl deze dreiging zich richt op autorisatie.

2) De drempel voor aanvallers is laag geworden

Device code phishing is inmiddels uitgegroeid tot een standaard onderdeel van phishing-as-a-service (PhaaS). Daarmee is de techniek niet langer afhankelijk van één gespecialiseerd team. In plaats daarvan kunnen criminelen of kwaadwillende partijen gebruikmaken van kant-en-klare tools die ze kunnen aanpassen en inzetten.

Volgens onderzoekers is het aantal verschillende device code phishing-kits in het wild inmiddels enorm. Waar dergelijke kits eerder uitzonderlijk waren, zien security teams nu dat er continu nieuwe varianten opduiken. Dit wijst op snelle commercialisering en op een ontwikkelingstraject dat veel sneller gaat dan voorheen.

Waarom AI dit versnelt

AI-ondersteunde ontwikkeling verlaagt de tijd en moeite om nieuwe phishingkits te bouwen en te verfijnen. Kits kunnen daardoor qua opzet op elkaar lijken, doordat ontwikkelaars vergelijkbare instructies gebruiken. Tegelijk kunnen onafhankelijk gebouwde kits ook sterk op elkaar lijken wanneer ze op soortgelijke uitgangspunten voortbouwen.

3) Aanvallers publiceren nieuwe varianten sneller dan jij kunt bijhouden

Veel organisaties zijn gewend om dreigingen te catalogiseren op basis van indicatoren: specifieke domeinen, bekende domeinpatronen of herkenbare payloads. Bij device code phishing is dat lastiger, omdat de aanval via het web en de legitieme providerflow loopt. De “plek” waar het slachtoffer de code invoert, is vaak juist vertrouwd en wordt dus niet per definitie geblokkeerd door traditionele IOC-gedreven methoden.

Onderzoekers stellen dat de snelheid waarmee nieuwe device code phishing-kits verschijnen, zó hoog ligt dat catalogiseren vrijwel altijd achterloopt. Dat betekent dat je verdedigingsstrategie mee moet bewegen: niet alleen kijken naar bekende vingerafdrukken, maar naar het gedrag en de onderliggende aanvalsketen.

4) Niet alleen Microsoft: de techniek is cross-platform

Vandaag zien security partijen vooral aanvallen op Microsoft-omgevingen. Toch geven onderzoekers duidelijk aan dat device code phishing niet tot één leverancier beperkt is. De OAuth 2.0 device authorization grant is een standaard die breed wordt toegepast. Zodra een applicatie of dienst deze flow implementeert, ontstaat er een potentieel aanvalsoppervlak.

Er zijn ook al campagnes gesignaleerd die zich richten op andere platforms, waaronder Salesforce, en er wordt gewezen op het misbruik van de device flow op schaal via een kwaadaardige applicatie. Daarnaast worden ontwikkelplatformen genoemd zoals GitHub en AWS, waar de device flow een rol speelt in authenticatie voor CLI-tools en ontwikkelwerkstromen.

5) Het past in een bredere verschuiving: aanvallen op autorisatie

Device code phishing staat niet op zichzelf. Volgens onderzoekers is er een trend zichtbaar waarbij aanvallers minder tijd besteden aan de authenticatiestap en meer aan de autorisatie- en toestemmingslaag. De logica daarachter is eenvoudig: als authenticatie al “klopt” volgens de regels, kunnen aanvallers met de juiste aanpak toch toegang afkopen door autorisatie te manipuleren.

In dit kader wordt ook gesproken over OAuth-consent phishing technieken die eveneens inzetten op het misbruiken van toestemmingen na succesvolle authenticatie. Als deze verschuiving doorzet, wordt de verdediging rond autorisatie dus steeds belangrijker.

6) Detectie moet gebeuren waar het misbruik zichtbaar is

Een van de grootste uitdagingen bij device code phishing is dat de phishing-pagina’s via veel kanalen kunnen worden aangeboden: van e-mail en berichtenapps tot sociale media, zoekresultaten en gecompromitteerde websites. Het slachtoffer voert de code daarna echter in op een legitieme providerpagina. Daardoor kan het verkeer door infrastructuren gaan die niet altijd blokkeren.

Voor Microsoft-omgevingen wordt vaak geadviseerd device code authentication flows te beperken via conditional access policies. Dat kan helpen waar het technisch en operationeel haalbaar is. Maar er zit een duidelijke valkuil: organisaties kunnen deze flows niet altijd uitzetten zonder dat legitieme functionaliteit stukgaat (bijvoorbeeld ontwikkel- of CLI-workflows en scenario’s met beperkte input op apparaten).

Bovendien beschermt een Microsoft-specifieke lockdown niets tegen device code phishing op andere platforms waar vergelijkbare conditional access controles niet beschikbaar zijn of anders zijn ingericht.

De onderzoekers benadrukken daarom dat je detectie het beste kunt richten op het punt waar gebruiker en autorisatie samenkomen: in de browserlaag. Alleen daar kun je tegelijk zien welke lure wordt getoond én welke “approval” vervolgens wordt verleend.

Praktische aandachtspunten voor je security team

Hoewel de exacte implementatie per organisatie verschilt, kun je op basis van bovenstaande inzichten gericht werken aan je weerbaarheid:

  • Herken de aanvalsketen: focus niet alleen op inlogindicatoren, maar op signalen rond autorisatie en tokenverlening.
  • Beperk waar mogelijk device code flows met conditional access, maar controleer vooraf de impact op legitieme gebruiksscenario’s.
  • Vergroot zichtbaarheid in de browser voor consent- en approval-achtige handelingen die via legitieme providerpagina’s lopen.
  • Werk gedragsgedreven: omdat kits snel veranderen, is alleen IOC-gebaseerde detectie onvoldoende.

Gerelateerde informatie op onze site

Als je security posture breder gaat over identity- en autorisatiekwetsbaarheden, zijn dit mogelijk interessante vervolglees-links. Ze sluiten aan op het thema dat aanvallers profiteren van zwakheden of gaten in beveiligingslagen: