From 776d748a11d11f2c0e974e68c9e3adc77dcb3d9f Mon Sep 17 00:00:00 2001
From: Isai <59296946+imays11@users.noreply.github.com>
Date: Thu, 30 Oct 2025 13:49:49 -0400
Subject: [PATCH 1/4] [Rule Tuning][New Rule] AWS S3 Bucket Policy Added to
 Share with External Account/ to Allow Public Access

AWS S3 Bucket Policy Added to Share with External Account
Low telemetry volume overall, however false positives were seen for cloudfront identity and service accounts being given access to a bucket
- Reduced the scope of this rule to only analyze policy that include account ids or account ARNs (which include an account ID). This eliminates the false positives triggered by sharing buckets with a service account (i.e. cloudtrail.amazonaws.com)
- Excluded cloudfront identity, which should be treated the same way service accounts are being treated and be excluded as they do not include account IDs in their ARN
- This rule wasn't explicitly capturing the use of `Principal: *` which is a public sharing method, often accompanied by a Condition statement (i.e. aws.SourceAccount =  OR aws.PrincipalAccount= OR ip.address = ....). The new query will capture Condition statements that include an account id. However there is still a gap for Policies that have explicit `Principal:*` with or without a condition, so another rule was created that will account for these scenarios.
- added highlighted fields
- updated investigation guide and description
- updated Mitre tactics and tags
- `event.type` used in place of `event.category` field

### AWS S3 Bucket Policy Added to Allow Public Access
Rule added to cover gap in public bucket policy added which includes an `Effect=Allow` and `Principal: *`. While an additional condition might be added to this policy which would exclude public access, cases where the condition is not included mean the bucket is publicly accessible. Both cases need to be verified, because even the condition could be giving access to an attacker owned account. There is also the chance that an `Effect=Deny` for `Principal:*` will trigger a false positive for this rule if the same policy also includes an `Effect=Allow` statement. We call this out in the description, false positive and investigation guide sections of the rule.
---
 ...icy_added_for_external_account_access.toml | 179 +++++++++++++----
 ...bucket_policy_added_for_public_access.toml | 188 ++++++++++++++++++
 2 files changed, 323 insertions(+), 44 deletions(-)
 create mode 100644 rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml

diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
index 1fc310523c8..16ee579b23c 100644
--- a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
+++ b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
@@ -2,58 +2,115 @@
 creation_date = "2024/04/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/17"
+updated_date = "2025/10/30"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies an AWS S3 bucket policy change to share permissions with an external account. Adversaries may attempt to
-backdoor an S3 bucket by sharing it with an external account. This can be used to exfiltrate data or to provide access
-to other adversaries. This rule identifies changes to a bucket policy via the `PutBucketPolicy` API call where the
-policy includes an `Effect=Allow` statement that does not contain the AWS account ID of the bucket owner.
+Detects when an Amazon S3 bucket policy is modified to share access with an external AWS account. This rule analyzes
+PutBucketPolicy events and compares the S3 bucket’s account ID to any account IDs referenced in the policy’s
+Effect=Allow statements. If the policy includes principals from accounts other than the bucket owner’s, the rule
+triggers an alert. This behavior may indicate an adversary backdooring a bucket for data exfiltration or cross-account
+persistence. For example, an attacker who compromises credentials could attach a policy allowing access from an external
+AWS account they control, enabling continued access even after credentials are rotated. Note: This rule will not alert
+if the account ID is part of the bucket’s name or appears in the resource ARN. Such cases are common in standardized
+naming conventions (e.g., “mybucket-123456789012”). To ensure full coverage, use complementary rules to monitor for
+suspicious PutBucketPolicy API requests targeting buckets with account IDs embedded in their names or resources.
 """
+event_category_override = "event.type"
 false_positives = [
     """
-    Legitimate changes to share an S3 bucket with an external account may be identified as false positive but are not
-    best practice.
+    Legitimate changes to share an S3 bucket with an external account may be identified as false positives.
     """,
 ]
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Policy Added to Share with External Account"
-note = """
-## Triage and analysis
+note = """## Triage and analysis
 
-### Investigating AWS S3 Bucket Policy Added to Share with External Account
-
-This rule detects when an AWS S3 bucket policy is changed to share permissions with an external account. Adversaries may attempt to backdoor an S3 bucket by sharing it with an external account to exfiltrate data or provide access to other adversaries. This rule identifies changes to a bucket policy via the `PutBucketPolicy` API call where the policy includes an `Effect=Allow` statement that does not contain the AWS account ID of the bucket owner.
-
-#### Possible Investigation Steps:
-
-- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.
-- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the bucket policy. Look for any unusual parameters that could suggest unauthorized or malicious modifications.
-- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.
-- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny.
-- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
-
-### False Positive 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.
 
-- **Legitimate Administrative Actions**: Confirm if the bucket policy change aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.
-- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
-- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy.
-
-### Response and Remediation:
-
-- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the bucket policy to remove any unauthorized permissions and restore it to its previous state.
-- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
-- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning bucket policy management and sharing permissions.
-- **Audit Bucket Policies and Permissions**: Conduct a comprehensive audit of all bucket policies and associated permissions to ensure they adhere to the principle of least privilege.
-- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
-
-### Additional Information:
+### Investigating AWS S3 Bucket Policy Added to Share with External Account
 
-For further guidance on managing S3 bucket policies and securing AWS environments, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) and AWS best practices for security.
+This rule detects when an S3 bucket policy is modified using the `PutBucketPolicy` API call to include an external AWS account ID.
+It compares the bucket’s `recipient_account_id` to any account IDs included in the policy’s `Effect=Allow` statement, triggering
+an alert if the two do not match.  
+
+Adversaries may exploit this to backdoor a bucket and exfiltrate sensitive data by granting permissions to another AWS account
+they control, enabling ongoing access to the bucket’s contents even if IAM credentials are rotated or revoked.
+
+This detection specifically focuses on policy-based sharing and does not alert when:
+- The account ID appears within the bucket or object name being shared.
+- The account owner explicitly matches the policy’s condition keys on something other than an ARN or account id (i.e. IP address).
+  
+To fully monitor for suspicious sharing behavior, use this rule in combination with detections for:
+- Unusual PutBucketPolicy requests
+- Cross-account object access (e.g., `GetObject`, `PutObject`)
+- Changes to bucket ACLs or access points
+
+#### Possible investigation steps
+
+- **Identify the Actor and Context**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change.
+  - Determine if the identity typically manages S3 bucket policies.  
+  - Examine `aws.cloudtrail.resources.arn` to determine which bucket is being shared.
+
+- **Analyze the Policy Change**
+  - Review `aws.cloudtrail.request_parameters` to extract the policy JSON and identify the external AWS account ID(s) referenced.  
+  - Check for `Effect=Allow` statements granting broad permissions such as `"Action": "s3:*"` or `"Resource": "*"`.  
+  - Verify if the added principals correspond to known partners or external vendors.
+  - If AWS account ID(s) were only part of `Effect=Deny` statements, then this rule can be closed as a false positive. 
+
+- **Review Context and Source**
+  - Check `source.ip`, `source.geo`, and `user_agent.original` for anomalies — such as new IP ranges, access from unfamiliar geographies, or use of programmatic clients (`boto3`, `aws-cli`).
+
+- **Correlate with Related Activity**
+  - Search CloudTrail for subsequent activity by the external AWS account ID(s):
+    - `GetObject`, `ListBucket`, or `PutObject` events that indicate data access or exfiltration.
+  - Look for additional configuration changes by the same actor, such as:
+    - `PutBucketAcl`, `PutBucketVersioning`, or `PutBucketReplication` — often part of a larger bucket compromise chain.
+  - Determine if multiple buckets were modified in quick succession.
+
+- **Validate Intent**
+  - Review internal change requests or documentation to confirm whether this external sharing was approved.  
+  - If no approval exists, escalate immediately for potential compromise.
+
+### False positive analysis
+
+- **Authorized Cross-Account Access**
+  - Some organizations legitimately share S3 buckets across accounts within a trusted AWS Organization or partner accounts.  
+  - Validate whether the external account ID belongs to a known entity or service provider and is documented in your allowlist.
+- **Automation or Deployment Pipelines**
+  - Continuous integration/deployment pipelines may temporarily attach cross-account policies for replication or staging.  
+  - Verify the `user_agent.original` or role name — automation often includes identifiable strings.
+- **Naming and Rule Logic Limitations**
+  - This rule excludes detections where the account ID appears in the bucket resource ARN (e.g., `mybucket-123456789012`).  
+  - Such patterns are common in automated provisioning. For those scenarios, rely on complementary rules that directly monitor `PutBucketPolicy` events against those buckets.
+
+### Response and remediation
+
+- **Immediate Review and Containment**
+  - If unauthorized sharing is confirmed, use the AWS CLI or Console to delete or revert the modified policy (`aws s3api delete-bucket-policy` or restore from version control).  
+  - Remove external principals and reapply the correct bucket policy.  
+  - Rotate access keys for the actor involved, especially if API access came from unexpected locations or tools.
+
+- **Investigation and Scoping**
+  - Identify whether data was accessed by the external account via `GetObject` or `ListBucket` operations.  
+  - Search CloudTrail logs for other buckets modified by the same actor or IP within the same timeframe.
+  - Use AWS Config to review version history of affected bucket policies and detect similar cross-account permissions.
+
+- **Recovery and Hardening**
+  - Restrict `s3:PutBucketPolicy` to a limited set of administrative roles using least privilege.
+  - Enable AWS Config rule `s3-bucket-policy-grantee-check` to monitor for unauthorized policy additions.
+  - Use AWS GuardDuty or Security Hub findings to correlate policy changes with data exfiltration or credential compromise events.
+  - Apply service control policies (SCPs) to block cross-account sharing unless explicitly approved.
+
+### 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://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/",
@@ -61,11 +118,6 @@ references = [
 ]
 risk_score = 47
 rule_id = "e8c9ff14-fd1e-11ee-a0df-f661ea17fbce"
-setup = """
-## Setup
-
-S3 data event types must be collected in the AWS CloudTrail logs. Please refer to [AWS documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) for more information.
-"""
 severity = "medium"
 tags = [
     "Domain: Cloud",
@@ -74,17 +126,25 @@ tags = [
     "Data Source: AWS S3",
     "Use Case: Threat Detection",
     "Tactic: Exfiltration",
+    "Tactic: Collection",
     "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail"
+info where event.dataset == "aws.cloudtrail"
     and event.provider == "s3.amazonaws.com"
-    and event.action == "PutBucketPolicy" and event.outcome == "success"
+    and event.action == "PutBucketPolicy" 
     and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow")
-    and not stringContains(aws.cloudtrail.request_parameters, aws.cloudtrail.recipient_account_id)
+    and (
+        stringContains(aws.cloudtrail.request_parameters, "AWS=") or 
+        stringContains(aws.cloudtrail.request_parameters, "aws:PrincipalAccount=") or
+        stringContains(aws.cloudtrail.request_parameters, "aws:SourceAccount=")
+        )
+and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:cloudfront::")  
+and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:iam::cloudfront:user")
+and not stringContains(aws.cloudtrail.request_parameters, aws.cloudtrail.recipient_account_id)
 '''
 
 
@@ -100,4 +160,35 @@ reference = "https://attack.mitre.org/techniques/T1537/"
 id = "TA0010"
 name = "Exfiltration"
 reference = "https://attack.mitre.org/tactics/TA0010/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1530"
+name = "Data from Cloud Storage"
+reference = "https://attack.mitre.org/techniques/T1530/"
+
+
+[rule.threat.tactic]
+id = "TA0009"
+name = "Collection"
+reference = "https://attack.mitre.org/tactics/TA0009/"
+
+[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",
+    "aws.cloudtrail.resources.arn",
+    "aws.cloudtrail.resources.type",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
 
diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml
new file mode 100644
index 00000000000..c73cfed81b3
--- /dev/null
+++ b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml
@@ -0,0 +1,188 @@
+[metadata]
+creation_date = "2025/10/30"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/10/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"*") statement.
+This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"*" in the request parameters,
+indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly
+accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments.
+Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect
+credentials and logs left in open storage.
+"""
+event_category_override = "event.type"
+false_positives = [
+    """
+    This rule does not differentiate by itself whether the same policy also includes Deny statements that restrict
+    public access. If a policy includes both Effect=Allow and Effect=Deny with Principal:"*", this rule may still
+    trigger. Such cases should be manually analyzed to verify whether the Deny statement effectively negates the public
+    exposure.
+    """,
+]
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "AWS S3 Bucket Policy Added to Allow Public Access"
+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 your specific environment and operational needs.
+
+### Investigating AWS S3 Bucket Policy Added to Allow Public Access
+
+This rule detects modifications to Amazon S3 bucket policies using the `PutBucketPolicy` API where both `Effect=Allow`
+and `Principal:"*"` are present. This effectively grants permissions to all AWS identities, including unauthenticated users.  
+Such exposure can result in sensitive data leaks, ransomware staging, or unauthorized data collection.  
+
+This rule focuses on policy-based exposure rather than ACL-based or block-public-access configurations.  
+It will still trigger if a bucket policy includes both `Effect=Allow` and `Effect=Deny` statements that contain `Principal:"*"`. Those cases should be reviewed to confirm whether the `Deny` statement restricts access sufficiently.
+
+#### Possible investigation steps
+
+- **Identify the Actor**
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change.
+  - Validate whether this user or role is authorized to modify S3 bucket policies.
+  - Examine `source.ip`, `source.geo`, and `user_agent.original` to identify unusual sources or tools (e.g., CLI or SDK-based activity).
+
+- **Analyze the Bucket Policy Content**
+  - Extract the full JSON from `aws.cloudtrail.request_parameters`.
+  - Look for `Effect=Allow` statements paired with `Principal:"*"`.
+  - Identify what permissions were granted — for example:
+    - `s3:GetObject` (read access to all objects)
+    - `s3:PutObject` or `s3:*` (read/write access)
+  - Check if the policy also contains any `Effect=Deny` statements targeting `Principal:"*"`.  
+    If present, determine whether these statements fully restrict public access, if so this alert can be closed.
+
+- **Assess the Impact and Scope**
+  - Review `aws.cloudtrail.resources.arn` to confirm which bucket was affected.
+  - Determine if the bucket contains sensitive, regulated, or internal data.
+  - Check for `PutPublicAccessBlock` or `DeleteBucketPolicy` events in close proximity, as attackers often disable protections first.
+
+- **Correlate with Related Activity**
+  - Review CloudTrail for `GetObject` or `ListBucket` events following the policy change to identify possible data access.
+  - Look for policy changes across multiple buckets by the same actor, suggesting scripted or automated misuse.
+
+- **Validate Intent**
+  - Contact the bucket owner or application owner to determine whether this change was part of a legitimate operation (e.g., website hosting or public dataset publishing).
+  - Review change management logs or ticketing systems for documented approval.
+
+### False positive analysis
+
+- **Intended Public Access**
+  - Buckets used for static websites, documentation hosting, or public datasets may legitimately contain `Principal:"*"`.
+  - Verify such use cases are covered by organizational policies and hardened with least-privilege permissions (e.g., read-only).
+
+- **Effect=Deny Condition**
+  - This rule does not currently exclude cases where `Principal:"*"` appears under both `Effect=Allow` and `Effect=Deny`.
+  - Analysts should review the bucket policy JSON to confirm whether `Deny` statements restrict the same resources.
+  - If access remains blocked to unauthorized entities, the alert can be dismissed as a false positive.
+
+- **Automation or Pipeline Behavior**
+  - Some automated pipelines or templates (e.g., Terraform, CloudFormation) create temporary policies with `Principal:"*"` for bootstrap access.  
+    Review timing, user agent, and role identity for expected automation patterns.
+
+### Response and remediation
+
+- **Containment**
+  - If exposure is unauthorized, immediately remove the public access policy using:
+    - `aws s3api delete-bucket-policy` or restore from version control.
+  - Re-enable Block Public Access at the account and bucket levels.
+
+- **Investigation and Scoping**
+  - Review CloudTrail and S3 access logs to identify whether external IPs accessed bucket objects after the policy change.
+  - Search for similar policy updates across other buckets in the same account or region.
+  - Validate AWS Config history for baseline deviations and determine how long the bucket was publicly exposed.
+
+- **Recovery and Hardening**
+  - Reinstate the intended bucket policy from backups or version control.
+  - Implement AWS Config rules:
+    - `s3-bucket-public-read-prohibited`
+    - `s3-bucket-public-write-prohibited`
+  - Restrict `s3:PutBucketPolicy` permissions to trusted administrative roles.
+  - Apply service control policies (SCPs) that prevent policies containing `Principal:"*"` unless explicitly approved.
+  - Enable continuous monitoring through AWS Security Hub or GuardDuty for any new public exposure events.
+
+### 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://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/",
+    "https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html",
+]
+risk_score = 47
+rule_id = "618bb351-00f0-467b-8956-8cace8b81f07"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS S3",
+    "Use Case: Threat Detection",
+    "Tactic: Exfiltration",
+    "Tactic: Collection",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+info where event.dataset == "aws.cloudtrail"
+    and event.provider == "s3.amazonaws.com"
+    and event.action == "PutBucketPolicy" 
+    and event.outcome == "success"
+    and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow")
+    and stringContains(aws.cloudtrail.request_parameters, "Principal=\\*")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1537"
+name = "Transfer Data to Cloud Account"
+reference = "https://attack.mitre.org/techniques/T1537/"
+
+
+[rule.threat.tactic]
+id = "TA0010"
+name = "Exfiltration"
+reference = "https://attack.mitre.org/tactics/TA0010/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1530"
+name = "Data from Cloud Storage"
+reference = "https://attack.mitre.org/techniques/T1530/"
+
+
+[rule.threat.tactic]
+id = "TA0009"
+name = "Collection"
+reference = "https://attack.mitre.org/tactics/TA0009/"
+
+[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",
+    "aws.cloudtrail.resources.arn",
+    "aws.cloudtrail.resources.type",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+

From c66a4f11e1c690a856b1c2f4cbb03077739629d7 Mon Sep 17 00:00:00 2001
From: Isai <59296946+imays11@users.noreply.github.com>
Date: Thu, 30 Oct 2025 23:41:05 -0400
Subject: [PATCH 2/4] [Rule Tunings] AWS Group Creation, User Added to Group,
 Group Deletion

All 3 rules are showing extremely low telemetry volume as expected. No major changes needed to these queries.
- updated the descriptions, investigation guides and false positive sections
- reduced execution window
- added highlighted fields
---
 ...ial_access_iam_user_addition_to_group.toml | 103 +++++++++++-------
 .../aws/impact_iam_group_deletion.toml        |  80 +++++++++-----
 .../aws/persistence_iam_group_creation.toml   |  88 ++++++++++-----
 3 files changed, 175 insertions(+), 96 deletions(-)

diff --git a/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml b/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml
index 5e6d6ebeae3..7233b49122d 100644
--- a/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml
+++ b/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml
@@ -2,66 +2,75 @@
 creation_date = "2020/06/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/10/30"
 
 [rule]
 author = ["Elastic"]
-description = "Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM)."
+description = """
+Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). Any user added to a
+group automatically gains the permissions that are assigned to the group. If the target group carries elevated or admin
+privileges, this action can instantly grant high-risk permissions useful for credential misuse, lateral movement, or
+privilege escalation.
+"""
 false_positives = [
     """
-    Adding users to a specified group may be done by a system or network administrator. Verify whether the user
-    identity, user agent, and/or hostname should be making changes in your environment. User additions from unfamiliar
-    users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the
-    rule.
+    Legitimate operations such as new user onboarding, role changes, or service account updates may trigger this event.
+    Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. User
+    additions from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it
+    can be exempted from the rule.
     """,
 ]
-from = "now-60m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM User Addition to Group"
 note = """## Triage and analysis
 
-### Investigating AWS IAM User Addition to Group
+> **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.
 
-AWS Identity and Access Management (IAM) provides fine-grained access control across all of AWS. With IAM, you can specify who can access which services and resources, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to ensure least-privilege permissions.
+### Investigating AWS IAM User Addition to Group
 
-This rule looks for the addition of users to a specified user group.
+This rule detects when an IAM user is added to an IAM group via the `AddUserToGroup` API call. If the target group holds elevated privileges, this action may immediately grant that user wide-ranging access useful for credential misuse or lateral movement. This rule helps detect unauthorized privilege escalation via group membership change. Treat as high-risk when the destination group has wide scope (e.g., AdministratorAccess or permissive inline policies).
 
 #### Possible investigation steps
 
-- 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.
+- **Identify the actor and target**  
+  - Check `aws.cloudtrail.user_identity.arn` for who added the user.  
+  - From `aws.cloudtrail.request_parameters`, capture `userName` (added user) and `groupName` (destination group).  
+  - Check `source.ip`, `user_agent.original`, `cloud.region` for unusual patterns.
+
+- **Examine the group’s privileges**  
+  - Use `GetGroup`, `ListAttachedGroupPolicies` to see what policies the group holds. Look for `AdministratorAccess`, `iam:*`, `s3:*`, `ec2:*` or cross-account permissions.  
+  - Check whether the group was recently created (`CreateGroup`) or recently escalated (`AttachGroupPolicy`). Common attacker pattern: create > attach policy > add user.
+
+- **Correlate with surrounding activity**  
+  - Look for preceding events by the actor: `AssumeRole`, `GetSessionToken`, `CreateAccessKey`, `AttachGroupPolicy`.  
+  - Follow the added user’s activities after group membership. Look for sensitive operations (e.g., IAM actions, S3 policy changes, EC2 snapshot/AMI activity).
+
 
 ### 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 user agent and IP address conditions — to reduce noise from onboarding processes and administrator activities.
+- Onboarding or role transitions may legitimately add users to groups.  
+- Automated Identity-Management pipelines may add many users to service groups; validate know
 
 ### 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.
-- 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).
-
-## Setup
-
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+- **Containment**:
+  - If unapproved, remove the user from the group immediately (`RemoveUserFromGroup`) and rotate their access keys.
+  - Temporarily restrict group policy changes while assessing blast radius.
+- **Investigation and scoping**:
+  - Review all actions executed by the newly added user since the change (ex: PutBucketPolicy, CreateAccessKey, PassRole).
+  - Confirm whether other users were added to the same group within the same window. 
+- **Recovery and hardening**: 
+  - Enforce least privilege by redesigning large-group membership. 
+  - Restrict `iam:AddUserToGroup` to only appropriate service principals with approval workflow. 
+  - Create detections for AttachGroupPolicy to powerful policies and for mass AddUserToGroup patterns.
+
+### Additional information
+[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)
+"""
 references = ["https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html"]
 risk_score = 21
 rule_id = "333de828-8190-4cf5-8d7c-7575846f6fe0"
@@ -79,7 +88,10 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:iam.amazonaws.com and event.action:AddUserToGroup and event.outcome:success
+event.dataset: aws.cloudtrail and 
+    event.provider: iam.amazonaws.com and 
+    event.action: AddUserToGroup and 
+    event.outcome: success
 '''
 
 
@@ -103,3 +115,20 @@ 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",
+    "user.target.name",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+]
+
diff --git a/rules/integrations/aws/impact_iam_group_deletion.toml b/rules/integrations/aws/impact_iam_group_deletion.toml
index 207042b33a4..376cdd7560a 100644
--- a/rules/integrations/aws/impact_iam_group_deletion.toml
+++ b/rules/integrations/aws/impact_iam_group_deletion.toml
@@ -2,24 +2,25 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/10/30"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the deletion of a specified AWS Identity and Access Management (IAM) resource group. Deleting a resource
-group does not delete resources that are members of the group; it only deletes the group structure.
+Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious
+attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group
+briefly for privileged access). This is an indicator of impact or cleanup in an attack lifecycle.
 """
 false_positives = [
     """
-    A resource group may be deleted by a system administrator. Verify whether the user identity, user agent, and/or
-    hostname should be making changes in your environment. Resource group deletions by unfamiliar users or hosts should
-    be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    Legitimate group deletion during decommissioning of projects, clean-up of service accounts, or identity lifecycle
+    changes may trigger this alert. Verify whether the user identity, user agent, and/or hostname should be making
+    changes in your environment. Resource group deletions by unfamiliar users or hosts should be investigated. If known
+    behavior is causing false positives, it can be exempted from the rule.
     """,
 ]
-from = "now-60m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Group Deletion"
@@ -30,37 +31,37 @@ note = """## Triage and analysis
 
 ### Investigating AWS IAM Group Deletion
 
-AWS IAM groups facilitate user management by organizing users with similar permissions. Adversaries might exploit group deletion to disrupt access controls, potentially leading to unauthorized access or service disruption. The detection rule monitors successful group deletions via AWS CloudTrail, flagging potential misuse by correlating specific IAM actions and outcomes, thus aiding in timely threat identification.
+Attackers sometimes remove groups to erase evidence, disrupt operations, or prevent users from receiving needed permissions (Impact). Deletion can also follow malicious cleanup after attaching policies and using the group briefly. This alert fires on `DeleteGroup` API call. Consider intentional disruption or covering tracks, particularly if the group was privileged or recently modified.
 
 ### Possible investigation steps
 
-- Review the AWS CloudTrail logs to identify the user or role that performed the DeleteGroup action by examining the userIdentity field.
-- Check the event time to determine when the group deletion occurred and correlate it with any other suspicious activities around the same timeframe.
-- Investigate the specific IAM group that was deleted to understand its purpose and the permissions it granted by reviewing historical IAM policies and group membership.
-- Assess the impact of the group deletion by identifying any users or services that might have been affected due to the loss of group-based permissions.
-- Verify if the group deletion was authorized by cross-referencing with change management records or contacting the responsible team or individual.
-- Look for any patterns or repeated occurrences of similar actions in the logs to identify potential malicious behavior or misconfigurations.
+- **Identify the actor and environment**  
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id`.  
+  - Check `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for atypical activity.
+
+- **Determine what was lost**
+  - From `aws.cloudtrail.request_parameters`, capture `groupName`.  
+  - Use history or logs to identify existing members and attached policies prior to deletion (ex: `GetGroup`, `ListAttachedGroupPolicies`).  
+  - Determine if the group contained privileged roles/policies that could have been weaponized.
+
+- **Correlate with related activity**
+  - Look in the prior 1–24h for `DetachGroupPolicy`, `RemoveUserFromGroup`, `DeleteGroupPolicy`, which often precede deletion in adversary cleanup workflows.  
+  - After deletion, monitor for creation of new similarly-named groups, or re-attachment of policies to other groups/roles.
 
 ### False positive analysis
 
-- Routine administrative tasks may trigger alerts when IAM groups are deleted as part of regular maintenance or restructuring. To manage this, create exceptions for known maintenance periods or specific administrative accounts.
-- Automated scripts or tools that manage IAM resources might delete groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
-- Temporary groups created for short-term projects or testing purposes might be deleted frequently. Document these groups and exclude their deletion from monitoring by using naming conventions or tags.
-- Changes in organizational structure or policy might necessitate the deletion of certain groups. Coordinate with relevant teams to anticipate these changes and adjust monitoring rules accordingly.
+- Projects & services that are being decommissioned often require group deletion. Confirm through internal inventory and change control.  
+- Sandbox or dev accounts frequently create and delete groups; ensure the environment context is understood.
 
 ### Response and remediation
 
-- Immediately revoke any active sessions and access keys for users who were part of the deleted IAM group to prevent unauthorized access.
-- Restore the deleted IAM group from a backup or recreate it with the same permissions to ensure continuity of access for legitimate users.
-- Conduct a review of recent IAM activity logs to identify any unauthorized or suspicious actions that may have preceded the group deletion.
-- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
-- Implement additional monitoring on IAM activities, especially focusing on group management actions, to detect similar threats in the future.
-- Review and tighten IAM policies and permissions to ensure that only authorized personnel can delete IAM groups.
-- If malicious intent is suspected, escalate the incident to the incident response team for a comprehensive investigation and potential legal action.
-
-## Setup
+- **Containment**: If deletion was unauthorized, restrict the actor’s IAM privileges and block further configuration changes.  
+- **Investigation and scoping**: Recover details of the deleted group (members, policies) from logs or AWS Config, and determine the impact of the deletion (which users lost membership, service account disruption).  
+- **Recovery and hardening**: Recreate the group if necessary, restore intended policies and memberships, enforce change-control for group deletions, restrict `iam:DeleteGroup` privileges, and create alerts for destructive IAM operations.
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+### Additional information
+[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)
+"""
 references = [
     "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-group.html",
     "https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroup.html",
@@ -80,7 +81,10 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:iam.amazonaws.com and event.action:DeleteGroup and event.outcome:success
+event.dataset: aws.cloudtrail and 
+    event.provider: iam.amazonaws.com and 
+    event.action: DeleteGroup and 
+    event.outcome: success
 '''
 
 
@@ -97,3 +101,19 @@ id = "TA0040"
 name = "Impact"
 reference = "https://attack.mitre.org/tactics/TA0040/"
 
+[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",
+]
+
diff --git a/rules/integrations/aws/persistence_iam_group_creation.toml b/rules/integrations/aws/persistence_iam_group_creation.toml
index f67e8334e1e..75dcaa9f0bc 100644
--- a/rules/integrations/aws/persistence_iam_group_creation.toml
+++ b/rules/integrations/aws/persistence_iam_group_creation.toml
@@ -2,13 +2,15 @@
 creation_date = "2020/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/10/30"
 
 [rule]
 author = ["Elastic"]
 description = """
 Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple
-users. Any user in a group automatically has the permissions that are assigned to the group.
+users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain
+credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach
+admin-level policies to the group and quietly add users or roles to inherit those privileges.
 """
 false_positives = [
     """
@@ -17,9 +19,8 @@ false_positives = [
     investigated. If known behavior is causing false positives, it can be exempted from the rule.
     """,
 ]
-from = "now-60m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Group Creation"
@@ -30,38 +31,47 @@ note = """## Triage and analysis
 
 ### Investigating AWS IAM Group Creation
 
-AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. The detection rule monitors successful group creation events, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts.
+AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. This alert fires on `CreateGroup`. New group creation may indicate attacker staging for persistence, especially if followed by policy attachments or user additions.
 
-### Possible investigation steps
+#### Possible investigation steps
 
-- Review the AWS CloudTrail logs for the specific event.provider: iam.amazonaws.com and event.action: CreateGroup to identify the user or service that initiated the group creation.
-- Check the event.dataset: aws.cloudtrail logs for any associated event.outcome: success entries to confirm the successful creation of the group.
-- Investigate the permissions assigned to the newly created group to assess if they include any sensitive or high-privilege permissions that could pose a security risk.
-- Identify and review the IAM user or role that created the group to determine if they have a legitimate reason for this action and if their activity aligns with their typical behavior.
-- Cross-reference the group creation event with other recent IAM activities, such as user additions to the group or changes to group policies, to detect any suspicious patterns or anomalies.
-- Consult with relevant stakeholders or the user responsible for the group creation to verify the legitimacy of the action and gather additional context if necessary.
+- **Identify the actor and context**  
+  - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` to determine who performed the group creation.  
+  - Review `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for unusual network, client, or region usage.
 
-### False positive analysis
+- **Examine the group details**  
+  - From `aws.cloudtrail.response_elements`, extract `groupName` and `path` (e.g., /service/, /dev/).
+  - Look for immediate follow-on changes by the same actor within the next 15–30 minutes:
+    - AttachGroupPolicy (especially AdministratorAccess or broad s3:*, iam:*).
+    - AddUserToGroup (who was added and when?).
+  - Use GetGroup to enumerate current group membership and attached policies during triage.
 
-- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate group creation activities to differentiate them from unauthorized actions.
-- Automated scripts or tools used for infrastructure management may create groups as part of their normal operation. Identify and whitelist these scripts to prevent unnecessary alerts.
-- Temporary groups created for short-term projects or testing purposes might be flagged. Implement a naming convention for such groups and exclude them from alerts based on this pattern.
-- Scheduled tasks or maintenance activities that involve group creation should be logged and approved in advance. Use these logs to create exceptions in the detection rule.
-- Third-party integrations or services that require group creation for functionality can cause false positives. Verify these integrations and adjust the rule to exclude their known actions.
+- **Correlate with broader activity**  
+  - Look for prior suspicious actions by the same user: `AssumeRole`, `CreateAccessKey`, new IAM user/role.  
+  - After group creation, watch for data-access or configuration changes (e.g., S3 policy updates, KMS key policy changes) 
 
-### Response and remediation
+### False positive analysis:
 
-- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the IAM group and identify the user or service responsible for the action.
-- Revoke any permissions associated with the newly created IAM group to prevent further unauthorized access or actions.
-- Temporarily disable or delete the unauthorized IAM group to contain the threat and prevent any potential misuse.
-- Conduct a thorough audit of recent IAM changes to identify any other unauthorized activities or anomalies that may indicate further compromise.
-- Escalate the incident to the security operations team for a detailed investigation and to assess the potential impact on the organization's security posture.
-- Implement additional monitoring and alerting for IAM group creation events to enhance detection capabilities and prevent similar incidents in the future.
-- Review and update IAM policies and permissions to ensure they follow the principle of least privilege, reducing the risk of unauthorized access.
+- IAM onboarding workflows or DevOps pipelines creating groups for new projects can trigger this alert.  
+- Test or sandbox accounts often create and delete groups routinely, validate account context and approval flows.
 
-## Setup
+### Response and remediation:
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+- **Containment**: 
+  - If suspicious, disable further changes by the actor (temporarily remove IAM write privileges or deactivate keys).
+  - Place a change freeze on the newly created group (block `AttachGroupPolicy`/`AddUserToGroup` via SCP/permissions boundary until review completes).
+
+- **Investigation and scoping**: 
+  - Use `GetGroup`, `ListAttachedGroupPolicies`, `ListUsersInGroup` to enumerate the group’s state and identify any suspicious policies or members. Investigate any attached policies granting broad privileges. 
+  - Hunt for same-actor `AttachGroupPolicy`/`AddUserToGroup` events across the last 24–48h.
+ 
+- **Recovery and hardening**: 
+  - Delete unauthorized, unused or suspicious groups. remove rogue policies/members.
+  - Restrict who can call `iam:CreateGroup`, `iam:AttachGroupPolicy`, and `iam:AddUserToGroup` (least privilege). 
+
+### Additional information
+[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)
+"""
 references = [
     "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-group.html",
     "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.html",
@@ -82,7 +92,10 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:iam.amazonaws.com and event.action:CreateGroup and event.outcome:success
+event.dataset: aws.cloudtrail and 
+    event.provider: iam.amazonaws.com and 
+    event.action: CreateGroup and 
+    event.outcome: success
 '''
 
 
@@ -104,3 +117,20 @@ 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",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+

From 7c98d6052fae629c645bfaa8920ab826307e4145 Mon Sep 17 00:00:00 2001
From: Isai <59296946+imays11@users.noreply.github.com>
Date: Thu, 30 Oct 2025 23:53:11 -0400
Subject: [PATCH 3/4] slight edit to description

---
 rules/integrations/aws/impact_iam_group_deletion.toml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules/integrations/aws/impact_iam_group_deletion.toml b/rules/integrations/aws/impact_iam_group_deletion.toml
index 376cdd7560a..f34501ca5a6 100644
--- a/rules/integrations/aws/impact_iam_group_deletion.toml
+++ b/rules/integrations/aws/impact_iam_group_deletion.toml
@@ -9,7 +9,7 @@ author = ["Elastic"]
 description = """
 Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious
 attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group
-briefly for privileged access). This is an indicator of impact or cleanup in an attack lifecycle.
+briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle.
 """
 false_positives = [
     """

From 4f7873a123a62f2843c72a4ee833d4917ead2117 Mon Sep 17 00:00:00 2001
From: Isai <59296946+imays11@users.noreply.github.com>
Date: Thu, 30 Oct 2025 23:55:34 -0400
Subject: [PATCH 4/4] Revert "[Rule Tuning][New Rule] AWS S3 Bucket Policy
 Added to Share with External Account/ to Allow Public Access"

This reverts commit 776d748a11d11f2c0e974e68c9e3adc77dcb3d9f.
---
 ...icy_added_for_external_account_access.toml | 179 ++++-------------
 ...bucket_policy_added_for_public_access.toml | 188 ------------------
 2 files changed, 44 insertions(+), 323 deletions(-)
 delete mode 100644 rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml

diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
index 16ee579b23c..1fc310523c8 100644
--- a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
+++ b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
@@ -2,115 +2,58 @@
 creation_date = "2024/04/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/10/30"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
 description = """
-Detects when an Amazon S3 bucket policy is modified to share access with an external AWS account. This rule analyzes
-PutBucketPolicy events and compares the S3 bucket’s account ID to any account IDs referenced in the policy’s
-Effect=Allow statements. If the policy includes principals from accounts other than the bucket owner’s, the rule
-triggers an alert. This behavior may indicate an adversary backdooring a bucket for data exfiltration or cross-account
-persistence. For example, an attacker who compromises credentials could attach a policy allowing access from an external
-AWS account they control, enabling continued access even after credentials are rotated. Note: This rule will not alert
-if the account ID is part of the bucket’s name or appears in the resource ARN. Such cases are common in standardized
-naming conventions (e.g., “mybucket-123456789012”). To ensure full coverage, use complementary rules to monitor for
-suspicious PutBucketPolicy API requests targeting buckets with account IDs embedded in their names or resources.
+Identifies an AWS S3 bucket policy change to share permissions with an external account. Adversaries may attempt to
+backdoor an S3 bucket by sharing it with an external account. This can be used to exfiltrate data or to provide access
+to other adversaries. This rule identifies changes to a bucket policy via the `PutBucketPolicy` API call where the
+policy includes an `Effect=Allow` statement that does not contain the AWS account ID of the bucket owner.
 """
-event_category_override = "event.type"
 false_positives = [
     """
-    Legitimate changes to share an S3 bucket with an external account may be identified as false positives.
+    Legitimate changes to share an S3 bucket with an external account may be identified as false positive but are not
+    best practice.
     """,
 ]
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Policy Added to Share with External Account"
-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.
+note = """
+## Triage and analysis
 
 ### Investigating AWS S3 Bucket Policy Added to Share with External Account
 
-This rule detects when an S3 bucket policy is modified using the `PutBucketPolicy` API call to include an external AWS account ID.
-It compares the bucket’s `recipient_account_id` to any account IDs included in the policy’s `Effect=Allow` statement, triggering
-an alert if the two do not match.  
-
-Adversaries may exploit this to backdoor a bucket and exfiltrate sensitive data by granting permissions to another AWS account
-they control, enabling ongoing access to the bucket’s contents even if IAM credentials are rotated or revoked.
-
-This detection specifically focuses on policy-based sharing and does not alert when:
-- The account ID appears within the bucket or object name being shared.
-- The account owner explicitly matches the policy’s condition keys on something other than an ARN or account id (i.e. IP address).
-  
-To fully monitor for suspicious sharing behavior, use this rule in combination with detections for:
-- Unusual PutBucketPolicy requests
-- Cross-account object access (e.g., `GetObject`, `PutObject`)
-- Changes to bucket ACLs or access points
-
-#### Possible investigation steps
-
-- **Identify the Actor and Context**
-  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change.
-  - Determine if the identity typically manages S3 bucket policies.  
-  - Examine `aws.cloudtrail.resources.arn` to determine which bucket is being shared.
-
-- **Analyze the Policy Change**
-  - Review `aws.cloudtrail.request_parameters` to extract the policy JSON and identify the external AWS account ID(s) referenced.  
-  - Check for `Effect=Allow` statements granting broad permissions such as `"Action": "s3:*"` or `"Resource": "*"`.  
-  - Verify if the added principals correspond to known partners or external vendors.
-  - If AWS account ID(s) were only part of `Effect=Deny` statements, then this rule can be closed as a false positive. 
-
-- **Review Context and Source**
-  - Check `source.ip`, `source.geo`, and `user_agent.original` for anomalies — such as new IP ranges, access from unfamiliar geographies, or use of programmatic clients (`boto3`, `aws-cli`).
-
-- **Correlate with Related Activity**
-  - Search CloudTrail for subsequent activity by the external AWS account ID(s):
-    - `GetObject`, `ListBucket`, or `PutObject` events that indicate data access or exfiltration.
-  - Look for additional configuration changes by the same actor, such as:
-    - `PutBucketAcl`, `PutBucketVersioning`, or `PutBucketReplication` — often part of a larger bucket compromise chain.
-  - Determine if multiple buckets were modified in quick succession.
-
-- **Validate Intent**
-  - Review internal change requests or documentation to confirm whether this external sharing was approved.  
-  - If no approval exists, escalate immediately for potential compromise.
-
-### False positive analysis
-
-- **Authorized Cross-Account Access**
-  - Some organizations legitimately share S3 buckets across accounts within a trusted AWS Organization or partner accounts.  
-  - Validate whether the external account ID belongs to a known entity or service provider and is documented in your allowlist.
-- **Automation or Deployment Pipelines**
-  - Continuous integration/deployment pipelines may temporarily attach cross-account policies for replication or staging.  
-  - Verify the `user_agent.original` or role name — automation often includes identifiable strings.
-- **Naming and Rule Logic Limitations**
-  - This rule excludes detections where the account ID appears in the bucket resource ARN (e.g., `mybucket-123456789012`).  
-  - Such patterns are common in automated provisioning. For those scenarios, rely on complementary rules that directly monitor `PutBucketPolicy` events against those buckets.
-
-### Response and remediation
-
-- **Immediate Review and Containment**
-  - If unauthorized sharing is confirmed, use the AWS CLI or Console to delete or revert the modified policy (`aws s3api delete-bucket-policy` or restore from version control).  
-  - Remove external principals and reapply the correct bucket policy.  
-  - Rotate access keys for the actor involved, especially if API access came from unexpected locations or tools.
-
-- **Investigation and Scoping**
-  - Identify whether data was accessed by the external account via `GetObject` or `ListBucket` operations.  
-  - Search CloudTrail logs for other buckets modified by the same actor or IP within the same timeframe.
-  - Use AWS Config to review version history of affected bucket policies and detect similar cross-account permissions.
-
-- **Recovery and Hardening**
-  - Restrict `s3:PutBucketPolicy` to a limited set of administrative roles using least privilege.
-  - Enable AWS Config rule `s3-bucket-policy-grantee-check` to monitor for unauthorized policy additions.
-  - Use AWS GuardDuty or Security Hub findings to correlate policy changes with data exfiltration or credential compromise events.
-  - Apply service control policies (SCPs) to block cross-account sharing unless explicitly approved.
-
-### 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/).
+This rule detects when an AWS S3 bucket policy is changed to share permissions with an external account. Adversaries may attempt to backdoor an S3 bucket by sharing it with an external account to exfiltrate data or provide access to other adversaries. This rule identifies changes to a bucket policy via the `PutBucketPolicy` API call where the policy includes an `Effect=Allow` statement that does not contain the AWS account ID of the bucket owner.
+
+#### Possible Investigation Steps:
+
+- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.
+- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the bucket policy. Look for any unusual parameters that could suggest unauthorized or malicious modifications.
+- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.
+- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny.
+- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
+
+### False Positive Analysis:
+
+- **Legitimate Administrative Actions**: Confirm if the bucket policy change aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.
+- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
+- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy.
+
+### Response and Remediation:
+
+- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the bucket policy to remove any unauthorized permissions and restore it to its previous state.
+- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
+- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning bucket policy management and sharing permissions.
+- **Audit Bucket Policies and Permissions**: Conduct a comprehensive audit of all bucket policies and associated permissions to ensure they adhere to the principle of least privilege.
+- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
+
+### Additional Information:
+
+For further guidance on managing S3 bucket policies and securing AWS environments, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) and AWS best practices for security.
 """
 references = [
     "https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/",
@@ -118,6 +61,11 @@ references = [
 ]
 risk_score = 47
 rule_id = "e8c9ff14-fd1e-11ee-a0df-f661ea17fbce"
+setup = """
+## Setup
+
+S3 data event types must be collected in the AWS CloudTrail logs. Please refer to [AWS documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) for more information.
+"""
 severity = "medium"
 tags = [
     "Domain: Cloud",
@@ -126,25 +74,17 @@ tags = [
     "Data Source: AWS S3",
     "Use Case: Threat Detection",
     "Tactic: Exfiltration",
-    "Tactic: Collection",
     "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-info where event.dataset == "aws.cloudtrail"
+any where event.dataset == "aws.cloudtrail"
     and event.provider == "s3.amazonaws.com"
-    and event.action == "PutBucketPolicy" 
+    and event.action == "PutBucketPolicy" and event.outcome == "success"
     and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow")
-    and (
-        stringContains(aws.cloudtrail.request_parameters, "AWS=") or 
-        stringContains(aws.cloudtrail.request_parameters, "aws:PrincipalAccount=") or
-        stringContains(aws.cloudtrail.request_parameters, "aws:SourceAccount=")
-        )
-and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:cloudfront::")  
-and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:iam::cloudfront:user")
-and not stringContains(aws.cloudtrail.request_parameters, aws.cloudtrail.recipient_account_id)
+    and not stringContains(aws.cloudtrail.request_parameters, aws.cloudtrail.recipient_account_id)
 '''
 
 
@@ -160,35 +100,4 @@ reference = "https://attack.mitre.org/techniques/T1537/"
 id = "TA0010"
 name = "Exfiltration"
 reference = "https://attack.mitre.org/tactics/TA0010/"
-[[rule.threat]]
-framework = "MITRE ATT&CK"
-[[rule.threat.technique]]
-id = "T1530"
-name = "Data from Cloud Storage"
-reference = "https://attack.mitre.org/techniques/T1530/"
-
-
-[rule.threat.tactic]
-id = "TA0009"
-name = "Collection"
-reference = "https://attack.mitre.org/tactics/TA0009/"
-
-[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",
-    "aws.cloudtrail.resources.arn",
-    "aws.cloudtrail.resources.type",
-    "event.action",
-    "event.outcome",
-    "cloud.account.id",
-    "cloud.region",
-    "aws.cloudtrail.request_parameters",
-    "aws.cloudtrail.response_elements",
-]
 
diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml
deleted file mode 100644
index c73cfed81b3..00000000000
--- a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_public_access.toml
+++ /dev/null
@@ -1,188 +0,0 @@
-[metadata]
-creation_date = "2025/10/30"
-integration = ["aws"]
-maturity = "production"
-updated_date = "2025/10/30"
-
-[rule]
-author = ["Elastic"]
-description = """
-Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"*") statement.
-This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"*" in the request parameters,
-indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly
-accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments.
-Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect
-credentials and logs left in open storage.
-"""
-event_category_override = "event.type"
-false_positives = [
-    """
-    This rule does not differentiate by itself whether the same policy also includes Deny statements that restrict
-    public access. If a policy includes both Effect=Allow and Effect=Deny with Principal:"*", this rule may still
-    trigger. Such cases should be manually analyzed to verify whether the Deny statement effectively negates the public
-    exposure.
-    """,
-]
-index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-language = "eql"
-license = "Elastic License v2"
-name = "AWS S3 Bucket Policy Added to Allow Public Access"
-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 your specific environment and operational needs.
-
-### Investigating AWS S3 Bucket Policy Added to Allow Public Access
-
-This rule detects modifications to Amazon S3 bucket policies using the `PutBucketPolicy` API where both `Effect=Allow`
-and `Principal:"*"` are present. This effectively grants permissions to all AWS identities, including unauthenticated users.  
-Such exposure can result in sensitive data leaks, ransomware staging, or unauthorized data collection.  
-
-This rule focuses on policy-based exposure rather than ACL-based or block-public-access configurations.  
-It will still trigger if a bucket policy includes both `Effect=Allow` and `Effect=Deny` statements that contain `Principal:"*"`. Those cases should be reviewed to confirm whether the `Deny` statement restricts access sufficiently.
-
-#### Possible investigation steps
-
-- **Identify the Actor**
-  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change.
-  - Validate whether this user or role is authorized to modify S3 bucket policies.
-  - Examine `source.ip`, `source.geo`, and `user_agent.original` to identify unusual sources or tools (e.g., CLI or SDK-based activity).
-
-- **Analyze the Bucket Policy Content**
-  - Extract the full JSON from `aws.cloudtrail.request_parameters`.
-  - Look for `Effect=Allow` statements paired with `Principal:"*"`.
-  - Identify what permissions were granted — for example:
-    - `s3:GetObject` (read access to all objects)
-    - `s3:PutObject` or `s3:*` (read/write access)
-  - Check if the policy also contains any `Effect=Deny` statements targeting `Principal:"*"`.  
-    If present, determine whether these statements fully restrict public access, if so this alert can be closed.
-
-- **Assess the Impact and Scope**
-  - Review `aws.cloudtrail.resources.arn` to confirm which bucket was affected.
-  - Determine if the bucket contains sensitive, regulated, or internal data.
-  - Check for `PutPublicAccessBlock` or `DeleteBucketPolicy` events in close proximity, as attackers often disable protections first.
-
-- **Correlate with Related Activity**
-  - Review CloudTrail for `GetObject` or `ListBucket` events following the policy change to identify possible data access.
-  - Look for policy changes across multiple buckets by the same actor, suggesting scripted or automated misuse.
-
-- **Validate Intent**
-  - Contact the bucket owner or application owner to determine whether this change was part of a legitimate operation (e.g., website hosting or public dataset publishing).
-  - Review change management logs or ticketing systems for documented approval.
-
-### False positive analysis
-
-- **Intended Public Access**
-  - Buckets used for static websites, documentation hosting, or public datasets may legitimately contain `Principal:"*"`.
-  - Verify such use cases are covered by organizational policies and hardened with least-privilege permissions (e.g., read-only).
-
-- **Effect=Deny Condition**
-  - This rule does not currently exclude cases where `Principal:"*"` appears under both `Effect=Allow` and `Effect=Deny`.
-  - Analysts should review the bucket policy JSON to confirm whether `Deny` statements restrict the same resources.
-  - If access remains blocked to unauthorized entities, the alert can be dismissed as a false positive.
-
-- **Automation or Pipeline Behavior**
-  - Some automated pipelines or templates (e.g., Terraform, CloudFormation) create temporary policies with `Principal:"*"` for bootstrap access.  
-    Review timing, user agent, and role identity for expected automation patterns.
-
-### Response and remediation
-
-- **Containment**
-  - If exposure is unauthorized, immediately remove the public access policy using:
-    - `aws s3api delete-bucket-policy` or restore from version control.
-  - Re-enable Block Public Access at the account and bucket levels.
-
-- **Investigation and Scoping**
-  - Review CloudTrail and S3 access logs to identify whether external IPs accessed bucket objects after the policy change.
-  - Search for similar policy updates across other buckets in the same account or region.
-  - Validate AWS Config history for baseline deviations and determine how long the bucket was publicly exposed.
-
-- **Recovery and Hardening**
-  - Reinstate the intended bucket policy from backups or version control.
-  - Implement AWS Config rules:
-    - `s3-bucket-public-read-prohibited`
-    - `s3-bucket-public-write-prohibited`
-  - Restrict `s3:PutBucketPolicy` permissions to trusted administrative roles.
-  - Apply service control policies (SCPs) that prevent policies containing `Principal:"*"` unless explicitly approved.
-  - Enable continuous monitoring through AWS Security Hub or GuardDuty for any new public exposure events.
-
-### 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://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/",
-    "https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html",
-]
-risk_score = 47
-rule_id = "618bb351-00f0-467b-8956-8cace8b81f07"
-severity = "medium"
-tags = [
-    "Domain: Cloud",
-    "Data Source: AWS",
-    "Data Source: Amazon Web Services",
-    "Data Source: AWS S3",
-    "Use Case: Threat Detection",
-    "Tactic: Exfiltration",
-    "Tactic: Collection",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-info where event.dataset == "aws.cloudtrail"
-    and event.provider == "s3.amazonaws.com"
-    and event.action == "PutBucketPolicy" 
-    and event.outcome == "success"
-    and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow")
-    and stringContains(aws.cloudtrail.request_parameters, "Principal=\\*")
-'''
-
-
-[[rule.threat]]
-framework = "MITRE ATT&CK"
-[[rule.threat.technique]]
-id = "T1537"
-name = "Transfer Data to Cloud Account"
-reference = "https://attack.mitre.org/techniques/T1537/"
-
-
-[rule.threat.tactic]
-id = "TA0010"
-name = "Exfiltration"
-reference = "https://attack.mitre.org/tactics/TA0010/"
-[[rule.threat]]
-framework = "MITRE ATT&CK"
-[[rule.threat.technique]]
-id = "T1530"
-name = "Data from Cloud Storage"
-reference = "https://attack.mitre.org/techniques/T1530/"
-
-
-[rule.threat.tactic]
-id = "TA0009"
-name = "Collection"
-reference = "https://attack.mitre.org/tactics/TA0009/"
-
-[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",
-    "aws.cloudtrail.resources.arn",
-    "aws.cloudtrail.resources.type",
-    "event.action",
-    "event.outcome",
-    "cloud.account.id",
-    "cloud.region",
-    "aws.cloudtrail.request_parameters",
-    "aws.cloudtrail.response_elements",
-]
-