AN1471: Analytic 1471
Credential-related configuration changes in productivity apps, such as API key creation in Google Workspace, app tokens in Slack, or user-level OAuth credentials in M365.
Analyst context for executives and security teams
This analytic is about watching for credential-related configuration changes inside SaaS productivity platforms, such as creating API keys, app tokens, or user-level OAuth credentials. For leaders, the decision value is that these changes can create durable access paths outside normal password and MFA workflows, so they matter for identity governance, SaaS security, incident response scoping, and audit evidence.
Executive priority
Prioritize this as a SaaS identity and business-continuity control question: can the organization prove who created or changed application credentials, when it happened, and whether the change was authorized? Security leaders should use this to validate whether Google Workspace, Slack, M365, and similar productivity-app administration is covered by logging, alerting, access review, and incident-response playbooks. The object does not provide tactics or active threat context, so prioritization should be based on local SaaS dependency, sensitivity of hosted data, and credential governance maturity.
Technical view
SOC and detection teams should validate visibility into credential-related configuration events in SaaS productivity applications. The supplied analytic examples include API key creation in Google Workspace, app token activity in Slack, and user-level OAuth credential changes in M365. Because no official detection logic is provided, teams should define local detections around credential creation, token issuance, OAuth consent or credential changes, and similar administrative or user-level events, then baseline expected behavior by role, app, and business process.
Likely telemetry
- SaaS audit logs for productivity platforms
- Identity and access management logs tied to SaaS users and administrators
- OAuth application and consent change records
- API key creation or modification events
- App token creation, rotation, or revocation events
Detection direction
- Confirm the relevant SaaS platforms actually emit and retain credential-configuration events needed for investigation.
- Alert on new or unusual API keys, app tokens, or user-level OAuth credentials, especially for privileged users or sensitive applications.
- Tune detections against approved automation, integrations, helpdesk workflows, and developer activity to reduce false positives.
- Correlate credential changes with user identity, source context, role, timing, and change-management evidence.
- Review blind spots where user-level OAuth or app-token activity is not centrally logged, is retained for too short a period, or is excluded from SIEM ingestion.
Mitigation priorities
- Establish ownership and approval requirements for SaaS API keys, app tokens, and OAuth credentials.
- Limit who can create or approve application credentials in productivity platforms.
- Regularly review and revoke unused or unauthorized credentials.
- Ensure SaaS audit logs are enabled, retained, and forwarded for detection and incident response.
- Document response procedures for suspected unauthorized credential creation or token misuse.
Analyst notes and limits
This is a detection analytic object, not a technique description. The official description is specific to SaaS productivity-app credential configuration changes, but no official detection logic, tactics, or relationship context was supplied. Treat it as a validation prompt for SaaS credential governance and telemetry coverage rather than a complete analytic rule.
The supplied ATT&CK fields do not include a tactic, related techniques, data components, detection pseudocode, mitigations, or adversary relationships. Any assessment of risk, coverage, or priority requires local evidence about SaaS platforms in use, logging availability, retention, administrative roles, and approved integration workflows.
Analytic 1471
Credential-related configuration changes in productivity apps, such as API key creation in Google Workspace, app tokens in Slack, or user-level OAuth credentials in M365.
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 | 2a13845a38e7… |
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 AN1471Open 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.