Device Code Phishing

Spotit Red Team

Bij Spotit voeren we ‘red team engagements’ uit voor klanten en intern binnen het bedrijf. Deze kunnen een penetration test zijn tegen infrastructuur en assets, fysieke inbreuken, social engineering en phishing-campagnes omvatten. Een recente gerichte phishing-campagne door ons red team, waarbij gebruik werd gemaakt van de devicecode phishing techniek, resulteerde in het compromitteren van het AzureAD-account van een gebruiker, inclusief toegang tot alle Teams, e-mail, SharePoint en interne applicaties.

De phishing-techniek met devicecode werd misschien voor het eerst besproken in een blogpost op o365blog.com door Nestori Syynimaa (@DrAzureAD) van 13 oktober 2020.

Device code phishing maakt gebruik van het proces voor device authorization grant (RFC8628) in het Microsoft Identity Platform om het apparaat of de toepassing van een aanvaller toegang te geven tot het account of systeem van de doelgebruiker.

Gebruikte gereedschappen

Met een combinatie van AAD Internals, TokenTactics en MSGraph API-calls kon het red team een ​​devicecode genereren, controleren wanneer de devicecode op de Microsoft-site werd ingevoerd en het volgende verkrijgen:

• een access token voor EEN specifieke bron (bijv. Outlook, Teams, Sharepoint, …) die ongeveer 60 minuten geldig is, en
• een refresh token dat kan worden gebruikt om een ​​nieuw access token voor ELKE bron aan te vragen, dat 90 DAGEN geldig is.

Doel in zicht

TL;DR: red team kwam in direct contact met iemand van het doelbedrijf, stuurde hen een Microsoft 'devicelogin'-URL en een auth-code vermomd als uitnodiging voor een Teams-vergadering. Het personeelslid liet zich vangen dat tot een voledig gecompromitteerd account.

Ons zeer bekwame red team heeft een plan gemaakt om zich te richten op een medewerker die vermoedelijk veel toegang zou hebben. Iemand in Accounts of Sales idealiter. De red teamer zou een bericht sturen via het doelbedrijf en om hulp vragen bij een IT Security Assessment. Om dit te doen bedacht het red team een ​​plan om zich voor te doen als werknemer van een bedrijf in hetzelfde land dat actief is in de IT.

Het red team heeft LinkedIn doorgenomen en een geschikte persoon gevonden om te spoofen.

Het red team koos een naam en een rol voor een medewerker bij een vergelijkbaar bedrijf en maakte vervolgens een Gmail-account met de naam van die persoon.

Vervolgens werd een e-mail geschreven en verzonden naar de verkoopinbox van het doelbedrijf. Er werd geen reactie ontvangen, dus hetzelfde bericht werd vervolgens verzonden naar het contactformulier van het doelbedrijf op hun website en er werd een antwoord ontvangen.

Na enige discussie en schijnbaar geen vermoedens, werd een afspraak gemaakt om met spoed een Teams-vergadering te houden.

Het red team heeft een devicecode gegenereerd met behulp van een VPN in het land van het doelwit en de payload is verzonden.

De URL van de vergadering wees eigenlijk naar:

https://www.microsoft.com/devicelogin?meetup-join/19%3ameeting_NjFmMWI4MWEtYTI1My0…

Twee dingen zijn onjuist aan deze URL:

• Een echte Teams-vergaderings-URL moet verwijzen naar “https://teams.microsoft.com/…”
• Alles na “?” is toegevoegd om de URL er overtuigender uit te laten zien

Dit is het cruciale onderdeel van de phishing-aanval. Bij het bezoeken van “https://www.microsoft.com/devicelogin” wordt de gebruiker doorgestuurd naar “https://login.microsoftonline.com/common/oauth2/deviceauth”. Merk op dat beide legitieme websites van Microsoft zijn.

De pagina vraagt ​​de gebruiker om een ​​code in te voeren. Als het slachtoffer al is ingelogd op zijn Microsoft-account, levert het verzenden van de door de aanvaller gegenereerde devicecode de aanvaller een token op dat toegang heeft tot de bronnen van de organisatie als de gebruiker van het slachtoffer.

(Samenvattend: na het invoeren van de code heeft de aanvaller toegang tot het account van het slachtoffer)

Het voorbehoud is:
• Na het genereren van een code is deze slechts 15 minuten geldig.
• Als u de code invoert, wordt er een extra waarschuwingsbericht voor de gebruiker weergegeven: “U logt in op een ander apparaat in <attacker_country>. Weet je zeker dat je dit wilt doen?”

Beide problemen werden opgelost door de social engineering-aanpak, waarbij urgentie werd geïntroduceerd door alleen de uitnodiging voor de vergadering te verzenden vlak voordat de vergadering begon. Dit zorgde ervoor dat de code nog geldig was op het moment van invoer, maar ook dat de gebruiker mogelijk niet al te veel aandacht zou besteden aan de waarschuwingsberichten.

Hoe te vermijden

We raden ten zeerste aan om als onderdeel van de algemene training voor Phishing Awareness, het personeel te trainen om altijd te controleren of de URL’s geldig zijn voor de context van het gesprek. Te veel trainingsprogramma’s adviseren het personeel gewoon om te controleren op “https” en misschien dat het domein een geldig domein is voor wat ze verwachten. Deze techniek laat zien dat legitieme Microsoft-applicaties en workflows kunnen worden misbruikt door aanvallers.

Het personeel moet altijd het pad van de URL controleren (bijv. na de microsoft.com/) – “devicelogin“ had hier een dooddoener moeten zijn.

Zichtbaarheid

Op dit moment genereert geen van de Microsoft-tooling (Defender, AzureAD, O365-logboekregistratie enz.) waarschuwingen dat een nieuwe devicecode is geautoriseerd door een gebruiker.

Als de aanvaller toegang krijgt tot applicaties uit een ander land, dan kan er een ‘Impossible Travel’ waarschuwing worden gegenereerd van de tooling. Dit wordt gemakkelijk teniet gedaan door openbare VPN’s in landen te gebruiken van het doelwit.

Aangepaste waarschuwingen kunnen mogelijk worden gemaakt door gebruikers te detecteren die de ‘devicelogin’ URL of de ‘MIP’ flow, maar dat geeft nog steeds geen informatie over de aanvaller.

Conclusie

De phishing-techniek met devicecode kan bijzonder schadelijk zijn, aangezien:

• Er is geen initiële waarschuwingen zijn
• De payload wordt ingevoerd in een legitiem Microsoft-domein
• De gegeven tokens kunnen 90 dagen persistentie creëren
• De tokens geven toegang tot alles
• Overweeg om de Phishing Awareness-training bij te werken met de tips hierboven, en als je een methode bedenkt om waardevolle waarschuwingen te genereren, implementeer deze dan onmiddellijk.

Verder lezen

https://o365blog.com/post/phishing/

https://0xboku.com/2021/07/12/ArtOfDeviceCodePhish.html

https://docs.microsoft.com/en-us/azure/active-directory/develop/