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

nldcsc_elastic_rules/rules/integrations/aws/exfiltration_rds_snapshot_export.toml

@@ -2,62 +2,132 @@
 creation_date = "2021/06/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/11/24"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
-description = "Identifies the export of an Amazon Relational Database Service (RDS) Aurora database snapshot."
+description = """
+Identifies the export of a DB snapshot or DB cluster data to Amazon S3. Snapshot exports can be used for analytics or
+migration workflows, but adversaries may abuse them to exfiltrate sensitive data outside of RDS-managed storage.
+Exporting a snapshot creates a portable copy of the database contents, which, if performed without authorization, can
+indicate data theft, staging for exfiltration, or operator misconfiguration that exposes regulated information.
+"""
 false_positives = [
     """
-    Exporting snapshots 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. Snapshot exports from unfamiliar users or hosts should
-    be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    Snapshot exports may be performed by administrators, automation pipelines, or data engineering workflows. Confirm
+    whether the export was expected and initiated by an authorized user, role, or automation process. Snapshot exports
+    by unfamiliar principals or from unexpected networks should be investigated. If known behavior causes 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 RDS Snapshot Export"
 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.
+> 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, validate and adapt it to suit your operational needs.
 
 ### Investigating AWS RDS Snapshot Export
 
-Amazon RDS Snapshot Export allows users to export Aurora database snapshots to Amazon S3, facilitating data analysis and backup. However, adversaries may exploit this feature to exfiltrate sensitive data by exporting snapshots without authorization. The detection rule monitors successful export tasks in AWS CloudTrail logs, flagging potential misuse by identifying unexpected or unauthorized snapshot exports.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs for the specific event.action:StartExportTask to identify the user or role that initiated the export task.
-- Check the event.provider:rds.amazonaws.com logs to verify the source IP address and location from which the export task was initiated, looking for any anomalies or unexpected locations.
-- Investigate the event.dataset:aws.cloudtrail logs to determine the specific database snapshot that was exported and assess its sensitivity or criticality.
-- Cross-reference the event.outcome:success with IAM policies and permissions to ensure the user or role had legitimate access to perform the export task.
-- Analyze any recent changes in IAM roles or policies that might have inadvertently granted export permissions to unauthorized users.
-- Contact the data owner or relevant stakeholders to confirm whether the export task was authorized and aligns with business needs.
+Exporting an RDS snapshot to Amazon S3 allows the full contents of a database to be written outside the managed
+RDS service boundary. While legitimate for analytics or migration, this action can also be a mechanism for data
+exfiltration. Because snapshot exports produce files that can be downloaded, shared, or accessed by other AWS principals,
+unauthorized exports may indicate staging for data theft or attempts to bypass database access controls.
+
+This rule detects successful `StartExportTask` events. Activity of this type should be validated to ensure that only
+authorized database, platform engineering, or analytics workflows initiated the export.
+
+#### Possible investigation steps
+
+- **Identify the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which principal initiated the export.
+  - Look at `source.ip`, `user.name`, and `user_agent.original` to understand where the export originated (console, CLI, SDK, automation).
+  - Check whether the principal has historically performed snapshot exports.
+
+- **Determine what was exported**
+  - Examine `aws.cloudtrail.request_parameters`:
+    - Snapshot identifier being exported.
+    - S3 bucket name and path.
+    - KMS key used (or absence of encryption).
+  - Map the snapshot and destination bucket to:
+    - Application/owner team.
+    - Environment (prod/staging/dev).
+    - Data classification (PII, PHI, PCI, internal).
+
+- **Reconstruct timing and surrounding context**
+  - Use `@timestamp` to correlate the export with:
+    - Recent RDS modifications (`ModifyDBInstance`, `ModifyDBCluster`), snapshot deletions, or retention changes.
+    - IAM role changes, access key issuance, or privilege escalation attempts.
+    - Unusual authentication patterns (e.g., successful logins from new locations, failed console logins).
+  - Check whether the export timing aligns with approved deployments or maintenance windows.
+
+- **Correlate with broader CloudTrail activity**
+  - Pivot on the same user, role, or access key ID to look for:
+    - Prior reconnaissance (e.g., `DescribeDBSnapshots`, `DescribeDBClusters`, `ListBuckets`).
+    - Permission changes (`PutRolePolicy`, `AttachUserPolicy`).
+    - Public exposure (e.g., S3 bucket ACL changes).
+  - Determine whether multiple snapshots were exported around the same time.
+
+- **Validate intent with stakeholders**
+  - Confirm with the database owner, analytics team, or platform engineering team whether:
+    - The export was planned and authorized.
+    - The target S3 bucket is approved for storing database contents.
+    - Encryption and access controls meet organizational policy.
 
 ### False positive analysis
 
-- Routine data exports for legitimate business purposes may trigger alerts. Users should review export tasks to confirm they align with expected business operations and consider whitelisting known, authorized export activities.
-- Automated backup processes that regularly export snapshots to S3 can be mistaken for unauthorized actions. Identify and document these processes, then create exceptions in the monitoring system to prevent false alerts.
-- Development and testing environments often involve frequent snapshot exports for testing purposes. Ensure these environments are clearly identified and excluded from alerts by setting up specific rules or tags that differentiate them from production environments.
-- Exports initiated by third-party services or integrations that have been granted access to RDS snapshots might be flagged. Verify these integrations and adjust the detection rule to recognize and exclude these trusted services.
+- **Authorized data analytics or ETL workflows**
+  - Many organizations export snapshots for reporting, ML pipelines, or external data processing.
+  - Validate that the export aligns with documented ETL or analytics processes.
 
-### Response and remediation
+- **Automated snapshot export tools**
+  - Backup pipelines, cost optimization, or data replication systems may export snapshots.
+  - Tune the rule by excluding known IAM roles or automation user agents.
 
-- Immediately revoke access to the AWS account or IAM role that initiated the unauthorized snapshot export to prevent further data exfiltration.
-- Conduct a thorough review of AWS CloudTrail logs to identify any other unauthorized activities associated with the same account or IAM role, and assess the scope of the potential data breach.
-- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized export and any other suspicious activities discovered.
-- Restore the affected database from a known good backup if data integrity is suspected to be compromised, ensuring that the restored data is free from unauthorized changes.
-- Implement stricter IAM policies and permissions to limit who can perform snapshot exports, ensuring that only authorized personnel have the necessary permissions.
-- Enhance monitoring and alerting mechanisms to detect any future unauthorized snapshot export attempts, ensuring timely response to similar threats.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve readiness for future incidents.
+- **CloudFormation or IaC triggers**
+  - Infrastructure-as-code pipelines may trigger snapshot exports as part of stack updates.
+  - Correlate with CloudFormation events to confirm legitimacy.
 
-## Setup
+### Response and remediation
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+- **Contain potential exfiltration**
+  - Review access to the destination S3 bucket and confirm that:
+    - Bucket is encrypted with the expected KMS key.
+    - Access is restricted to authorized principals.
+    - No unusual downloads or cross-account accesses occurred.
+
+- **Investigate scope and impact**
+  - Use CloudTrail to enumerate:
+    - All export tasks started by the same actor.
+    - Other snapshot or data-access API calls in the same time window.
+  - Validate whether sensitive or regulated data may have been included.
+
+- **Credential and access remediation**
+  - If activity appears unauthorized:
+    - Revoke or rotate compromised IAM credentials.
+    - Review STS session activity related to the actor.
+    - Inspect IAM role policies for privilege escalation.
+
+- **Hardening and preventive controls**
+  - Restrict the ability to call `StartExportTask` using:
+    - IAM least-privilege policies.
+    - Service Control Policies (SCPs) in production accounts.
+    - Conditional IAM (e.g., requiring MFA, restricting by VPC endpoint or IP range).
+  - Enable guardrails:
+    - AWS Config/Security Hub controls for monitoring snapshot policy changes.
+    - Alerts for exports to buckets outside approved accounts.
+
+### 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/AmazonRDS/latest/APIReference/API_StartExportTask.html"]
 risk_score = 21
 rule_id = "119c8877-8613-416d-a98a-96b6664ee73a"
@@ -67,6 +137,7 @@ tags = [
     "Data Source: AWS",
     "Data Source: Amazon Web Services",
     "Use Case: Asset Visibility",
+    "Tactic: Collection",
     "Tactic: Exfiltration",
     "Resources: Investigation Guide",
 ]
@@ -74,7 +145,10 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:StartExportTask and event.outcome:success
+event.dataset: aws.cloudtrail 
+    and event.provider: rds.amazonaws.com 
+    and event.action: StartExportTask 
+    and event.outcome: success
 '''
 
 
@@ -85,4 +159,38 @@ framework = "MITRE ATT&CK"
 id = "TA0010"
 name = "Exfiltration"
 reference = "https://attack.mitre.org/tactics/TA0010/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1213"
+name = "Data from Information Repositories"
+reference = "https://attack.mitre.org/techniques/T1213/"
+[[rule.threat.technique.subtechnique]]
+id = "T1213.006"
+name = "Databases"
+reference = "https://attack.mitre.org/techniques/T1213/006/"
+
+
+
+[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",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
 

nldcsc_elastic_rules/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml

@@ -2,16 +2,23 @@
 creation_date = "2024/06/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/12/05"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies an AWS RDS DB snapshot being shared with another AWS account. DB snapshots contain a full backup of an entire DB instance including sensitive data that can be abused if shared with unauthorized accounts or made public. Adversaries may use snapshots to restore a DB Instance in an environment they control as a means of data exfiltration.
+Identifies when an AWS RDS DB snapshot is shared with another AWS account or made public. DB snapshots contain complete
+backups of database instances, including schemas, table data, and sensitive application content. When shared externally,
+snapshots can be restored in another AWS environment, enabling unauthorized access, offline analysis, or data
+exfiltration. Adversaries who obtain valid credentials or exploit misconfigurations may modify snapshot attributes to
+grant access to accounts they control, bypassing network, IAM, and monitoring controls.
 """
+event_category_override = "event.type"
 false_positives = [
     """
-    DB snapshot sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action.
+    Cross-account DB snapshot sharing is common in multi-account AWS Organizations, particularly for backup workflows,
+    migrations, analytics pipelines, and disaster recovery. Ensure the added account is expected, previously approved,
+    and aligns with operational change plans before taking action.
     """,
 ]
 from = "now-6m"
@@ -19,43 +26,94 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Snapshot Shared with Another Account"
-note = """
-## Triage and analysis
+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 RDS DB Snapshot Shared with Another Account
 
-This rule identifies when an RDS DB snapshot is shared with another AWS account. While sharing DB snapshots is a common practice, adversaries may exploit this feature to exfiltrate data by sharing snapshots with external accounts under their control.
+Amazon RDS DB snapshots capture full backups of database instances and clusters. Modifying a snapshot’s restore
+attributes to include external AWS accounts allows those accounts to restore and fully access the underlying data.
+While cross-account snapshot sharing is widely used for migrations and disaster-recovery workflows, adversaries may
+abuse this mechanism for stealthy data exfiltration, restoring the snapshot in infrastructure they control, outside of your monitoring boundary.
+
+This rule detects successful modifications to snapshot attributes where one or more additional AWS accounts are added to the snapshot’s restore permissions.
+
+#### Possible investigation steps
+
+- **Identify the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.
+  - Determine whether the caller is an automation role, interactive user, CI/CD pipeline, or previously unseen principal.
+  - Check `source.ip` and `user_agent.original` for signs of unauthorized access or atypical tooling.
+
+- **Understand what snapshot was shared**
+  - From `aws.cloudtrail.request_parameters`, extract:
+    - The snapshot or cluster snapshot identifier.
+    - The list of `valuesToAdd` accounts added to `attributeName=restore`.
+  - Identify the associated database instance or cluster and evaluate:
+    - Data classification level (PII, customer data, secrets, credentials, financials, etc.)
+    - Application ownership and business impact.
+
+- **Validate the external account**
+  - Determine whether the recipient account:
+    - Belongs to your AWS Organization.
+    - Has previously been authorized for snapshot restore operations.
+    - Represents a new or unexpected dependency.
+  - Cross-reference with known partner accounts or migration plans.
+
+- **Correlate with related activity**
+  - Pivot in CloudTrail on the same user identity or account to identify:
+    - Prior reconnaissance actions (`DescribeDBSnapshots`, `DescribeDBInstances`).
+    - Snapshot copying or creation of manual snapshots just before sharing.
+    - IAM privilege escalation (`AttachRolePolicy`, `PutUserPolicy`, `AssumeRole` patterns).
+    - Unusual RDS configuration changes (backup retention decrease, deletion protection toggles).
+
+- **Assess for exfiltration indicators**
+  - Look for:
+    - Subsequent `CopyDBSnapshot` or `StartExportTask` events.
+    - Snapshot downloads, exports, or restoration from the external account.
+    - Snapshot attributes set to `all` (public sharing), which is extremely dangerous.
 
-#### Possible Investigation Steps
+- **Validate operational intent**
+  - Contact application owners, DBAs, or platform teams to confirm:
+    - Whether migration, replication, or DR workflows explain the share.
+    - Whether new accounts were intentionally onboarded.
+    - Whether the timing aligns with approved change windows.
 
-- **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 Sharing Event**: Identify the DB snapshot involved and review the event details. Look for `ModifyDBSnapshotAttribute` or `ModifyDBClusterSnapshotAttribute` actions where the snapshot attributes were changed to include additional user accounts.
-    - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` fields in the CloudTrail event to identify the DB Snapshot Identifier and account ID with which the snapshot was shared.
-- **Verify the Shared Snapshot**: Check the DB snapshot that was shared and its contents to determine the sensitivity of the data stored within it.
-- **Validate External Account**: Examine the AWS account to which the snapshot was shared. Determine whether this account is known and previously authorized to access such resources.
-- **Contextualize with Recent Changes**: Compare this sharing event against recent changes in RDS DB or Cluster configurations and deployments. Look for any other recent permissions changes or unusual administrative actions.
-- **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.
-- **Interview Relevant Personnel**: If the share was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing DB backups and snapshots.
+### False positive analysis
 
-### False Positive Analysis
+- **Legitimate migration or DR workflows**
+  - Many organizations routinely share snapshots with other accounts for staging, analytics, or DR replication.
 
-- **Legitimate Backup Actions**: Confirm if the Db snapshot sharing aligns with scheduled backups or legitimate automation tasks.
-- **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.
+- **Automation roles**
+  - Infrastructure-as-code pipelines and backup automation tools may modify snapshot permissions as part of normal behavior.
 
-### Response and Remediation
+If behavior is expected and consistently performed by a known principal, tune the rule using exceptional user identities, service roles, or controlled organizational accounts.
 
-- **Immediate Review and Reversal**: If the change was unauthorized, update the snapshot permissions to remove any unauthorized accounts 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.
-- **Audit Snapshots and Policies**: Conduct a comprehensive audit of all snapshots and associated policies to ensure they adhere to the principle of least privilege.
-- **Policy Update**: Review and possibly update your organization’s policies on DB snapshot sharing to tighten control and prevent unauthorized access.
-- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.
+### Response and remediation
 
-### Additional Information:
+- **Revoke unauthorized sharing**
+  - Immediately remove unauthorized accounts from snapshot restore attributes.
+  - Ensure the snapshot is not publicly shared.
 
-For further guidance on managing DB backups and securing AWS environments, refer to the [AWS RDS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_CommonTasks.BackupRestore.html) and AWS best practices for security. Additionally, consult the following resources for specific details on DB snapshot security:
-- [AWS RDS DB Snapshot Sharing](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html)
-- [AWS RDS ModifyDBSnapshotAttribute](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshotAttribute.html)
-- [AWS RDS Snapshot Dump](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation#rds-modifydbsnapshotattribute-rds-createdbsnapshot)
+- **Contain potential compromise**
+  - Rotate access keys or credentials for the principal that performed the modification.
+  - Review IAM permissions to ensure only approved roles can share snapshots.
+
+- **Assess impact**
+  - Determine whether the external account restored the snapshot and accessed data.
+  - If data exposure is likely, notify compliance, legal, and incident response teams.
+
+- **Hardening and preventive controls**
+  - Restrict snapshot sharing via IAM condition keys (`kms:ViaService`, `rds:dbSnapshotArn`, `aws:PrincipalArn`).
+  - Use AWS Organizations SCPs to block cross-account snapshot sharing in production accounts.
+  - Enable Config rules and Security Hub controls for public or cross-account snapshot access.
+
+### 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/AmazonRDS/latest/APIReference/API_ModifyDBSnapshotAttribute.html",
@@ -78,7 +136,7 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail"
+info where event.dataset == "aws.cloudtrail"
     and event.provider == "rds.amazonaws.com"
     and event.outcome == "success"
     and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute")
@@ -86,6 +144,7 @@ any where event.dataset == "aws.cloudtrail"
     and stringContains(aws.cloudtrail.request_parameters, "valuesToAdd=[*]")
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
@@ -93,8 +152,27 @@ 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.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",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements",
+]
+

nldcsc_elastic_rules/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml

@@ -2,7 +2,7 @@
 creation_date = "2024/04/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/10/30"
+updated_date = "2025/12/04"
 
 [rule]
 author = ["Elastic"]
@@ -136,6 +136,7 @@ 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, "AWS=") or 

nldcsc_elastic_rules/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml

@@ -2,16 +2,24 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/12/04"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies when the `PutBucketReplication` operation is used to replicate S3 objects to a bucket in another AWS account. Adversaries may use bucket replication to exfiltrate sensitive data to an environment they control.
+Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a
+different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and
+multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently
+exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where
+the configured destination account differs from the source bucket's account, indicating potential unauthorized
+cross-account data movement.
 """
+event_category_override = "event.type"
 false_positives = [
     """
-    Bucket replication accross accounts is a legitimate practice in some AWS environments. Ensure that the sharing is authorized before taking action.
+    Cross-account S3 replication is common in multi-account AWS Organizations, centralized logging architectures, and
+    disaster-recovery designs. Confirm whether the destination account is an approved replication target. Unexpected
+    replication configuration changes should be treated as suspicious.
     """,
 ]
 from = "now-6m"
@@ -19,39 +27,97 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Replicated to Another Account"
-note = """
-## Triage and analysis
+note = """## Triage and analysis
 
 ### Investigating AWS S3 Bucket Replicated to Another Account
 
-This rule identifies when an S3 bucket is replicated to another AWS account. While sharing bucket replication is a common practice, adversaries may exploit this feature to exfiltrate data by replicating objects to external accounts under their control.
+Cross-account S3 replication enables automated copying of S3 objects into a different AWS bucket. While useful for backup and organizational data flows, adversaries may exploit it as a covert exfiltration channel. Once replication is configured, any future writes to the bucket are silently copied to the destination bucket—even if object-level access controls block the attacker’s direct downloads. For this reason, unauthorized replication configuration should be considered high-risk.
 
-#### Possible Investigation Steps
+This rule detects successful `PutBucketReplication` events and flags cases where the replication configuration specifies a destination AWS account different from the source.
 
-- **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 Sharing Event**: Identify the S3 bucket involved and review the event details. Look for `PutBucketReplication` actions where an `Account` key-value pair is included signifying replication to an external account.
-    - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` fields in the CloudTrail event to identify the role used and account ID where the bucket was replicated.
-- **Verify the Shared Bucket**: Check the S3 bucket that was replicated and its contents to determine the sensitivity of the data stored within it.
-- **Validate External Account**: Examine the AWS account to which the bucket was replicated. Determine whether this account is known and previously authorized to access such resources.
-- **Contextualize with Recent Changes**: Compare this sharing event against recent changes in S3 configurations. Look for any other recent permissions changes or unusual administrative actions.
-- **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.
-- **Interview Relevant Personnel**: If the share was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing DB backups and snapshots.
+#### Possible investigation steps
 
-### False Positive Analysis
+**Understand who initiated the replication change**
+- Inspect `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify the actor.
+- Review authentication patterns such as federated session names, role chaining via STS, or unfamiliar IAM roles.
+- Examine `source.ip`, `source.geo` fields, and `user_agent.original` for unusual locations, automation tools, or anomalous access paths.
 
-- **Legitimate Backup Actions**: Confirm if the S3 bucket replication aligns with scheduled backups or legitimate automation tasks.
-- **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.
+**Examine the replication rule details**
+- Inspect `aws.cloudtrail.request_parameters` for:
+  - The **destination account ID** (`Account=`).
+  - The **IAM role ARN** used for replication. (`Role=`)
+  - Any filtering rules (prefixes, tags) that narrow or broaden what will be replicated.
 
-### Response and Remediation
+**Determine whether the destination account is authorized**
+- Validate whether the destination AWS account belongs to your AWS Organization.
+- Check internal documentation, IaC templates, or tagging standards to confirm whether replication to this account is expected.
+- Look for prior legitimate infrastructure workflows such as:
+  - Centralized logging
+  - Backup/DR accounts
+  - Cross-region compliance replicas
 
-- **Immediate Review and Reversal**: If the change was unauthorized, update the S3 configurations to remove any unauthorized replication rules.
-- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
-- **Policy Update**: Review and possibly update your organization’s policies on S3 bucket/object sharing to tighten control and prevent unauthorized access.
-- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.
+Unrecognized accounts should be treated as a strong exfiltration signal.
 
-### Additional Information:
+**Assess the scope of potential data exposure**
+- Determine whether the bucket contains sensitive or regulated data (PII, financial records, secrets, logs, etc.).
+- Identify whether object versioning, lifecycle rules, or access logging were modified recently.
+- Check for preceding or subsequent actions such as:
+  - `PutBucketPolicy` updates granting new principals access
+  - Creation or modification of IAM roles tied to replication
+  - `DeleteObject` or `PutObjectRetention` attempts that might pair with exfiltration
 
-For further guidance on managing and securing S3 buckets in AWS environments, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security.html/) and AWS best practices for security.
+**Correlate with other suspicious activity**
+Pivot in CloudTrail on the same principal or same bucket:
+- Prior reconnaissance such as `ListBuckets`, `GetBucketReplication`, or `GetBucketPolicy`
+- Modification of KMS policies or unexpected encryption key usage
+- New access patterns from external IP addresses or unusual automation
+
+### False positive analysis
+
+**Legitimate cross-account replication**
+Validate:
+- The destination account belongs to a known OU or business unit
+- The replication role ARN matches expected automation
+- The change aligns with documented deployment or maintenance schedules
+
+**Temporary migrations or transitions**
+During account restructuring or workload migration, administrators may temporarily redirect replication to new accounts.
+
+Tuning options:
+- Exception lists based on IAM role ARNs
+- Tag-based environment scoping
+- Change-window-based suppression
+
+### Response and remediation
+
+**Contain potential exfiltration**
+- Remove or update replication rules to eliminate unauthorized destinations.
+- Disable or restrict the replication IAM role until the investigation is complete.
+- Review S3 object access logs to determine whether data has begun replicating to the external account.
+
+**Investigate scope and impact**
+- Identify the volume and types of data at risk of replication.
+- Determine whether the external bucket shows successful replication traffic (if logs or access are available).
+- Assess whether the actor also modified bucket policies, encryption settings, or KMS keys.
+
+**Credential and role hygiene**
+- Rotate credentials for the initiating user or role if compromise is suspected.
+- Review IAM role trust policies, especially if STS sessions or EC2 role assumptions were involved.
+- Enable MFA and tighten conditions for administrative roles capable of modifying replication.
+
+**Hardening and preventive controls**
+- Enforce SCPs that restrict cross-account replication except for explicitly approved destinations.
+- Require approval workflows before modifying replication or retention settings.
+- Use AWS Config and Security Hub controls to detect:
+  - Buckets with unexpected replication rules
+  - Newly added cross-account permissions
+  - Changes to bucket policies, block-public-access settings, or KMS key policies
+
+### 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/AmazonS3/latest/userguide/replication-walkthrough-2.html/",
@@ -73,12 +139,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail"
+info where event.dataset == "aws.cloudtrail"
    and event.action == "PutBucketReplication"
    and event.outcome == "success"
-   and stringContains(aws.cloudtrail.request_parameters, "Account")
+   and stringContains(aws.cloudtrail.request_parameters, "Account=")
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
@@ -86,8 +153,28 @@ 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.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",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+]
+