In December 2022, attackers ran a consent phishing campaign with a twist: their malicious OAuth apps carried Microsoft's blue "verified publisher" badge. Microsoft says the actor "used fraudulent partner accounts to add a verified publisher to OAuth app registrations they created in Azure AD," by impersonating legitimate companies when enrolling in the Microsoft Cloud Partner Program. Proofpoint, which found the campaign on 6 December 2022, saw three apps posing as single sign-on and meeting tools, aimed mainly at UK organisations. When users clicked consent, the apps received delegated access to their mailboxes, calendars and meetings, with offline access and refresh tokens that Proofpoint says usually lasted over a year. Microsoft found the attackers used the apps mainly to exfiltrate email. It disabled the apps and accounts, notified affected customers and tightened partner vetting.
Key takeaways
- No passwords were stolen. Users were tricked into granting OAuth consent to apps, which then held their own long-lived tokens to users' email and calendars.
- The apps looked trustworthy because they had Microsoft's verified publisher badge, obtained through fraudulent Microsoft Cloud Partner Program accounts impersonating real companies.
- Proofpoint observed three malicious apps from three publishers targeting mainly UK organisations, including finance and marketing staff and executives, from 6 to 27 December 2022.
- Microsoft says the attackers used the apps primarily to exfiltrate email; it disabled them and improved its partner vetting.
- The identity lesson: an OAuth grant creates a non-human identity with standing access to a user's data, so consent needs the same governance as any other access.
At a glance
| Organisations | Microsoft (Azure AD and the Microsoft Cloud Partner Program); targeted organisations, mainly in the UK and Ireland; impersonated legitimate publishers |
|---|---|
| When | Campaign observed 6 to 27 December 2022; Microsoft aware 15 December 2022; Proofpoint published 27 December 2022; Microsoft published its investigation in January 2023 |
| Attacker | Unattributed; Microsoft engaged its Digital Crimes Unit |
| Entry point | Consent phishing links to malicious multi-tenant OAuth apps registered in Azure AD with a fraudulently obtained verified publisher status |
| Identities abused | Malicious OAuth applications and the delegated access tokens, including long-lived refresh tokens, that users granted them; fraudulent partner program accounts |
| Impact | Email exfiltrated from users who consented, according to Microsoft; potential calendar and meeting abuse, business email compromise and brand abuse |
| Category | NHI. Incident class: confirmed NHI breach (malicious OAuth apps holding delegated tokens) |
What happened
Consent phishing does not ask for a password. It sends the victim to a genuine Microsoft consent screen for an attacker's app. If the user accepts, the app receives delegated permissions and tokens to read their data. To make that screen more convincing, the attackers in this campaign got Microsoft to mark their apps as coming from a verified publisher. According to Microsoft, they impersonated legitimate companies when enrolling in the Microsoft Cloud Partner Program (formerly the Microsoft Partner Network) and used those fraudulent partner accounts to verify the apps they registered in Azure AD.
Proofpoint's researchers first saw the apps on 6 December 2022. They found three apps, from three different malicious publishers, sharing infrastructure and targeting the same organisations. The apps posed as "Single Sign-on (SSO)" and "Meeting" tools, one with an old Zoom icon, according to Help Net Security. The publisher names were lookalikes of real publishers, the apps linked to the impersonated companies' terms of service and privacy pages, and in two cases the verification was granted one day after the app was created. Consent requests were spread through personalised HTML files. Targets included finance and marketing staff and managers and executives, mainly in the UK.
The default permissions let the apps read and manipulate mailboxes, calendars and meeting invitations, and included offline access. "The granted token (refresh token) has a long expiry duration of over a year in most cases," Proofpoint wrote. Proofpoint told Microsoft on 20 December, and the campaign ended on 27 December.
Microsoft says it became aware of the campaign on 15 December 2022. Its investigation "determined that once consent was granted by victim users, threat actors used third party OAuth applications as a primary technique/vector to exfiltrate email." It disabled the apps across all tenants, disabled the actor's accounts, notified impacted customers with an email titled "Review the suspicious application disabled in your [tenant name] tenant", engaged its Digital Crimes Unit and "implemented several additional security measures to improve the MCPP vetting process."
Timeline
| Date | Event |
|---|---|
| 6 December 2022 | Proofpoint first observes the malicious verified OAuth apps. |
| 15 December 2022 | Microsoft becomes aware of the consent phishing campaign. |
| 20 December 2022 | Proofpoint informs Microsoft of the attack. |
| 27 December 2022 | The campaign ends; Proofpoint publishes its findings. |
| January 2023 | Microsoft publishes its investigation and confirms the apps and accounts were disabled. |
How it happened: the identity attack path
- Fraudulent publisher identity. The attackers enrolled in Microsoft's partner programme while impersonating real companies, gaining a verified publisher ID.
- Malicious apps registered. They created OAuth app registrations in Azure AD, attached the verified publisher and dressed the apps as SSO and meeting tools.
- Consent phishing. Targeted users received personalised links to the apps' consent screens, which showed Microsoft's verified badge.
- Tokens granted. Users who consented gave the apps delegated access to mail, calendars and meetings, including refresh tokens valid for over a year.
- Email exfiltration. The attackers used the apps' tokens to take email, without needing the users' passwords or MFA.
Impact
- Confirmed: email exfiltrated from users who granted consent; all impacted customers notified by Microsoft.
- Potential: business email compromise, mailbox and calendar abuse, and brand abuse of the impersonated publishers, according to Proofpoint.
- Platform: Microsoft changed its partner vetting process to reduce the chance of fraudulent verification.
What this means for NHI governance
Every OAuth consent creates a new non-human identity inside the tenant: an application with its own tokens and permissions that keeps working after the user closes the browser. In this campaign, that identity belonged to an attacker, and the refresh tokens meant access could last for more than a year. MFA did not help, because the user signed in legitimately and then handed access to the app.
Trust signals like a verified badge are not a control. Organisations need to decide which apps users may consent to, require admin approval for sensitive scopes such as mail and file access, and review existing grants regularly. Our SaaS and OAuth App Governance Guide and OAuth 2.0 and OpenID Connect Guide explain how.
Recommendations
- Restrict user consent. Allow users to consent only to apps from verified publishers with low-risk permissions, and route everything else to admin review. See the SaaS and OAuth App Governance Guide.
- Do not treat verification badges as proof of safety. Check publisher names, domains and requested scopes before approving.
- Audit existing OAuth grants. Review which apps hold mail, file and offline access, and revoke unknown or unused ones.
- Alert on new high-privilege consents. Monitor for grants of mail read, offline access and similar scopes, especially to recently created apps.
- Revoke tokens as well as apps. When an app is disabled, make sure its refresh tokens are revoked too. See the Token and Session Security Guide.
Frequently asked questions
What is consent phishing?
Consent phishing tricks a user into granting permissions to an attacker's app on a genuine sign-in and consent screen. The app then receives tokens to the user's data, so the attacker never needs the password.
How did malicious apps get Microsoft's verified publisher badge?
Microsoft says the attackers impersonated legitimate companies when enrolling in the Microsoft Cloud Partner Program, then used those fraudulent partner accounts to verify the apps they registered in Azure AD.
What did the attackers access?
The apps had delegated access to mailboxes, calendars and meetings. Microsoft found they were used mainly to exfiltrate email from users who consented.
Related NHI Mgmt Group resources
GitHub OAuth Token Breach 2022 · CoPhish OAuth Token Theft · SaaS and OAuth App Governance Guide · OAuth 2.0 and OpenID Connect Guide · Token and Session Security Guide
How NHI Mgmt Group can help
OAuth apps are often the least governed identities in a Microsoft 365 or Google Workspace tenant. We help teams set consent policies, review existing grants and bring third-party apps into their identity governance. See our NHI and AI agent security training.
References
- Proofpoint: The Dangerous Consequences of Threat Actors Abusing Microsoft's "Verified Publisher" Status (27 December 2022)
- Microsoft MSRC: Threat actor consent phishing campaign abusing the verified publisher process (January 2023)
- Help Net Security: Attackers used malicious "verified" OAuth apps to infiltrate organizations' O365 email accounts (31 January 2023)