T1671: Cloud Application Integration
Adversaries may achieve persistence by leveraging OAuth application integrations in a software-as-a-service environment. Adversaries may create a custom application, add a legitimate application into the environment, or even co-opt an existing integration to achieve malicious ends.[1][2]
OAuth is an open standard that allows users to authorize applications to access their information on their behalf. In a SaaS environment such as Microsoft 365 or Google Workspace, users may integrate applications to improve their workflow and achieve tasks.
Leveraging application integrations may allow adversaries to persist in an environment – for example, by granting consent to an application from a high-privileged adversary-controlled account in order to maintain access to its data, even in the event of losing access to the account.[3][4][5] In some cases, integrations may remain valid even after the original consenting user account is disabled.[6] Application integrations may also allow adversaries to bypass multi-factor authentication requirements through the use of Application Access Tokens. Finally, they may enable persistent Automated Exfiltration over time.[7]
Creating or adding a new application may require the adversary to create a dedicated Cloud Account for the application and assign it Additional Cloud Roles – for example, in Microsoft 365 environments, an application can only access resources via an associated service principal.[8]
Analyst context for executives and security teams
Cloud Application Integration is a persistence technique where an adversary abuses OAuth-based SaaS app integrations to keep access to cloud data or services even if the original user session or account access is lost. For leaders, the key issue is that SaaS compromise may not end when passwords are reset or MFA is enforced: a malicious or co-opted integration can retain delegated access through application tokens, service principals, or consent grants.
Executive priority
Prioritize this where Office Suite and SaaS platforms hold regulated, business-critical, or customer data. The business decision is whether the organization can prove which third-party and custom applications have access, who consented to them, what privileges they hold, and how quickly risky integrations can be revoked during an incident. This matters for incident containment, audit evidence, cloud governance, and reducing persistent access paths that can outlive normal account remediation.
Technical view
ATT&CK lists this as a persistence technique for Office Suite and SaaS environments. SOC, IR, and cloud identity teams should validate visibility into OAuth consent events, application registrations, service principals, application access tokens, role assignments, and changes to existing integrations. Because no official ATT&CK detection text is provided for T1671, detection engineering should be based on local SaaS and identity-provider audit capabilities and the related ATT&CK detection strategy DET0539. Relationship context also points to related behaviors such as Application Access Token, Cloud Account creation, Additional Cloud Roles, and possible Automated Exfiltration over time.
Likely telemetry
- SaaS audit logs for application consent, integration installation, and permission changes
- Identity-provider logs for OAuth grants, application registrations, and service principal creation or modification
- Administrative audit logs for cloud role assignments to applications or service principals
- Token and app activity records where available, especially application access token usage
- User and administrator activity around adding legitimate third-party apps or custom applications
Detection direction
- Inventory OAuth applications and compare granted permissions against business owners and expected use cases.
- Alert or review high-privilege consent grants, new service principals, new custom applications, and role additions tied to SaaS resources.
- Tune detections to distinguish expected enterprise integrations from newly added, rarely used, or lookalike integrations; false positives are likely without an approved-app baseline.
- During account-compromise investigations, include delegated application access and service principals in scoping, not only user sessions, passwords, and MFA state.
- Use DET0539 as the ATT&CK-linked detection strategy reference, but validate actual coverage against each SaaS platform’s available audit events because the technique object does not provide official detection logic.
Mitigation priorities
- Apply M1047 Audit first: maintain reviewable records of SaaS integrations, consent grants, service principals, permissions, and role assignments.
- Apply M1042 Disable or Remove Feature or Program by removing unnecessary, unused, or unapproved SaaS integrations and disabling features that permit unmanaged application consent where appropriate.
- Establish an approval and ownership process for third-party and custom OAuth applications, especially those requesting broad or high-privilege access.
- During incident response, revoke suspicious application grants, remove malicious or unnecessary service principals, and verify whether integrations remain valid after disabling affected users.
- Regularly review high-privilege application access as part of cloud security, IAM governance, compliance readiness, and SaaS attack-surface management.
Analyst notes and limits
The material risk is persistence through delegated SaaS access. Password resets, MFA enforcement, and user disablement may be insufficient if an OAuth integration or service principal retains access. The supplied ATT&CK relationships include mitigations for auditing and disabling/removing unnecessary features, plus a campaign relationship to Salesforce Data Exfiltration, which supports treating SaaS application integration governance as both an identity and data-protection control area.
MITRE provides no official detection text for this object, and the supplied relationship to DET0539 does not include detection details. Platform coverage is limited to Office Suite and SaaS. Local SaaS provider logs, identity-provider capabilities, licensing, retention, and integration inventory quality will determine practical detection and response effectiveness.
Cloud Application Integration
Adversaries may achieve persistence by leveraging OAuth application integrations in a software-as-a-service environment. Adversaries may create a custom application, add a legitimate application into the environment, or even co-opt an existing integration to achieve malicious ends.[1][2]
OAuth is an open standard that allows users to authorize applications to access their information on their behalf. In a SaaS environment such as Microsoft 365 or Google Workspace, users may integrate applications to improve their workflow and achieve tasks.
Leveraging application integrations may allow adversaries to persist in an environment – for example, by granting consent to an application from a high-privileged adversary-controlled account in order to maintain access to its data, even in the event of losing access to the account.[3][4][5] In some cases, integrations may remain valid even after the original consenting user account is disabled.[6] Application integrations may also allow adversaries to bypass multi-factor authentication requirements through the use of Application Access Tokens. Finally, they may enable persistent Automated Exfiltration over time.[7]
Creating or adding a new application may require the adversary to create a dedicated Cloud Account for the application and assign it Additional Cloud Roles – for example, in Microsoft 365 environments, an application can only access resources via an associated service principal.[8]
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.
Groups, software, and campaigns
C0059: Salesforce Data Exfiltration
The Salesforce Data Exfiltration campaign began in October 2024 with financially-motivated threat actor UNC6040 using Spearphishing Voice (vishing) to compromise corporate Salesforce instances for large-scale data theft and extortion. Following the initial data theft, victim organizations received extortion demands from a separate threat actor, UNC6240, who claimed to be the “ShinyHunters” group. The observed infrastructure and TTPs used during the Salesforce Data Exfiltration campaign overlap with those used by threat groups with suspected ties to the broader collective known as "The Com.” These overlaps could plausibly be the result of associated actors operating within the same communities and are not necessarily an indication of a direct operational relationship.[1][2]
All related ATT&CK context
Mitigation direction
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 | 95db254ac058… |
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]
Push Security SaaS Persistence 2022
Luke Jennings. (2022, November 29). Maintaining persistent access in a SaaS-first world. Retrieved March 20, 2025.
Open source URL -
[2]
SaaS Attacks GitHub Evil Twin Integrations
Push Security. (n.d.). Evil twin integrations. Retrieved March 20, 2025.
Open source URL -
[3]
Wiz Midnight Blizzard 2024
Lior Sonntag. (2024, February 8). Midnight Blizzard attack on Microsoft corporate environment: a detailed analysis, detections and recommendations. Retrieved March 20, 2025.
Open source URL -
[4]
Microsoft Malicious OAuth Applications 2022
Microsoft Threat Intelligence. (2022, September 22). Malicious OAuth applications abuse cloud email services to spread spam. Retrieved March 20, 2025.
Open source URL -
[5]
Huntress Persistence Microsoft 365 Compromise 2024
Sharon Martin. (2024, November 5). Legitimate Apps as Traitorware for Persistent Microsoft 365 Compromise. Retrieved March 20, 2025.
Open source URL -
[6]
Push Security Slack Persistence 2023
Luke Jennings. (2023, October 24). Slack Attack: A phisher's guide to persistence and lateral movement. Retrieved March 20, 2025.
Open source URL -
[7]
Synes Cyber Corner Malicious Azure Application 2023
syne0. (2023, July 10). Malicious Azure Application PERFECTDATA SOFTWARE and Microsoft 365 Business Email Compromise. Retrieved March 20, 2025.
Open source URL -
[8]
Microsoft Entra ID Service Principals
Microsoft. (2023, December 15). Application and service principal objects in Microsoft Entra ID. Retrieved February 28, 2024.
Open source URL -
[9]
mitre-attack T1671Open 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.