Entrepreneurship Device Code Phishing

Spotit Red Team

At Spotit, we conduct red team engagements for customers and internally within the company. These can include a penetration test against infrastructure and assets, physical breaches, social engineering, and phishing campaigns. A recent targeted phishing campaign by our red team, using the device code phishing technique , resulted in a user’s Azured account being compromised , including access to all Teams , email , SharePoint , and internal applications.

The device code phishing technique was perhaps first discussed in a blog post on o365 blog.com by Nestori Syynimaa (@DrAzureAD) dated October 13, 2020. Device code phishing uses the device authorization grant (RFC8628) process in the Microsoft identity platform to allow an attacker’s device or application to access the target user’s account or system.

Tools used

Using a combination of AAD Internals, TokenTactics, and MSGraph API calls, the red team was able to generate a device code, check when the device code was entered on the Microsoft site, and obtain:

• an access token for ONE specific resource (e.g. Outlook, Teams, Sharepoint, …) that is valid for approximately 60 minutes, and
• a refresh toke that can be use to request a new access toke for ANY resource, which Valid for 90 DAYS.

Target in sight

Our highly skilled red team created a plan to target an employee likely to have a lot of access. Someone in Accounts or Sales ideally. The red teamer would send a message through the target company asking for help with an IT Security Assessment. To do this, the red team came up with a plan to pose as an employee of a company in the same country that is active in IT. The red team went through LinkedIn and found a suitable person to spoof. It’s easy to find and filter employees on LinkedIn The red team chose a name and role for an employee at a similar company, then created a Gmail account with that person’s name.

An email was then write and sent to the target company’s sale inbox. No response was receive, so the same message was then sent to the target company’s contact form on their website and a response was receive. After some discussion and seemingly no suspicion, an appointment was made to urgently hold a Teams meeting. The red team generate a device code using a VPN in the target country and sent the payload. Device code verification page

Entrepreneurship,  The page prompts the user to enter a code. If the victim is already log into their Microsoft account, sending the attacker-generate device code will provide the attacker with a toke that can access the organization’s resource as the victim’s user. (In summary, after entering the code, the attacker can access the victim’s account)

The caveat is:
• After generating a code, it is only valid for 15 minutes.
• Entering the code will display an additional warning message to the user: “You are logging in on another device in <attacker_country>. Are you sure you want to do this?”

Both problem were solve by the social engineering approach, which introduce urgency by only sending the meeting invite right before the meeting start. This ensured that the code was still valid at the time of entry, but also that the user might not pay too much attention to the warning messages.

How to avoid

Entrepreneurship, As part of general Phishing Awareness training, we strongly recommend training staff to always check that the URLs are valid for the context of the conversation. Too many training programs simply advise staff to check for “https” and maybe the domain is a valid domain for what they expect.

This technique show that legitimate Microsoft applications and workflow can be exploit by attacker. Staff should always check the path of the URL (e.g. after the microsoft.com/) – “devicelogin” should have been a clincher here .

Visibility

Currently, none of the Microsoft tooling (Defender, Azured, O365 logging, etc.) generates alerts that a new device code has been authorized by a user. If the attacker gain access to application from another country , an ‘Impossible Travel’ warning may be generate from the tooling.

Entrepreneurship,  This is easily negate by using public VPN in country of the target. Custom alert can be enable by detecting user entering the ‘device login’ URL or the ‘MIP’ flow, but that still doesn’t provide any information about the attacker.

Conclusion

The device code phishing technique can be particularly damaging as:

• There will be no initial warnings
• The payload is enter into a legitimate Microsoft domain
• The given tokens can create persistence for 90 days
• The tokens give access to everything
• Consider updating the Phishing Awareness training with the tips above , and if you come up with a method to generate valuable alerts, implement it immediately .