FBI Warns of MFA-Bypassing OAuth Phishing
FBI Warns of OAuth Consent Phishing Campaign Bypassing MFA
Related Entities(initial)
Organizations
Products & Tech
Full Report(when first published)
Executive Summary
The Federal Bureau of Investigation (FBI) has issued a public service announcement (PSA) through its Internet Crime Complaint Center (IC3) warning of an ongoing and sophisticated phishing campaign that abuses the OAuth 2.0 protocol. The technique, known as "consent phishing," targets prominent individuals by tricking them into granting malicious third-party applications access to their email and cloud service accounts. Once consent is granted, the attacker gains persistent access via an authorization token, effectively bypassing conventional security measures like password changes and even multi-factor authentication (MFA). The FBI urges users to be extremely cautious when granting permissions to any application, no matter how legitimate the request may seem.
Threat Overview
The campaign, active since late 2025, begins with social engineering. Threat actors impersonate public figures, journalists, or government officials and contact targets via email or messaging apps. They use a pretext, such as reviewing a document or verifying an identity, to lure the victim into clicking a link. This link leads to a legitimate OAuth consent screen from a major provider like Google or Microsoft, asking the user to grant permissions to a seemingly benign application.
If the user clicks "Accept," they are not giving away their password. Instead, they are authorizing the attacker's malicious application to access their account data (e.g., read/send emails, access files) on their behalf. This access is persistent and will survive password resets. The only way to sever the connection is to manually review the account's security settings and revoke the token granted to the malicious application.
Technical Analysis
This attack abuses the legitimate, intended functionality of the OAuth 2.0 authorization framework.
- Registration: The attacker registers a malicious application with an OAuth 2.0 provider, such as Google or Microsoft Azure AD.
- Social Engineering: The attacker crafts a phishing email or message with a link to the OAuth consent endpoint, including their application's client ID (
T1566.002 - Spearphishing Link). - Trick User Consent: The victim clicks the link and is presented with a real consent screen from the provider. Trusting the provider (Google/Microsoft), the user grants the requested permissions (e.g.,
Mail.Read,Files.ReadWrite.All). - Token Theft & Access: The provider gives the attacker's application an access token. The attacker can now use this token to access the victim's data via API calls, completely bypassing the need for a password or MFA (
T1528 - Steal Application Access Token). - Persistence: This access remains valid until the user manually revokes the application's permission in their account settings.
Impact Assessment
- MFA Bypass: This is the most significant impact. Organizations that rely on MFA as a primary defense are vulnerable if users are tricked into granting consent.
- Persistent Access: Attackers gain long-term, stealthy access to a victim's most sensitive data, including emails, contacts, and files stored in services like OneDrive or Google Drive.
- Account Takeover: With access to email, attackers can perform password resets for other services, leading to a complete takeover of the victim's digital life.
- High-Profile Targeting: The focus on prominent individuals means the potential for espionage, blackmail, or the theft of highly valuable intellectual property or state secrets is significant.
IOCs — Directly from Articles
No specific application names, IP addresses, or domains were mentioned in the source articles.
Cyber Observables — Hunting Hints
Detection for this threat shifts from network indicators to cloud audit logs:
Cloud Audit Logs (e.g., Azure AD, Google Workspace)/oauth2/v2.0/authorizeUnverified PublisherAnomalous API usageDetection & Response
- Audit OAuth Consents: Regularly audit all OAuth applications that have been granted permissions in your environment. In Azure AD, this can be done via the "Enterprise applications" blade. Look for applications with high-risk permissions (e.g.,
Mail.ReadWrite,User.Read.All) that are not recognized or approved (D3-AZET: Authorization Event Thresholding). - Monitor for New App Consents: Create alerts in your SIEM or cloud security platform for every time a user grants consent to a new application. This allows for rapid review and revocation if the application is malicious.
- User-Reported Phishing: Encourage users to report any suspicious emails or messages, especially those asking them to grant permissions or 'verify' their account. This is often the earliest indicator of a consent phishing campaign.
Mitigation
Mitigation requires a combination of technical controls and user education.
- Configure Consent Settings: In Microsoft 365 and Google Workspace, administrators can configure user consent settings. The most secure posture is to disable user consent entirely and require an administrator to review and approve any new application. This aligns with
M1054 - Software Configuration. - User Training: Educate users about the dangers of OAuth consent phishing. Specifically, teach them to scrutinize the permissions an application is requesting before clicking "Accept." They should ask, "Why does this document viewer need to send email on my behalf?" (
M1017 - User Training). - Application Vetting: For organizations that cannot disable user consent, develop a process to vet and approve a list of known-good applications. Use technical controls to block or warn users when they attempt to grant consent to an unapproved application.
- Regularly Review Permissions: Instruct users on how to periodically review the applications connected to their accounts and revoke any they do not recognize or no longer use.
Timeline of Events
Article Updates
September 30, 2026
New campaigns 'N0va' and 'CSuite' use Device Code phishing to bypass MFA in M365, stealing access/refresh tokens.
Update Sources:
MITRE ATT&CK Mitigations
User Training
Educating users on the dangers of OAuth consent screens and the meaning of requested permissions is the primary defense.
Software Configuration
Administrators can configure cloud environments to disable user consent, forcing all application approvals through an admin review process.
Mapped D3FEND Techniques:
D3FEND Defensive Countermeasures
The most effective technical countermeasure against consent phishing is to harden the OAuth configuration in your cloud environment (Microsoft 365 or Google Workspace). Administrators should configure user consent settings to 'Disable user consent'. This prevents non-administrator users from granting permissions to any new application. Instead, when a user wants to use a new third-party app, it will trigger an 'admin consent workflow'. This forces the application request to be reviewed by the IT or security team, who can vet the application's publisher, requested permissions, and legitimacy before approving it for the organization. This control moves the decision from a potentially naive user to a trained administrator, effectively shutting down the primary vector for this attack.
Detecting a successful consent phishing attack requires monitoring post-compromise activity. A UBA or Cloud Access Security Broker (CASB) solution can baseline normal API usage for a given user and application. Once an attacker gains an access token for their malicious app, their activity will likely be anomalous. For example, the malicious app might immediately begin downloading all emails from the user's inbox or accessing files that the user has never touched. A UBA system would detect this spike in API calls or access to unusual resources and flag it as a high-risk event. This allows security teams to detect the compromise and quickly move to revoke the malicious application's token, even if the initial consent event was missed.
Since this attack relies on tricking the user, targeted training is a critical defense layer. Users must be taught that the OAuth consent screen is a security checkpoint, not just a formality. Training should include concrete examples. Show users a legitimate consent screen next to a malicious one. Highlight the key areas to inspect: the application name, the publisher (is it 'unverified'?), and, most importantly, the permissions being requested. Teach them to apply the principle of least privilege: 'Why does this simple document viewer need permission to read all my email and send mail as me?'. Empower users to deny suspicious requests and provide them with a simple process to report them to the security team. This turns every user into a sensor for detecting consent phishing campaigns.
Timeline of Events
The FBI reports the OAuth consent phishing campaign has been active since at least late 2025.
The FBI's Internet Crime Complaint Center (IC3) issues a Public Service Announcement (PSA) about the campaign.
Sources & References(when first published)
Article Author
Jason Gomes
• Cybersecurity PractitionerCybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Editorial Standards & Analyst Review
CyberNetSec.io uses automation to assist source monitoring, deduplication, observable extraction, and structured intelligence generation. Published analysis follows human-defined editorial standards and adds defensive context including MITRE ATT&CK, D3FEND, STIX, and Sigma where applicable. Read our editorial policy.
Tags
📢 Share This Article
Help others stay informed about cybersecurity threats
🎯 MITRE ATT&CK Mapped
Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.
🧠 Enriched & Analyzed
Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.
🛡️ Actionable Guidance
Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.
🔗 STIX Visualizer
Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.
⚡ Sigma Generator
Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.