De deur die MFA en passkeys niet sluiten: kwaadaardige OAuth-toestemming

Je kunt je wachtwoord resetten, MFA afdwingen en passkeys uitrollen voor je hele team, en de aanvaller zit nog steeds in je Microsoft 365. Niet omdat een van die maatregelen faalde, maar omdat hij nooit door de voordeur naar binnen kwam.

Dat is het ongemakkelijke aan de aanvalsklasse die de afgelopen maanden opkomt onder namen als ConsentFix en de OAuth-vishing van ShinyHunters. Ze kraken je inlog niet, ze slaan hem over. Iemand laat een medewerker eenmalig een app goedkeuren, en die app krijgt een token dat blijft werken tot iemand het handmatig intrekt. Vrijwel niemand kijkt daar ooit naar.

Mijn stelling is dit: de aanval die MFA en passkeys structureel omzeilt, is geen betere phishingtruc maar kwaadaardige app-toestemming. Een sterke factor bewaakt de deur waar je doorheen inlogt. Consent geeft een sleutel weg voor een deur die daar los naast zit, en die sleutel past ook morgen nog.

Consent slaat de inlog over

Kijk naar hoe de twee verse campagnes werken, dan zie je waarom de factor er niet toe doet. ShinyHunters belt een medewerker, doet zich voor als de eigen IT-afdeling en laat het slachtoffer tijdens het gesprek een frauduleuze OAuth-app goedkeuren in de Salesforce-omgeving. De app doet zich voor als een bekend hulpmiddel, de medewerker voert een aangeleverde verbindingscode in, en het token dat daaruit rolt exporteert de data in bulk. Er wordt geen wachtwoord gestolen, want er wordt er geen gebruikt.

ConsentFix, dit najaar voor het eerst onderschept, doet hetzelfde langs de browser. Het slachtoffer belandt via een zoekresultaat op een geprepareerde pagina, klikt zich door een namaakcontrole heen en logt in een nieuw tabblad in op een echte Microsoft-pagina. Microsoft geeft na die inlog een autorisatiecode terug, en de pagina vraagt het slachtoffer die code te kopieren en te plakken. Daarmee ruilt de aanvaller de code in voor een token. De onderzoekers die de campagne betrapten, noteren dat de aanpak zelfs phishingbestendige factoren als passkeys omzeilt, omdat er geen inlog meer nodig is: wie al is ingelogd, kiest alleen nog zijn account.

Daar zit de kern. Een passkey is phishingbestendig op de inlogpagina, en dat is echte winst. Maar in deze aanval is er geen namaakinlogpagina om je passkey op te vangen. De gebruiker logt in bij de echte Microsoft en geeft daarna toestemming aan een app. De sterkste factor ter wereld beschermt een stap die de aanvaller gewoon overslaat.

De toegang overleeft je herstel

Als het hierbij bleef, was het een dure les en een schoongepoetst account. Het venijn zit in wat er na de klik gebeurt. Een gekoppelde OAuth-app behoudt zijn toegang ook als de gebruiker zijn wachtwoord reset of je MFA afdwingt, omdat de app werkt op een eigen set tokens die losstaan van dat wachtwoord. De rechten die zo'n app op het toestemmingsscherm vraagt ogen bescheiden, maar reiken ver: van het lezen van je mailbox en de optie om buiten je aanwezigheid door te werken tot je bestanden in SharePoint en OneDrive, je Teams-berichten en je agenda. Onderzoekers lieten een variant zien met een clientsleutel die twee jaar geldig bleef, en in een echt geval bleef de kwaadaardige app gewoon draaien nadat het wachtwoord al was gereset.

En zelfs als je de app herkent en meldt, gaat het licht niet meteen uit. In Microsofts eigen beschrijving van consent phishing staat dat wanneer het bedrijf zo'n app uitschakelt, de al afgegeven tokens geldig blijven tot ze verlopen. Het intrekken is dus een handeling die iemand bewust moet verrichten, en daarna nog even geduld vergt. Zolang niemand die handeling doet, staat de deur open.

Dit ligt een laag anders dan de sessiekaping waar ik eerder over schreef, waar de aanval verschoof naar de sessietoken die je na een echte inlog krijgt. Bij sessiekaping steelt de aanvaller de token van jouw inlog. Verloopt die sessie, dan is hij weg en moet hij opnieuw. Bij consent is er geen inlog van jou om over te nemen. De app van de aanvaller maakt zelf verse tokens aan, telkens opnieuw, zolang de toestemming staat. Je kunt je wachtwoord wisselen en je passkey opnieuw registreren tot je een ons weegt: de koppeling raakt het niet.

Geindustrialiseerd, en toch onzichtbaar

Je zou kunnen denken dat dit iets is voor spraakmakende doelwitten. Dat is het niet. Microsoft telde bij een enkele campagne kwaadaardige OAuth-apps die meer dan 927.000 phishingmails verstuurden, en de ShinyHunters-golf loopt al van medio 2025 tot medio 2026, dwars door de toeleveringsketen van gekoppelde SaaS-partners heen. ConsentFix wordt op schaal uitgeserveerd via gewone zoekresultaten. De vaardigheid die zo'n aanval vroeger vereiste, zit inmiddels in een kant-en-klare aanpak, en dat verschuift de rekensom: je hoeft geen strategisch doelwit te zijn, je hoeft alleen SaaS te gebruiken en een medewerker te hebben die een app goedkeurt.

Het wrange is dat de sleutel niet verborgen ligt. Een verleende toestemming staat gewoon zichtbaar in je Entra-omgeving, tussen de gekoppelde bedrijfsapplicaties. Alleen kijkt vrijwel niemand in die lijst, en al helemaal niet met de vraag of een app er wel hoort. Dat maakt het net als bij account-overnames breder: het probleem is zelden je wachtwoordbeleid, maar hoe snel je merkt dat er iemand binnen is. Een consent-grant is het perfecte voorbeeld van een spoor dat er ligt, maar dat onzichtbaar blijft zolang niemand de gewoonte heeft om te kijken.

Om eerlijk te zijn: MFA en passkeys zijn de juiste zet

Het sterkste tegenargument verdient zijn beste vorm, want het klopt grotendeels. MFA en passkeys zijn geen theater. Ze blokkeren de overgrote meerderheid van de aanvallen, van klassieke wachtwoordphishing tot de tussenliggende proxy die inloggegevens onderschept. Microsoft maakt passkeys terecht standaard in Entra ID en schrapt sms-MFA, en dat is precies de goede richting. Consent phishing is bovendien nog altijd een minderheid van alle identiteitscompromittering. Heb je die basis nog niet op orde, dan is dat je eerste zet, geen consent-audit.

En toch houd ik mijn lijn. Precies die categorie die MFA en passkeys niet raken, is de categorie die groeit, want de aanvaller omzeilt de factor in plaats van hem te kraken. Passkeys uitrollen en daarna denken dat identiteit af is, is dezelfde denkfout als "we hebben MFA aan": je beschrijft een sterk slot op een deur en negeert de tweede deur die er los naast zit. De basis leggen en de consentlaag negeren lost het zichtbare probleem op en laat het stille probleem staan.

Identiteit is geen deur, maar een gastenlijst

De kern is deze. Identiteit beveiligen is niet een sterke deur bouwen waar iedereen doorheen moet. Het is beheersen wie er namens jou toegang mag weggeven, en bijhouden aan wie je die al gaf. Elke gekoppelde app is een permanente gast met een eigen sleutel, aangemaakt op het moment dat een medewerker "toestaan" aanklikte. Die gast blijft, ook nadat de medewerker zijn wachtwoord tien keer wisselde.

De vraag die telt is dus niet of je inlog sterk genoeg is. Dat is hij waarschijnlijk. De vraag is wie in jouw omgeving een externe app mag koppelen, en wie de gastenlijst kort houdt door de koppelingen op te ruimen die niemand nog herkent. Je kunt het wachtwoord resetten zo vaak je wilt. De deur die openstaat, is de deur waarvan je de sleutel zelf hebt weggegeven.