Consent Phishing: When Employees Grant Attackers Full Account Access

Most businesses have invested in multi-factor authentication and secure email gateways to protect against phishing. But there is a category of phishing attack that bypasses both of these defences entirely, and it does so by exploiting a legitimate feature of modern cloud platforms. It is called consent phishing, and it works by tricking employees into granting malicious third-party applications access to their accounts through standard OAuth authorisation flows.

flowchart LR
    A["Fake OAuth Prompt"] --> B["User Grants Permissions"]
    B --> C["Malicious App Authorized"]
    C --> D["Reads Emails and Files"]
    D --> E["Exfiltrates Data"]
    E --> F["Persistent Access"]
  

Unlike traditional phishing, which steals passwords, consent phishing never asks for credentials at all. Instead, it convinces the victim to click "Allow" or "Accept" on what appears to be a routine application permissions request. Once that consent is granted, the attacker has persistent access to the victim's email, files, contacts, and calendar, and they keep that access even if the victim later changes their password.

Understanding OAuth and Application Consent

To understand consent phishing, you first need to understand how modern cloud platforms handle third-party application access. When you use a service like Microsoft 365 or Google Workspace, you encounter OAuth every time an application asks to connect to your account. OAuth is the protocol that allows third-party applications to access your data without you sharing your password directly.

When you click a link that says "Sign in with Microsoft" or "Connect to Google," you are redirected to a consent screen that lists the permissions the application is requesting. These permissions might include the ability to read your email, access your files, send messages on your behalf, or view your calendar. If you click "Accept," the application receives an access token that allows it to perform those actions on your behalf.

This is a perfectly legitimate mechanism. Productivity tools, CRM integrations, and collaboration platforms all rely on OAuth to function. The problem arises when attackers create malicious applications that request the same permissions, disguising them as legitimate tools. Because the consent flow is handled by Microsoft, Google, or another trusted platform, the process looks and feels entirely authentic to the end user.

Anatomy of a Consent Phishing Attack

A typical consent phishing attack follows a predictable sequence that exploits both technical trust mechanisms and human psychology.

Step One: The Lure

The attack begins with a phishing email that creates a reason for the recipient to click a link. Common pretexts include a shared document notification, a meeting invitation, a voicemail transcription, or a security alert requiring action. The email often impersonates a trusted entity such as a colleague, IT department, or cloud service provider. Because the email does not contain a malicious attachment or a link to a credential-harvesting page, many traditional email security filters let it through.

Step Two: The Redirect to a Legitimate Platform

When the victim clicks the link, they are redirected to the actual Microsoft or Google login page. This is not a spoofed page; it is the real thing. The victim authenticates using their real credentials and, if enabled, their real multi-factor authentication method. At this point, the authentication is completely legitimate, which is what makes consent phishing so insidious.

Step Three: The Consent Request

After authentication, the victim is presented with a consent screen asking them to grant permissions to an application. The application typically has an innocuous name, perhaps mimicking a well-known tool or using a generic name like "Document Viewer" or "Meeting Scheduler." The permissions requested might include reading and sending email, accessing files on OneDrive or SharePoint, reading contacts, and managing calendar events.

Step Four: Persistent Access

If the victim clicks "Accept," the attacker's malicious application receives an OAuth token that grants it ongoing access to the victim's account. This access persists until the consent is explicitly revoked by an administrator. Changing the password does not help because the application does not rely on the password; it uses the OAuth token. Even re-enrolling in multi-factor authentication has no effect on existing OAuth grants.

Why Traditional Security Controls Fail

Consent phishing is particularly dangerous because it circumvents the security controls that organisations rely on most heavily.

Email security gateways are designed to detect malicious attachments, suspicious URLs, and known phishing patterns. Consent phishing emails contain links to legitimate Microsoft or Google domains, which are almost universally whitelisted. There is no malicious payload in the email itself, so there is nothing for the gateway to flag.

Multi-factor authentication protects against credential theft, but consent phishing does not steal credentials. The victim authenticates normally through the legitimate login process. MFA confirms the victim's identity, but it cannot determine whether the application they are consenting to is legitimate or malicious.

Password policies are irrelevant because the attack does not involve passwords at all after the initial authentication. The OAuth token operates independently of the user's credentials, and rotating passwords does not revoke existing application consents.

This combination of bypass capabilities makes consent phishing one of the most effective attack vectors against organisations that have otherwise strong security postures. It targets a blind spot that exists by design in the way cloud platforms handle third-party integration.

Real-World Impact: Microsoft 365 Consent Phishing

The most common environment for consent phishing attacks is Microsoft 365, where the volume of third-party applications and integrations creates a large attack surface. Attackers register applications in Azure Active Directory, sometimes using compromised tenant accounts, and configure them to request broad permissions.

In a typical Microsoft 365 consent phishing scenario, the attacker's application requests permissions such as "Mail.ReadWrite" (read and write all mail), "Files.ReadWrite.All" (full access to all files), and "User.Read" (read the user's profile). With these permissions, the attacker can read every email in the victim's mailbox, download sensitive files, send emails as the victim, and harvest contacts for further phishing campaigns.

The damage is compounded when the attacker uses the compromised account to send internal phishing emails to the victim's colleagues. Because the emails genuinely originate from the victim's account, they bypass sender verification checks and are inherently trusted by recipients. This can quickly escalate into a business email compromise scenario with severe financial consequences.

Small businesses are disproportionately affected because they often use the default Microsoft 365 configuration, which allows any user to consent to third-party applications without administrator approval. This means a single employee clicking "Accept" can give an attacker full access to their account without any oversight or approval process.

Configuring Consent Policies to Reduce Risk

The single most effective technical defence against consent phishing is restricting who can grant application consent in your cloud environment. Here is how to configure your Microsoft 365 or Google Workspace tenant to minimise this risk.

Restrict User Consent in Microsoft 365

In the Azure Active Directory admin centre, navigate to Enterprise Applications and then User Settings. Change the setting "Users can consent to apps accessing company data on their behalf" to "No." This prevents all users from granting consent to third-party applications without administrator approval.

For organisations that need some flexibility, Microsoft offers a consent workflow that allows users to request application access, which an administrator then reviews and approves or denies. This strikes a balance between security and usability by keeping the approval process visible to the security team.

Restrict Application Consent in Google Workspace

In the Google Workspace Admin console, navigate to Security and then API Controls. Under Third-party App Access Control, configure the settings to restrict access to trusted applications only. You can maintain a whitelist of approved applications and block all others from receiving OAuth consent.

Regularly Audit Existing Consents

Even after restricting future consent, you should audit the applications that already have access to user accounts. In Microsoft 365, use the Enterprise Applications blade in Azure AD to review all applications with delegated permissions. In Google Workspace, the Admin console provides a list of third-party applications with access. Revoke consent for any application that is not recognised, no longer needed, or requesting excessive permissions.

Implement Conditional Access Policies

Conditional access policies can add an additional layer of protection by restricting application consent to specific conditions, such as requiring that consent be granted only from managed devices or from specific network locations. This limits the attacker's ability to exploit consent flows from arbitrary environments.

Building Employee Awareness Around Consent Phishing

Technical controls are essential, but employee awareness remains a critical defence layer. Many employees have never heard of consent phishing and do not understand the implications of granting application permissions.

Teach employees what consent screens look like. Most people have clicked through dozens of permission requests without reading them. Show employees examples of both legitimate and malicious consent requests, and explain what each permission actually means in practical terms. "Read and write your mail" means an application can read every email you have ever sent or received and can send emails as you.

Establish a verification process. Instruct employees to contact the IT team before granting consent to any new application, especially if the consent request arrived via email. This simple step can prevent the vast majority of consent phishing attacks from succeeding.

Include consent phishing in simulation programmes. If your organisation runs phishing simulations, include scenarios that mimic consent phishing flows. This gives employees hands-on experience recognising the attack pattern in a safe environment.

Explain why MFA is not enough. Many employees have a false sense of security because they use multi-factor authentication. Help them understand that MFA protects their password but does not protect against granting a malicious application access to their account. This contextual understanding makes employees more vigilant when encountering unexpected application consent requests.

Responding to a Consent Phishing Incident

If you suspect that an employee has fallen victim to a consent phishing attack, speed is critical. The attacker already has persistent access and may be actively exfiltrating data or using the compromised account for further attacks.

First, revoke the malicious application's OAuth consent immediately through the admin console. In Microsoft 365, navigate to the user's account in Azure AD, select "Applications," and revoke consent for the suspicious application. In Google Workspace, use the Admin console to revoke access. This immediately invalidates the application's access token.

Second, review the compromised account's recent activity. Check sent emails for phishing messages that may have been sent to colleagues or external contacts. Review file access logs for evidence of data exfiltration. Check calendar entries and contact exports for signs of reconnaissance.

Third, notify affected parties. If the attacker sent emails from the compromised account, warn the recipients that the messages were fraudulent. If sensitive data was accessed, follow your incident response and breach notification procedures.

Consent phishing represents one of the most underappreciated threats in the modern cloud security landscape. By combining technical controls, employee awareness, and incident response readiness, organisations can significantly reduce their exposure to this increasingly common attack vector.