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

nldcsc_elastic_rules/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml

@@ -0,0 +1,97 @@
+[metadata]
+creation_date = "2024/06/28"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/01/10"
+
+[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.
+"""
+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.
+    """,
+]
+from = "now-6m"
+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
+
+### Investigating AWS RDS DB Instance or Cluster Deletion Protection Disabled
+
+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.
+
+#### 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 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
+
+- **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.
+
+### 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.
+
+### Additional Information:
+
+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)
+"""
+references = [
+    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html",
+    "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html",
+]
+risk_score = 47
+rule_id = "f6652fb5-cd8e-499c-8311-2ce2bb6cac62"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS RDS",
+    "Resources: Investigation Guide",
+    "Use Case: Threat Detection",
+    "Tactic: Impact",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+any where event.dataset == "aws.cloudtrail"
+    and event.provider == "rds.amazonaws.com"
+    and event.action in ("ModifyDBInstance", "ModifyDBCluster")
+    and event.outcome == "success"
+    and stringContains(aws.cloudtrail.request_parameters, "deletionProtection=false")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1485"
+name = "Data Destruction"
+reference = "https://attack.mitre.org/techniques/T1485/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2020/05/20"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/11/21"
+
+[rule]
+author = ["Elastic"]
+description = "Identifies that an Amazon Relational Database Service (RDS) cluster or instance has been stopped."
+false_positives = [
+    """
+    Valid clusters or instances may be stopped by a system administrator. Verify whether the user identity, user agent,
+    and/or hostname should be making changes in your environment. Cluster or instance stoppages 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"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Deprecated - AWS RDS Instance/Cluster Stoppage"
+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 Deprecated - AWS RDS Instance/Cluster Stoppage
+
+Amazon RDS is a managed database service that simplifies database setup, operation, and scaling. Adversaries may stop RDS instances or clusters to disrupt services, potentially causing data unavailability or loss. The detection rule monitors AWS CloudTrail logs for successful stop actions on RDS resources, alerting analysts to potential unauthorized disruptions aligned with impact tactics.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the StopDBCluster or StopDBInstance action to determine if the action was authorized.
+- Check the event time and correlate it with any scheduled maintenance or known operational activities to rule out legitimate stoppage.
+- Investigate the source IP address and location from which the stop action was initiated to identify any anomalies or unauthorized access.
+- Examine the AWS IAM policies and permissions associated with the user or role to ensure they align with the principle of least privilege.
+- Look for any related alerts or logs around the same timeframe that might indicate a broader security incident or unauthorized access attempt.
+- Contact the relevant database or application owner to confirm whether the stoppage was planned or expected.
+
+### False positive analysis
+
+- Routine maintenance activities may trigger stop actions on RDS instances or clusters. To manage this, create exceptions for scheduled maintenance windows by excluding events occurring during these times.
+- Development and testing environments often involve frequent stopping and starting of RDS instances. Identify and exclude these environments from alerts by using tags or specific instance identifiers.
+- Automated scripts or tools used for cost-saving measures might stop RDS instances during off-peak hours. Review and whitelist these scripts by verifying their source and purpose.
+- User-initiated stop actions for legitimate reasons, such as troubleshooting or configuration changes, can be excluded by maintaining a list of authorized personnel and their activities.
+- CloudFormation or other infrastructure-as-code tools may stop RDS instances as part of deployment processes. Exclude these actions by identifying and filtering events associated with these tools.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the stop action by reviewing the associated CloudTrail logs, focusing on the user identity, source IP, and time of the event to determine if the action was authorized.
+- If unauthorized, isolate the affected RDS instance or cluster by disabling any associated IAM user or role that performed the stop action to prevent further unauthorized access.
+- Restore the RDS instance or cluster from the latest backup or snapshot to minimize data unavailability and ensure service continuity.
+- Conduct a root cause analysis to identify how the unauthorized stop action was executed, focusing on potential security gaps in IAM policies or network configurations.
+- Implement additional security measures, such as enabling multi-factor authentication (MFA) for all IAM users and roles with permissions to stop RDS instances or clusters.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted.
+- Update the incident response plan to include lessons learned from this event, ensuring quicker and more effective responses to similar threats in the future.
+
+## Setup
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/stop-db-cluster.html",
+    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopDBCluster.html",
+    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/stop-db-instance.html",
+    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopDBInstance.html",
+]
+risk_score = 47
+rule_id = "ecf2b32c-e221-4bd4-aa3b-c7d59b3bc01d"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS RDS",
+    "Use Case: Asset Visibility",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(StopDBCluster or StopDBInstance) and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1489"
+name = "Service Stop"
+reference = "https://attack.mitre.org/techniques/T1489/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/aws/impact_rds_snapshot_deleted.toml

@@ -0,0 +1,98 @@
+[metadata]
+creation_date = "2024/06/29"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[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.
+"""
+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.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "AWS RDS Snapshot Deleted"
+references = [
+    "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteSnapshot.html",
+    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSnapshot.html",
+]
+risk_score = 47
+rule_id = "b36c99af-b944-4509-a523-7e0fad275be1"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS RDS",
+    "Use Case: Asset Visibility",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+any where event.dataset == "aws.cloudtrail"
+    and event.provider == "rds.amazonaws.com"
+    and event.outcome == "success"
+    and (
+        event.action in ("DeleteDBSnapshot", "DeleteDBClusterSnapshot") or
+        (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "backupRetentionPeriod=0"))
+    )
+'''
+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]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1485"
+name = "Data Destruction"
+reference = "https://attack.mitre.org/techniques/T1485/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml

@@ -0,0 +1,155 @@
+[metadata]
+creation_date = "2024/04/17"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call
+with a common ransomware note file name or extension such as ransom or .lock. Adversaries with access to a misconfigured
+S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.
+"""
+false_positives = [
+    """
+    Administrators may legitimately access, delete, and replace objects in S3 buckets. Ensure that the uploaded files are not part of a legitimate operation before taking action.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential AWS S3 Bucket Ransomware Note Uploaded"
+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 Potential AWS S3 Bucket Ransomware Note Uploaded
+
+This rule detects a successful `PutObject` to S3 where the object key matches common ransomware-note patterns (for example, `readme`, `how_to_decrypt`, `decrypt_instructions`, `ransom`, `lock`). Attackers who obtain credentials or abuse overly-permissive bucket policies can upload ransom notes (often after deleting or encrypting data).
+
+#### Possible Investigation Steps:
+- **Confirm the actor and session details.** Review `aws.cloudtrail.user_identity.*` (ARN, type, access key, session context), `source.ip`, `user.agent`, and `tls.client.server_name` to identify *who* performed the upload and *from where*. Validate whether this principal typically writes to this bucket. 
+- **Inspect the object key and bucket context.** From `aws.cloudtrail.request_parameters`, capture the exact `key` and `bucketName`. Check whether the key is publicly readable (ACL), whether the bucket is internet-exposed, and whether replication or lifecycle rules could propagate or remove related objects. 
+- **Pivot to related S3 activity around the same time.** Look for `DeleteObject`/`DeleteObjects`, mass `PutObject` spikes, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, and `PutBucketLifecycleConfiguration` events on the same bucket or by the same actor to determine if data destruction, policy tampering, or guard-rail changes occurred. 
+- **Assess blast radius across the account.** Search recent CloudTrail for the same actor/IP touching other buckets, KMS keys used by those buckets, and IAM changes (new access keys, policy attachments, role assumptions) that could indicate broader compromise paths consistent with ransomware playbooks. 
+- **Check protections and recovery posture on the bucket.** Verify whether S3 Versioning and (if in use) Object Lock legal hold are enabled; note prior versions available for the affected key, and whether lifecycle rules might expire them. 
+- **Correlate with threat signals.** Review other related alerts, GuardDuty S3-related findings, AWS Config drift on the bucket and its policy, and any SOAR/IR runbook executions tied to ransomware triage. 
+
+### False Positive Analysis:
+- **Planned tests or red-team exercises.** Confirm change tickets or test windows for staging/dev buckets; red teams often drop “ransom-note-like” files during exercises. 
+- **Benign automation naming.** Some data-migration or backup tools may use “readme”/“recovery”-style filenames; validate by `user.agent`, principal, and target environment (dev vs prod). 
+- **Log/archive buckets.** Exclude infrastructure/logging buckets (for example, `AWSLogs`, CloudTrail, access logs) per rule guidance to reduce noise. 
+
+### Response and Remediation:
+
+**1. Immediate, low-risk actions (safe for most environments)**
+- **Preserve context:** Export the triggering `PutObject` CloudTrail record(s), plus 15–30 min before/after, to an evidence bucket (restricted access). 
+- **Snapshot configuration:** Record current bucket settings (Block Public Access, Versioning, Object Lock, Bucket Policy, Lifecycle rules) and any KMS keys used.
+- **Quiet the spread:** Pause destructive automation: disable/bypass lifecycle rules that would expire/delete object versions; temporarily pause data pipelines targeting the bucket.
+- **Notify owners:** Inform the bucket/application owner(s) and security leadership.
+
+**2. Containment options (choose the least disruptive first)**
+- **Harden exposure:** If not already enforced, enable `Block Public Access` for the bucket.
+- **Targeted deny policy (temporary):** Add a restrictive bucket policy allowing only IR/admin roles while you scope impact. Reconfirm critical workload dependencies before applying.
+- **Credential risk reduction:** If a specific IAM user/key or role is implicated, rotate access keys; for roles, remove risky policy attachments or temporarily restrict with an SCP/deny statement.
+
+**3. Evidence preservation**
+- Export relevant CloudTrail events, S3 server/access logs (if enabled), AWS Config history for the bucket/policy, and the suspicious object plus its previous versions (if Versioning is enabled).
+- Document actor ARN, source IPs, user agent(s), exact `bucketName`/`key`, and timestamps. Maintain a simple chain-of-custody note for collected artifacts.
+
+**4. Scope and hunting (same actor/time window)**
+- Look for `DeleteObject(s)`, unusual `PutObject` volume, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning` changes, `PutBucketLifecycleConfiguration`, and cross-account access.
+- Cross reference other buckets touched by the same actor/IP; recent IAM changes (new keys, policy/role edits); GuardDuty findings tied to S3/credentials.
+
+**5. Recovery (prioritize data integrity)**
+- If Versioning is enabled, restore last known-good versions for impacted objects. Consider applying Object Lock legal hold to clean versions during recovery if configured.
+- If Versioning is not enabled, recover from backups (AWS Backup, replication targets). Enable Versioning going forward on critical buckets; evaluate Object Lock for high-value data.
+- Carefully remove any temporary deny policy only after credentials are rotated, policies re-validated, and no ongoing destructive activity is observed.
+
+**6. Post-incident hardening**
+- Enforce `Block Public Access`, enable Versioning (and MFA-Delete where appropriate), and review bucket policies for least privilege.
+- Ensure continuous CloudTrail data events for S3 are enabled in covered regions; enable/verify GuardDuty S3 protections and alerts routing.
+- Add detections for related behaviors (policy tampering, bulk deletes, versioning/lifecycle toggles) and create allowlists for known maintenance windows.
+
+**7. Communication & escalation**
+- If you have an IR team/provider: escalate with the evidence bundle and a summary (bucket/key, actor, protections, related activity, business impact).
+- If you do not have an IR team: designate an internal incident lead, track actions/time, and follow these steps conservatively. Favor reversible controls (temporary deny, key rotation) over invasive changes.
+
+### Additional Information:
+- 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.
+- [AWS IRP—Ransomware](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-Ransomware.md) (NIST-aligned template for evidence, containment, eradication, recovery, post-incident). 
+- [AWS Customer Playbook—Ransom Response (S3)](https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Ransom_Response_S3.md) (bucket-level response steps: public access blocks, temporary deny, versioning/object lock, lifecycle considerations, recovery). 
+"""
+
+references = [
+    "https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/",
+    "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/",
+]
+risk_score = 47
+rule_id = "7fda9bb2-fd28-11ee-85f9-f661ea17fbce"
+setup = "AWS S3 data types need to be enabled in the CloudTrail trail configuration to capture PutObject API calls."
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS S3",
+    "Use Case: Threat Detection",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where
+  event.dataset == "aws.cloudtrail" and
+  event.provider == "s3.amazonaws.com" and
+  event.action == "PutObject" and
+  event.outcome == "success" and
+  /* Apply regex to match patterns only after the bucket name */
+  aws.cloudtrail.resources.arn regex "arn:aws:s3:::[^/]+/.*?(ransom|lock|crypt|enc|readme|how_to_decrypt|decrypt_instructions|recovery|datarescue).*" and
+  not aws.cloudtrail.resources.arn regex ".*(AWSLogs|CloudTrail|access-logs).*"
+'''
+
+[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",
+    "tls.client.server_name",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements"
+]
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1485"
+name = "Data Destruction"
+reference = "https://attack.mitre.org/techniques/T1485/"
+
+[[rule.threat.technique]]
+id = "T1486"
+name = "Data Encrypted for Impact"
+reference =  "https://attack.mitre.org/techniques/T1486/"
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/aws/impact_s3_excessive_object_encryption_with_sse_c.toml

@@ -0,0 +1,139 @@
+[metadata]
+creation_date = "2025/01/15"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/07/10"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window.
+"""
+false_positives = [
+    """
+    Legitimate use of Server-Side Encryption with Customer-Provided Keys (SSE-C) to encrypt objects in an S3 bucket.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Excessive AWS S3 Object Encryption with SSE-C"
+note = """### Triage and Analysis
+
+#### Investigating Excessive AWS S3 Object Encryption with SSE-C
+This rule identifies a high volume of objects being encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys.
+
+##### Possible Investigation Steps
+
+1. **Identify the User and Source**:
+   - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation.
+   - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access.
+   - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key.
+
+2. **Examine the Targeted Resources**:
+   - Check `aws.cloudtrail.request_parameters` to identify the bucket involved.
+   - Analyze the object key from `aws.cloudtrail.request_parameters`.
+
+3. **Evaluate Encryption Behavior**:
+   - Confirm the encryption details in `aws.cloudtrail.request_parameters` and `aws.cloudtrail.additional_eventdata`.
+   - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key.
+
+4. **Correlate with Recent Events**:
+   - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP.
+   - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects.
+   - For `PutObject` events, identify any other unusual objecs uploaded such as a ransom note.
+
+5. **Validate Access Permissions**:
+   - Check the IAM policies and roles associated with the user to verify if they had legitimate access to encrypt objects.
+
+6. **Assess Impact**:
+   - Identify the number of encrypted objects in the bucket by examining other similar events.
+   - Determine if this encryption aligns with standard business practices or constitutes a deviation.
+
+### False Positive Analysis
+
+- **Legitimate Use Cases**:
+  - Confirm if SSE-C encryption is part of regular operations for compliance or data protection.
+  - Cross-reference known processes or users authorized for SSE-C encryption in the affected bucket.
+
+### Response and Remediation
+
+1. **Immediate Actions**:
+   - Disable access keys or permissions for the user if unauthorized behavior is confirmed.
+   - Rotate the bucket's encryption configuration to mitigate further misuse.
+
+2. **Data Recovery**:
+   - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary.
+
+3. **Enhance Monitoring**:
+   - Enable alerts for future SSE-C encryption attempts in critical buckets.
+   - Review and tighten IAM policies for roles and users accessing S3.
+
+4. **Post-Incident Review**:
+   - Audit logs for additional activities by the same user or IP.
+   - Document findings and apply lessons learned to improve preventive measures.
+"""
+references = [
+    "https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c",
+    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html",
+]
+risk_score = 73
+rule_id = "909bf7c8-d371-11ef-bcc3-f661ea17fbcd"
+setup = "AWS S3 data event types need to be enabled in the CloudTrail trail configuration."
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS S3",
+    "Resources: Investigation Guide",
+    "Use Case: Threat Detection",
+    "Tactic: Impact",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset: "aws.cloudtrail"
+    and event.provider: "s3.amazonaws.com"
+    and event.action: "PutObject"
+    and event.outcome: "success"
+    and aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: "AES256"
+'''
+
+[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",
+    "tls.client.server_name",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters"
+]
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1486"
+name = "Data Encrypted for Impact"
+reference = "https://attack.mitre.org/techniques/T1486/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+
+[rule.threshold]
+field = ["tls.client.server_name"]
+value = 20
+
+