Edit

Share via

Protect against consent phishing

  • Article

Productivity is no longer confined to private networks, and work is shifting 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 might 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 a legitimate provider (such as the Microsoft identity platform) hosts the application, unsuspecting users accept the terms. This action grants 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 might flag OAuth applications that appear to behave suspiciously. Microsoft reviews a flagged application to determine whether it violates the terms of service. If a violation is confirmed, Microsoft Entra ID disables the application and prevents further use across all Microsoft services.

When Microsoft Entra ID 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 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 can't delete these objects.
  • An email is sent to a Privileged Role 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 a Microsoft disabled application impacts the organization, the organization should take the following steps 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 Microsoft Entra 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 in the following section.

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 investigates 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 applications include applications developed by your organization or from verified publishers and only for low risk permissions you select.
    • Use applications that are 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's 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, other app and publisher details on the consent prompt, and so on.
    • Create proactive application governance policies to monitor third-party application behavior on the Microsoft 365 platform to address common suspicious application behaviors.

Next steps