Account manipulation: additional cloud credentials is a technique where an attacker adds, registers, or enables extra credentials on an existing cloud account. Those credentials can be API keys, tokens, certificates, or federated sign-in methods, giving persistent access even if the original password is changed.
What additional cloud credentials change
Adding a second credential path to the same cloud account changes the access model from a single login path to multiple persistent ways in. That matters because the attacker can keep access even after the original password is reset, disabled, or watched more closely.
Additional credentials are especially valuable to an intruder because they can survive normal password hygiene and remain usable across API calls, console access, federated access, and automation workflows. In practice, the technique turns a one-time compromise into a durable foothold.
Why attackers use this technique
Credential addition is a persistence move, not just an initial access method. Once an attacker can register an API key, token, certificate, or alternate sign-in method, they can return later without reusing the first entry point that may be monitored or revoked.
This technique also supports privilege expansion. If the added credential inherits the account’s permissions, the attacker can act through normal cloud control plane actions, blend into routine administrator traffic, and use legitimate authentication paths rather than noisy malware.
Where organisations should look for exposure
Exposure usually depends on account inventory, audit visibility, and the provider’s identity controls. Security teams should know which identities can create new keys, register certificates, add federation trust, or attach alternate sign-in methods, then compare that against expected business use.
Cloud audit logs, IAM change events, and identity provider records are the main places to verify whether a new credential was intentionally issued or silently added. A useful starting point is MITRE ATT&CK T1098 Account Manipulation Guide, which covers the broader pattern and related persistence variants.
When the issue involves API keys specifically, API Key Management Guide is the most direct operational reference for scoping, rotation, and revocation of exposed keys.
Containment, detection, and recovery
If additional cloud credentials are suspected, containment should focus on revoking the attacker-created access path, not only the original password. That often means disabling the injected credential, invalidating sessions, reviewing trust relationships, and checking whether the new credential was used to create more persistence.
Detection should look for creation events, unusual credential sprawl, new federation links, and sign-ins from the newly added method. Recovery should include a post-patch compromise review of IAM changes, access logs, and dependent services so the team can confirm the attacker did not leave behind another durable path.
Where the added credential is tied to an automation or workload identity, Guide to NHI Rotation Challenges helps explain why rotation and revocation can be difficult at scale and why lifecycle control matters after compromise.
Risk and Threat Considerations
The main risk is persistence. An attacker who adds their own cloud credential can survive password resets, MFA resets, and partial incident response, then return through a legitimate-looking authentication path.
Failure mechanism: The added credential becomes an alternate trust root for the same account, so removing only the original password or one sign-in method does not actually remove attacker access.
Impact: The attacker can preserve access, expand privileges, create more credentials, and continue data theft, abuse, or lateral movement until every trusted access path is found and revoked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1098 — Account Manipulation | Defines added credentials as account persistence and privilege abuse. |
| Recommendation — Map added credential events to T1098 and hunt for persistence and follow-on access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers issuing, rotating, revoking and protecting cloud authenticators and keys. |
| AC-2 — Account Management | Covers account provisioning, modification and removal of access paths. | |
| AU-12 — Audit Record Generation | Supports logging of credential creation and identity changes needed to detect this technique. | |
| Recommendation — Apply IA-5 to control the full lifecycle of cloud credentials and revoke untrusted authenticators. Use AC-2 to review account changes and remove unauthorized credential additions. Enable AU-12 logging for credential issuance and identity modification events. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Additional cloud credentials create insecure alternate authentication paths for a non-human account. |
| NHI-05 — Overprivileged NHI | Added credentials inherit or enable excessive cloud access, increasing abuse potential. | |
| Recommendation — Harden authentication so extra credentials cannot be added without strong approval and validation. Limit privilege on every credential-bearing path and remove unnecessary access grants. | ||
Practitioner Guidance
Why practitioners should care: Treat this as an identity persistence event, not a simple password problem. The response target is the account’s entire credential set, plus any sessions, federation links, and delegated access created after compromise.
Common misunderstanding: Teams often assume that password resets end the incident. In cloud environments, the attacker may already hold an API key, certificate, or federated token that remains valid after the password changes.
Practitioner takeaway: Confirm every credential-bearing path for the account, then revoke what is untrusted and review whether the added credential was used to establish additional access.
Related resources from NHI Mgmt Group
- What breaks when service account credentials are reused across cloud services?
- Why do stale credentials and unmanaged service-account keys matter so much in cloud environments?
- What breaks when malware steals cloud service account tokens and metadata credentials?
- What happens when attackers obtain valid credentials for a cloud service account?