AN1469: Analytic 1469
Addition of credentials (keys, app passwords, x.509 certs) to existing cloud accounts, service principals, or OAuth apps via portal or API by non-standard identities or IP ranges.
Analyst context for executives and security teams
This analytic focuses on a high-value identity risk: new credentials being added to existing cloud accounts, service principals, or OAuth applications from unusual identities or IP ranges. For leaders, the practical issue is control over who can extend access to cloud identities and applications. If this activity is not monitored, an organization may miss unauthorized persistence or privilege continuity through newly added keys, app passwords, or certificates.
Executive priority
Prioritize this as an identity and cloud security governance question: can the organization prove who is allowed to add credentials to cloud accounts and applications, and can the SOC quickly identify additions from non-standard administrators or unexpected network locations? This matters for incident response scoping, access review evidence, audit readiness, and reducing business disruption from compromised cloud identity objects.
Technical view
Validate monitoring around the Identity Provider platform for credential additions to existing cloud accounts, service principals, and OAuth apps through both portal and API paths. Because the official object provides no detection logic and no tactic mapping, teams should treat this as a detection requirement rather than a finished rule: define the approved identities, roles, automation accounts, source IP ranges, and change windows that are expected to perform credential additions, then alert or review activity outside those baselines.
Likely telemetry
- Identity provider audit logs for credential, key, app password, and certificate additions
- Cloud application or service principal change logs
- OAuth application management events
- Administrator and service account activity logs
- API activity logs for identity or application credential changes
Detection direction
- Build or validate detections for credential additions to existing cloud accounts, service principals, and OAuth apps.
- Compare the actor identity and source IP range against known administrative groups, approved automation, and expected management networks.
- Separate portal-driven changes from API-driven changes so automation noise can be tuned without hiding interactive misuse.
- Review false positives from planned certificate rotation, app secret renewal, break-glass administration, and CI/CD automation.
- Ensure alerts preserve enough context for triage: actor, target identity or app, credential type, source IP, method used, and surrounding administrative actions.
Mitigation priorities
- Restrict who can add credentials to cloud accounts, service principals, and OAuth apps.
- Maintain an approved inventory of administrative identities, automation identities, and trusted source IP ranges for credential management.
- Require documented change control or approval for credential additions where operationally feasible.
- Regularly review existing keys, app passwords, and certificates for ownership, age, and business justification.
- Test incident response procedures for rapid validation and removal of suspicious credentials from identity provider objects.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, AN1469, for the enterprise domain and Identity Provider platform. It describes credential additions to existing cloud accounts, service principals, or OAuth apps by non-standard identities or IP ranges. No ATT&CK relationships, tactics, labels, aliases, or official detection implementation were supplied, so the value is in translating the behavior into identity-provider monitoring and governance validation.
This take is limited to the official STIX fields and the single MITRE external reference provided. It does not assert active exploitation, attribution, business impact, or current detection coverage. Local identity provider audit capabilities, cloud architecture, administrator baselines, and change-management practices are required to turn this into a production-quality analytic.
Analytic 1469
Addition of credentials (keys, app passwords, x.509 certs) to existing cloud accounts, service principals, or OAuth apps via portal or API by non-standard identities or IP ranges.
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 | 111255d2ee8a… |
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 AN1469Open 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.