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 IAM SAML Provider Updated (#5284)
* [Rule Tuning] AWS IAM SAML Provider Updated
Rule is performing well in telemetry, low volume as expected. The only obvious false positives are from AWS SSO service so that internal behavior has been excluded from the rule.
- added AWS SSO exclusion to query
- updated description and IG
- added highlighted fields
* Update rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
Co-authored-by: Ruben Groenewoud <[email protected]>
---------
Co-authored-by: Ruben Groenewoud <[email protected]>
(cherry picked from commit 9925a39)
Copy file name to clipboardExpand all lines: rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
+94-33Lines changed: 94 additions & 33 deletions
Original file line number
Diff line number
Diff line change
@@ -2,19 +2,26 @@
2
2
creation_date = "2021/09/22"
3
3
integration = ["aws"]
4
4
maturity = "production"
5
-
updated_date = "2025/01/15"
5
+
updated_date = "2025/11/05"
6
6
7
7
[rule]
8
8
author = ["Elastic", "Austin Songer"]
9
-
description = "Identifies when a user has updated a SAML provider in AWS. SAML providers are used to enable federated access to the AWS Management Console. This activity could be an indication of an attacker attempting to escalate privileges."
9
+
description = """
10
+
Detects when an AWS IAM SAML provider is updated, which manages federated authentication between AWS and external
11
+
identity providers (IdPs). Adversaries with administrative access may modify a SAML provider’s metadata or certificate
12
+
to redirect authentication flows, enable unauthorized federation, or escalate privileges through identity trust
13
+
manipulation. Because SAML providers underpin single sign-on (SSO) access for users and applications, unauthorized
14
+
modifications may allow persistent or covert access even after credentials are revoked. Monitoring "UpdateSAMLProvider"
15
+
API activity is critical to detect potential compromise of federated trust relationships.
16
+
"""
10
17
false_positives = [
11
18
"""
12
19
SAML Provider could be updated by a system administrator. Verify whether the user identity, user agent, and/or
13
20
hostname should be making changes in your environment. SAML Provider updates by unfamiliar users should be
14
21
investigated. If known behavior is causing false positives, it can be exempted from the rule.
15
22
""",
16
23
]
17
-
from = "now-9m"
24
+
from = "now-6m"
18
25
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
19
26
language = "kuery"
20
27
license = "Elastic License v2"
@@ -26,40 +33,75 @@ note = """## Triage and analysis
26
33
27
34
### Investigating AWS IAM SAML Provider Updated
28
35
29
-
AWS IAM SAML providers facilitate federated access, allowing users to authenticate via external identity providers. Adversaries may exploit this by updating SAML providers to gain unauthorized access or escalate privileges. The detection rule monitors successful updates to SAML providers, flagging potential privilege escalation attempts by correlating specific AWS CloudTrail events.
36
+
AWS IAM SAML providers enable federated authentication between AWS and external identity providers (IdPs),
37
+
allowing users from trusted domains to access AWS resources without separate credentials.
38
+
Updating a SAML provider can modify the trust relationship — including the signing certificate or metadata document —
39
+
and, if abused, may allow an attacker to redirect authentication flows or gain access through a malicious or compromised IdP.
40
+
41
+
This rule detects successful `UpdateSAMLProvider` API calls that do not originate from AWS Single Sign-On (SSO),
42
+
as normal SSO operations are filtered out. These changes can be significant because a single unauthorized update
43
+
can affect all federated authentication in the account.
30
44
31
45
### Possible investigation steps
32
46
33
-
- Review the AWS CloudTrail logs to identify the user or role associated with the UpdateSAMLProvider event. Check for any unusual or unauthorized users making changes.
34
-
- Examine the context of the UpdateSAMLProvider event, including the time of the event and any associated IP addresses or locations, to identify any anomalies or suspicious patterns.
35
-
- Investigate the history of changes to the specific SAML provider to determine if there have been any recent unauthorized or unexpected modifications.
36
-
- Check for any other related AWS CloudTrail events around the same timeframe, such as changes to IAM roles or policies, which might indicate a broader privilege escalation attempt.
37
-
- Assess the permissions and access levels of the user or role that performed the update to ensure they align with expected privileges and responsibilities.
38
-
- If suspicious activity is confirmed, consider revoking or limiting access for the involved user or role and review the security posture of the AWS environment to prevent future incidents.
47
+
- **Validate the actor and context**
48
+
- Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `user_agent.original` to determine who performed the update.
49
+
- Confirm if the actor is part of an authorized identity management or platform engineering group.
50
+
- Review `source.ip` and `cloud.region` fields for unexpected geolocations, IP ranges, or service origins.
39
51
40
-
### False positive analysis
52
+
- **Assess the scope of the modification**
53
+
- Parse the `aws.cloudtrail.request_parameters` for updates to `SAMLMetadataDocument` or `Certificate` attributes.
54
+
- Compare the new metadata with previous versions (available via AWS CLI or AWS Config) to detect unauthorized IdP URLs,
55
+
certificates, or assertion endpoints.
56
+
- Identify whether the change replaced a valid trusted certificate with an unknown or self-signed one.
41
57
42
-
- Routine administrative updates to SAML providers by authorized personnel can trigger alerts. To manage this, maintain a list of known administrators and their expected activities, and create exceptions for these users in the detection rule.
43
-
- Scheduled updates or maintenance activities involving SAML providers may also result in false positives. Document these activities and adjust the detection rule to exclude events occurring during these scheduled times.
44
-
- Automated scripts or tools used for managing SAML providers can generate alerts if they perform updates. Identify these scripts and their expected behavior, then configure the detection rule to recognize and exclude these specific actions.
45
-
- Changes made by trusted third-party services integrated with AWS IAM might be flagged. Verify the legitimacy of these services and consider adding them to an allowlist to prevent unnecessary alerts.
58
+
- **Correlate related IAM and authentication events**
59
+
- Look for preceding `CreateSAMLProvider` or `DeleteSAMLProvider` activity, as attackers may replace existing trust entities.
60
+
- Search for follow-up logins (`AssumeRoleWithSAML`) or STS tokens issued shortly after the update — this could indicate
61
+
immediate exploitation of the new configuration.
62
+
- Check for concurrent changes to IAM roles associated with SAML federated access.
46
63
47
-
### Response and remediation
64
+
- **Confirm authorization**
65
+
- Coordinate with your identity management team to confirm whether the SAML provider update aligns with
66
+
planned IdP maintenance or certificate rotation.
48
67
49
-
- Immediately revoke any unauthorized changes to the SAML provider by restoring the previous configuration from backups or logs.
50
-
- Conduct a thorough review of recent IAM activity logs to identify any unauthorized access or privilege escalation attempts associated with the updated SAML provider.
51
-
- Temporarily disable the affected SAML provider to prevent further unauthorized access while the investigation is ongoing.
52
-
- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
53
-
- Implement additional monitoring and alerting for any future changes to SAML providers to ensure rapid detection of unauthorized modifications.
54
-
- Review and tighten IAM policies and permissions to ensure that only authorized personnel can update SAML providers.
55
-
- Consider implementing multi-factor authentication (MFA) for all users with permissions to modify IAM configurations to enhance security.
68
+
### False positive analysis
56
69
57
-
## Setup
70
+
- **Planned SSO certificate rotation**
71
+
- Most legitimate SAML provider updates occur during routine certificate renewals by authorized IdP admins.
72
+
Validate that the update timing aligns with planned identity provider operations.
73
+
- **Automated infrastructure processes**
74
+
- CI/CD or configuration-as-code pipelines may automatically update SAML metadata as part of deployment.
75
+
Verify whether this activity matches known automation patterns.
76
+
- **Third-party IdP integrations**
77
+
- Some integrated SaaS applications update SAML providers programmatically. Confirm the vendor and the originating credentials before closing as benign.
58
78
59
-
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
0 commit comments