AN1349: Analytic 1349
Behavioral chain: (1) third-party app or admin connects via OAuth/marketplace install; (2) high-privilege scopes granted; (3) anomalous actions (mass read/exports, admin changes).
Analyst context for executives and security teams
This analytic matters because risky SaaS access can arrive through OAuth or marketplace app connections rather than a traditional login or malware event. For leaders, the key issue is whether the organization can see when a third-party app or administrator is granted high-privilege SaaS scopes and then begins behavior such as mass reads, exports, or administrative changes.
Executive priority
Prioritize this as a SaaS governance and incident-readiness question: who can approve high-privilege app access, how quickly can security review it, and what evidence exists if sensitive data is exported or admin settings are changed. It supports budget and control decisions around SaaS audit logging, OAuth/app consent governance, privileged access review, and SOC workflows for investigating suspicious third-party integrations.
Technical view
Validate whether SaaS telemetry can correlate the described behavioral chain: OAuth or marketplace install, high-privilege scope grant, and subsequent anomalous activity such as mass reads, exports, or admin changes. Because the ATT&CK object does not provide a specific detection implementation or tactics, SOC teams should treat this as a detection design pattern rather than a ready rule. Detection engineering should focus on joining app authorization events, scope/permission details, actor identity, admin actions, and data access/export activity over time.
Likely telemetry
- SaaS OAuth consent or marketplace application installation events
- Granted scopes, permissions, roles, or app privilege changes
- Administrator activity logs for SaaS configuration or policy changes
- SaaS data access logs showing bulk reads or unusual access volume
- Export, download, or sharing activity from SaaS platforms
Detection direction
- Confirm that logs include both the app connection event and the specific scopes or privileges granted; without scope detail, the highest-risk cases may look like routine app installs.
- Correlate high-privilege grants with later mass reads, exports, or administrative changes rather than alerting only on a single event type.
- Tune for business-approved integrations to reduce false positives, but require periodic revalidation of apps with elevated permissions.
- Review blind spots where SaaS audit logs are disabled, retained too briefly, or not forwarded to the SOC.
- Include administrator-driven installs as well as end-user OAuth consent where the SaaS platform supports both patterns.
Mitigation priorities
- Establish governance for approving third-party SaaS apps and high-privilege OAuth scopes.
- Limit who can grant marketplace or OAuth permissions with broad administrative or data access impact.
- Maintain an inventory of connected SaaS applications, owners, scopes, and review status.
- Ensure SaaS audit logging captures consent, scope grants, admin changes, reads, and exports with sufficient retention.
- Create incident response procedures for disabling or revoking suspicious app access and preserving related logs.
Analyst notes and limits
This object is a MITRE detection analytic for SaaS behavior involving OAuth or marketplace installation, high-privilege scopes, and anomalous follow-on activity. No relationship context, tactics, aliases, or official detection logic were supplied, so the take emphasizes validation questions and telemetry requirements rather than a specific rule.
The supplied ATT&CK fields do not identify specific SaaS products, tactics, adversaries, procedures, mitigations, or active exploitation. Local platform capabilities, licensing, audit log retention, and app consent policies will determine whether this analytic can be implemented effectively.
Analytic 1349
Behavioral chain: (1) third-party app or admin connects via OAuth/marketplace install; (2) high-privilege scopes granted; (3) anomalous actions (mass read/exports, admin changes).
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 | e2d1dfd71492… |
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 AN1349Open 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.