AWS IAM Principal Enumeration via UpdateAssumeRolePolicy
Detects repeated failed attempts to update an IAM role’s trust policy in an AWS account, consistent with role and user enumeration techniques. In this technique, an attacker who controls credentials in the current account repeatedly calls UpdateAssumeRolePolicy on a single role, cycling through guessed cross-account role or user ARNs as the principal. When those principals are invalid, IAM returns MalformedPolicyDocumentException, producing a burst of failed UpdateAssumeRolePolicy events. This rule alerts on that brute-force pattern originating from this account, which may indicate that the account is being used as attack infrastructure or that offensive tooling (such as Pacu) is running here. Note: this rule does not detect other accounts enumerating roles, because those API calls are logged in the caller’s account, not the target account.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/07/16"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2026/01/16"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects repeated failed attempts to update an IAM role’s trust policy in an AWS account, consistent with role and user
11enumeration techniques. In this technique, an attacker who controls credentials in the current account repeatedly calls
12UpdateAssumeRolePolicy on a single role, cycling through guessed cross-account role or user ARNs as the principal. When
13those principals are invalid, IAM returns MalformedPolicyDocumentException, producing a burst of failed
14UpdateAssumeRolePolicy events. This rule alerts on that brute-force pattern originating from this account, which may
15indicate that the account is being used as attack infrastructure or that offensive tooling (such as Pacu) is running
16here. Note: this rule does not detect other accounts enumerating roles, because those API calls are logged in the
17caller’s account, not the target account.
18"""
19from = "now-6m"
20index = ["filebeat-*", "logs-aws.cloudtrail-*"]
21language = "kuery"
22license = "Elastic License v2"
23name = "AWS IAM Principal Enumeration via UpdateAssumeRolePolicy"
24note = """## Triage and analysis
25
26### Investigating AWS IAM Principal Enumeration via UpdateAssumeRolePolicy
27
28This rule detects bursts of failed attempts to update an IAM role’s trust policy — typically resulting in `MalformedPolicyDocumentException` errors — which can indicate enumeration of IAM principals.
29Adversaries who have obtained valid AWS credentials may attempt to identify roles or accounts that can be assumed by repeatedly modifying a role’s trust relationship using guessed `Principal` ARNs.
30When these principals are invalid, IAM rejects the request, creating a recognizable sequence of failed `UpdateAssumeRolePolicy` events.
31
32Because this is a threshold rule, it triggers when the number of failures exceeds a defined count within a short period. This pattern suggests brute-force-style enumeration rather than normal misconfiguration.
33
34#### Possible investigation steps
35
36- **Validate the context of the threshold trigger**
37 - Review the `@timestamp` range for when the burst occurred and the number of failed attempts in the threshold window.
38 - Identify whether all failures targeted the same `RoleName` or multiple roles — targeting a single role is often indicative of brute-force enumeration.
39 - Confirm the source identity and IP address (`aws.cloudtrail.user_identity.arn`, `source.ip`, `user_agent.original`) to determine whether these calls originated from a known automation process or an unexpected host.
40
41- **Correlate with other IAM activity**
42 - Look for any subsequent successful `UpdateAssumeRolePolicy` or `AssumeRole` calls, which may indicate the attacker eventually discovered a valid principal.
43 - Search for reconnaissance-related API calls (`ListRoles`, `ListUsers`, `GetCallerIdentity`) before the threshold event — these often precede enumeration bursts.
44 - Investigate whether other suspicious role- or identity-related actions occurred near the same timeframe, such as `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy`.
45
46- **Identify infrastructure patterns**
47 - Examine the `user_agent.original` field — the presence of automation frameworks or penetration tools (e.g., “Boto3”, “Pacu”) may signal offensive tooling.
48 - Review the `source.ip` or `cloud.account.id` fields to see whether this account may be acting as attacker-controlled infrastructure attempting to enumerate roles in other environments.
49
50- **Validate authorization**
51 - Confirm with your DevOps or Cloud IAM teams whether any expected testing, migration, or cross-account role configuration changes were planned for this time period.
52 - If the identity performing these actions does not typically manage IAM roles or trust relationships, escalate for investigation as a possible credential compromise.
53
54### False positive analysis
55
56- **Legitimate automation retries**
57 - Continuous integration or configuration management systems may retry failed IAM API calls during deployment rollouts.
58 If the same IAM role was being updated as part of a known change, validate the timing and source identity before closing as benign.
59- **Misconfigured scripts or infrastructure drift**
60 - Scripts that deploy trust policies using outdated or invalid ARNs can cause repetitive failures that mimic brute-force patterns.
61 Review the `RoleName` and `Principal` ARNs included in the failed requests to confirm if they correspond to known but outdated configurations.
62
63### Response and remediation
64
65- **Immediate review and containment**
66 - Investigate whether the source account is being used for offensive operations or compromised automation.
67 - Disable or suspend the IAM user or access key responsible for the enumeration burst.
68 - If activity originated from a workload or CI/CD system, audit its access keys and environment variables for compromise.
69
70- **Investigation and scoping**
71 - Review CloudTrail logs for other IAM or STS actions from the same source in the preceding and following 24 hours.
72 - Check for any successful privilege changes (`PutRolePolicy`, `AttachRolePolicy`, or `AssumeRole`) by the same identity.
73 - Determine if other roles in the same account experienced similar failed updates or bursts.
74
75- **Recovery and hardening**
76 - Rotate credentials for any identities involved.
77 - Limit permissions to modify trust policies (`iam:UpdateAssumeRolePolicy`) to a small set of administrative roles.
78 - Enable AWS Config rule `iam-role-trust-policy-check` to detect overly permissive or unusual trust relationships.
79 - Use AWS GuardDuty or Security Hub to monitor for subsequent privilege escalation or reconnaissance findings.
80 - Review the event against AWS Incident Response Playbook guidance (containment > investigation > recovery > hardening).
81
82### Additional information
83 - **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**
84 - **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)**
85 - **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)
86"""
87references = [
88 "https://www.praetorian.com/blog/aws-iam-assume-role-vulnerabilities",
89 "https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/",
90]
91risk_score = 47
92rule_id = "ea248a02-bc47-4043-8e94-2885b19b2636"
93severity = "medium"
94tags = [
95 "Domain: Cloud",
96 "Data Source: AWS",
97 "Data Source: Amazon Web Services",
98 "Data Source: AWS IAM",
99 "Use Case: Identity and Access Audit",
100 "Resources: Investigation Guide",
101 "Tactic: Discovery",
102 "Tactic: Credential Access",
103]
104timestamp_override = "event.ingested"
105type = "threshold"
106
107query = '''
108event.dataset: "aws.cloudtrail"
109 and event.provider: "iam.amazonaws.com"
110 and event.action: "UpdateAssumeRolePolicy"
111 and aws.cloudtrail.error_code: "MalformedPolicyDocumentException"
112 and event.outcome: "failure"
113'''
114
115
116[[rule.threat]]
117framework = "MITRE ATT&CK"
118[[rule.threat.technique]]
119id = "T1087"
120name = "Account Discovery"
121reference = "https://attack.mitre.org/techniques/T1087/"
122[[rule.threat.technique.subtechnique]]
123id = "T1087.004"
124name = "Cloud Account"
125reference = "https://attack.mitre.org/techniques/T1087/004/"
126
127
128
129[rule.threat.tactic]
130id = "TA0007"
131name = "Discovery"
132reference = "https://attack.mitre.org/tactics/TA0007/"
133[[rule.threat]]
134framework = "MITRE ATT&CK"
135[[rule.threat.technique]]
136id = "T1110"
137name = "Brute Force"
138reference = "https://attack.mitre.org/techniques/T1110/"
139
140
141[rule.threat.tactic]
142id = "TA0006"
143name = "Credential Access"
144reference = "https://attack.mitre.org/tactics/TA0006/"
145
146[rule.threshold]
147field = ["cloud.account.id", "user.name", "source.ip"]
148value = 25
Triage and analysis
Investigating AWS IAM Principal Enumeration via UpdateAssumeRolePolicy
This rule detects bursts of failed attempts to update an IAM role’s trust policy — typically resulting in MalformedPolicyDocumentException errors — which can indicate enumeration of IAM principals.
Adversaries who have obtained valid AWS credentials may attempt to identify roles or accounts that can be assumed by repeatedly modifying a role’s trust relationship using guessed Principal ARNs.
When these principals are invalid, IAM rejects the request, creating a recognizable sequence of failed UpdateAssumeRolePolicy events.
Because this is a threshold rule, it triggers when the number of failures exceeds a defined count within a short period. This pattern suggests brute-force-style enumeration rather than normal misconfiguration.
Possible investigation steps
-
Validate the context of the threshold trigger
- Review the
@timestamprange for when the burst occurred and the number of failed attempts in the threshold window. - Identify whether all failures targeted the same
RoleNameor multiple roles — targeting a single role is often indicative of brute-force enumeration. - Confirm the source identity and IP address (
aws.cloudtrail.user_identity.arn,source.ip,user_agent.original) to determine whether these calls originated from a known automation process or an unexpected host.
- Review the
-
Correlate with other IAM activity
- Look for any subsequent successful
UpdateAssumeRolePolicyorAssumeRolecalls, which may indicate the attacker eventually discovered a valid principal. - Search for reconnaissance-related API calls (
ListRoles,ListUsers,GetCallerIdentity) before the threshold event — these often precede enumeration bursts. - Investigate whether other suspicious role- or identity-related actions occurred near the same timeframe, such as
CreateRole,PutRolePolicy, orAttachRolePolicy.
- Look for any subsequent successful
-
Identify infrastructure patterns
- Examine the
user_agent.originalfield — the presence of automation frameworks or penetration tools (e.g., “Boto3”, “Pacu”) may signal offensive tooling. - Review the
source.iporcloud.account.idfields to see whether this account may be acting as attacker-controlled infrastructure attempting to enumerate roles in other environments.
- Examine the
-
Validate authorization
- Confirm with your DevOps or Cloud IAM teams whether any expected testing, migration, or cross-account role configuration changes were planned for this time period.
- If the identity performing these actions does not typically manage IAM roles or trust relationships, escalate for investigation as a possible credential compromise.
False positive analysis
- Legitimate automation retries
- Continuous integration or configuration management systems may retry failed IAM API calls during deployment rollouts.
If the same IAM role was being updated as part of a known change, validate the timing and source identity before closing as benign.
- Continuous integration or configuration management systems may retry failed IAM API calls during deployment rollouts.
- Misconfigured scripts or infrastructure drift
- Scripts that deploy trust policies using outdated or invalid ARNs can cause repetitive failures that mimic brute-force patterns.
Review theRoleNameandPrincipalARNs included in the failed requests to confirm if they correspond to known but outdated configurations.
- Scripts that deploy trust policies using outdated or invalid ARNs can cause repetitive failures that mimic brute-force patterns.
Response and remediation
-
Immediate review and containment
- Investigate whether the source account is being used for offensive operations or compromised automation.
- Disable or suspend the IAM user or access key responsible for the enumeration burst.
- If activity originated from a workload or CI/CD system, audit its access keys and environment variables for compromise.
-
Investigation and scoping
- Review CloudTrail logs for other IAM or STS actions from the same source in the preceding and following 24 hours.
- Check for any successful privilege changes (
PutRolePolicy,AttachRolePolicy, orAssumeRole) by the same identity. - Determine if other roles in the same account experienced similar failed updates or bursts.
-
Recovery and hardening
- Rotate credentials for any identities involved.
- Limit permissions to modify trust policies (
iam:UpdateAssumeRolePolicy) to a small set of administrative roles. - Enable AWS Config rule
iam-role-trust-policy-checkto detect overly permissive or unusual trust relationships. - Use AWS GuardDuty or Security Hub to monitor for subsequent privilege escalation or reconnaissance findings.
- Review the event against AWS Incident Response Playbook guidance (containment > investigation > recovery > hardening).
Additional information
- AWS IR Playbooks
- AWS Customer Playbook Framework
- Security Best Practices: AWS Knowledge Center – Security Best Practices
References
Related rules
- AWS IAM CompromisedKeyQuarantine Policy Attached to User
- AWS EC2 Instance Console Login via Assumed Role
- AWS IAM AdministratorAccess Policy Attached to Group
- AWS IAM AdministratorAccess Policy Attached to Role
- AWS IAM AdministratorAccess Policy Attached to User