Device code phishing is een vorm van phishing, waarbij dreigingsactoren misbruik maken van een legitieme inlogmethode voor apparaten zonder browser, zoals IOT-apparaten. Dit met als doel om jouw account over te kunnen nemen. In deze blog leg ik uit hoe device code phishing werkt en welke maatregelen je kan nemen om de kans op misbruik te verkleinen.
Wat zijn tokens?
Door misbruik te maken van legitieme authenticatieprocessen kunnen dreigingsactoren tokens bemachtigen, waarmee wachtwoorden en MFA kunnen worden omzeild. Maar wat is nu een token?
Een token is een tijdelijk digitaal bewijs dat een gebruiker succesvol is geauthenticeerd. Er zijn verschillende typen tokens, ieder met een eigen functie die interessant is voor dreigingsactoren.
- Sessietokens
Zodra er met een account succesvol wordt ingelogd wordt er door Microsoft een sessietoken uitgegeven, waarmee de gebruiker gedurende een bepaalde periode toegang krijgt tot het account zonder opnieuw in te hoeven loggen totdat deze verloopt (expire) of wordt ingetrokken (revoke).
- Accesstokens
Een accesstoken bevat alle toegangsinformatie en geeft direct toegang tot resources. Accesstokens zijn beperkt geldig, meestal gedurende een periode van minuten tot enkele uren.
- Refreshtokens
Met een refreshtoken kunnen nieuwe accesstokens worden gegenereerd, zonder dat er opnieuw ingelogd hoeft te worden, ook nadat het originele token is verlopen.
Afhankelijk van de aanvalsmethode kunnen deze tokens door de dreigingsactor gestolen en misbruikt worden. In deze blog nemen we een adversary in the middle-aanval als voorbeeld.
Adversary in the Middle-aanval
Dreigingsactoren weten het sessietoken te stelen door een slachtoffer te lokken naar een zorgvuldig ontworpen webpagina die identiek oogt aan het inlogportaal van de organisatie van het slachtoffer. Zodra het slachtoffer inlogt met de gebruikersnaam en het wachtwoord, wordt dit via de infrastructuur van de dreigingsactor doorgestuurd naar Microsoft. Microsoft stuurt een MFA-code terug waarmee de inlogpoging kan worden bevestigd. Deze wordt via de dreigingsactor aan het slachtoffer getoond, waarna het slachtoffer de inlogpoging goedkeurt. Zodra de inlogpoging is goedgekeurd stuurt Microsoft de sessietoken terug. Deze belandt bij de dreigingsactor, waardoor de dreigingsactor toegang heeft tot het account van het slachtoffer.
Op dit moment bevindt de dreigingsactor zich tussen het slachtoffer en het daadwerkelijke inlogportaal, vandaar dat dit een ‘Adversary-in-the-Middle’ (AitM)-aanval wordt genoemd, zie figuur 1 voor een schematisch overzicht.
In deze videodemo wordt dit stap voor stap in beeld gebracht.
Device code phishing-aanval
Anders dan bij een reguliere Adversary in the Middle-aanval, waarbij het slachtoffer naar een neppe inlogpagina wordt gelokt, wordt er bij een device code phishing-aanval misbruik gemaakt van een legitiem authenticatiemechanisme van Microsoft, namelijk de OAuth device code flow.
Deze flow is oorspronkelijk ontworpen voor apparaten zonder browser, zoals smart-tv’s, waarbij de gebruiker een code genereert op een apparaat zonder toetsenbord en deze code invoert op een ander apparaat om te autoriseren. Een dreigingsactor maakt hier misbruik van door zelf een device code bij Microsoft te genereren. De ontvangen code stuurt hij door naar het slachtoffer, waarna het slachtoffer wordt misleid om deze code in te voeren op de echte inlogpagina van Microsoft.
Figuur 2: Weergave van een device code phishing-aanval (bron)
Zodra een slachtoffer de device code flow succesvol doorloopt van een device code flow-aanval, ontvangt de dreigingsactor een geldig accesstoken én doorgaans ook een refreshtoken. Daarmee kan de dreigingsactor met het verkregen accesstoken toegang tot de resources misbruiken. Zodra dit accesstoken verloopt, kan de dreigingsactor met het refreshtoken nieuwe accesstokens genereren waardoor de dreigingsactor toegang behoudt tot het account van het slachtoffer.
Handelingsperspectief
Het handelingsperspectief om deze aanval te voorkomen of de impact ervan te beperken is als volgt:
- Door het activeren van Continuous Access Evaluation (CAE) worden gestolen tokens onmiddellijk ongeldig wanneer er een wijziging plaatsvindt (bijv. IP‑verandering, sessie‑intrekking of verdachte activiteit).
- Richt een conditional access policy in waarmee de device-code flow wordt uitgeschakeld. Aanvullende conditional access policies maken het mogelijk om apparaat-compliance af te dwingen (Intune‑gedelegeerd of Hybrid Azure AD- joined); om de toegang vanuit specifieke geografische locaties te beperken; om inlogpogingen vanuit accounts met een hoge risicoscore blokkeren; en om aanvullende MFA-methode af te dwingen bij verdachte logins.
- Beheer de levensduur van access‑tokens en refresh‑tokens via een token‑lifetime‑policy, zodat een dreigingsactor niet meerdere dagen toegang kan behouden.
- Trek in geval van een incident alle actieve tokens in (via RevokeSessions) en schakel het account vervolgens uit (disable). Zo kan voorkomen worden dat een dreigingsactor opnieuw inlogt op het account en daarmee een nieuwe token kan genereren. Het is belangrijk om het account minimaal 2 uur (of de aangepaste tijd dat de refresh token geldig blijft) uitgeschakeld te houden. Vóórdat het account vrijgegeven kan worden, dienen alle actieve sessies nogmaals ingetrokken te worden.
Gelaagde verdediging
De maatregelen uit het handelingsperspectief vullen elkaar aan en vormen samen een gelaagde verdediging. Het activeren van Continuous Access Evaluation zorgt ervoor dat gestolen tokens onbruikbaar worden zodra er iets verandert aan het gedrag of de context van de gebruiker, zoals een andere locatie of een ingetrokken sessie. Het uitschakelen van de device code flow via een conditional access policy blokkeert de misbruikte authenticatiemethode volledig, waardoor een dreigingsactor deze aanvalsvector niet langer kan benutten.
Aanvullende conditional access policies verhogen de controle over welke apparaten en locaties überhaupt toegang kunnen krijgen tot het netwerk. Het beperken van de levensduur van tokens verkleint het tijdvenster waarin een dreigingsactor iets kan doen met een gestolen token.
Tot slot beschrijven de triagestappen hoe je na een incident voorkomt dat een dreigingsactor opnieuw toegang krijgt, door tokens in te trekken en het account tijdelijk uit te schakelen.
Conclusie
Device code phishing onderscheidt zich van een AitM-aanval doordat de drempel voor de dreigingsactor aanzienlijk lager ligt: bij een AitM-aanval moet de aanvaller een nepwebpagina opzetten en actief verkeer onderscheppen, terwijl het bij een device code phishing-aanval volstaat om enkel een device code te genereren waarna de dreigingsactor enkel dient af te wachten totdat een slachtoffer de authenticatieflow doorloopt.
Doordat er misbruik gemaakt wordt van een legitiem Microsoft-authenticatiemechanisme, is er geen eigen infrastructuur nodig.
Deze lage instapdrempel maakt deze aanvalsmethode aantrekkelijk voor een breed scala aan dreigingsactoren.
Daarom verwachten we dat device code phishing de komende tijd vaker zal worden ingezet ten opzichte van AitM-aanvallen.
Wij raden organisaties dan ook aan om zo snel mogelijk de conditional access policy voor de device code flow in te richten, en de overige maatregelen parallel of op korte termijn in te plannen.
Lees ook: Aantal phishing-aanvallen verdubbeld in een jaar tijd