The Dangerous Consequences of Threat Actors Abusing Microsoft’s “Verified Publisher” Status

 Key Takeaways

• Proofpoint researchers discovered a new threat campaign involving malicious third-party OAuth apps that are used to infiltrate organizations’ cloud environments.
• Threat actors satisfied Microsoft’s requirements for third-party OAuth apps by abusing the Microsoft “verified publisher” status. 
• In this campaign, which Proofpoint researchers uncovered on December 6th, 2022, the threat actors employed brand abuse, app impersonation and other social engineering tactics to lure users into authorizing malicious apps.
• The potential impact of this malicious campaign includes data exfiltration, brand abuse, and delegated permissions over compromised users’ mailboxes, calendars, and meetings.
• Users and organizations should not trust OAuth apps based on the verified publisher status alone.
• Organizations are encouraged to use cloud security solutions that can automatically detect and revoke malicious third-party OAuth apps from their environments.

Overview

Getting verified on popular platforms such as Instagram, Twitter, or the Apple AppStore is the modern online status symbol. As users, we naturally trust verified accounts more. It is the same in the enterprise world with third-party OAuth app publishers verified by Microsoft. Unfortunately, threat actors have recognized the value of the verified status in the Microsoft environment as well.

Proofpoint researchers discovered a new malicious third-party OAuth app campaign that abused the Microsoft “verified publisher” status to satisfy some of Microsoft’s requirements on OAuth app distribution. This increased the probability that users were tricked into granting consent when a malicious third-party OAuth app (hereafter referred to as “OAuth app” or “malicious app”) requests access to data accessible via a user’s account. We observed that the malicious apps had far-reaching delegated permissions such as reading emails, adjusting mailbox settings, and gaining access to files and other data linked to the user’s account. 

The potential impact to organizations includes compromised user accounts, data exfiltration, brand abuse of impersonated organizations, business email compromise (BEC) fraud, and mailbox abuse. The attack was less likely to be detected than traditional targeted phishing or brute force attacks. Organizations typically have weaker defense-in-depth controls against threat actors using verified OAuth apps.  

What does “publisher verification” mean?

“Publisher verified” or “verified publisher” is a status that a Microsoft account can gain when the “publisher of the app has verified their identity using their Microsoft Partner Network (MPN) account and has associated this MPN account with their app registration”, according to Microsoft. (To avoid confusion, a “verified publisher” has nothing to do with the Microsoft Publisher desktop application, which is included in some tiers of Microsoft 365.) 

Microsoft’s documentation goes on to clarify that “when the publisher of an app has been verified, a blue verified badge appears in the Azure Active Directory (Azure AD) consent prompt for the app and on other webpages.” Note that Microsoft is referring to third-party OAuth apps created by third-party organizations, known as “publishers” in the Microsoft environment.

In a previous blog post, Proofpoint described how threat actors compromised existing Microsoft verified publishers to abuse OAuth app privileges. The recent attacks in this campaign used a new method of impersonating credible publishers to become verified and spread malicious OAuth apps. This method allowed the threat actors to satisfy Microsoft requirements and enhances the credibility of the malicious OAuth apps. 

Three distinct malicious publishers observed targeting UK organizations

We identified three malicious apps created by three different malicious publishers. These apps targeted the same organizations and are associated with the same malicious infrastructure. Multiple users were observed authorizing the malicious apps, thereby compromising their organization’s environment.

According to our analysis, this campaign appeared to target mainly UK-based organizations and users. Among the affected users were financial and marketing personnel, as well as high-profile users such as managers and executives. We initially observed this avatar of malicious third-party OAuth apps beginning December 6th, 2022. In each case, the dedicated infrastructure behind the apps was established only days or weeks before December 6th. 

Proofpoint threat researchers continue to monitor the campaign, including the threat actors’ activity and associated infrastructure. Proofpoint informed Microsoft of this attack on December 20th, 2022. The campaign ended on December 27th, 2022. Microsoft has since disabled the malicious applications while continuing to investigate this attack. At this point, users cannot consent to the malicious apps and previously authorized malicious apps can only continue to access data until the expiration of the last access token (usually between 60 – 90 minutes). More recently, Microsoft has updated their partner vetting processes and documentation on OAuth app “consent phishing” to resist future attacks using the methods described in this blog. 

Potential Impact: Data exfiltration, mailbox abuse, and brand abuse 

When granted consent by users, the default delegated permissions in the malicious applications allow threat actors to access and manipulate mailbox resources, calendar and meeting invitations linked to the compromised users’ accounts. As the permissions also provide “offline access”, the access does not require user interaction after consent. The granted token (refresh token) has a long expiry duration of over a year in most cases. This gave threat actors access to the compromised account’s data and the ability to leverage the compromised Microsoft account in subsequent BEC or other attacks.

In addition to user accounts being compromised, impersonated organizations could suffer brand abuse. For such organizations, it is very difficult to identify that their brand is being abused in these attacks. There is no required interaction between the impersonated organization and the malicious verified publisher.

Recommendations

It is important to exercise caution when granting access to third-party OAuth apps, even if they are verified by Microsoft. Do not trust and rely on OAuth apps based on their verified publisher status alone. Due to the sophistication of such attacks, end users are likely to fall prey to the advanced social engineering methods outlined in this blog.

Organizations should carefully evaluate the risks and benefits of granting access to third-party apps. Microsoft recommends security teams follow best practices to prevent OAuth app “consent phishing”. Further, organizations should restrict user consent to apps with verified publishers and low risk delegated permissions. 

They should take proactive steps to protect their cloud environments. Ensure your security solutions can: (1) detect malicious third-party OAuth apps employing impersonation techniques; and (2) notify your security team in-time to stop and remediate risks.

Automated remediation actions, such as revoking malicious OAuth apps from your cloud environment, can greatly decrease threat actors’ dwell time and prevent most post-access risks.

Proofpoint has been assisting customers who have faced these attacks by investigating the malicious activity in their environment and improving their security policies. We have also reached out to the impersonated organizations about the potential brand abuse. 

How threat actors impersonated legitimate publishers 

We observed the employment of several tricks by threat actors to impersonate legitimate organizations and boost credibility. The displayed name of the malicious publisher for each of the malicious apps (for example: "Acme LLC”) was a lookalike to an existing legitimate publisher’s name. The “verified publisher” name was hidden and different from the displayed name (for example: “Acme Holdings LLC” instead of “Acme LLC”). The fact that threat actors registered malicious apps with “publisher verified” status suggests successful authentication via the MPN process. Microsoft communicated to Proofpoint that changing the publisher name associated with their MPN account requires re-verification. 

After gaining a verified publisher ID, threat actors added links in each app to the “terms of service” and “policy statement” that point to the impersonated organization’s website. Presumably this added credibility because the two links are displayed in the app consent form. This can be done by simply adding the links in the definition of the application, using the Azure AD Portal (web interface) or API.

Figure 1: Terms of service and policy statement URLs in Azure AD API response.

It is also notable that in two cases, the verification was granted one day after the creation of the malicious application.

Figure 2: "Verified publisher" information in Azure AD API response.

Figure 3: App info details for a malicious app, "Single Sign-on (SSO)". The app creation date is one day before the publisher was verified (impersonated organization's domain name is redacted).

The threat actors also registered and added a domain with a name resembling the impersonated organization's domain. In two cases, the top level domain of choice for the threat actors was ".events".

The application authorization request is proliferated via personalized ".html" and ".htm" files, which are linked to the application consent screen. We have redacted the user information from the file name for privacy reasons. 

Figure 4: Example of the personalization in the file name (user information is redacted).

By using a variety of tactics, users and organizations have been tricked into granting permission for these malicious apps without fully scrutinizing the permissions.

Impersonation of popular SaaS apps by malicious verified publishers 

We have observed these malicious verified publishers impersonating popular apps, such as Single-Sign On (SSO), using lookalike app icons, app names and reply-to URLs. 

Two of the observed malicious apps have the following extensive delegated scopes/permissions:

• User.Read
• email
• offline_access
• profile
• openid
• Mail.Read
• MailboxSettings.Read

 An additional detected app has the following additional delegated scopes with even greater potential for harm within organizations:

• Calendars.read
• Onlinemeetings.read
• Mail.send

Two of the malicious cloud applications are named "Single Sign On (SSO)", while the third is named "Meeting". They use an outdated version of the well-recognized Zoom icon and redirect to Zoom-resembling URLs, as well as a genuine Zoom domain, to increase their credibility. However, Zoom Video Communications was not directly impersonated as a publisher, and we have not observed any apps using the Zoom name.

Here are some examples of the user consent requests for the malicious apps.

Figure 5a: Authorization request and app scopes for malicious app, "Single Sign-on (SSO)" (publisher name is redacted).

Figure 5b: App info details for the same malicious app, "Single Sign-on (SSO)" (impersonated organization's domain name is redacted).

Figure 5c: Authorization request and app scopes for malicious app, "Meeting" (publisher name is redacted).

Figure 5d: App info details for the same malicious app, "Meeting" (impersonated organization's domain name is redacted).

We have observed a legitimate domain being added to the list of reply URLs in the later stages of this campaign.

Figure 6: Reply URLs used for one of the malicious apps, including a legitimate Zoom domain.
App IDs:

• 599fc26c-5a11-432e-a1b1-f441314ab378
• 2e024fe5-fe68-4b4f-893a-53630a97b0ae
• 8bf3e5b9-2888-4cf3-b82f-9ba6e8a1a8b9

For more information on how Proofpoint can help protect your organization against these and other cloud threats, please check out our cloud security resources.