How T1671 cloud application integration keeps an attacker in SaaS
T1671 Cloud Application Integration sits under the Persistence tactic (TA0003), where ATT&CK describes the adversary as trying to maintain their foothold. In practice, the technique lets an attacker keep a working path into a SaaS or Office tenant by attaching a malicious or abused integration to the tenant, so access continues without relying on the user's password or session. For a SOC lead, the key point is that the foothold lives in the tenant's integration layer, which many teams do not review as an access path at all. Across Office and SaaS estates, third-party apps, add-ins, connectors and service principals are often granted broad delegated permissions and then forgotten by the business owners who approved them.
This is why the technique survives password resets and many MFA changes. An integration authenticates with its own grant or credential, so resetting the user who consented to it may leave the grant intact, and a session revocation does not necessarily remove it. Incident responders therefore need to treat integration inventory as part of identity response, not only as an application management task. Confirm with your identity and SaaS administrators which tenant features expose app consent, service principal creation and connector registration, who can approve them, and whether those events are written to logs your SOC can query. Also confirm how long app grants and credentials remain valid after a user is disabled, because the answer changes your containment steps.
Planning starts with three decisions. First, decide which integrations are sanctioned, who owns each one and what permissions it actually needs, so that unexpected grants stand out. Second, decide which change events on integrations (new consent, new credential, permission expansion, new owner) generate alerts and who triages them. Third, decide how quickly an unapproved integration can be disabled or removed during an incident, and who has the authority to do it. Ask your SaaS vendor or implementation partner to show the audit records for these events in your own tenant before you rely on them, because the names and fields differ across platforms and this page does not assume a specific one.
Which telemetry reveals cloud application integration changes
This table maps the three data sources named for T1671 to the signal defenders should watch, the open-source collector that gathers it, and the coverage question to settle with each SaaS tenant. The mappings target ATT&CK v20.0, so confirm data component IDs against the version your rules cite. Coverage depends on which SaaS audit logs the client actually exports, so treat missing exports as a gap to close before relying on any detection.
| Data source | Signal to look for | Open-source collector | Coverage question to confirm |
|---|---|---|---|
| Application Log Content (DC0038) | New or changed OAuth consent grants, app registrations and service principal credential additions in the Office suite audit log | Wazuh with a custom log decoder for the tenant audit feed | Does the client export unified audit or sign-in logs for every Office and SaaS tenant in scope? |
| Active Directory Object Modification | Changes to directory objects that host application identities, such as service principals, app role assignments and group membership tied to integrations | Wazuh Windows event collection on domain controllers and directory sync servers | Are directory change auditing and object access auditing enabled on the domain controllers that replicate to the cloud identity provider? |
| Cloud Service Modification | New integrations, webhooks, connectors or marketplace apps added to a SaaS tenant, especially outside change windows | Zeek or Security Onion for outbound API traffic to new SaaS endpoints, combined with tenant audit logs | Does the SaaS vendor expose configuration change events through an API or export, and at what retention? |
| Network connection telemetry (supporting) | First-seen egress to SaaS API domains from a service account or host that has not called them before | Zeek connection logs in Security Onion | Is TLS metadata retained long enough to baseline normal integration traffic per host? |
| Authentication events (supporting) | Token issuance for an integration identity from an unfamiliar address or at an unusual time | Wazuh ingestion of identity provider sign-in logs | Are service principal and workload sign-ins logged, or only interactive user sign-ins? |
Detection logic for suspicious SaaS integration activity
T1671 Cloud application integration abuses the trust a SaaS tenant places in third-party apps, so detection focuses on how integrations are created, what they are allowed to do, and when they change. The cards below pair each detection idea with its logic, the thresholds to tune, and the benign activity that will trigger it. Treat every rule as a starting point to validate against your own tenant's change calendar and vendor list.
New or newly consented integrations
Alert when a previously unseen application receives consent for the first time, especially when the consent is granted by a user rather than an administrator. The logic is a join between the application registration or consent event and a baseline of approved application identifiers kept by your identity team. Tune the lookback window to your onboarding cadence and start by alerting only on applications that request mailbox, file or directory scopes. Expect false positives from sanctioned onboarding, pilot teams trialing tools, and vendor apps that re-consent after a version change. Ask each application owner for a named business justification before closing the alert.
Elevated or broad permission grants
Flag consent events where an integration requests high-privilege scopes such as full mailbox access, directory-wide read or write, or application-level permissions that act without a signed-in user. The logic compares requested scopes against a short list of sensitive permissions that your tenant policy defines. Set the threshold at the scope level rather than the count of permissions, so one sensitive grant still produces an alert. Common false positives include backup, archiving and endpoint management products that legitimately need broad access, so review them against their documented permission requirements before tuning them out.
Integrations created outside change windows
Correlate integration creation, secret or certificate addition, and redirect URI changes with your approved change calendar and the identity of the actor. The signal is an event that falls outside a window or is performed by an identity that does not normally administer applications, such as a service account or a recently created guest user. Set the lookback to match your change process and review any service principal that gains credentials without a matching ticket. Expect noise from scheduled vendor maintenance and automation pipelines, so maintain an allowlist of those service identities with named owners.
Unusual identities creating integrations
Alert when an identity that has never performed application administration creates an application, adds a credential, or assigns an app role. The logic builds a per-identity baseline of administrative actions over a stable period and flags first-time occurrences of high-impact operations. Pay attention to privileged roles granted recently, since an account that gains an administrator role and immediately registers an app is a stronger signal than either event alone. False positives come from new platform administrators during onboarding and from helpdesk staff performing one-off fixes, so confirm the role assignment history first.
Directory object changes tied to integrations
Watch for changes to service principals, app role assignments and ownership of applications that occur close in time to an integration event. The logic correlates directory audit records for these object types within a short window around a consent or registration, and it raises priority when the same actor touches several objects. Tune the window in minutes or hours based on how your administrators work, and exclude known synchronization accounts. Vendor upgrades and identity sync tools produce the most common false positives, so record their expected change patterns before the detection goes live.
How to validate that the T1671 detections fire
This sequence proves, in a sanctioned non-production tenant, that the T1671 Cloud Application Integration detections fire on the expected telemetry, within a known time, with the fields analysts need. It ends with a documented baseline that is re-run after every rule change and tied to the ATT&CK version the rules target.
Agree scope and rules of engagement
The security lead and the owner of the Office suite or SaaS tenant agree in writing which tenant, which application integrations and which accounts the exercise may touch, who can approve a rollback, and who receives the alerts during the run. The platform owner confirms that the test is sanctioned and that no production mailboxes, shared drives or customer data are in reach. The output is a signed scope note that names the ATT&CK technique, the target version of the mapping (ATT&CK v20.0) and the detection identifiers under test.
Prepare a sanctioned test integration
The team creates or designates a test application registration or integration in a non-production tenant, using a dedicated test identity with the minimum permissions the scenario needs. The integration is labeled so that every event it generates can be traced back to the exercise. Nothing is granted to production groups. The output is a test record listing the integration name, identity, permissions and owner, so that the analysts can separate exercise activity from routine activity.
Confirm log ingestion and field mapping
Before any scenario runs, the detection engineer checks that the audit and sign-in logs for the tenant reach the SIEM, such as Wazuh or Security Onion, with the events expected for application consent, service principal creation and permission changes. The engineer compares the parsed fields against the fields named in the Sigma rules and records any field that is missing, renamed or delayed. The output is an ingestion checklist with a pass or fail result for each log source.
Run the scenario from the emulation plan
The red or purple team runs the agreed scenario against the test integration, following a written plan that describes each behavior in words and the time window it occurs in. The plan is executed without deviating from scope, and the exercise lead logs the start and end time of each stage. The output is a timestamped run log that the detection engineer can match against the alerts that follow.
Record time to alert and fields present
For each stage, the detection engineer records when the underlying event was written, when it reached the SIEM, and when the rule raised an alert, so that the delay at each point is visible. The engineer also notes which fields were populated in the alert, such as the actor, the integration name, the permissions granted and the source address. The output is a results table with time to alert and field completeness per detection, which becomes the baseline for later comparison.
Document gaps and assign tuning actions
The team compares the results with the expected detection outcome and sorts each gap into one of three groups: no event recorded, event recorded but not parsed, or alert raised but missing key fields or firing too late. Each gap receives an owner and a tuning action, and the response runbook is checked to confirm that the on-call analyst can act on the alert. The output is a gap register linked to the scope note, reviewed by the security lead before any rule is changed.
Re-run after tuning and map to ATT&CK v20.0
After rule changes, the same scenario is run again on the same test integration, and the results are compared with the baseline to confirm that each gap is closed without a rise in false positives on routine integration activity. The detection engineer confirms that each rule still references the T1671 technique and the ATT&CK v20.0 mapping, and notes any change that ATT&CK releases may require, since releases can rename or deprecate techniques. The output is a versioned validation record that auditors and the platform owner can review.
Preventive controls that limit integration persistence
Most integration persistence is hard to remove once it exists, so the cheapest wins come before an attacker registers anything. The cards below cover the two ATT&CK mitigations mapped to this technique, Audit and Disable or Remove Feature or Program, along with the related account controls that decide who can grant integrations in the first place.
Audit who can grant integrations
Every integration grant should be logged and reviewed. Treat the ability to consent to an application, or to create a service principal or add a credential to one, as a privileged action. Confirm in your SaaS tenant which audit logs record consent grants, app role assignments and new credentials, how long they are retained, and whether they reach your central log platform, such as Wazuh, where Application Log Content can be correlated with identity events. Mapping to ATT&CK mitigation Audit (M1047) supports this review.
Disable unused integrations
Integrations that nobody uses are persistence waiting to be found. Inventory the third-party applications, extensions and connectors registered in your Office Suite and SaaS tenants, then disable or remove those without a current owner or business purpose. This applies the ATT&CK mitigation Disable or Remove Feature or Program (M1042) to integration surfaces. Confirm with each vendor whether disabling an app revokes its tokens or only blocks new sign-ins, because that difference determines whether a cleanup actually closes the access path.
Restrict admin consent
Require administrator review before any application receives tenant-wide permissions. Most SaaS platforms let you separate user consent from administrator consent, and some let you limit which permission scopes users can approve on their own. Confirm the exact admin consent workflow, default user consent settings and any app governance features your provider offers, since names and defaults differ between vendors and change over time. Document who approves requests and how approvals are recorded.
Limit privileged administrator roles
Fewer administrators means fewer ways to add a trusted integration. Privileged Account Management (M1026) is a related control because the accounts that can register applications or grant tenant-wide consent are often the same ones that can change identity settings. Keep these roles to named individuals, use separate accounts for administrative tasks, and review role assignments on a fixed schedule. Confirm with your identity provider which roles can create or modify application registrations.
Govern standard user accounts
Ordinary user accounts should not be able to introduce new integrations. User Account Management (M1018) covers the lifecycle of accounts that can consent to or install third-party software. Remove access for leavers promptly, review dormant accounts that still hold delegated permissions, and check whether integrations created by departed users remain active under a shared or orphaned owner. Ask your SaaS provider how ownership of an integration is reassigned when its creator leaves the organization.
Triaging and responding when an integration alert fires
The first decision on an integration alert is whether the application is legitimate and whether its consent still reflects an approved business need. Start by confirming the integration itself: its display name, publisher, application identifier, creation date and the identity that granted consent. Then compare the requested permissions against the owner's documented purpose. Delegated scopes that read mail, files or directory data, and application permissions with tenant-wide reach, deserve the closest review. Record the approving identity and whether that approval went through your normal consent workflow or was granted directly by a user. An integration that was approved, owned and scoped as documented can usually be closed with a note. One that cannot be tied to an owner or an approval should be treated as suspect until proven otherwise.
Next, establish what the integration has done since it was added. Pull the sign-in records for the service principal and for the users who consented, and review the Application Log Content for data access, mailbox or file reads, and any new credentials, certificates or redirect addresses added to the application. Check whether the same consenting identity has recent risky sign-ins or changed authentication methods. Keep the scope of this review tight and time-bounded so that the investigation does not drift into unrelated accounts. If the evidence points to unauthorized access, decide between suspending the service principal, revoking user consent, or removing the integration. Suspension is the reversible choice while you investigate, and removal should follow only after the owner confirms the application is not needed. Preserve the audit records, configuration snapshots and consent history before making changes, and export them to write-once storage that your incident team controls.
Finally, communicate with the application owner and the affected business unit in writing. Ask the owner to confirm the integration's purpose, the people who depend on it and the data it should touch, and log their answers with timestamps. Agree in advance who may approve a suspension, who informs the users affected by a revoked consent, and how the decision is recorded in your case management system. After closure, feed the outcome back into the consent policy: tighten the approval path for the permission types involved, and record which integrations were reviewed so the next alert starts from a known baseline. Confirm with your identity provider's current documentation how consent revocation and service principal suspension behave in your tenant, because the exact steps and their effect on running tokens vary by platform and should be verified before you rehearse them.
Rehearsing T1671 detection and response in a private cyber range
A cyber range exercise for T1671 only produces useful evidence if the sandbox behaves like the production Office and SaaS estate closely enough that log sources, identity objects and integration events appear in the same shape. The range should use a private tenant or a sandbox subscription that the organization controls, with audit and sign-in logs exported to the same pipeline that feeds production detections. Keep the range isolated from production identities, and use synthetic users and integration accounts that match the naming and role patterns of the real estate.
- Log export parity: Confirm that the sandbox exports the same audit log categories that the production detections depend on, and that the export path into the SIEM is identical.
- Identity structure: Create test administrators, service principals and an application owner group so that directory changes have realistic actors and targets.
- Clock and time zone: Synchronize the range with the production time source so that off-hours events line up with the detection logic.
- Isolation controls: Restrict outbound connectivity and keep exercise credentials separate from production secrets.
- Baseline capture: Record a quiet baseline period before injects begin so the team can see normal integration activity.
Before the exercise, ask the provider or your platform team to confirm which audit categories the sandbox tenant emits and whether retention in the range matches production.
Injects give the team specific events to find. Each inject should map to a telemetry source named in this page's detection approach, so the exercise tests the rule and the analyst at the same time. Scenarios should be written in advance, approved by the exercise owner, and kept out of the knowledge of the responders until execution. Use change tickets or a scripted change calendar so the blue team can distinguish sanctioned activity from the injected activity during review.
- Sanctioned integration change at an unusual hour: A new application registration or consent grant made by an authorized owner outside business hours, paired with a change ticket that is either present or absent. This tests whether the rule weighs timing and change records.
- Permission escalation: An integration gaining broader delegated or application permissions than its documented purpose, which exercises Cloud Service Modification and Application Log Content.
- Directory object change: A modification to a service principal or group membership that touches Active Directory Object Modification telemetry, to confirm the correlation across sources.
- Credential addition: A new secret or certificate added to an existing integration, a common way to keep access after the original grant is reviewed.
- Control inject: A benign change that should not alert, to measure false positives.
Record the inject time, the expected alert and the expected triage decision before the run, so results can be compared fairly.
A cyber range exercise is only as useful as the criteria used to judge it. Define success before the run, in writing, and agree the thresholds with the security operations lead, the platform owner and the application owner. Avoid judging the exercise on speed alone: a fast alert that is misclassified is a weaker result than a slower alert with correct triage and a documented containment decision.
- Alert within the agreed time: Each inject should produce an alert within the window the exercise owner sets for the detection path being tested.
- Correct triage: Analysts should classify each event as sanctioned, suspicious or inconclusive, and cite the evidence used, such as the change ticket and the actor identity.
- Documented containment: For malicious-looking injects, the team should disable or remove the integration grant or secret through the approved change process, and record who approved it.
- Owner notification: The application owner should be contacted through the agreed path and confirm or deny the change.
- False positive handling: Control injects should be closed without escalation, with the reason recorded.
Confirm the alert window and escalation path with your own SOC procedures before the exercise, since DeployOpen does not set these for your environment.
The most valuable output of a T1671 exercise is a record that the team can use to change detection content and response procedures. Capture what happened, what the analysts saw and what they decided, in a form that can be replayed. Findings that do not lead to a tuning decision, an owner action or a procedure change are wasted effort, so assign each finding a named owner and a review date.
- Timeline record: Log the inject time, the first alert time, the analyst acknowledgment and each containment step, with the source system for each timestamp.
- Evidence bundle: Store the raw audit events, the rule version that fired and the change ticket references, so the result can be reproduced.
- Gap register: List missed injects, late alerts and unclear ownership, with a severity and an owner for each.
- Rule tuning loop: Adjust thresholds, allow-lists and correlation logic in a version-controlled repository, then rerun the same injects to confirm the change.
- Version reference: Record the ATT&CK version and detection mapping the rules target, since ATT&CK releases can rename or revoke techniques.
After tuning, ask the exercise owner to confirm that the rerun results match the agreed criteria before the rule change moves to production.
Questions detection engineers ask about T1671
How do you tell a sanctioned integration from a malicious one?
Start with an inventory of approved integrations, then treat anything outside that inventory as a finding to investigate, not an automatic incident. Each sanctioned integration should have a named business owner, a recorded set of requested permissions, and a registration date. Alerts should fire on new consent grants, new app registrations, added credentials or certificates on existing applications, and permission scopes that grow after installation. Malicious integrations tend to request broad mail, file or directory scopes, use a recently created publisher, or are added outside change windows. Confirm with your identity and SaaS administrators which events your tenant records and how long they are retained before you write the baseline, since the exact event names differ by platform.
Which log fields matter most for T1671 detection?
The fields that identify who added what, to which object, and with which permissions matter most. In practice, that means the acting account and its role, the application or service principal identifier and display name, the type of change (consent, registration, credential addition, role assignment), the requested scopes or roles, the client IP and user agent, and the result of the operation. Object modification events in directory logs and cloud service modification events are the main sources. Keep the timestamps in one time standard across sources so you can correlate an identity change with a later data access event. Verify field names against your platform's own schema before writing Sigma or Wazuh rules, because they vary between vendors and between log export methods.
What should we do when a SaaS platform offers only limited audit exports?
Treat the gap as a risk to document, not a reason to skip detection. First, list every integration point that can add an app, token, webhook or connector, then check which of them write audit events to an export you can reach. Where native export is limited, look for a supported API or a scheduled export, and record the retention period the vendor states. Compensating controls include restricting who can grant consent, requiring administrator approval for high-risk scopes, and monitoring the downstream identity provider logs that record the sign-in or token issuance. Document the residual gap in your risk register and ask the vendor, in writing, what audit coverage applies to your plan tier.
How often should we re-map detections to new ATT&CK versions?
Re-map on each ATT&CK release that touches your techniques, and pin every detection to the version it was written against. MITRE's recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Since v18, technique pages reference detection strategies and analytics, and data components and data sources were reworked, so a mapping written for an older version may point at a data component that no longer carries the same meaning. Review the release notes for changes to T1671, its sub-techniques and the mitigations you cite, then update your detection register with the version identifier and the review date. Most teams review after each release and run a quick regression against their range.
How do we measure detection quality for T1671 in a cyber range?
Measure whether the detection fires, how quickly it fires, and how often it fires for the wrong reason. Run scripted exercises that add a test integration, grant a scope, add a credential and then exercise the access, and record the time from each action to the alert. Track true positives, missed events, and false positives from ordinary administrator activity that looks similar. Keep the test scripts and expected outcomes under version control so you can rerun them after log schema changes or SIEM upgrades. Compare results across releases of your log pipeline. Agree on the metrics and acceptance thresholds with your security leadership before the exercise, so the results are useful for decisions.
Can our own team build T1671 detections, or do we need outside help?
Your team can build these detections if it has administrator-level access to the identity and SaaS platforms, someone who can write and test rules, and time to maintain them after each log schema change. Outside help usually adds value in three places: scoping the telemetry gaps across your platforms, building the range scenarios, and running an independent test of the rules. Whatever the split, ask any provider for a written scope that names the platforms, log sources, ATT&CK version and deliverables. DeployOpen implements and tests self-hosted open-source detection stacks inside client environments, and its engagements are fixed-scope, so the agreed deliverables and boundaries are recorded before work begins.
What recurring work keeps T1671 detections accurate over time?
Recurring work covers rule tuning, log source health checks, and periodic re-testing. Rules drift when vendors rename events, when administrators adopt new integration types, or when a business unit starts using a new connector. Plan a regular review of the integration inventory, a check that each log source still delivers events, and a repeat run of the range scenarios after platform updates. Assign an owner for each detection and record changes with the ATT&CK version they target. Costs for this work are mostly staff time and log storage, and they grow with the number of SaaS platforms and the retention period you choose. Ask any provider to state which of these tasks are included in a one-time build and which are ongoing.
How DeployOpen builds T1671 detections and range scenarios
DeployOpen starts every T1671 Cloud application integration engagement with a written, fixed scope that names the Office suite and SaaS tenants in view, the identity provider that issues tokens, the log sources that will feed the detections and the specific integration types the client wants covered, such as OAuth consent grants, application registrations and service principals. The scope also states who on the client side approves changes, who receives alerts and which evidence the client expects at the end. Before any rule is written, the team confirms with the client which audit log categories are actually enabled in each tenant, because a detection built on a log that is not being collected cannot be validated. Deliverables, timelines and responsibilities are agreed in writing before work begins, and a quote follows from that scope.
Detections are built on self-hosted open-source tooling deployed in the client's own environment, typically Wazuh for collection and rule evaluation, with Sigma rules translated into the local SIEM format and Velociraptor available for follow-up on endpoints that consented to a grant. The team maps each analytic to the ATT&CK version the client has chosen and records it, because technique details can change between releases. Each rule is tested first against recorded sample events from a private cyber range, then reviewed with the client's identity and application owners so that a new third-party integration is not mistaken for persistence. Every tuning decision, such as an allow list for approved publishers or a threshold for consent volume, is written down with the reason, the owner and the date it was made.
Purple team exercises run in a private cyber range that mirrors the client's Office and SaaS configuration without touching production tenants. The range replays the integration activity an adversary might use to keep access, and the client's analysts must detect it, triage it and contain it under the response runbook. Results are compared against the expected detection outcome, and gaps lead to specific rule changes or log collection fixes. DeployOpen prepares the evidence for these controls, including configuration records, test results and tuning logs, so that the client's auditors can assess them. DeployOpen does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, and the client should confirm early which evidence format its assessor expects.
