nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_user.toml

@@ -0,0 +1,180 @@
+[metadata]
+creation_date = "2024/05/30"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/10/13"
+
+[rule]
+author = ["Elastic"]
+description = """
+An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching
+additional permissions to compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation
+to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user.
+"""
+false_positives = [
+    """
+    While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity
+    should be using the IAM `AttachUserPolicy` API operation to attach the `AdministratorAccess` policy to the target
+    user.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "AWS IAM AdministratorAccess Policy Attached to User"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating AWS IAM AdministratorAccess Policy Attached to User
+
+The AWS-managed `AdministratorAccess` policy grants full access to all AWS services and resources.  
+When attached to a user, it effectively elevates that user to full administrative privileges.  
+An adversary with `iam:AttachUserPolicy` permissions can abuse this operation to escalate privileges or maintain persistence.  
+This rule detects `AttachUserPolicy` events where the attached policy name is `AdministratorAccess`.
+
+#### Possible investigation steps
+
+- **Validate intent and context.**  
+  Identify the calling user (`aws.cloudtrail.user_identity.arn`) and the target IAM user (`aws.cloudtrail.request_parameters.userName`).  
+  Confirm whether this was an intentional administrative action, part of provisioning automation, or a potential privilege escalation.  
+
+- **Review CloudTrail event details.**  
+  Check `source.ip`, `user_agent.original`, and `source.geo` fields.  
+  Compare to historical login or automation behavior. Unrecognized IPs, non-SDK user agents, or new regions may indicate misuse.  
+
+- **Correlate with related IAM activity.**  
+  Search CloudTrail for additional IAM events around the same time (`CreateUser`, `CreateAccessKey`, `AttachGroupPolicy`, `PutUserPolicy`, etc.) that could indicate lateral movement or persistence attempts.  
+
+- **Review the target user’s permissions.**  
+  Determine if the target user already had elevated privileges or if this represents a meaningful privilege increase.  
+  Check for new API calls from the target user post-attachment, especially `CreateAccessKey`, `UpdateAssumeRolePolicy`, or S3 access attempts.  
+
+- **Investigate associated entities.**  
+  Look for other alerts tied to the same caller or target within the past 48 hours to identify potential correlated activity.  
+
+### False positive analysis
+
+- **Legitimate administrative change.**  
+  Policy attachments may be expected during provisioning or troubleshooting. Validate through change management records.  
+- **Authorized automation.**  
+  Some CI/CD pipelines or identity automation systems temporarily attach this policy. Review automation logs and intended IAM behavior.  
+- **Delegated admin scenarios.**  
+  Verify if the calling user or role is part of a delegated IAM administration group.
+
+### Response and remediation
+
+> Per AWS IR Playbooks, unauthorized administrative policy attachment represents a Privilege Escalation event.
+
+**1. Immediate containment**
+- Detach the policy. Remove the `AdministratorAccess` policy from the affected IAM user immediately (`aws iam detach-user-policy`).  
+- Rotate credentials. Rotate passwords and access keys for both the caller and target users.  
+- Restrict IAM permissions. Temporarily remove `iam:AttachUserPolicy` privileges from non-administrative roles during scoping.  
+- Enable or confirm MFA for affected accounts.  
+
+**2. Evidence preservation**
+- Export related `AttachUserPolicy` CloudTrail events ±30 minutes from the alert to a secure evidence bucket.  
+- Preserve GuardDuty findings and AWS Config snapshots for correlation.  
+
+**3. Scoping and investigation**
+- Search CloudTrail for subsequent use of the affected user’s credentials.  
+  Look for newly created keys, S3 access, or changes to IAM trust policies.  
+- Review other accounts for similar policy attachment attempts from the same user or IP.  
+
+**4. Recovery and hardening**
+- Reinforce least privilege by granting only role-based admin access instead of direct user-level AdministratorAccess.  
+- Implement IAM service control policies (SCPs) to prevent attachment of `AdministratorAccess` except for trusted roles.  
+- Enable CloudTrail, GuardDuty, and Security Hub across all regions.  
+- Regularly audit IAM policy attachments through AWS Config or CloudFormation drift detection.  
+
+### Additional information
+
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/): response steps related to IAM policy modification and unauthorized privilege escalation.  
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/):** for containment, analysis, and recovery guidance.  
+- **AWS Documentation:** [AdministratorAccess Policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator).  
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).  
+"""
+references = [
+    "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html",
+    "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html",
+    "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/",
+]
+risk_score = 47
+rule_id = "9aa4be8d-5828-417d-9f54-7cd304571b24"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS IAM",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Privilege Escalation",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+iam where event.dataset == "aws.cloudtrail"
+   and event.provider == "iam.amazonaws.com"
+   and event.action == "AttachUserPolicy"
+   and event.outcome == "success"
+   and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+[[rule.threat.technique.subtechnique]]
+id = "T1098.003"
+name = "Additional Cloud Roles"
+reference = "https://attack.mitre.org/techniques/T1098/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+[[rule.threat.technique.subtechnique]]
+id = "T1098.003"
+name = "Additional Cloud Roles"
+reference = "https://attack.mitre.org/techniques/T1098/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "event.action",
+    "user.target.name",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+]
+

nldcsc_elastic_rules/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml

@@ -0,0 +1,140 @@
+[metadata]
+creation_date = "2024/11/04"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/10/17"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or
+unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting
+specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging
+cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized
+access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the
+AWS environment. This is a New Terms rule that uses the "cloud.account.id", "user.name" and "target.entity.id" fields to
+check if the combination of the actor identity and target role name has not been seen before.
+"""
+false_positives = [
+    """
+    Legitimate IAM administrators may attach customer-managed policies to roles for various reasons, such as granting
+    temporary permissions or updating existing policies. Ensure that the user attaching the policy is authorized to do
+    so and that the action is expected.
+    """,
+]
+from = "now-6m"
+index = ["logs-aws.cloudtrail-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS IAM Customer-Managed Policy Attached to Role by Rare User"
+note = """## Triage and analysis
+
+### Investigating AWS IAM Customer-Managed Policy Attached to Role by Rare User
+
+This rule detects when a customer-managed IAM policy is attached to a role by an unusual or unauthorized user. This activity may indicate a potential privilege escalation attempt within the AWS environment. Adversaries could attach policies to roles to expand permissions, thereby increasing their capabilities and achieving elevated access.
+
+#### Possible Investigation Steps
+
+- **Identify the Initiating User and Target Role**:
+  - **User Identity**: Examine the `aws.cloudtrail.user_identity.arn` field to determine the user who initiated the policy attachment. Confirm if this user typically has permissions to modify IAM roles and if their activity is consistent with their usual responsibilities.
+  - **Target Role**: Review `target.entity.id` to identify the role to which the policy was attached. Assess whether modifying this role is expected for this user or if this action is unusual in your environment.
+
+- **Analyze the Attached Policy**:
+  - **Policy ARN**: Inspect the `aws.cloudtrail.request_parameters` field to identify the specific customer-managed policy attached to the role. Evaluate if this policy grants sensitive permissions, especially permissions that could enable privileged actions or data access.
+  - **Policy Permissions**: Examine the policy content to determine the scope of permissions granted. Policies enabling actions like `s3:*`, `ec2:*`, or `iam:*` could be leveraged for broader access, persistence, or lateral movement.
+
+- **Review Source and User Agent Details**:
+  - **Source IP and Location**: Analyze the `source.ip` and `source.geo` fields to confirm the IP address and geographic location where the policy attachment originated. Verify if this matches expected locations for the initiating user.
+  - **User Agent Analysis**: Examine `user_agent.original` to determine if AWS CLI, SDK, or other tooling was used to perform this action. Tool identifiers like `aws-cli` or `boto3` may indicate automation, while others may suggest interactive sessions.
+
+- **Evaluate Anomalous Behavior Patterns**:
+  - **User’s Historical Activity**: Check if the initiating user has a history of attaching policies to roles. An unusual pattern in policy attachments could indicate suspicious behavior, especially if the user lacks authorization.
+  - **Role Modification History**: Investigate if the targeted role is frequently modified by this or other users. Repeated, unauthorized modifications to a role could signal an attempt to maintain elevated access.
+
+- **Correlate with Related CloudTrail Events**:
+  - **Other IAM or CloudTrail Activities**: Look for recent actions associated with the same user or role by reviewing `event.action` and `event.provider` to identify which AWS services were accessed. This may provide context on the user’s intent or additional actions taken.
+  - **Broader Suspicious Patterns**: Identify if similar anomalous events have recently occurred, potentially suggesting a coordinated or escalating attack pattern within the AWS account.
+
+### False Positive Analysis
+
+- **Authorized Administrative Actions**: IAM administrators may legitimately attach policies to roles as part of routine role management. Verify if the user is authorized and if the activity aligns with expected administrative tasks.
+- **Role-Specific Modifications**: Roles that frequently undergo policy updates may trigger this rule during standard operations. Consider monitoring for patterns or establishing known exceptions for specific users or roles where appropriate.
+
+### Response and Remediation
+
+- **Immediate Access Review**: If the policy attachment is unauthorized, consider detaching the policy and reviewing the permissions granted to the initiating user.
+- **Restrict Role Modification Permissions**: Limit which users or roles can attach policies to critical IAM roles. Apply least privilege principles to reduce the risk of unauthorized policy changes.
+- **Enhance Monitoring and Alerts**: Enable real-time alerts and monitoring on IAM policy modifications to detect similar actions promptly.
+- **Regular Policy Audits**: Conduct periodic audits of IAM policies and role permissions to ensure that unauthorized changes are quickly identified and addressed.
+
+### Additional Information
+
+For more information on managing IAM policies and roles in AWS environments, refer to the [AWS IAM Documentation](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) and AWS security best practices.
+"""
+references = ["https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html"]
+risk_score = 21
+rule_id = "f6d07a70-9ad0-11ef-954f-f661ea17fbcd"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS IAM",
+    "Resources: Investigation Guide",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Privilege Escalation",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: "aws.cloudtrail"
+    and event.provider: "iam.amazonaws.com"
+    and event.action: "AttachRolePolicy"
+    and event.outcome: "success"
+    and not related.entity: arn\:aws\:iam\:\:aws\:policy*
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1548"
+name = "Abuse Elevation Control Mechanism"
+reference = "https://attack.mitre.org/techniques/T1548/"
+[[rule.threat.technique.subtechnique]]
+id = "T1548.005"
+name = "Temporary Elevated Cloud Access"
+reference = "https://attack.mitre.org/techniques/T1548/005/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+]
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["cloud.account.id", "user.name", "target.entity.id"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"
+
+

nldcsc_elastic_rules/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml

@@ -0,0 +1,163 @@
+[metadata]
+creation_date = "2021/09/22"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/11/05"
+
+[rule]
+author = ["Elastic", "Austin Songer"]
+description = """
+Detects when an AWS IAM SAML provider is updated, which manages federated authentication between AWS and external
+identity providers (IdPs). Adversaries with administrative access may modify a SAML provider’s metadata or certificate
+to redirect authentication flows, enable unauthorized federation, or escalate privileges through identity trust
+manipulation. Because SAML providers underpin single sign-on (SSO) access for users and applications, unauthorized
+modifications may allow persistent or covert access even after credentials are revoked. Monitoring  "UpdateSAMLProvider"
+API activity is critical to detect potential compromise of federated trust relationships.
+"""
+false_positives = [
+    """
+    SAML Provider could be updated by a system administrator. Verify whether the user identity, user agent, and/or
+    hostname should be making changes in your environment. SAML Provider updates by unfamiliar users should be
+    investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS IAM SAML Provider Updated"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating AWS IAM SAML Provider Updated
+
+AWS IAM SAML providers enable federated authentication between AWS and external identity providers (IdPs), 
+allowing users from trusted domains to access AWS resources without separate credentials. 
+Updating a SAML provider can modify the trust relationship — including the signing certificate or metadata document — 
+and, if abused, may allow an attacker to redirect authentication flows or gain access through a malicious or compromised IdP.
+
+This rule detects successful `UpdateSAMLProvider` API calls that do not originate from AWS Single Sign-On (SSO), 
+as normal SSO operations are filtered out. These changes can be significant because a single unauthorized update 
+can affect all federated authentication in the account.
+
+### Possible investigation steps
+
+- **Validate the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `user_agent.original` to determine who performed the update.
+  - Confirm if the actor is part of an authorized identity management or platform engineering group.
+  - Review `source.ip` and `cloud.region` fields for unexpected geolocations, IP ranges, or service origins.
+
+- **Assess the scope of the modification**
+  - Parse the `aws.cloudtrail.request_parameters` for updates to `SAMLMetadataDocument` or `Certificate` attributes.
+  - Compare the new metadata with previous versions (available via AWS CLI or AWS Config) to detect unauthorized IdP URLs, 
+    certificates, or assertion endpoints.
+  - Identify whether the change replaced a valid trusted certificate with an unknown or self-signed one.
+
+- **Correlate related IAM and authentication events**
+  - Look for preceding `CreateSAMLProvider` or `DeleteSAMLProvider` activity, as attackers may replace existing trust entities.
+  - Search for follow-up logins (`AssumeRoleWithSAML`) or STS tokens issued shortly after the update — this could indicate 
+    immediate exploitation of the new configuration.
+  - Check for concurrent changes to IAM roles associated with SAML federated access.
+
+- **Confirm authorization**
+  - Coordinate with your identity management team to confirm whether the SAML provider update aligns with 
+    planned IdP maintenance or certificate rotation.
+
+### False positive analysis
+
+- **Planned SSO certificate rotation**
+  - Most legitimate SAML provider updates occur during routine certificate renewals by authorized IdP admins. 
+    Validate that the update timing aligns with planned identity provider operations.
+- **Automated infrastructure processes**
+  - CI/CD or configuration-as-code pipelines may automatically update SAML metadata as part of deployment. 
+    Verify whether this activity matches known automation patterns.
+- **Third-party IdP integrations**
+  - Some integrated SaaS applications update SAML providers programmatically. Confirm the vendor and the originating credentials before closing as benign.
+
+### Response and remediation
+
+- **Immediate review and containment**
+  - Retrieve the current SAML provider configuration using the AWS CLI (`aws iam get-saml-provider`) 
+    and compare it with the previous known-good state.
+  - If unauthorized changes are confirmed, restore the previous configuration or delete the compromised provider.
+  - Temporarily disable federated login access for affected roles or accounts until validation is complete.
+
+- **Investigation and scoping**
+  - Review CloudTrail logs for related IAM configuration changes, including `CreateRole`, `AttachRolePolicy`, or 
+    `UpdateAssumeRolePolicy` events that may expand federated trust scope.
+  - Identify any `AssumeRoleWithSAML` or `GetFederationToken` events following the update, indicating possible exploitation.
+  - Cross-check logs from your external IdP to verify if unauthorized assertions or logins were attempted post-update.
+
+- **Recovery and hardening**
+  - Limit permissions to modify SAML providers (`iam:UpdateSAMLProvider`) to a dedicated identity management role.
+  - Enforce change control documentation and peer review for all federation configuration changes.
+  - Enable AWS Config to monitor and record SAML provider resource configuration history.
+
+### Additional information
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
+
+"""
+references = ["https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html"]
+risk_score = 47
+rule_id = "979729e7-0c52-4c4c-b71e-88103304a79f"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS IAM",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: "aws.cloudtrail"
+    and event.provider: "iam.amazonaws.com"
+    and event.action: "UpdateSAMLProvider"
+    and event.outcome: "success"
+    and not (source.address: "sso.amazonaws.com" and user_agent.original: "sso.amazonaws.com")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1484"
+name = "Domain or Tenant Policy Modification"
+reference = "https://attack.mitre.org/techniques/T1484/"
+[[rule.threat.technique.subtechnique]]
+id = "T1484.002"
+name = "Trust Modification"
+reference = "https://attack.mitre.org/techniques/T1484/002/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+

nldcsc_elastic_rules/rules/integrations/aws/privilege_escalation_iam_update_assume_role_policy.toml

@@ -0,0 +1,139 @@
+[metadata]
+creation_date = "2020/07/06"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/10/17"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies AWS CloudTrail events where an IAM role's trust policy has been updated by an IAM user or Assumed Role
+identity. The trust policy is a JSON document that defines which principals are allowed to assume the role. An attacker
+may attempt to modify this policy to gain the privileges of the role. This is a New Terms rule, which means it will only
+trigger once for each unique combination of the "cloud.account.id", "user.name" and "target.entity.id" fields, that have
+not been seen making this API request.
+"""
+false_positives = [
+    """
+    Verify whether the user identity should be making changes in your environment. Policy updates from unfamiliar users
+    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+interval = "5m"
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS IAM Assume Role Policy Update"
+note = """## Triage and analysis
+
+### Investigating AWS IAM Assume Role Policy Update
+
+An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.
+
+The role trust policy is a JSON document in which you define the principals you trust to assume the role. This policy is a required resource-based policy that is attached to a role in IAM. An attacker may attempt to modify this policy by using the `UpdateAssumeRolePolicy` API action to gain the privileges of that role.
+
+#### Possible investigation steps
+
+- Review the `aws.cloudtrail.user_identity.arn` to determine the IAM User that performed the action. 
+- If an AssumedRole identity type performed the action review the `aws.cloudtrail.user_identity.session_context.session_issuer.arn` field to determine which role was used.
+- Review the `target.entity.id` field to confirm the role that was updated.
+- Within the `aws.cloudtrail.request_parameters` field, review the `policyDocument` to understand the changes made to the trust policy.
+- If `aws.cloudtrail.user_identity.access_key_id` is present, investigate the access key used to perform the action as it may be compromised.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Investigate other alerts associated with the user account during the past 48 hours.
+- Contact the account and resource owners and confirm whether they are aware of this activity.
+- Check if this operation was approved and performed according to the organization's change management policy.
+- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+
+### False positive analysis
+
+- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher confidence. Consider adding exceptions — preferably with a combination of the user agent and user ID conditions — to cover administrator activities and infrastructure as code tooling.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Disable or limit the account during the investigation and response.
+- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
+    - Identify the account role in the cloud environment.
+    - Assess the criticality of affected services and servers.
+    - Work with your IT team to identify and minimize the impact on users.
+    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
+    - Identify any regulatory or legal ramifications related to this activity.
+- Use AWS [policy versioning](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html) to restore the trust policy to the desired state.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
+- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
+- Consider enabling multi-factor authentication for users.
+- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
+- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+"""
+references = ["https://labs.bishopfox.com/tech-blog/5-privesc-attack-vectors-in-aws"]
+risk_score = 21
+rule_id = "a60326d7-dca7-4fb7-93eb-1ca03a1febbd"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS IAM",
+    "Use Case: Identity and Access Audit",
+    "Resources: Investigation Guide",
+    "Tactic: Privilege Escalation",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: "aws.cloudtrail"
+    and event.provider: "iam.amazonaws.com"
+    and event.action: "UpdateAssumeRolePolicy"
+    and event.outcome: "success"
+    and not source.address: "cloudformation.amazonaws.com"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.004"
+name = "Cloud Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+]
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["cloud.account.id", "user.name", "target.entity.id"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"
+
+