DET0531: Detection Strategy for Additional Cloud Credentials in IaaS/IdP/SaaS
This detection strategy matters because it points defenders at a high-value persistence problem in cloud and identity environments: adversaries adding extr...
Analyst context for executives and security teams
This detection strategy matters because it points defenders at a high-value persistence problem in cloud and identity environments: adversaries adding extra credentials to accounts, service principals, or applications so access can survive password resets or normal account review. For leaders, the practical question is whether the organization can prove when cloud credentials are added, by whom, to what identity, and whether that change was expected.
Executive priority
Treat this as an identity and cloud resilience priority. Additional cloud credentials are tied to persistence and privilege escalation for IaaS, Identity Provider, and SaaS environments, so gaps here can affect incident containment, access revocation confidence, audit evidence, and cloud control assurance. Executives should ask whether credential creation and modification events are centrally logged, reviewed, retained, and correlated with approved change activity.
Technical view
The supplied ATT&CK detection strategy object does not include official detection logic, but its relationship to T1098.001 directs SOC and IR teams to validate monitoring for added cloud credentials in IaaS, IdP, and SaaS control planes. Detection engineering should focus on events where passwords, x509 keys, secrets, certificates, or equivalent credentials are added to cloud accounts, service principals, applications, or similar identities. Analysts should correlate these changes with the actor, target identity, privilege level, source context, and change-management records.
Likely telemetry
- Cloud identity provider audit logs for credential additions or updates
- IaaS control-plane audit logs for account, role, application, or service principal credential changes
- SaaS administrative audit logs showing credential, key, certificate, or application secret creation
- Identity governance or access management records showing approvers, owners, and expected credential lifecycle
- Change-management tickets or administrative activity records for false-positive reduction
Detection direction
- Validate that credential-addition events are collected from IaaS, Identity Provider, and SaaS platforms in scope for the environment.
- Prioritize alerting where new credentials are added to privileged users, service principals, applications, or accounts with broad access.
- Tune detections against expected administrative workflows such as key rotation, application onboarding, or certificate renewal.
- Correlate credential additions with unusual administrator activity, unexpected source locations, newly elevated permissions, or absence of an approved change record where such context is available.
- Test incident-response visibility by confirming analysts can identify the target identity, credential type, creator, timestamp, and affected platform from retained logs.
Mitigation priorities
- Establish ownership and lifecycle controls for cloud credentials, including review of application secrets, keys, certificates, and service principal credentials.
- Limit who can add or modify cloud credentials, especially for privileged identities and applications.
- Require documented approval or change control for credential creation and rotation where operationally feasible.
- Regularly review cloud and identity audit logs for unauthorized or stale credentials.
- Ensure incident response playbooks include searching for and removing added cloud credentials during containment and recovery.
Analyst notes and limits
This take is based on the detection strategy identifier DET0531 and its ATT&CK relationship to T1098.001 Additional Cloud Credentials. The most useful local validation is whether the organization can distinguish legitimate credential rotation from suspicious persistence-oriented credential creation across IaaS, IdP, and SaaS environments.
The supplied detection strategy has no official description, detection text, tactics, or platforms of its own. Platform and tactic context comes from the related ATT&CK technique T1098.001. Specific log source names, event IDs, vendor implementations, and detection thresholds require local platform evidence and are not provided in the source fields.
Detection Strategy for Additional Cloud Credentials in IaaS/IdP/SaaS
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1098.001 | Additional Cloud Credentials Sub-technique | This object detects Additional Cloud Credentials. |
All related ATT&CK context
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 | 6157c9fa947c… |
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 DET0531Open 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.