How do attackers use additional cloud credentials?

Attackers use additional cloud credentials to create new access paths after compromise, then return later even if the original account is disabled. They may add access keys, tokens or service credentials tied to users, workloads or applications. Defenders should alert on credential creation, rotate secrets promptly, and review whether new credentials are tied to approved workflows.

How additional cloud credentials extend an attacker’s foothold

Once an attacker has one cloud foothold, additional credentials let them create a second, third, or hidden access path that survives account disablement. That matters because cloud environments often authenticate users, workloads, and applications differently, so one stolen password is not the only concern. New access keys, tokens, or service credentials can become the real persistence layer.

Those credentials are usually valuable because they are operationally believable, not noisy. A freshly created key for a user, app, or workload can blend into normal administration, deployment, or automation activity while giving the attacker a cleaner way back in. That is why teams should treat credential creation itself as an intrusion signal, not just credential use.

Attackers also benefit from scope chaining. A low-friction credential may open management APIs, CI/CD jobs, storage, or support tooling, which can then reveal more secrets or create yet more identities. Guide to the Secret Sprawl Challenge is useful here because secret exposure often turns a single compromise into a wider credential harvest.

Why this persistence model is so effective in cloud environments

Cloud platforms make it easy to create credentials for different trust boundaries, and attackers exploit that flexibility. If an original interactive account is disabled, a token, API key, or service credential may still authenticate through a different path, sometimes with different logs, different owners, or weaker review coverage. That is what makes post-compromise credential creation such a durable persistence tactic.

This pattern is especially dangerous when long-lived secrets are involved. A credential that does not expire quickly gives the attacker time to wait out incident response, testing, or password resets. Guide to NHI Rotation Challenges explains why rotation is harder than it looks when credentials are embedded in apps, automation, or dependent services.

It also helps explain why cloud compromise often looks unfinished at first. The attacker may not need immediate destructive action. They only need a durable alternative path that survives ordinary remediation steps, which is why secret inventory, dependency mapping, and lifecycle review matter as much as the first compromise investigation.

What defenders should watch and verify after new credentials appear

New credential issuance should be treated as a change in trust, not a routine admin event, until proven otherwise. The key question is whether the new key, token, or service credential was created by an approved workflow, for an approved workload, and with an expected scope. If not, assume it may be an attacker-created persistence mechanism.

Defenders should also check whether the new credential was used to create more credentials, add access to storage or orchestration services, or re-enable access through automation. When a cloud identity has been abused, API Key Management Guide is a practical reference for scoping, rotation, revocation, and response when a key leaks or is misused.

In practice, the highest-value evidence is the sequence: creation event, first use, source IP or workload context, and whether the credential touched sensitive control-plane actions. That sequence tells you whether you are seeing normal lifecycle activity or an attacker building a return path.

Risk and Threat Considerations

additional cloud credentials turn a one-time compromise into a persistence problem. Even after the original account is disabled, attacker-created keys or tokens can preserve access, widen blast radius, and mask the true entry path if they are not discovered quickly.

Failure mechanism: The attacker creates or steals alternate credentials that authenticate through a different trust path, then uses those credentials to survive password resets, session termination, or account suspension.

Impact: Incident response slows down, access revocation becomes incomplete, and the attacker can return later through a credential that was not part of the original containment action.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Attackers abuse leftover cloud credentials as a lingering access path.
	NHI-02 — Secret Leakage	New keys and tokens are secrets that often leak or are newly minted after compromise.
	NHI-07 — Long-Lived Secrets	Long-lived cloud credentials give attackers durable return access after compromise.
Recommendation — Revoke every non-human credential tied to the compromised identity. Scan for leaked secrets and rotate exposed credentials immediately. Shorten secret lifetime and replace static credentials with ephemeral ones.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Cloud credentials require lifecycle control, rotation, and revocation after compromise.
	IA-9 — Service Identification and Authentication	Workload and service credentials are central to the attack path described.
Recommendation — Enforce rotation, revocation, and secure storage for all authenticators. Authenticate services with tightly scoped, monitored machine credentials.
NIST Zero Trust (SP 800-207)	AC-6 — Least Privilege	Attackers gain more value from new credentials when those credentials are overprivileged.
Recommendation — Constrain each credential to the minimum access needed for its task.
MITRE ATT&CK	T1136 — Create Account	Creating new cloud credentials is a classic persistence mechanism after compromise.
	T1098 — Account Manipulation	Adding keys, tokens, or service credentials is account manipulation used for persistence.
Recommendation — Hunt for unexpected account or credential creation in your detections. Alert on credential additions and other account changes that expand access.
OWASP API Security Top 10	API2 — Broken Authentication	Cloud tokens and keys can become alternative authentication paths after compromise.
Recommendation — Validate token issuance, revocation, and authentication flows for abuse.

Practitioner Guidance

What to prioritise: Investigate credential creation events first, not last. In cloud compromise, the creation of a new access key, token, or service credential is often more operationally important than the original login event because it marks the attacker’s persistence path.

What to verify: Confirm who approved the credential, which workflow created it, what it can access, and whether it is tied to a human user, workload, or application that should exist. If the answer is unclear, treat the credential as hostile until ownership is proven.

Common mistake: Teams often rotate only the visibly exposed account secret and overlook the new credential the attacker created during the compromise window. That leaves a live path back into the environment even after the original account is cleaned up.

Practitioner takeaway: The real containment goal is not just disabling the compromised account, it is eliminating every alternate credential path the attacker may have created to come back through later.