OAuth consent phishing, in the wild

TL;DR

An interesting incident response investigation showed exploitation of a recent OAuth related consent-phishing issue. We had been asked to investigate as the organisation had noticed some odd behaviours in the mailbox of one of the exec team. The mailbox was being queried using GraphAPI and mailbox rules were being added.

By correlating logs, and reviewing the forensic image of the phone, it was clear that the user had interacted with a phishing email and given permissions to a rogue application that exploited application consent to steal an OAuth token

Walk through and mitigation advice

Note: OAuth token revocation feature provided by Azure doesn’t actually work as intended. Mitigation is to disable the user, but if the user is enabled prior to the token expiring, the attack is re-enabled. Check how long the access token is valid for and only re-enable the user after that token has expired.

The attack

The attack works by targeting an already or to-be authenticated session which allows for bypassing the need for credential harvesting and MFA requirements. What differentiates this attack from others is how the OAuth URL serves malicious content.

To the email recipient, the App Creation OAuth URL appears legitimate. The URL is formatted with the identity provider URL as well as the compromised threat actors domain.

Attackers typically configure apps so that they appear trustworthy, registering them using names like “Enable4Calc”, “SettingsEnabler”, “Settings4Enabler,” or “upgrade”  which resemble legitimate business productivity app integrations. Attackers then distribute OAuth 2.0 URLs via conventional email-based phishing attacks, among other possible techniques.

Clicking the URL triggers an authentic consent prompt, asking users to grant the malicious app permissions, similar to the below:

When users click “accept” or “allow”, the app obtains an authorization code that it redeems for an access token. This access token is then used to make API calls on behalf of the user, giving attackers access to the user’s email, forwarding rules, files, contacts, and other sensitive data and resources.

Example URL:

The pattern we observed from the forensic phone image displays the OAuth URL as “login.microsoftonline.com” and the threat actor’s domain of “viox{.}dev”

We can see the same observation when we simulate the attack using Burp:

How the attack works:

Image source: Microsoft

The client receives a notification from Microsoft regarding the app names “upgrade”. It’s already been widely covered;

• https://www.zdnet.com/article/microsoft-warns-about-this-phishing-attack-that-wants-to-read-your-emails/
• https://twitter.com/MsftSecIntel/status/1484623341155610624
• https://www.exploitone.com/cyber-security/new-fake-app-upgrade-tries-to-get-oauth-permissions-to-read-office-365-emails-uninstall-the-app/

Here’s the attack being simulated by a researcher: https://www.youtube.com/watch?v=s5UDqHpAZH8

Remediation

• Reset the users password
• Disable all future user consent operations to applications
• Ensure the access tokens have been revoked and that no sessions are active. Note that, as detailed above, the Azure feature to revoke the OAuth tokens doesn’t work properly
• Run eDiscovery searches on all users mailboxes with some repetitive pattens or regex (continue to run these daily for a period of time)
• Monitor mailbox forwarding rules created
• Mail forwarding recommendation: You can create a policy in O365 to block rule creations and should look into this, this will alert you when such a rule is attempted and provide an early indication of compromise.
• As detailed above, the Azure feature to revoke the OAuth tokens doesn’t work properly