Guide · Detection engineering

AWS IAM abuse detection guide

Last reviewed:

Identify identity-abuse patterns in AWS IAM, including role assumption abuse, access key enumeration and risky policy changes for SOC detection teams.

Understanding AWS IAM abuse patterns

Identity and Access Management (IAM) is the primary target for attackers seeking long-term persistence or data access in AWS. Detection focuses on identifying administrative actions that deviate from established patterns, particularly those involving identity transitions or permission escalations.

Detecting role assumption abuse

Attackers use sts:AssumeRole to move laterally or hide their origin. Monitor for role assumptions coming from unexpected source IP addresses, particularly those not associated with your known office ranges or internal VPC endpoints.

A sudden increase in assumptions for high-privileged roles by historically low-privileged users is a strong indicator of compromise. Pay close attention to calls where the SourceIdentity or RoleSessionName parameters contain unusual strings or patterns that do not match your standard naming conventions.

Access key misuse and discovery

Long-lived access keys remain a frequent source of exposure. Detecting abuse involves looking for 'enumeration' behaviour where a single key is used to call a wide variety of Describe and List actions across multiple services in a short window.

Be alert for GetCallerIdentity followed immediately by attempts to list S3 buckets or IAM policies. This suggests an attacker is orientating themselves after a credential theft. If an access key is used from a geographic location or an ISP that has never appeared in your logs for that specific identity, treat it as a high-severity alert.

Monitoring risky policy changes

Risky policy changes often precede data exfiltration or privilege escalation. Make sure you are alerted whenever the AdministratorAccess policy is attached to a new user, group, or role.

Similarly, monitor for the creation of new IAM policy versions that weaken security controls, such as adding '*' permissions or allowing iam:PassRole to arbitrary targets. Attackers may also try to create new access keys for existing users (CreateAccessKey) to ensure they maintain access if their initial entry point is discovered.

Recommended detection actions

Start with these specific event monitors to identify IAM abuse in its early stages.

  • Review CloudTrail logs for UpdateAssumeRolePolicy calls that add external account IDs or unusual service principals to a trust relationship.
  • Set up alerts for PutUserPolicy, PutRolePolicy, and CreatePolicyVersion actions that include administrative permissions.
  • Analyse AssumeRole events where the ExternalId parameter is missing or uses a weak value, especially for cross-account roles.
  • Monitor for login attempts to the AWS Management Console from identities that usually only perform programmatic actions through the CLI or SDK.
Sources
  • AWS STS API Reference, AssumeRole, https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html
  • AWS IAM API Reference, UpdateAssumeRolePolicy, https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAssumeRolePolicy.html
  • AWS IAM API Reference, CreateAccessKey, https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html
  • MITRE ATT&CK T1078 Valid Accounts, https://attack.mitre.org/techniques/T1078/
  • MITRE ATT&CK T1098 Account Manipulation, https://attack.mitre.org/techniques/T1098/
Last verified: 2026-05-28