AN0301: Analytic 0301
Detection of OAuth consent phishing or malicious login attempts initiated through spearphishing links. Behavior chain includes inbound email with OAuth URL → consent page visited → unusual token grants logged in IdP logs.
Analyst context for executives and security teams
This analytic matters because OAuth consent phishing can turn a successful email click into persistent identity access without requiring a stolen password. The supplied ATT&CK description focuses on a chain: inbound email containing an OAuth URL, a user visiting a consent page, and unusual token grants appearing in identity provider logs. For leaders, the key issue is whether the organization can connect email, web/identity activity, and token-grant evidence quickly enough to contain identity abuse before it affects business applications.
Executive priority
Prioritize this as an identity and cloud-access readiness question: do security teams have visibility into OAuth consent activity, token grants, and suspicious email-driven login flows in the identity provider? This supports incident decision-making, audit evidence for identity controls, and budget prioritization for managed detection, identity monitoring, and phishing response. The business risk is not just credential theft; it is unauthorized delegated access that may persist through granted tokens or app consent if not reviewed and revoked.
Technical view
SOC and IR teams should validate whether Identity Provider telemetry can show unusual OAuth consent events, token grants, and login attempts associated with spearphishing links. Because the official object has no separate detection logic and no relationship context, teams should build the analytic around correlation of the described behavior chain rather than a single event: inbound email with an OAuth URL, subsequent consent-page visit, and abnormal token grant activity in IdP logs. Review baselines for normal application consent, expected publishers/apps, user populations, geographies, and timing so detections can distinguish suspicious consent from legitimate onboarding or SaaS usage.
Likely telemetry
- Identity provider audit logs for OAuth consent events and token grants
- Identity provider sign-in or authentication logs for malicious or unusual login attempts
- Email security logs or message metadata showing inbound email containing OAuth URLs
- URL click or web proxy/browser telemetry showing consent page visits
- Application consent records, service principal/app registration data, and granted permission scopes where available
Detection direction
- Validate that IdP logs capture consent grants, token grants, application identifiers, permission scopes, user identity, timestamp, source IP, and related sign-in context.
- Correlate email receipt and URL click events with subsequent IdP consent or token-grant events for the same user or session window.
- Tune for unusual grants, unfamiliar applications, unexpected permission scopes, first-seen apps, abnormal user populations, or activity following suspicious inbound email.
- Account for false positives from legitimate SaaS onboarding, approved enterprise applications, helpdesk-driven access setup, or normal user consent where permitted.
- Identify blind spots where email telemetry, URL-click telemetry, or IdP token-grant logs are not centrally retained or cannot be correlated by user and time.
Mitigation priorities
- Confirm governance over OAuth application consent, including review of who can grant consent and how high-risk permissions are approved.
- Ensure identity provider logging is enabled and retained for consent events, token grants, and sign-in activity.
- Establish response procedures to revoke suspicious grants, disable or remove malicious app consent, invalidate sessions/tokens where appropriate, and review affected user activity.
- Integrate email, identity provider, and web/click telemetry into SOC workflows or managed detection use cases.
- Maintain an approved-application baseline and periodically review unusual or stale delegated permissions.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for the Identity Provider platform. Its description is specific enough to guide defensive validation around OAuth consent phishing and malicious login attempts initiated through spearphishing links, but it does not provide formal detection pseudocode, tactics, linked techniques, or relationship context.
Official detection content was not provided, tactics were not specified, and no relationships were supplied. This take therefore avoids claims about active exploitation, attribution, impact, or guaranteed coverage. Local identity provider configuration, logging retention, application-consent policy, and email/web telemetry determine whether this analytic is actionable.
Analytic 0301
Detection of OAuth consent phishing or malicious login attempts initiated through spearphishing links. Behavior chain includes inbound email with OAuth URL → consent page visited → unusual token grants logged in IdP logs.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 1a68ce80269c… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0301Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.