Cloud IAM: Pivoting Between Identities
AWS STS AssumeRole, Azure managed identities, Entra ID, service principals, GCP impersonation and Cognito trust policies: movement without a password.
Cloud lateral movement mostly happens without credentials in the usual sense. One identity is allowed to become another, and the policy that permits it is the finding.
AWS STS and AssumeRole
In AWS, changing identity can be a normal API call. Risk comes from who may assume which role and under which conditions. STS issues temporary credentials for role sessions. AssumeRole requires caller-side authorization and a compatible trust policy on the destination role. ExternalId, MFA, session tags, source identity and conditions may constrain or expand the path. I start with get-caller-identity, map trust policies and test only roles where both sides of the relationship appear to allow the transition. A policy containing sts:AssumeRole does not prove access by itself. The destination trust policy and organization controls still participate in the decision.
1
2
aws sts get-caller-identity
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/BackupAdmin --role-session-name lab
Azure Managed Identities
A VM with no stored password may still have a powerful Azure identity locally available to any process that reaches the right endpoint. Managed Identity provides temporary tokens for Azure resources without a static workload secret. System-assigned and user-assigned identities differ in lifecycle and reuse. Inside Azure compute, the metadata service participates in token acquisition. SSRF or code execution in the workload may reach that identity. I identify attached managed identities, which token resources or audiences are requested and which Azure RBAC roles each identity holds. Managed Identity improves secret management. Risk appears when the workload identity has more permission than the application requires.
1
2
az vm identity show -g lab-rg -n app01
az role assignment list --assignee <principal-id>
Microsoft Entra ID
Entra ID looks like Active Directory until you search for an ACL and discover that power moved into roles, applications and consent grants. Entra organizes users, groups, service principals, applications, directory roles and Conditional Access. The identity model is cloud-first. Admin roles, application permissions, consent and ownership create attack paths that do not appear in classic group membership. I enumerate tenant, roles, apps, service principals, owners, API permissions and consent before testing changes. Global Administrator is only one target. Privileged Role Administrator, Application Administrator and Cloud Application Administrator can create strong paths through different relationships.
1
2
az ad signed-in-user show
az ad sp list --all --query '[].{displayName:displayName,appId:appId,id:id}'
Azure Service Principals and App Registrations
An application registered in the tenant may have more access than many users while remaining outside reviews focused only on human accounts. An app registration defines the application object. A service principal represents an instance of that application in a tenant and receives permissions and role assignments. Client secrets, certificates, federated credentials and owners are different paths toward control of the identity. I map owners, credentials, API permissions, admin consent and Azure RBAC assignments before attempting application authentication. Adding a new credential may be more useful than stealing an existing one when the compromised identity has application ownership or administrative rights.
1
2
az ad app credential list --id <app-id>
az role assignment list --assignee <service-principal-id>
GCP IAM
In GCP, a service account is both an identity and a resource. Permission over the account can be as important as possessing one of its keys. GCP IAM policies bind principals to roles at organization, folder, project and resource levels. Inheritance composes permissions. Service Account Token Creator enables impersonation and token minting. Service Account User participates in attaching identities to workloads. I start with gcloud auth list, projects, IAM policies and service accounts, then map impersonation and workload paths. Owner is an obvious target, but custom roles and service-account permissions create more subtle pivots. Conditions also constrain grants.
1
2
3
gcloud auth list
gcloud projects get-iam-policy <project-id>
gcloud iam service-accounts list
AWS Cognito
Cognito can authenticate a user and also exchange that identity for AWS credentials. Mixing User Pools and Identity Pools without understanding the difference creates bad findings. User Pools handle user directories and OIDC tokens. Identity Pools federate identities into temporary AWS credentials through roles. Unauthenticated identities, role mappings, token validation and attribute-based role selection change reach. I identify pool IDs, app clients, OAuth configuration and identity-pool roles before requesting any AWS credential. A mobile app client without a secret is normal. Risk appears in auth flows, redirects, user enumeration or overprivileged roles obtained after login.
1
2
aws cognito-idp describe-user-pool-client --user-pool-id <pool> --client-id <client>
aws cognito-identity describe-identity-pool --identity-pool-id <id>