Cloud Application Integration (T1671) is a persistence technique in which adversaries use OAuth application integrations in a software-as-a-service (SaaS) environment. MITRE lists Office Suite and SaaS as platforms.
OAuth lets users authorize an application to access their data on their behalf. In SaaS platforms such as Microsoft 365 or Google Workspace, people connect apps all the time to get work done. That convenience is the opening.
How attackers use it
MITRE says an adversary may create a custom application, add a legitimate application to the environment, or co-opt an existing integration. The point is to keep access to the data even after the adversary loses the account they started with.
Several properties make this attractive:
- Consent granted to an application from a high-privileged adversary-controlled account can maintain access to its data even if the account is later lost.
- In some cases an integration stays valid after the user who consented has been disabled.
- Integrations may bypass multi-factor authentication requirements through Application Access Tokens (T1550.001).
- They can support persistent Automated Exfiltration (T1020) over time.
Creating or adding an app may require a dedicated Cloud Account (T1136.003) and Additional Cloud Roles (T1098.003). In Microsoft 365, for example, an application can access resources only through an associated service principal.
MITRE's example is a data theft campaign in which victims were deceived into authorizing malicious connected apps to their organization's Salesforce portal.
How to detect it
MITRE's detection strategy has two parts.
- Office 365 and Google Workspace. Look for new app registrations, unexpected consent grants and privilege assignments. Correlate application creation or modification with the activity of the related user or service principal.
- Other SaaS such as Slack or Salesforce. Look for unauthorized app additions, unusual permission grants, and persistence through service principal tokens.
A useful rule of thumb: a new consent to a broad scope, especially by an admin or from an unfamiliar location, deserves a human look the same day.
How to reduce the risk
- Disable or Remove Feature or Program. Do not let users add new application integrations on their own. In Entra ID, consider enforcing the option "Do not allow user consent," so that new apps go through an approval path.
- Audit. Periodically review SaaS integrations for unapproved or potentially malicious applications.
Two supporting habits help. Make sure that disabling a compromised account also triggers a review of apps it consented to, because those can outlive the user. And train people to treat an unexpected "Allow access" prompt as a security decision.
Check your own environment
- Export the list of connected or enterprise applications in your main SaaS platforms and mark each one with an owner and a reason.
- Remove anything without an owner.
- Check your consent settings: who can approve a new integration?
- Review the permissions granted to each app, and flag any that can read all mail or all files.
- After an account compromise, include its app consents in the cleanup checklist.
Third-party apps are also a vendor risk question. The demo below walks through how to review one.
Click through it at your own pace, or open it full screen.
Quick check
Why can an OAuth integration outlast a disabled account?
MITRE notes that in some cases an integration remains valid after the user who consented is disabled. The app holds its own grant, so removing the user does not remove the app.
Which Entra ID setting does MITRE mention?
Enforcing the "Do not allow user consent" option, so users cannot approve new application integrations on their own.
Sources
- MITRE ATT&CK, Cloud Application Integration (T1671): https://attack.mitre.org/techniques/T1671
