What are the signs that a compromised cloud identity is being used for persistence?

What persistence looks like in a cloud identity

When a cloud identity is being used for persistence, the attacker is trying to make access survive password resets, incident response, or normal operator churn. The clearest clue is not a single login event, but changes that create durable authority, especially where the identity can keep minting tokens, assume roles, or modify its own trust path.

That is why persistence often shows up as configuration drift around the identity itself, not just activity from it. In practice, the identity starts to look like an access foothold the attacker can return to, rather than a normal workload principal doing its intended job.

For cloud workload identity behaviour and the control points around roles, federated access, and keyless patterns, see Cloud Workload Identity Guide and Ultimate Guide to NHIs, What are Non-Human Identities.

Which signals usually matter most

The highest-value signals are changes that increase the identity’s reach or reduce your ability to notice abuse. New roles, new app registrations, altered trust policies, new federation settings, and added permission grants are especially important because they can turn a one-time compromise into standing access.

Token behaviour also matters. Unusual token issuance, refresh token replay, repeated use of long-lived sessions, and access from locations or hours that do not fit the workload’s normal pattern can indicate that the attacker is maintaining durable access rather than simply reusing one stolen credential.

Identity-management actions are another strong indicator. If the principal begins creating or modifying credentials, adding certificates or secrets, changing conditional access-adjacent settings, or making administrative changes that the workload never normally performs, treat that as a persistence attempt until proven otherwise.

That detection logic aligns with the identity lifecycle and with the difference between ordinary service behaviour and abuse of authorization paths. For deeper lifecycle context, review NHI Lifecycle Management Guide and the incident patterns collected in Identity Threat Detection and Response (ITDR) Guide.

Why persistence is easy to miss in cloud environments

Cloud identities often blend into automation, CI/CD, and infrastructure operations, so malicious persistence can look like normal service traffic unless you compare it to the expected job function. An attacker may prefer identity-side persistence because it is quieter than malware and can survive host rebuilds, making it attractive even when endpoint signals are clean.

The strongest clue is mismatch. A workload principal that suddenly performs tenant-wide administration, identity administration, or trust manipulation is not merely “busy”, it is behaving outside its normal authority. If that behaviour is repeated after revocation events or after the original access path should have been closed, the persistence hypothesis becomes much stronger.

Real cloud breaches show the same pattern: once the attacker controls a cloud identity, they often pivot into role changes, token abuse, and trust manipulation to keep access alive. That is why persistence hunting should focus on what the identity can now do, not only on how it first got in. Storm-2949 Azure Breach, Entra ID actor token flaw (CVE-2025-55241), and Capital One breach 2019 all illustrate how cloud access paths can be turned into durable control.

Risk and Threat Considerations

Persistence through a cloud identity is dangerous because the attacker can keep coming back through a legitimate trust path even after the initial credential or session is removed. That often defeats narrow remediation that only rotates one secret or closes one session.

Failure mechanism: The identity gains or retains durable authority through added roles, altered trust relationships, refresh-token abuse, or hidden federation paths, so access continues after the original compromise point is addressed.

Impact: The attacker can preserve access, re-escalate privileges, and pivot into other cloud resources without triggering the kinds of alerts that usually catch host-based persistence.

Practitioner Guidance

What to verify: Compare the identity’s current permissions, trust policies, and token issuance patterns against a known-good baseline. If the principal can now modify its own access path, treat that as persistence infrastructure, not just suspicious activity.

Decision rule: If the identity can mint fresh access or alter trust after revocation, prioritise role rollback, token invalidation, and trust-path review before hunting for broader lateral movement. If you only rotate a secret, you may leave the persistence mechanism intact.

Practitioner takeaway: Cloud identity persistence is usually a control-plane problem, so the most important question is whether the attacker can still re-establish access through roles, trust, or tokens after the apparent compromise has been removed.

Related resources from NHI Mgmt Group

• Who is accountable when compromised cloud identity is used for business email compromise?
• What are the signs that a compromised VPN appliance is being used for persistence?
• What are the signs that a cloud storage provider may have been compromised through an upstream identity breach?
• What are the signs that compromised IAM keys are being used for cryptojacking or cloud abuse?