OAuth consent phishing targets high-profile individuals via CMAs

Vorant's rating weighs the evidence in the report: confirmed exploitation, victims claimed, CVSS and EPSS, and how many sources agree. It rates the report, not your assets.

Since late 2025, cyber actors have been conducting OAuth consent phishing attacks against prominent victims and their contacts through commercial messaging applications, bypassing passwords and MFA by tricking users into granting persistent account access to malicious apps.

Sourceic3.gov — open the original

The FBI has observed a sustained campaign since late 2025 in which malicious actors target high-profile individuals, their family members, and personal associates via commercial messaging applications (CMAs). Attackers impersonate government officials, media personalities, event coordinators, and other trusted figures to trick victims into clicking malicious links. OAuth consent phishing exploits a fundamental weakness in OAuth authorization flows: once a user grants permission to a malicious application masquerading as a legitimate service, the attacker gains persistent, high-level access to the victim's account—including the ability to read and send emails, access sensitive data, and act on the victim's behalf.

The technique is particularly dangerous because it bypasses both passwords and multi-factor authentication entirely. Unlike credential harvesting or malware deployment, OAuth consent phishing does not require the attacker to possess the user's credentials; the victim themselves delegate access by approving a fake authorization prompt. The persistence of this access is a critical differentiator: the attacker retains privileges until the victim manually revokes the malicious application's token in their security settings—a step many users may not know to take or may not discover until long after the compromise.

Defenders should focus on detection of anomalous third-party application grants, user education on authorization flows, and monitoring for unauthorized account activity that may indicate a compromised OAuth token. Organizations should also implement policies requiring users to review and audit connected third-party applications regularly.

title: Suspicious OAuth Token Grant via Browser
description: Detects browser processes navigating to OAuth authorization endpoints
  (accounts.google.com/o/oauth2/auth, login.microsoftonline.com/oauth2/v2.0/authorize,
  etc.) with suspicious redirect_uri parameters pointing to attacker infrastructure
  or data exfiltration domains. Targets the consent-phishing vector where victims
  grant token access to malicious apps.
tags:
- attack.initial-access
- attack.t1528
- attack.t1566.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_browser:
    Image|endswith:
    - \chrome.exe
    - \firefox.exe
    - \iexplore.exe
    - \msedge.exe
  selection_oauth_url:
    CommandLine|contains:
    - accounts.google.com/o/oauth2/auth
    - login.microsoftonline.com/oauth2/v2.0/authorize
    - accounts.google.com/signin/oauth
  selection_suspicious_param:
    CommandLine|contains:
    - redirect_uri=http://
    - redirect_uri=file://
    - response_type=token
  filter_legitimate_apps:
    CommandLine|contains:
    - redirect_uri=https://localhost
    - redirect_uri=https://127.0.0.1
  condition: (selection_browser and selection_oauth_url and selection_suspicious_param)
    and not filter_legitimate_apps
falsepositives:
- Legitimate OAuth integrations with http redirects in dev/test environments
- Enterprise applications performing authorized OAuth flows during setup
level: high
id: befd5bfa-9ac5-5212-8da6-b7552527508c
status: experimental
author: Vorant

Source reporting: https://www.ic3.gov/PSA/2026/PSA260901

Free public brief. The detections with Splunk SPL already written (plus Elastic and KQL where they apply) are in the app with a free account, no card. Slack alerts on the vendors you run come with the paid plans, and a new account gets three days of them.