Protecting against consent phishing

Productivity is no longer confined to private networks, and work has shifted dramatically toward cloud services. While cloud applications enable employees to be productive remotely, attackers can also use application-based attacks to gain access to valuable organization data. You may be familiar with attacks focused on users, such as email phishing or credential compromise. Consent phishing is another threat vector to be aware of. This article explores what consent phishing is, what Microsoft does to protect you, and what steps organizations can take to stay safe.

Consent phishing attacks trick users into granting permissions to malicious cloud apps. These malicious apps can then gain access to users’ legitimate cloud services and data. Unlike credential compromise, threat actors who perform consent phishing will target users who can grant access to their personal or organizational data directly. The consent screen displays all permissions the app receives. Because the application is hosted by a legitimate provider (such as Microsoft’s identity platform), unsuspecting users accept the terms or hit ‘Accept’, which grants a malicious application the requested permissions to the user’s or organization's data.

Screenshot showing permissions requested window requiring user consent.

An example of an OAuth app that is requesting access to a wide variety of permissions.

Admins, users, or Microsoft security researchers may flag OAuth applications that appear to behave suspiciously. A flagged application will be reviewed by Microsoft to determine whether the app violates the terms of service. If a violation is confirmed, Azure AD will disable the application and prevent further use across all Microsoft services.

When Azure AD disables an OAuth application, a few things happen:

  • The malicious application and related service principals are placed into a fully disabled state. Any new token requests or requests for refresh tokens will be denied, but existing access tokens will still be valid until their expiration.
  • We surface the disabled state through an exposed property called disabledByMicrosoftStatus on the related application and service principal resource types in Microsoft Graph.
  • Global admins who may have had a user in their organization that consented to an application before disablement by Microsoft should receive an email reflecting the action taken and recommended steps they can take to investigate and improve their security posture.

If your organization has been impacted by an application disabled by Microsoft, we recommend these immediate steps to keep your environment secure:

  1. Investigate the application activity for the disabled application, including:
    • The delegated permissions or application permissions requested by the application.
    • The Azure AD audit logs for activity by the application and sign-in activity for users authorized to use the application.
  2. Review and implement the guidance on defending against illicit consent grants in Microsoft cloud products, including auditing permissions and consent for the disabled application or any other suspicious apps found during review.
  3. Implement best practices for hardening against consent phishing, described below.

At Microsoft, we want to put admins in control by providing the right insights and capabilities to control how applications are allowed and used within organizations. While attackers will never rest, there are steps organizations can take to improve their security posture. Some best practices to follow include:

  • Educate your organization on how our permissions and consent framework works
  • Know how to spot and block common consent phishing tactics
    • Check for poor spelling and grammar. If an email message or the application’s consent screen has spelling and grammatical errors, it’s likely a suspicious application. In that case, you can report it directly on the consent prompt with the “Report it here” link and Microsoft will investigate if it is a malicious application and disable it, if confirmed.
    • Don’t rely on app names and domain URLs as a source of authenticity. Attackers like to spoof app names and domains that make it appear to come from a legitimate service or company to drive consent to a malicious app. Instead validate the source of the domain URL and use applications from verified publishers when possible.
    • Block consent phishing emails with Microsoft Defender for Office 365 by protecting against phishing campaigns where an attacker is impersonating a known user in your organization.
    • Configure Microsoft Defender for Cloud Apps policies such as activity policies, anomaly detection, and OAuth app policies to help manage and take action on abnormal application activity in to your organization.
    • Investigate and hunt for consent phishing attacks by following the guidance on advanced hunting with Microsoft 365 Defender.
  • Allow access to apps you trust and protect against those you don’t trust
    • Use applications that have been publisher verified. Publisher verification helps admins and end users understand the authenticity of application developers through a Microsoft supported vetting process.
    • Configure user consent settings to allow users to only consent to specific applications you trust, such as application developed by your organization or from verified publishers.
    • Create proactive app governance policies to monitor third-party app behavior on the Microsoft 365 platform to address common suspicious app behaviors.

Next steps