Protect 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 an organization, and what steps organizations can take to stay safe.

Consent phishing attacks trick users into granting permissions to malicious cloud applications. These malicious applications can then gain access to legitimate cloud services and data of users. Unlike credential compromise, threat actors who perform consent phishing target users who can grant access to their personal or organizational data directly. The consent screen displays all permissions the application receives. Because the application is hosted by a legitimate provider (such as the Microsoft identity platform), unsuspecting users accept the terms, which grant a malicious application the requested permissions to the data. The following image shows an example of an OAuth app that is requesting access to a wide variety of permissions.

Screenshot showing permissions requested window requiring user consent.

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

When Azure AD disables an OAuth application, the following actions occur:

  • The malicious application and related service principals are placed into a fully disabled state. Any new token requests or requests for refresh tokens are denied, but existing access tokens are still valid until their expiration.
  • These applications will show DisabledDueToViolationOfServicesAgreement on the disabledByMicrosoftStatus property on the related application and service principal resource types in Microsoft Graph. To prevent them from being instantiated in your organization again in the future, you cannot delete these objects.
  • An email is sent to a global administrator when a user in an organization consented to an application before it was disabled. The email specifies the action taken and recommended steps they can do to investigate and improve their security posture.

If the organization has been impacted by an application disabled by Microsoft, the following immediate steps should be taken to keep the 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 use the guidance for defending against illicit consent grants. The guidance includes auditing permissions and consent for disabled and suspicious applications found during review.
  3. Implement best practices for hardening against consent phishing, described below.

Administrators should be in control of application use by providing the right insights and capabilities to control how applications are allowed and used within organizations. While attackers never rest, there are steps organizations can take to improve the 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 consent screen of the application has spelling and grammatical errors, it's likely a suspicious application. In that case, report it directly on the consent prompt with the Report it here link and Microsoft will investigate if it's a malicious application and disable it, if confirmed.
    • Don't rely on application names and domain URLs as a source of authenticity. Attackers like to spoof application names and domains that make it appear to come from a legitimate service or company to drive consent to a malicious application. 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 the organization.
    • Configure Microsoft Defender for Cloud Apps policies to help manage abnormal application activity in the organization. For example, activity policies, anomaly detection, and OAuth app policies.
    • Investigate and hunt for consent phishing attacks by following the guidance on advanced hunting with Microsoft 365 Defender.
  • Allow access to trusted applications that meet certain criteria and protect against those applications that don't:
    • Configure user consent settings to allow users to only consent to applications that meet certain criteria, such as applications developed by your organization or from verified publishers and only for low risk permissions you select.
    • Use applications that have been publisher verified. Publisher verification helps administrators and users understand the authenticity of application developers through a Microsoft supported vetting process. Even if an application does have a verified publisher, it is still important to review the consent prompt to understand and evaluate the request. For example, reviewing the permissions being requested to ensure they align with the scenario the app is requesting them to enable, additional app and publisher details on the consent prompt, etc.
    • Create proactive application governance policies to monitor third-party application behavior on the Microsoft 365 platform to address common suspicious application behaviors.

Next steps