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

nldcsc_elastic_rules/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml

@@ -2,16 +2,21 @@
 creation_date = "2024/06/28"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/11/24"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the modification of an AWS RDS DB instance or cluster to remove the deletionProtection feature. Deletion protection is enabled automatically for instances set up through the console and can be used to protect them from unintentional deletion activity. If disabled an instance or cluster can be deleted, destroying sensitive or critical information. Adversaries with the proper permissions can take advantage of this to set up future deletion events against a compromised environment.
+Identifies the modification of an AWS RDS DB instance or cluster to disable the deletionProtection feature. Deletion
+protection prevents accidental or unauthorized deletion of RDS resources. Adversaries with sufficient permissions may
+disable this protection as a precursor to destructive actions, including the deletion of databases containing sensitive
+or business-critical data. This rule alerts when deletionProtection is explicitly set to false on an RDS DB instance or
+cluster.
 """
 false_positives = [
     """
-    The deletionProtection feature must be disabled as a prerequisite for deletion of a DB instance or cluster. Ensure that the instance should not be modified in this way before taking action.
+    The deletionProtection feature must be disabled as a prerequisite for deletion of a DB instance or cluster. Ensure
+    that the instance should not be modified in this way before taking action.
     """,
 ]
 from = "now-6m"
@@ -19,40 +24,79 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance or Cluster Deletion Protection Disabled"
-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, validate and adapt it to suit your operational needs.
 
 ### Investigating AWS RDS DB Instance or Cluster Deletion Protection Disabled
+ 
+Deletion protection is designed to safeguard RDS DB instances and clusters from accidental or unauthorized deletion. An adversary with privileged access in a compromised environment, can disable this safeguard before issuing a `DeleteDBInstance` or `DeleteDBCluster` action. This rule detects successful attempts to modify deletionProtection and set it to false on any RDS instance or cluster.
+
+#### Possible investigation steps
+
+- **Identify the Actor**
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `access_key_id` to determine which IAM principal made the change.
+  - Validate whether this principal normally performs RDS lifecycle operations.
+
+- **Review Event Details**
+  - Inspect `aws.cloudtrail.request_parameters` or `target.entity.id` to confirm the targeted DB instance or cluster identifier.
+  - Confirm that the request explicitly contains `deletionProtection=false`.
+
+- **Contextualize the Change**
+  - Determine if recent activities justify the removal of deletion protection (migration, decommissioning, or maintenance).
+  - Compare the timestamp to normal operational hours or deployment windows.
+
+- **Correlate with Additional Activity**
+  - Look for subsequent or preceding RDS actions such as:
+    - `DeleteDBInstance`
+    - `DeleteDBCluster`
+    - Security group modifications
+    - Changes to parameter groups or backup retention policies.
+  - Sudden removal of backups or snapshots may indicate imminent destructive activity.
+
+- **Verify Environmental Risk**
+  - Assess the sensitivity of data stored in the affected DB instance or cluster.
+  - Determine if the instance is production, customer-facing, or mission-critical.
 
-This rule identifies when the deletion protection feature is removed from an RDS DB instance or cluster. Removing deletion protection is a prerequisite for deleting a DB instance. Adversaries may exploit this feature to permanently delete data in a compromised environment.
+- **Interview Relevant Personnel**
+  - Confirm with service owners or DB administrators whether the modification was intended and approved.
 
-#### Possible Investigation Steps
+### False positive analysis
 
-- **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 Modification Event**: Identify the DB instance involved and review the event details. Look for `ModifyDBInstance` actions where the deletionProtection parameter was changed.
-    - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` field in the CloudTrail event to identify the DB instance or cluster identifier and any other modifications made to the instance.
-- **Verify the Modified Instance**: Check the DB instance that was modified and its contents to determine the sensitivity of the data stored within it.
-- **Contextualize with Recent Changes**: Compare this modification event against recent changes in RDS DB instance 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 modification was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing DB instances.
-### False Positive Analysis
+- **Expected Decommissioning**
+  - Instances undergoing teardown or migration legitimately require deletion protection to be disabled first.
 
-- **Legitimate Instance Modification**: Confirm if the DB instance modification aligns with legitimate 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.
+- **Inconsistent Historical Behavior**
+  - Compare the action to historical modification patterns for the user or role. If the action aligns with past legitimate changes, it may not be suspicious.
 
-### Response and Remediation
+### Response and remediation
 
-- **Immediate Review and Reversal**: If the change was unauthorized, reset deletionProtection to true.
-- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
-- **Audit Instances and Policies**: Conduct a comprehensive audit of all instances 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 instance access 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.
+- **Immediate Remediation**
+  - If unauthorized, re-enable deletion protection (`deletionProtection=true`) on the affected DB instance or cluster.
+  - Review security groups, backup retention, and snapshot policies for additional unauthorized changes.
 
-### Additional Information:
+- **Access Review**
+  - Investigate credential exposure for the IAM principal that performed the action.
+  - Rotate access keys or temporarily revoke permissions if compromise is suspected.
 
-For further guidance on managing DB instances and securing AWS environments, refer to the [AWS RDS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_RDS_Managing.html) and AWS best practices for security. Additionally, consult the following resources for specific details on DB instance security:
-- [AWS RDS ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)
-- [Deleting AWS RDS DB Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html)
+- **Containment**
+  - If destructive intent is suspected, apply guardrails (e.g., IAM condition keys, SCPs) to prevent DB deletion.
+
+- **Audit and Harden**
+  - Ensure RDS instances adhere to least-privilege principles.
+  - Restrict who can modify `ModifyDBInstance` or `ModifyDBCluster` destructive settings, such as deletion protection, backup retention, and public accessibility.
+
+- **Incident Response Activation**
+  - Treat unauthorized removal of deletion protection as a high-risk precursor to data destruction.
+  - Trigger IR processes for containment, root cause analysis, and post-incident hardening.
+
+### 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_ModifyDBInstance.html",
@@ -95,3 +139,21 @@ 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",
+    "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/impact_rds_snapshot_deleted.toml

@@ -2,16 +2,22 @@
 creation_date = "2024/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/11/24"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the deletion of an AWS RDS DB snapshot. Snapshots contain a full backup of an entire DB instance. Unauthorized deletion of snapshots can make it impossible to recover critical or sensitive data. This rule detects deleted snapshots and instances modified so that backupRetentionPeriod is set to 0 which disables automated backups and is functionally similar to deleting the system snapshot.
+Identifies the deletion of an AWS RDS DB snapshot or configuration changes that effectively remove backup coverage for a
+DB instance. RDS snapshots contain full backups of database instances, and disabling automated backups by setting
+"backupRetentionPeriod=0" has a similar impact by preventing future restore points. Adversaries with the appropriate
+permissions may delete snapshots or disable backups to inhibit recovery, destroy forensic evidence, or prepare for
+follow-on destructive actions such as instance or cluster deletion.
 """
 false_positives = [
     """
-    Snapshots may be deleted by a system administrator. Verify whether the user identity should be making changes in your environment. Snapshot deletions by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    Snapshots may be deleted by a system administrator. Verify whether the user identity should be making changes in
+    your environment. Snapshot 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-6m"
@@ -19,6 +25,103 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS Snapshot Deleted"
+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, validate and adapt it to suit your operational needs.
+
+### Investigating AWS RDS Snapshot Deleted
+
+AWS RDS snapshots (manual or automated) and backup retention settings are core to database recovery and incident response. Deleting snapshots or disabling automated backups (`backupRetentionPeriod=0`) can prevent restoration to a known-good state and destroy forensic evidence of attacker actions.
+
+This rule detects successful snapshot deletions and configuration changes that disable automated backups. Activity that matches this pattern may indicate destructive actions, ransomware preparation, cleanup after data theft, or an operator misconfiguration that materially weakens recovery options.
+
+#### Possible investigation steps
+
+- **Identify the actor and context**
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action.
+  - Check `user.name`, `source.ip`, and `user_agent.original` to understand where and how the change was made (console, CLI, SDK, automation).
+
+- **Determine what was affected**
+  - Inspect `aws.cloudtrail.request_parameters` to identify:
+    - The snapshot or cluster snapshot identifier (`DeleteDBSnapshot` / `DeleteDBClusterSnapshot`).
+    - The DB instance identifier and the new `backupRetentionPeriod` value for `ModifyDBInstance`.
+  - Map the snapshot/instance to:
+    - Application/owner team.
+    - Environment (prod, staging, dev).
+    - Data sensitivity or criticality.
+
+- **Reconstruct intent and timing**
+  - Use `@timestamp` to correlate the event with:
+    - Recent `ModifyDBInstance`, `ModifyDBCluster`, `DeleteDBInstance`, or `DeleteDBCluster` events.
+    - Other data-impacting changes (e.g., `deletionProtection=false`, security group changes, public accessibility, or RDS parameter modifications).
+  - Compare the timing against approved maintenance/change windows and deployment pipelines.
+
+- **Correlate with broader activity**
+  - In CloudTrail, pivot on:
+    - The same `aws.cloudtrail.user_identity.arn` or access key ID.
+    - The same DB instance/cluster identifiers.
+  - Look for:
+    - Suspicious reads or exports before deletion (`DescribeDBSnapshots`, `CopyDBSnapshot`, data export, or large `SELECT` / dump activity visible via other telemetry).
+    - Follow-on destructive actions (DB instance deletion, subnet/security group changes that isolate monitoring tools, or IAM policy changes).
+  - Verify whether other snapshots for the same instance or account were deleted in the same time window.
+
+- **Validate intent with owners**
+  - Confirm with the DB/application owner and platform/DBA teams whether:
+    - The snapshot deletion or backup change was requested and approved.
+    - There are parallel infrastructure changes (migrations, environment teardown, or cost-optimization tasks) that explain the activity.
+
+### False positive analysis
+
+- **Planned lifecycle and cost optimization**
+  - Many environments routinely prune old snapshots or adjust backup retention for non-production workloads.
+
+- **Automated backup and housekeeping tools**
+  - Backup or housekeeping services may manage snapshots and retention. This rule already excludes typical `backup.amazonaws.com` events, but you should:
+    - Identify any additional in-house or third-party automation roles.
+    - Tune the rule with exceptions based on `user_agent.original`, `aws.cloudtrail.user_identity.arn`, or known service roles.
+
+### Response and remediation
+
+- **Contain and restore protection**
+  - If activity appears unauthorized:
+    - Immediately review the affected DB instances and clusters and restore `backupRetentionPeriod` to an appropriate value.
+    - Verify that deletion protection and other guardrails are enabled where applicable.
+  - For snapshot deletions, assess:
+    - Whether alternate snapshots (manual or automated) are still available.
+    - Whether point-in-time recovery is still possible based on transaction logs and remaining backups.
+
+- **Investigate scope and impact**
+  - Use CloudTrail to:
+    - Enumerate all recent snapshot deletions and backup configuration changes by the same actor or from the same `source.ip`.
+    - Identify any subsequent `DeleteDBInstance`, `DeleteDBCluster`, or public exposure (`publiclyAccessible=true`) events.
+  - Engage the application and data owners to:
+    - Evaluate potential data loss, downtime impact, and regulatory implications.
+    - Determine if any sensitive or compliance-bound data may be unrecoverable.
+
+- **Hardening and preventive controls**
+  - Restrict RDS administration:
+    - Limit `rds:DeleteDBSnapshot`, `rds:DeleteDBClusterSnapshot`, and `rds:ModifyDBInstance` (especially backup and deletion-related parameters) to a small set of privileged roles.
+    - Use IAM conditions (e.g., `aws:PrincipalArn`, `aws:RequestedRegion`) to constrain where and by whom destructive actions can be performed.
+  - Add guardrails:
+    - Use AWS Config rules and/or Security Hub controls to detect:
+      - Instances with `backupRetentionPeriod=0`.
+      - Instances lacking deletion protection or cross-region/cross-AZ backup strategy.
+    - Consider SCPs in AWS Organizations to block or tightly control destructive RDS APIs in production accounts.
+
+- **Post-incident improvements**
+  - If malicious or unsafe behavior is confirmed:
+    - Rotate credentials for the involved principals and review STS session usage.
+    - Update runbooks and change management to explicitly track snapshot and backup policy changes.
+    - Refine this rule’s exceptions, tags, or severity to better align with your environment while preserving coverage for truly risky 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://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteSnapshot.html",
     "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSnapshot.html",
@@ -46,41 +149,11 @@ any where event.dataset == "aws.cloudtrail"
         event.action in ("DeleteDBSnapshot", "DeleteDBClusterSnapshot") or
         (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "backupRetentionPeriod=0"))
     )
+    and not (
+        user_agent.original == "backup.amazonaws.com" 
+        and source.address == "backup.amazonaws.com"
+    )
 '''
-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 Snapshot Deleted
-
-AWS RDS snapshots are critical for data recovery, capturing full backups of database instances. Adversaries may delete these snapshots to prevent data restoration, effectively causing data loss. The detection rule monitors AWS CloudTrail logs for successful deletion actions or modifications that disable automated backups, signaling potential malicious activity aimed at data destruction.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to identify the user or role associated with the event.action values "DeleteDBSnapshot" or "DeleteDBClusterSnapshot" to determine if the action was authorized or expected.
-- Check the timestamp of the deletion event to correlate with any known maintenance activities or incidents that might explain the snapshot deletion.
-- Investigate the source IP address and location from which the deletion request was made to identify any anomalies or unauthorized access patterns.
-- Examine the AWS IAM policies and permissions associated with the user or role to ensure they have the appropriate level of access and to identify any potential over-permissioning.
-- Look for any recent changes in the AWS environment, such as modifications to IAM roles or policies, that could have allowed unauthorized snapshot deletions.
-- If the event.action is "ModifyDBInstance" with "backupRetentionPeriod=0", verify if there was a legitimate reason for disabling automated backups and assess the impact on data recovery capabilities.
-
-### False positive analysis
-
-- Routine maintenance activities by database administrators may involve deleting old or unnecessary snapshots. To manage this, create exceptions for specific user accounts or roles known to perform these tasks regularly.
-- Automated scripts or tools used for database management might delete snapshots as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated IAM roles or user accounts.
-- Testing environments often involve frequent creation and deletion of snapshots. Consider excluding specific RDS instances or environments used solely for testing purposes to reduce noise in alerts.
-- Scheduled cleanup jobs that remove outdated snapshots to manage storage costs can trigger false positives. Document these jobs and adjust the detection rule to ignore actions performed by these jobs' IAM roles.
-
-### Response and remediation
-
-- Immediately revoke access to AWS accounts or roles suspected of unauthorized activity to prevent further malicious actions.
-- Restore the deleted RDS snapshots from any available backups or replicas to ensure data recovery and continuity.
-- Enable and configure automated backups for the affected RDS instances to prevent future data loss, ensuring the backupRetentionPeriod is set to a non-zero value.
-- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized access patterns or anomalies leading up to the snapshot deletion.
-- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources were compromised.
-- Implement stricter IAM policies and multi-factor authentication for accessing AWS RDS resources to enhance security and prevent unauthorized deletions.
-- Update and test the incident response plan to include specific procedures for handling AWS RDS snapshot deletions, ensuring rapid response in future incidents."""
 
 
 [[rule.threat]]
@@ -96,3 +169,20 @@ 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",
+    "aws.cloudtrail.response_elements",
+]
+

nldcsc_elastic_rules/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml

@@ -2,61 +2,143 @@
 creation_date = "2024/07/02"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/07/16"
+updated_date = "2025/12/02"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption.
-Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS
-key to deny their victims access to their own data.
+Identifies use of the S3 CopyObject API where the destination object is encrypted using an AWS KMS key from an external
+AWS account. This behavior may indicate ransomware-style impact activity where an adversary with access to a
+misconfigured S3 bucket encrypts objects using a KMS key they control, preventing the bucket owner from decrypting their
+own data. This technique is a critical early signal of destructive intent or cross-account misuse.
 """
 false_positives = [
     """
-    Administrators within an AWS Organization structure may legitimately encrypt bucket objects with a key from an
-    account different from the target bucket. Ensure that this behavior is not part of a legitimate operation before
-    taking action.
+    Cross-account KMS key usage may be legitimate in multi-account AWS Organizations architectures where centralized
+    encryption keys are used for data governance or auditing workflows. Confirm whether the external KMS key belongs to
+    an expected account before taking action. Data migration or cross-account backup workflows may legitimately
+    re-encrypt S3 objects using a key in another account. Ensure these workflows are documented, tied to known IAM
+    roles, and occur on predictable schedules.
     """,
 ]
-from = "now-9m"
+from = "now-6m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS S3 Object Encryption Using External KMS Key"
 note = """## Triage and analysis
 
-### Investigating AWS S3 Object Encryption Using External KMS Key
-
-This rule detects the use of an external AWS KMS key to encrypt objects within an S3 bucket. Adversaries with access to a misconfigured S3 bucket may use an external key to copy objects within a bucket and deny victims the ability to access their own data.
-This rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule) to look for use of the `CopyObject` operation where the target bucket's `cloud.account.id` is different from the `key.account.id` dissected from the AWS KMS key used for encryption.
-
-#### 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 performed the action. 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 details of the `CopyObject` action. Look for any unusual parameters that could suggest unauthorized or malicious modifications or usage of an unknown KMS keyId.
-- **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 object was copied. Changes 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 action to see if the same actor or IP address engaged in other potentially suspicious activities.
-- **Check for Object Deletion or Access**: Look for `DeleteObject`, `DeleteObjects`, or `GetObject` API calls to the same S3 bucket that may indicate the adversary accessing and destroying objects including older object versions.
-- **Interview Relevant Personnel**: If the copy event was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing S3 buckets.
-
-### False Positive Analysis:
-
-- **Legitimate Administrative Actions**: Confirm if the `CopyObject` action aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management systems.
-- **Consistency Check**: Compare the action against historical data of similar activities performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
-
-### Response and Remediation:
+> **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, validate and adapt it to suit your operational needs.
 
-- **Immediate Review**: If the activity was unauthorized, search for potential ransom note placed in S3 bucket and review the bucket's access logs for any suspicious activity.
-- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar `CopyObject` actions, especially those involving sensitive data or unusual file extensions.
-- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning S3 bucket management and the risks of ransomware.
-- **Audit S3 Bucket Policies and Permissions**: Conduct a comprehensive audit of all S3 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 Object Encryption Using External KMS Key
 
-For further guidance on managing S3 bucket security and protecting against ransomware, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) and AWS best practices for security. Additionally, consult the following resources for specific details on S3 ransomware protection:
-- [ERMETIC REPORT - AWS S3 Ransomware Exposure in the Wild](https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf)
-- [S3 Ransomware Part 1: Attack Vector](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)
+This rule detects when an S3 `CopyObject` operation encrypts an object using a KMS key belonging to a different AWS account than the bucket owner. This behavior is unusual and a strong indicator of:
+
+- Cloud ransomware techniques, where adversaries encrypt data using a key only they control.
+- Cross-account privilege misuse, especially when an unauthorized principal has write access to S3.
+- Misconfigured bucket permissions, enabling principals from another account to perform privileged copy operations.
+- Early impact-stage activity in incidents where attackers prepare to destroy availability or deny the owner access.
+
+The rule uses ESQL to identify cases where the `cloud.account.id` (bucket owner) differs from the dissected `kms_key_account_id` used for encrypting the new object version.
+
+
+#### Possible investigation steps
+
+**Identify the actor and access pathway**
+- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.
+- Check whether the caller is:
+  - A legitimate cross-account automation role,  
+  - A compromised IAM user or workload identity, or  
+  - A federated identity behaving outside of normal patterns.
+- Inspect `user_agent.original` to determine whether the action came from the AWS Console, CLI, SDK, or unusual tooling.
+
+**Analyze the encryption behavior**
+- Inspect the dissected KMS key fields:
+  - `Esql.aws_cloudtrail_request_parameters_kms_key_account_id`
+  - `Esql.aws_cloudtrail_request_parameters_kms_key_id`
+- Confirm whether the external key:
+  - Belongs to an attacker-controlled account,  
+  - Is unknown to your organization, or  
+  - Lives in a shared or security tooling account.
+
+**Assess the objects affected**
+- Review:
+  - `Esql.aws_cloudtrail_request_parameters_target_bucket_name`
+  - `Esql.aws_cloudtrail_request_parameters_target_object_key`
+- Identify:
+  - Whether objects were overwritten or new encrypted copies were created.
+  - The sensitivity or criticality of the affected data.
+  - Whether object versioning is enabled (important for recovery).
+
+**Correlate surrounding access patterns**
+Pivot in CloudTrail on:
+- The same access key ID  
+- The same IAM principal  
+- Affected bucket ARN  
+
+Look for:
+- `DeleteObject` or `DeleteObjects` calls (common in ransomware behavior)
+- Mass enumeration prior to the event (`ListObjectsV2`, `GetObject`)
+- Other impact-stage actions (`PutBucketPolicy`, `PutBucketAcl`, disabling logging)
+- Attempts to encrypt additional objects in rapid succession
+
+**Evaluate bucket permissions and exposure**
+Review:
+- S3 bucket policy changes
+- IAM roles with `s3:PutObject` or `s3:PutObjectAcl` permissions
+- Whether unintended cross-account `Principal` entries exist
+- Whether the KMS key policy explicitly trusts your account or a foreign one
+
+**Validate business justification**
+- Confirm with storage, data engineering, or application teams whether:
+  - Any migration, transformation, or backup workflows should be encrypting objects cross-account.
+  - Scheduled jobs or CI/CD pipelines were operating at the time of the event.
+
+### False positive analysis
+
+- **Expected cross-account encryption**  
+  Many organizations use centralized encryption accounts or shared security accounts. Validate:
+  - Whether the KMS key account is part of your AWS Organization
+  - Whether the workflow, role, or application is documented
+  - Whether the principal routinely performs CopyObject operations
+
+### Response and remediation
+
+**Contain and prevent further impact**
+- Immediately restrict S3 write access for the principal involved.
+- If the KMS key is attacker-controlled, the impacted objects may be unrecoverable without versioning.
+- If object versioning is disabled, enable it on the affected bucket to strengthen future resilience.
+
+**Investigate scope and severity**
+- Identify:
+  - Additional objects encrypted using external keys
+  - Related suspicious actions (delete, modify, exfiltration events)
+  - Whether any ransom markers or unauthorized files were uploaded
+- Validate whether the external KMS key grants *decrypt* permission back to the bucket owner (rare in attacker use).
+
+**Recover and secure the bucket**
+- Restore accessible previous versions if versioning is enabled.
+- Revoke unauthorized access key pairs or session credentials.
+- Audit bucket policies, ACLs, and IAM conditions (`aws:PrincipalArn`, `aws:SourceAccount`, `aws:SourceArn`).
+- Tighten cross-account access controls:
+  - Remove unintended `Principal` clauses
+  - Restrict KMS usage to known accounts
+  - Enforce SCPs that block cross-account KMS use unless explicitly approved
+
+**Long-term hardening**
+- Integrate object-level access logging and S3 server access logging into security monitoring.
+- Add AWS Config rules (or Security Hub controls) detecting:
+  - Public buckets
+  - Cross-account access to S3
+  - KMS policies permitting foreign principals
+- Document required cross-account workflows and add explicit allowlists.
+
+### 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/UsingKMSEncryption.html/",
@@ -66,7 +148,7 @@ references = [
 ]
 risk_score = 47
 rule_id = "ab8f074c-5565-4bc4-991c-d49770e19fc9"
-setup = "AWS S3 data event types need to be enabled in the CloudTrail trail configuration."
+setup = "AWS S3 data event types need to be enabled in the CloudTrail trail configuration for CopyObject events."
 severity = "medium"
 tags = [
     "Domain: Cloud",
@@ -101,13 +183,25 @@ from logs-aws.cloudtrail-* metadata _id, _version, _index
 // keep ECS and dissected fields
 | keep
   @timestamp,
+  data_stream.namespace,
+  user.name,
+  user_agent.original,
+  source.ip,
   aws.cloudtrail.user_identity.arn,
-  cloud.account.id,
+  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,
   Esql.aws_cloudtrail_request_parameters_target_bucket_name,
+  Esql.aws_cloudtrail_request_parameters_target_object_key,
   Esql.aws_cloudtrail_request_parameters_kms_key_account_id,
-  Esql.aws_cloudtrail_request_parameters_kms_key_id,
-  Esql.aws_cloudtrail_request_parameters_target_object_key
+  Esql.aws_cloudtrail_request_parameters_kms_key_id
 '''
 
 
@@ -124,3 +218,26 @@ 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",
+    "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",
+    "Esql.aws_cloudtrail_request_parameters_target_bucket_name",
+    "Esql.aws_cloudtrail_request_parameters_target_object_key",
+    "Esql.aws_cloudtrail_request_parameters_kms_key_account_id",
+    "Esql.aws_cloudtrail_request_parameters_kms_key_id",
+]
+