In 2026, identity theft in AWS has become the preferred path to compromise cloud environments. The reason is simple from the attacker’s point of view: it is cheaper and more reliable to steal or abuse credentials, tokens, and trust relationships than to look for a “classic” exploit against an exposed service.
Recent 2026 data points to a clear pattern: 83% of initial cloud attacks take advantage of identity issues (leaked credentials, STS sessions, permissive trust policies, poorly governed OAuth/SAML) instead of traditional technical vulnerabilities. It’s not that exploits have disappeared; it’s that identity has become the most direct highway to real permissions.
What went wrong: when “valid” access becomes the intrusion vector
Most identity incidents in AWS do not start with a “0-day”. They start with something that in logs looks legitimate: an AWS STS session issued, a call to AssumeRole, a login via SSO, an access key used from a new environment. The trap is that the attacker does not need to break AWS; they need to convince your identity control to hand them a valid session.
In large companies, this is exacerbated by delivery pressure: teams that automate with IAM users because “it’s faster”, third-party integrations that ask for roles with wildcards, or legacy accounts where nobody dares touch trust relationships for fear of stopping production. Result: the intruder gets in with the appearance of an internal user, and the SOC wastes time ruling out a false positive.
Typical real consequence: the attacker does not “scan” or exploit; they enumerate with permissions. They start with sts:GetCallerIdentity, move on to listing roles/policies, look for escalation paths (IAM permissions or roles with broad trust), and move laterally across accounts if there is a poorly segmented organization.
Why the 83% is better explained by economics and operational friction than by attacker “magic”
In 2026, the market for credentials, tokens, and brokered access is too mature to ignore. An exploit requires research, compatibility, and often public exposure. In contrast, identity theft “buys” direct access to the APIs, through the same channel your automation uses. In addition, many companies have hardened perimeters and patching, but still carry IAM debt: excessive permissions, broad trust relationships, and little visibility into which identities workloads actually use.
The 83% fits with what is seen in the field: the first access is obtained with identity material (credentials, tokens, sessions) or by abusing the trust chain (IdP → SSO → roles; CI/CD → OIDC → roles; cross-account trust). It is not a change in “fashion”; it is a change in incentive. If your operation is designed so that identity is flexible, the attacker will exploit that flexibility.
A very common anti-pattern in corporations is to confuse “having MFA on the console” with “being protected”. The attacker rarely needs your console; API access and permissions are enough. When the security focus is centered on human login and not on the issuance/use of STS sessions, the most profitable door is left open.
Early signals in AWS that reveal identity theft or abuse
Effective detection in AWS is not about looking for “malware” inside AWS, but about monitoring identity and permission behaviors. In real incidents, early signals are often subtle: changes in geographic pattern, new user agents (SDKs), calls to enumeration APIs, or spikes in AssumeRole. The danger is that, if the attacker steals a short-lived STS session, the event looks too much like a legitimate automation job.
In CloudTrail (and if applicable, in CloudTrail Lake), it is worth looking for sequences: first GetCallerIdentity, then ListRoles/ListPolicies, then IAM actions (attach policies, update trust), and finally data access (S3, Secrets Manager, Parameter Store) or compute (ECS/EKS/Lambda) for persistence. In companies, this often appears outside business hours or from a network origin that does not match the CI/CD runners.
- Anomalous use of
AssumeRoleand chained role changes
An unusual role chaining pattern usually indicates exploration or lateral movement. If you have not modeled which roles each pipeline and each team assumes, separating “legitimate” from “intruder” becomes reactive.
- Unusual IAM actions in non-operational identities
When an application role (for example, a Lambda role) executes iam:PassRole or modifies policies, it is usually a flawed design or an intrusion. In corporations, the root cause is often “temporary” permissions that became permanent due to an emergency.
- Mass reads of secrets or parameters
An attacker who gets in through identity looks for secondary credentials: third-party API keys, internal tokens, connection strings. A spike in secretsmanager:GetSecretValue or ssm:GetParameter from an unusual principal is a strong signal, especially if it coincides with new STS sessions.
How to do it in practice: hardening IAM/STS so stealing identity is not enough
The operational goal is not to “prevent credentials from being stolen” (that is aspirational), but to reduce the blast radius when it happens and make abuse harder. In AWS, that translates into limiting who can assume which role, from where, under what conditions, for how long, and with what effective permissions. In corporate environments, the failure point is usually the trust policy that is too open or the use of human/static identities where federation and ephemeral credentials should be used.
A measure with immediate impact is to harden trust policies with verifiable conditions. For example, in OIDC integrations (CI/CD), avoid generic trust and tie the role to specific claims (repo, branch, audience). In cross-account, avoid trusting another account’s root and require ExternalId when a third party assumes your role.
Example trust policy (cross-account) with ExternalId and principal restriction:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:role/ThirdPartyIntegratorRole" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "sts:ExternalId": "CORP-UNIQUE-EXT-ID" }
}
}
]
}
Example trust policy (OIDC) tied to claims (the idea is to restrict “who” and “from what context”):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:org/proyecto:ref:refs/heads/main"
}
}
}
]
}
The part that is often forgotten is validation. In AWS, validate that the role is not assumable “by accident” by reviewing: trust relationships (IAM → Roles → Trust relationships), AssumeRole events in CloudTrail, and effective permission with IAM Access Analyzer (external access findings) to detect roles/policies that allow access from outside your organization.
- Configure session limits and pattern rotation
Reduce session duration when it makes operational sense (especially for sensitive roles) and force the use of ephemeral sessions over long-lived keys. In real incidents, shortening session windows reduces the useful time of a stolen token and forces the attacker to re-authenticate, where you can already block them.
- Eliminate IAM users in automation and migrate to roles with federated identity
The most expensive debt is the “temporary” IAM user for a script or a vendor. Replacing it with assumable roles (OIDC/SAML/SSO) changes the game: you reduce exposure of static secrets and improve traceability. In enterprises, this often requires coordination with DevOps, but it drastically lowers the risk of leakage in repositories, tickets, or CI tools.
Recommendations for corporate environments
If in 2026 identity theft is the main threat in AWS, the practical response is to treat IAM/STS as a prioritized attack surface. The 83% figure makes sense because identity provides real access without needing to exploit vulnerabilities: that is why controls must focus on sessions, trust, and effective permissions, not only on hardening hosts or perimeters.
In corporate operations, what works best is to combine signals (CloudTrail focused on AssumeRole, IAM actions, and access to secrets) with pragmatic hardening: restrictive trust policies (claims/ExternalId), reduced permissions, and the progressive elimination of static credentials. That way, even if an identity is compromised, the attacker is left without easy escalation and lateral movement paths.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.