je zit op het clearnet. de adressen hier openen alleen binnen het tor netwerk - download de tor browser hier »
AlphaBay.Market
NL
laatste controle: 13 min geleden 260 onions gevolgd
home / nieuws / security
28 oktober 2026 security 5 min leestijd

Device-code-phishing: een aanmelding goedkeuren die je nooit startte

In februari 2025 documenteerde Microsoft Threat Intelligence Center een actieve campagne van de actor die het volgt als Storm-2372, die inlogsessies afnam van organisaties in Europa, Noord-Amerika, Afrika en het Midden-Oosten. Wat opvalt aan de techniek, device-code-phishing, is wat ze vermijdt: er is geen nep-inlogpagina te herkennen, geen wachtwoord te stelen en geen malware te vinden. Het slachtoffer typt helemaal geen geheim. Een door de aanvaller geleverde code wordt ingevoerd op de echte inlogpagina van Microsoft, het slachtoffer keurt de melding goed op het eigen apparaat, en de aanvaller loopt weg met een werkende sessie.

Een legitieme functie, tegen je gebruikt

De device code flow is een echte OAuth 2.0-functie, geen vervalsing. Ze bestaat voor hardware zonder bruikbaar toetsenbord of browser: printers, televisies, schermen in overlegruimten, settopboxen. Het apparaat toont een korte code, de gebruiker opent het inlogportaal op een telefoon of laptop, voert de code in, logt in en keurt goed. Het apparaat krijgt zijn tokens. Storm-2372 draaide deze volgorde om. Volgens Microsoft voerde de groep de campagne uit vanaf augustus 2024: ze opende chats in Microsoft Teams alsof ze bestuursleden of ambtenaren waren en verplaatste het gesprek vervolgens, onder het voorwendsel documenten te delen, naar Signal of WhatsApp. Vergaderuitnodigingen per e-mail droegen hetzelfde aas, vermomd als gewoon Teams-verkeer. De berichtgeving van BleepingComputer over dezelfde campagne beschreef slachtoffers die werd gevraagd een apparaat te authentiseren om een belangrijk document te ontvangen: ze volgden een link naar de echte inlogpagina van Microsoft, voerden de ontvangen code in en keurden de aanmelding goed, inclusief de gebruikelijke multifactorstap. Doelen die Microsoft documenteerde waren overheidsinstanties, IT-dienstverleners, defensie, telecom, zorg, hoger onderwijs en energiebedrijven.

Waarom dit MFA volledig omzeilt

De volgorde van de stappen maakt het verschil. De aanvaller start eerst een legitiem device-code-verzoek en betrekt het slachtoffer pas daarna. Wanneer het slachtoffer de code invoert en goedkeurt, slagen alle controles op de pagina eerlijk: de pagina is echt, de code is geldig en de persoon die interageert voltooit een echte aanmelding, inclusief de van toepassing zijnde multifactorauthenticatie. De tokens die Microsoft uitgeeft, inclusief langlevende refresh tokens, gaan naar wie het verzoek startte: de aanvaller. Uit het oogpunt van de directory logde een gebruiker gewoon succesvol in. Er is niets voor mailfilters of webproxies te markeren, want de betrokken infrastructuur is volkomen legitiem. Microsofts verslag legt vast wat daarna gebeurde in gecompromitteerde tenants: aanvallers doorzochten postvakken met Graph API-query's op termen als credentials, wachtwoorden en admin, haalden correspondentie op en gebruikten vertrouwde interne accounts om collega's te phishen, zodat één goedkeuring zich cascaderend door de organisatie kon verspreiden. In een update een dag na het oorspronkelijke bericht documenteerde Microsoft ook een verschuiving naar verzoeken via de Microsoft Authentication Broker-client, waarmee apparaten onder controle van de aanvaller konden worden geregistreerd en primary refresh tokens konden worden aangevraagd. Proofpoint, dat de techniek volgde terwijl ze zich in 2026 verspreidde via phishingkits, zag bovendien een verfijning: codes die op afroep worden gegenereerd op het moment dat het slachtoffer op een link klikt, waarmee de vijftien minuten vervaltermijn van een vooraf gegenereerde code wordt omzeild.
Het gebruikelijke advies, de inlogpagina goed bekijken voor je iets typt, helpt hier niet. Zoals Proofpoint in de analyse van latere campagnes opmerkt, faalt de URL-controle omdat het portal echt dat van Microsoft is; wat wordt misbruikt is de goedkeuring van het slachtoffer, niet de adresbalk.

Rode vlaggen die je zou moeten kennen

De signalen zijn over campagnes heen consistent, en geen ervan vereist technische kennis om op te merken.
  • een aanmelding die je niet zelf startte: een device-code bestaat alleen omdat iemand hem aanvroeg
  • haast en druk om te handelen voordat een code verloopt of een vergadering begint
  • een e-mail, chat of bericht dat vraagt iets goed te keuren of te authenticeren met een code die je nooit aanvroeg
  • contact dat van platform wisselt, zoals een Teams-chat die naar Signal of WhatsApp verhuist
  • een document of vergaderuitnodiging die pas ontgrendelt nadat je een code verifieert
Microsoft merkt ook op dat de huidige Azure-inloginterfaces vragen te bevestigen bij welke toepassing je inlogt voordat de device code flow wordt voltooid. Dat bevestigingsscherm werkelijk lezen in plaats van door te klikken is vaak het moment waarop de illusie breekt: de app die aan de andere kant wacht, is niet die van jou.

Wat de aanval echt beperkt

Voor beheerders is de sterkste maatregel beperkt van opzet: laat de device code flow alleen toe waar een echte operationele behoefte bestaat. In Microsoft Entra ID betekent dat een Conditional Access-beleid met de voorwaarde Authentication Flows die device-code-authenticatie blokkeert; Proofpoint adviseert eerst in report-only-modus uit te rollen om de impact te meten vóór afdwinging, en waar de flow niet volledig kan worden uitgeschakeld een allowlist van goedgekeurde gebruikers, platforms of benoemde locaties te gebruiken. CISAs richtlijn over multifactorauthenticatie dringt sterk aan op phishingbestendige methoden zoals FIDO-sleutels en passkeys, die de referentie binden aan de aanmelding die daadwerkelijk plaatsvindt in plaats van aan iets dat een externe aanvaller kan inwisselen. De phishingleidraad van het Britse NCSC brengt het bredere punt onder woorden: gelaagde technische controles, een meldcultuur zonder verwijten en het via een tweede kanaal verifiëren van ongebruikelijke verzoeken baten meer dan waakzaamheidstraining alleen. Wie al een code heeft ingevoerd en een melding heeft goedgekeurd, moet het account als gecompromitteerd behandelen en op de sessie handelen, niet op het wachtwoord: wanneer een beheerder de aanmeldsessies van het account intrekt, verliezen de gestolen refresh tokens hun geldigheid — precies de herstelstap die Microsoft documenteert. Postvakregels, verleende toestemmingen en verzonden mail verdienen daarna een controle, want de tokens kunnen al zijn gebruikt om collega's te phishen. De truc hoort bij dezelfde familie als de oplichting met nep-supportmedewerkers die we eerder behandelden: de aanvaller verslaat de technologie niet, hij leent voor even de autoriteit van de gebruiker zelf. Een aanmelding die niemand je vroeg te starten, is degene om te weigeren.

meer notities

al het nieuws ›