Hunting Cloud Credential Compromise and Lateral Movement

There’s no ADMIN$ share to connect to in the cloud, no PsExec, no obvious protocol handshake announcing “an attacker just moved from host to host.” Lateral movement in cloud environments looks like a series of API calls that are each individually mundane assume this role, read this secret, launch this instance strung together into a chain that on-prem lateral movement hunting instincts don’t automatically catch, because there’s no network-layer equivalent of the SMB fan-out pattern to anchor on.

This is genuinely one of the harder hunting problems covered in this whole series, precisely because “movement” in a cloud context is often just permission usage, not anything resembling traditional network traversal.

Role assumption chains are the closest cloud equivalent to lateral movement

The AWS AssumeRole API, Azure’s role-based access control combined with managed identity federation, and GCP’s service account impersonation all serve the same functional purpose letting a principal temporarily take on a different identity’s permissions. Attackers who’ve compromised an initial credential frequently chain multiple role assumptions together specifically to reach a permission set the original credential didn’t have directly, which mirrors privilege escalation and pivoting in an on-prem environment almost exactly, just expressed through API calls instead of network connections.

The hunt: build a graph of role assumption chains over time for a given identity, and flag chains that are unusually long, unusually broad in scope, or that terminate in a role with significantly more privilege than the originating credential ever had reason to hold directly. A CI/CD service account that normally assumes one specific deployment role suddenly chaining through three additional roles to reach an administrative permission set is a strong signal, and it’s a pattern that’s genuinely difficult to catch without building this kind of chain-tracking analysis deliberately, because each individual AssumeRole call looks unremarkable reviewed in isolation.

Cross-account and cross-subscription access deserves heightened scrutiny

Multi-account AWS organizations and multi-subscription Azure environments create legitimate reasons for cross-boundary access shared services accounts, centralized logging roles, that kind of thing. They also create a lateral movement path that’s genuinely more dangerous than staying within a single account, because a compromised credential that can hop accounts potentially reaches resources with completely different security postures and monitoring maturity than wherever the attacker started.

Hunting for this means specifically flagging cross-account or cross-subscription role assumptions that don’t match documented, expected patterns a credential based in a development account assuming a role in a production account is worth investigating regardless of whether the permission itself was technically granted correctly, because the mere existence of that access path represents risk that deserves periodic review independent of whether it’s actively being abused right now.

Metadata service abuse remains a classic, still-effective technique

Cloud instance metadata services AWS’s IMDS, Azure’s equivalent, GCP’s metadata server hand out temporary credentials to anything running on the instance, which is convenient for legitimate applications and equally convenient for an attacker who’s achieved code execution on that instance through some other vulnerability, typically SSRF against a web application that has access to the metadata endpoint. Once those instance credentials are stolen, the attacker effectively has whatever permissions that instance’s role carries, without ever needing to compromise a human user’s credentials at all.

The specific hunt here overlaps with the GuardDuty finding mentioned in the AWS post credentials being used from outside the instance they were issued to is the tell, and it’s worth building this as a standing hunt even independent of whatever your cloud provider’s own threat detection surfaces, because confirming the finding through your own CloudTrail or equivalent analysis, and scoping exactly what that stolen credential subsequently did, is where the real investigative value shows up.

Distinguishing legitimate automation from attacker behavior is the genuine hard problem

Here’s the honest caveat worth stating plainly: a huge amount of legitimate cloud activity looks structurally identical to lateral movement if you’re only looking at the shape of the API calls. CI/CD pipelines assume roles constantly. Infrastructure automation tools chain permissions across services routinely as part of completely normal operations. The volume of legitimate role-assumption and cross-service activity in an actively used cloud environment can be enormous, and separating malicious chains from routine automation is where a lot of cloud lateral movement hunting programs genuinely struggle.

What helps: building a solid inventory of known, expected automation patterns which service accounts run which pipelines, which roles get assumed as part of which documented workflows and treating deviations from that known-good baseline as the actual signal, rather than trying to build generic lateral-movement detection logic that has to work without any environment-specific context. This baseline work is tedious and never fully finished as environments keep changing, but it’s genuinely the foundation everything else in this hunt depends on.

Correlating identity, network, and API layers together

The strongest cloud lateral movement investigations pull together everything covered elsewhere in this series the identity-layer signals from Entra ID or Okta hunting, the API-layer role assumption chains covered here, and the network-layer VPC Flow Log analysis from the AWS and GCP posts. An attacker moving from a compromised human identity into cloud infrastructure access, then chaining role assumptions to reach sensitive resources, leaves evidence at every one of these layers, and no single layer tells the whole story on its own.