An OAuth application that an attacker adds or co-opts inside your SaaS tenant keeps working after you reset the password, revoke the sessions and even disable the user who approved it. MITRE ATT&CK tracks this as T1671 Cloud Application Integration, a Persistence technique on the Office Suite and SaaS platforms. This guide is about the persistence half of the problem: how app integrations hold access, what to log, how to hunt for integrations that should not be there, and how to evict them completely. It is written for SaaS administrators, identity engineers and incident responders. How users are tricked into the first grant is covered in the Consent Phishing and Illicit OAuth Grants Guide, and the broader persistence picture in the Persistence Techniques Guide.
Key takeaways
- The app is a new identity. Once consented, an integration authenticates as itself with its own tokens or credentials, so it is a non-human identity that survives action taken against the human account.
- Three routes to the same foothold. ATT&CK lists creating a custom application, adding a legitimate application, and co-opting an existing integration. Each needs a different hunt.
- Grants outlive the granter. ATT&CK notes integrations may remain valid after the consenting account is disabled, and that tokens issued to apps can sidestep MFA.
- Eviction is several steps, not one. Revoke delegated grants, remove application permissions, remove credentials, disable or delete the app, and stop re-consent. Missing any one leaves a path back.
- Prevention is consent policy plus inventory. ATT&CK's two mitigations are restricting who can add integrations (M1042) and periodic review (M1047). Both depend on knowing what is installed and who owns it.
How the technique works
ATT&CK v20 defines T1671 as achieving persistence by leveraging OAuth application integrations in a SaaS environment such as Microsoft 365 or Google Workspace. It has no sub-techniques. The technique description gives four reasons attackers use it: consent from a privileged account keeps data access even if the account is lost; integrations can stay valid after the consenting user is disabled; application access tokens (T1550.001) can bypass MFA; and integrations can run T1020 Automated Exfiltration over time. Adding a new app may also involve creating a T1136.003 Cloud Account and assigning T1098.003 Additional Cloud Roles; in Microsoft 365 an application reaches resources only through its service principal.
| Route | What the attacker does | What it looks like in logs | Nearest related technique |
|---|---|---|---|
| Create a custom app | Registers an app in the tenant, adds a secret or certificate, grants it permissions or roles | App registration, credential added, role or permission grant, often from one admin account in a short window | T1098.001 Additional Cloud Credentials |
| Add a legitimate or look-alike app | Persuades a user or admin to consent to an attacker-controlled multi-tenant app, or a modified copy of a known tool | New service principal, consent event, first-seen app ID, then API reads at volume | T1528 Steal Application Access Token |
| Co-opt an existing integration | Adds credentials or scopes to an app already trusted in the tenant | Credential or permission change on an established app, sign-ins by that app from new IP ranges | T1098.001, T1550.001 |
Two cases that show the pattern
- Connected apps approved over the phone: in the ShinyHunters Salesforce data theft campaign, callers posing as IT support persuaded employees at customer organisations to authorise a modified data loading tool in their own tenant. ATT&CK records this as campaign C0059 under T1671. The customer-side control point was who may approve connected apps.
- App identities used to run workloads: in the Storm-1283 OAuth apps abuse, a compromised account registered a new application, added secrets, granted it a subscription role and added credentials to existing line-of-business apps. Resetting the user's password would not have removed that access.
Prevention: control who can add and change integrations
ATT&CK maps two mitigations to T1671: M1042 Disable or Remove Feature or Program ("do not allow users to add new application integrations", with the Entra ID option "Do not allow user consent" given as an example) and M1047 Audit. The settings below apply them on three common platforms. Platforms are listed alphabetically; confirm current setting names in each vendor's documentation.
| Platform | Consent and install control | Review and restrict |
|---|---|---|
| Google Workspace | Security, Access and data control, API controls: set unconfigured third-party apps to "Allow only apps that request basic sign-in info" or "Block all third-party apps until they're configured" | Set each app to Trusted, Specific Google data, Limited or Blocked; mark Gmail, Drive and Chat high-risk scopes as Restricted, which revokes tokens for untrusted apps |
| Microsoft Entra ID | Enterprise apps, Consent and permissions, User consent settings: disable user consent, or allow it only for verified publishers and low-impact permissions (policy microsoft-user-default-low); turn on the admin consent workflow | Enterprise apps, Permissions: review Admin consent and User consent tabs; restrict who can register applications and manage credentials |
| Salesforce | Install the connected apps you trust and block untrusted ones (blocking ends active sessions and prevents new connections); grant "Approve Uninstalled Connected Apps" and "Use Any API Client" only to a few trusted users | In each app's OAuth policies set Permitted Users to "Admin approved users are pre-authorized" and choose which profiles and permission sets may use it |
Two cautions from Microsoft Learn apply to every platform in principle. Changing consent settings affects future consent only, so existing grants stay until you revoke them. And revoking permissions does not stop a user from consenting again, so pair eviction with a consent policy. Platform depth sits in the Google Workspace Security Guide, the Entra ID Security Guide and the Salesforce Security Guide.
Hardening priorities
- Admin consent for anything sensitive: mail, files, chat, directory write and offline access scopes should go through review, with a named business owner recorded at approval.
- Least privilege for app registration: limit the ability to register apps and add credentials to a small role, protected with phishing-resistant MFA. See the Azure RBAC and Service Principals Guide.
- Scope down what an app can reach: prefer specific-data or per-resource access over tenant-wide permissions. See the OAuth Scope Design Guide.
- Network restrictions where the platform offers them: our recommendation at NHI Mgmt Group is to apply any IP or network restrictions your platform documents for integrations, so app access from unexpected networks is denied or challenged.
Detection: the DET0539 analytics
ATT&CK v20 detection strategy DET0539 has two analytics. AN1487 (Office Suite) looks for new app registrations, unexpected consent grants or privilege assignments in Microsoft 365 or Google Workspace, and correlates them with the user or service principal activity that follows. AN1488 (SaaS) looks for unauthorised app additions, unusual permission grants and integrations that persist after the original user was disabled, across services such as Slack and Salesforce.
| Signal | Example event or source | Why it matters |
|---|---|---|
| Consent by a privileged or unexpected account | Entra audit "Consent to application"; unified audit "Add app role assignment grant to user" (both named in DET0539) | Admin consent gives tenant-wide reach |
| New credential on an existing app | Entra audit: certificate or secret added to an application or service principal | The co-opt route; rarely legitimate outside a change window |
| New application or service principal | Entra audit "Add application", "Add service principal"; SaaS integration install events | The create and add routes |
| Role granted to an app | Directory role or subscription role assignment to a service principal | App identity gains standing privilege |
| App activity after owner disabled | Service principal or connected app API calls after the consenting user is disabled | The persistence signal AN1488 names |
| Bulk reads by an app | Platform API or event monitoring logs showing large exports by one client | Exfiltration riding on the integration |
Hunting queries to run quarterly
- List every integration with its owner, publisher, scopes or roles, creation date and last use. Flag any with no owner.
- Find apps whose consenting user is now disabled or deleted and which still show recent activity.
- Find apps with a credential added in the last 90 days that were not part of a recorded change.
- Find multi-tenant apps from unverified publishers holding mail, file or directory scopes.
- Find app names that imitate your organisation or a well-known tool but have a different publisher or app ID.
For Salesforce specifically, the Salesforce Event Monitoring Detection Guide covers the event types that show connected app use and bulk API exports.
Eviction: removing integration-based persistence
Responders often revoke the user's sessions and stop. For T1671 that leaves the app in place. Work through every layer, after preserving the audit records that show when the app arrived and what it touched.
- Scope: list every app the compromised accounts created, consented to, or changed credentials or permissions on during the incident window.
- Contain without destroying evidence: in Entra ID, disable sign-in for the enterprise app first; in Google Workspace set the app to Blocked; in Salesforce, block the connected app as described in Salesforce Help. This stops use while keeping the object for investigation.
- Revoke delegated grants: Microsoft Learn notes permissions on the User consent tab cannot be revoked in the portal and are removed with Microsoft Graph or PowerShell (with Graph, delete the oAuth2PermissionGrant objects for the service principal).
- Remove application permissions and role assignments: delete the app role assignments and any directory or subscription roles given to the service principal.
- Remove credentials: delete secrets and certificates added during the window, on both new and co-opted apps. For a co-opted line-of-business app, rotate every credential, not just the new one.
- Delete or restore: delete attacker-created apps once evidence is captured; return co-opted apps to their documented permission set.
- Stop re-consent: tighten the consent policy so the same app cannot be approved again, and block its app ID where the platform allows.
- Review what it took: use the app's activity logs to scope data access for notification decisions. The OAuth Token Theft Incident Playbook covers notification and recovery.
Decision guidance
- Block user consent or allow verified publishers only? Blocking all user consent is simplest for regulated or high-risk tenants and works well with a responsive admin consent workflow. Allowing low-impact permissions from verified publishers reduces help desk load in large, app-heavy organisations, but needs permission classification kept current.
- Small organisations: block third-party consent by default and approve a short allowlist. A quarterly manual review of fewer than a hundred apps is realistic.
- Large organisations: automate the inventory, enforce owner and expiry on every integration and alert in real time on credential and permission changes. A SaaS security posture tool can help aggregate across platforms; see the SaaS and OAuth App Governance Guide.
Where identity fits
Every integration is a non-human identity with credentials, permissions and an owner, or it should be. T1671 succeeds where those identities are created more easily than they are reviewed. Bring service principals, connected apps and marketplace apps into the same lifecycle as other machine identities: registration, owner, least privilege, credential rotation and decommissioning. The guide How to find and remove stale service principals in Entra ID covers the cleanup side, and domain-wide delegation in Google Workspace is covered in the Google Workspace Domain-Wide Delegation Security Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1671 (TA0003 Persistence); related T1550.001, T1098.001, T1098.003, T1136.003, T1020, T1528 | Technique and the techniques it chains with |
| ATT&CK mitigations | M1042 Disable or Remove Feature or Program; M1047 Audit | Consent restriction and periodic review |
| NIST SP 800-53 Rev. 5 | AC-2 Account Management; AC-6 Least Privilege; CM-8 System Component Inventory; AU-6 Audit Record Review, Analysis, and Reporting | Integration lifecycle, scoped permissions, inventory and review |
| NIST SP 800-53 Rev. 5 | SA-9 External System Services | Third-party apps as external services with defined controls |
| NIST CSF 2.0 | PR.AA-05 (access permissions managed, least privilege); DE.CM-01 (networks and services monitored) | Consent policy and integration monitoring |
Measuring progress
- Percentage of integrations with a named owner and documented business purpose.
- Number of integrations holding high-risk scopes or tenant-wide roles, trending down.
- Median time from an app credential or permission change to analyst review.
- Number of apps whose consenting user is disabled but which remain active.
- Admin consent workflow requests approved, denied and their median decision time.
Common failure patterns
- Treating it as a user incident only: resetting the password and revoking sessions while the app keeps its own tokens.
- Revoking but not blocking: removing the grant without changing consent policy, so the app is approved again the next day.
- Missing the co-opted app: hunting only for new apps while a trusted integration quietly gains a new secret.
- Ownerless integrations: apps approved years ago by staff who have left, with nobody able to say whether current activity is normal.
- Help desk pretexting: staff approve an app or enter a connection code because a caller claims to be IT, as in the campaign above.
Practitioner checklist
- Export every OAuth integration across your main SaaS platforms with owner, scopes, roles and last use.
- Restrict user consent and turn on an admin consent or approval workflow.
- Limit who can register apps, add credentials and manage connected apps.
- Alert on consent by privileged accounts, credentials added to apps and roles granted to apps.
- Hunt quarterly for apps active after their consenting user was disabled.
- Write the eviction sequence into your incident runbooks, platform by platform.
- Rehearse removing a test integration end to end and time it.
- Train help desk and users that no legitimate support call asks them to approve an app or enter a code.
Standards and references
- MITRE ATT&CK: Cloud Application Integration (T1671)
- MITRE ATT&CK: Use Alternate Authentication Material: Application Access Token (T1550.001)
- Microsoft Learn: Configure how users consent to applications
- Microsoft Learn: Review and revoke permissions granted to enterprise applications
- Google Workspace Admin Help: Control which third-party and internal apps access Google Workspace data
- Salesforce Admins: Get ready for changes to connected app usage restrictions
Related NHI Mgmt Group resources: Persistence Techniques Guide · Consent Phishing and Illicit OAuth Grants Guide · SaaS and OAuth App Governance Guide · SaaS Security Maturity Model · OAuth Token Theft Incident Playbook