You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Rule Tuning] AWS Access Token Used from Multiple Addresses (#5412)
* [Rule Tuning] AWS Access Token Used from Multiple Addresses
This rule is extremely loud in telemetry ~2612 alerts in last 24 hours. There have also been a couple community requests for changes.
- reduced the scope of the alerts to only surface the "high" fidelity_score cases for `"multiple_ip_network_city"` or `"multiple_ip_network_city_user_agent"` criteria. This reduced telemetry by ~90%
- excluded 2 more benign service providers `support` which reduced volume by another 6%.
- added the `data_stream.namespace` field as requested.
- kept the rest of the rule logic visible so that if customers would like to broaden the scope of this rule again, they can duplicate the rules and revert back to the broader condition `Esql.activity_type != "normal_activity"`. This has been included as a comment in the rule query.
I will keep an eye on this rule in telemetry to determine it's value moving forward.
* nit IG format changes
Copy file name to clipboardExpand all lines: rules/integrations/aws/initial_access_iam_session_token_used_from_multiple_addresses.toml
+20-10Lines changed: 20 additions & 10 deletions
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
creation_date = "2025/04/11"
3
3
integration = ["aws"]
4
4
maturity = "production"
5
-
updated_date = "2025/09/02"
5
+
updated_date = "2025/12/04"
6
6
7
7
[rule]
8
8
author = ["Elastic"]
@@ -35,7 +35,7 @@ note = """## Triage and Analysis
35
35
36
36
Access tokens are bound to a single user. Usage from multiple IP addresses may indicate the token was stolen and used elsewhere. By correlating this with additional detection criteria like multiple user agents, different cities, and different networks, we can improve the fidelity of the rule and help to eliminate false positives associated with expected behavior, like dual-stack IPV4/IPV6 usage.
37
37
38
-
#### Possible Investigation Steps
38
+
#### Possible investigation steps
39
39
40
40
- **Identify the IAM User**: Examine the `aws.cloudtrail.user_identity.arn` stored in `user_id` and correlate with the `source.ips` stored in `ip_list` and `unique_ips` count to determine how widely the token was used.
41
41
- **Correlate Additional Detection Context**: Examine `activity_type` and `fidelity_score` to determine additional cities, networks or user agents associated with the token usage.
@@ -44,18 +44,18 @@ Access tokens are bound to a single user. Usage from multiple IP addresses may i
44
44
- **Review Workload Context**: Confirm whether the user was expected to be active across multiple cities, networks or user agent environments.
45
45
- **Trace Adversary Movement**: Pivot to related actions (e.g., `s3:ListBuckets`, `iam:ListUsers`, `sts:GetCallerIdentity`) to track further enumeration.
46
46
47
-
### False Positive Analysis
47
+
### False positive analysis
48
48
49
49
- Automation frameworks that rotate through multiple IPs or cloud functions with dynamic egress IPs may cause this alert to fire.
50
50
- Confirm geolocation and workload context before escalating.
51
51
52
-
### Response and Remediation
52
+
### Response and remediation
53
53
54
54
- **Revoke the Token**: Disable or rotate the IAM credentials and invalidate the temporary session token.
55
55
- **Audit the Environment**: Look for signs of lateral movement or data access during the token's validity.
56
56
- **Strengthen Controls**: Require MFA for high-privilege actions, restrict access via policy conditions (e.g., IP range or device).
0 commit comments