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

nldcsc_elastic_rules/rules/integrations/aws/impact_cloudwatch_log_stream_deletion.toml

@@ -0,0 +1,189 @@
+[metadata]
+creation_date = "2020/05/20"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/11/13"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects the deletion of an Amazon CloudWatch log stream using the "DeleteLogStream" API. Deleting a log stream
+permanently removes its associated log events and may disrupt security visibility, break audit trails, or suppress
+forensic evidence. Adversaries may delete log streams to conceal malicious actions, impair monitoring pipelines, or
+remove artifacts generated during post-exploitation activity.
+"""
+false_positives = [
+    """
+    CloudWatch log streams may be deleted legitimately during log rotation processes, test environment resets, or
+    infrastructure deployments that recreate log groups and streams. Validate the identity, automation pipeline, and IP
+    address associated with the deletion. If deletions are expected from specific CI/CD systems or administrative roles,
+    consider adding targeted exceptions.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS CloudWatch Log Stream Deletion"
+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 your operational context.
+
+### Investigating AWS CloudWatch Log Stream Deletion
+
+CloudWatch log streams contain sequential log events from a single application, service, or AWS resource.  
+Deleting a log stream permanently removes its archived log events, which may disable monitoring workflows, eliminate 
+critical telemetry, or disrupt forensic visibility.
+
+Adversaries may delete log streams to cover their tracks after unauthorized actions, break ingestion pipelines feeding SIEM, alerting, or anomaly detection or to remove evidence before escalating privileges or moving laterally. This rule detects successful invocations of the `DeleteLogStream` API from CloudTrail.
+
+#### Possible investigation steps
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.  
+  - Confirm whether the user or role normally manages CloudWatch Logs resources.
+
+- **Review request details**
+  - Inspect `aws.cloudtrail.request_parameters` to determine which log stream and parent log group were deleted.  
+  - Assess the importance of the deleted stream:
+    - Was it used for VPC Flow Logs, CloudTrail, Lambda functions, ECS tasks, or application logs?  
+    - Did it contain logs used for security detection or compliance auditing?
+
+- **Examine request origin and context**
+  - Review `source.ip` and `user_agent.original` for anomalies (e.g., unfamiliar CLI tools, suspicious automation, 
+    unknown IP ranges, or external geolocations).
+  - Validate whether the request originated from a legitimate automation host or jump box.  
+  - Check activity around the same timestamp for related operations such as:
+    - `DeleteLogGroup`
+    - `StopLogging`, `UpdateTrail`, or `DeleteTrail`
+    - GuardDuty detector or CloudWatch alarm deletions
+    - IAM policy or role modifications
+
+- **Determine operational justification**
+  - Consult change management systems or deployment pipelines to confirm whether the deletion was planned.  
+  - Contact application owners or platform teams to determine whether the log stream was part of normal rotation or cleanup.
+
+- **Investigate broader compromise indicators**
+  - Look for suspicious activity by the same identity in the past 24–48 hours, such as:
+    - Failed authentication attempts  
+    - IAM privilege escalations  
+    - Unusual STS AssumeRole usage  
+    - Access from new geolocations  
+
+### False positive analysis
+
+- **Log rotation and automation**
+  - Some systems delete log streams automatically when rolling new deployments or recycling compute resources.
+  - CI/CD pipelines managing immutable infrastructure may delete and recreate streams during each deploy.
+
+- **Test and development accounts**
+  - Dev/test environments may frequently create and delete log streams as part of iterative work.
+
+- **Bulk cleanup operations**
+  - Platform engineering teams may delete obsolete log streams during cost-optimization or log-retention management.
+
+If the rule triggers frequently from known infrastructure accounts or automation hosts, consider adding narrow exceptions using a combination of IAM role, IP range, or user agent.
+
+### Response and remediation
+
+- **Containment**
+  - If the deletion is unauthorized, review other CloudWatch resources for additional tampering (alarms, log groups, metric filters).
+  - Temporarily restrict permissions for the implicated IAM user or role.
+
+- **Investigation**
+  - Reconstruct any missing telemetry from alternative sources (e.g., S3 buckets, application logs, third-party logging systems).
+  - Review CloudTrail and Config timelines for preceding suspicious events.
+  - Validate whether the deleted log stream contained evidence of prior compromise.
+
+- **Recovery and hardening**
+  - Implement IAM least-privilege for `logs:DeleteLogStream`.
+  - Enable AWS Config rules to monitor CloudWatch Logs configuration changes.  
+  - Ensure that business-critical log groups enforce minimum retention periods and prevent accidental deletion.
+  - Integrate log stream lifecycle management into CI/CD to avoid manual deletions.
+  - Establish guardrails using Service Control Policies (SCPs) to block log deletions outside designated automation roles.
+
+### 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://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/delete-log-stream.html",
+    "https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteLogStream.html",
+]
+risk_score = 47
+rule_id = "d624f0ae-3dd1-4856-9aad-ccfe4d4bfa17"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: Amazon CloudWatch",
+    "Use Case: Log Auditing",
+    "Tactic: Defense Evasion",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: "aws.cloudtrail" 
+  and event.provider: "logs.amazonaws.com" 
+  and event.action: "DeleteLogStream" 
+  and event.outcome: "success"
+  and source.ip: * 
+  and not user_agent.original : "AWS Internal"
+'''
+
+
+[[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/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.001"
+name = "Disable or Modify Tools"
+reference = "https://attack.mitre.org/techniques/T1562/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[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",
+]
+

nldcsc_elastic_rules/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml

@@ -0,0 +1,156 @@
+[metadata]
+creation_date = "2020/06/05"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/10/16"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures
+that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys.
+Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by
+default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection
+before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or
+ransomware-style attacks that depend on unencrypted volumes.
+"""
+false_positives = [
+    """
+    Disabling encryption 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. Disabling encryption 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 = "kuery"
+license = "Elastic License v2"
+name = "AWS EC2 Encryption Disabled"
+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 EC2 Encryption Disabled
+
+Amazon Elastic Block Store (EBS) encryption ensures that all new EBS volumes and snapshots are encrypted at rest using AWS KMS keys.  
+When encryption by default is disabled, new EBS volumes in the region will no longer inherit automatic encryption.  
+This action can have serious security implications as it can weaken the organization’s data protection posture, violate compliance requirements, or enable adversaries to read or exfiltrate sensitive information without triggering encryption-based access controls.
+
+#### Possible investigation steps
+
+**Identify the initiator and context**
+- Review the `aws.cloudtrail.user_identity` fields to determine who or what performed the `DisableEbsEncryptionByDefault` action.  
+  - Examine the `user_identity.type` (e.g., IAMUser, AssumedRole, Root, FederatedUser).  
+  - Validate whether the actor is authorized to modify account-level encryption defaults.
+- Check `source.ip` and `user_agent.original` to identify the origin of the request and whether it came from a known administrative system, automation process, or an unfamiliar host.
+- Correlate with recent IAM activity such as `AttachUserPolicy`, `UpdateAccountPasswordPolicy`, or `PutAccountSetting` to identify potential privilege escalation or account misuse.
+**Review the timing and scope**
+- Compare the event `@timestamp` with other CloudTrail management events to determine if the encryption change occurred alongside other administrative modifications.  
+- Investigate if similar actions were executed in other AWS regions, disabling encryption regionally may be part of a broader campaign.
+- Review AWS Config or Security Hub findings to determine whether compliance controls or data protection standards (e.g., CIS, PCI-DSS, ISO 27001) have been violated.
+**Assess data exposure risk**
+- Identify newly created or modified EBS volumes after the timestamp of this change.  
+  - Query CloudTrail for `CreateVolume` or `CreateSnapshot` events without `Encrypted:true`.  
+- Determine whether sensitive workloads, such as production databases or applications, rely on unencrypted EBS volumes.  
+- Check for `CopySnapshot` or `ModifySnapshotAttribute` activity that could indicate data staging or exfiltration.
+**Correlate related security events**
+- Look for concurrent detections or GuardDuty findings involving IAM privilege misuse, credential exposure, or configuration tampering.  
+- Review CloudTrail logs for any `DisableKeyRotation` or `ScheduleKeyDeletion` events related to the KMS key used for EBS encryption. These may indicate attempts to disrupt encryption mechanisms entirely.
+- Review AWS Config timeline to confirm whether encryption-by-default was re-enabled or remained off.
+
+### False positive analysis
+
+- **Administrative changes**: System or cloud administrators may disable default encryption temporarily for troubleshooting or migration. Verify if the user identity, role, or automation process is part of a legitimate change.  
+- **Infrastructure testing**: Non-production environments may disable encryption for cost or performance benchmarking. These should be tagged and excluded.  
+- **Service misconfiguration**: Some provisioning frameworks or scripts may unintentionally disable encryption defaults during environment setup. Ensure automation code uses explicit encryption flags when creating resources.
+
+If confirmed as expected, document the change request, implementation window, and user responsible for traceability.
+
+### Response and remediation
+
+**1. Containment and restoration**
+- Re-enable EBS encryption by default in the affected region to restore protection for new volumes:
+  - Via AWS Console: EC2 → Account Attributes → EBS encryption → Enable by default.  
+  - Or via CLI/API: `enable-ebs-encryption-by-default`.  
+- Audit recently created EBS volumes and snapshots.  
+  - Identify any unencrypted resources and re-encrypt them using KMS keys or snapshot-copy encryption workflows.  
+- Verify that AWS Config rules and Security Hub controls related to EBS encryption (`ec2-ebs-encryption-by-default-enabled`) are enabled and compliant.
+**2. Investigate and scope**
+- Review IAM policies to ensure only designated administrators have the `ec2:DisableEbsEncryptionByDefault` permission.  
+- Check for other regional encryption settings (e.g., S3 default encryption) that may have been modified by the same user or automation role.  
+- Examine whether any new IAM roles or policies were added that allow similar encryption or security modifications.
+**3. Long-term hardening**
+- Enable organization-level service control policies (SCPs) to prevent future disabling of encryption-by-default across accounts.  
+- Establish AWS Config conformance packs or Security Hub standards to continuously monitor this setting.  
+- Integrate detection correlation (e.g., link EBS encryption disablement with subsequent unencrypted `CreateVolume` events) for improved alert fidelity.
+- Educate administrators on data protection implications and require change approvals for encryption-related settings.
+**4. Recovery validation**
+- After restoring encryption-by-default, validate the change in CloudTrail and AWS Config timelines.  
+- Confirm that subsequent EBS volumes are created with `Encrypted:true`.  
+- Conduct a short post-incident review to document root cause, impact, and lessons learned for compliance audits.
+
+### Additional information
+
+- **[AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**: guidance for investigating unauthorized access to modify account settings.  
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/)**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services
+- **AWS Documentation: [EBS Encryption at Rest](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)**
+"""
+references = [
+    "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html",
+    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/disable-ebs-encryption-by-default.html",
+    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisableEbsEncryptionByDefault.html",
+]
+risk_score = 47
+rule_id = "bb9b13b2-1700-48a8-a750-b43b0a72ab69"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS EC2",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:DisableEbsEncryptionByDefault and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1565"
+name = "Data Manipulation"
+reference = "https://attack.mitre.org/techniques/T1565/"
+[[rule.threat.technique.subtechnique]]
+id = "T1565.001"
+name = "Stored Data Manipulation"
+reference = "https://attack.mitre.org/techniques/T1565/001/"
+
+
+
+[rule.threat.tactic]
+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.response_elements",
+]
+

nldcsc_elastic_rules/rules/integrations/aws/impact_ec2_ebs_snapshot_access_removed.toml

@@ -0,0 +1,147 @@
+[metadata]
+creation_date = "2024/06/02"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/10/24"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data
+retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from
+accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be
+used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack
+and complicating incident response.
+"""
+event_category_override = "event.type"
+false_positives = ["Access removal may be a part of normal operations and should be verified before taking action."]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "AWS EC2 EBS Snapshot Access Removed"
+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 EC2 EBS Snapshot Access Removed
+
+This rule detects when access is removed for an AWS EC2 EBS snapshot. EBS virtual disks can be copied into snapshots, which can then be used as backups for recovery and data retention efforts. Adversaries may attempt to remove access to snapshots in order to prevent legitimate users or automated processes from accessing or restoring from snapshots following data loss, ransomware, or destructive actions. This can significantly delay or even prevent recovery, increasing the impact of the attack. Restricting snapshot access may help adversaries cover their tracks by making it harder for defenders to analyze or recover deleted or altered data. Attackers may remove permissions for all users except their own compromised account, allowing them to maintain exclusive access to backups for future use or leverage. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious.
+
+#### Possible investigation steps:
+
+- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. Evaluate whether the identity is authorized to manage EBS snapshot permissions (check IAM policies for `ec2:ModifySnapshotAttribute`). 
+- **Analyze the source of the request**: Examine `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. Review `user_agent.original` to determine if the request came from an expected administrative tool or host.
+- **Examine the scope of the change**:
+  - Review `aws.cloudtrail.request_parameters` to understand which accounts or entities had access removed.  
+    - Look for unusual patterns such as `createVolumePermission={remove=all}` or removal of specific external or organizational accounts.  
+  - Cross-check the affected `snapshotId` in the AWS console or via CLI to confirm current sharing status and determine if any copies or dependent volumes exist.  
+  - Use AWS Config or AWS CLI (`describe-snapshot-attribute`) to verify whether other snapshots were modified within the same timeframe.
+- **Correlate with other activities**:
+  - Search CloudTrail for additional activity from the same actor or `source.ip` around the event time.  
+    - Pay special attention to subsequent `DeleteSnapshot`, `DeregisterImage`, or `RevokeSnapshotAccess` events, which may signal ongoing destruction.  
+    - Check for parallel IAM activity, such as policy changes that grant or revoke permissions.  
+  - Correlate with GuardDuty or Security Hub findings related to data exfiltration, destructive actions, or unauthorized configuration changes.  
+  - Determine if any high-value or production snapshots were affected, especially those linked to business-critical EBS volumes.
+- **Evaluate timing and intent**: Compare `@timestamp` with maintenance windows or known change requests. Actions taken outside approved hours or without associated tickets may indicate compromise or sabotage. If this change coincides with other detections (for example, `EBS encryption disabled` or `root login` events), treat it as part of a coordinated impact campaign.
+
+### False positive analysis:
+
+- **Planned administrative maintenance**: Confirm whether this snapshot modification aligns with backup rotation, retention policy enforcement, or snapshot lifecycle automation.  
+- **Automation and tooling**: Infrastructure-as-code pipelines or DevOps scripts may legitimately remove snapshot sharing to enforce compliance. Review tags, user agents, and automation identifiers.  
+- **Testing or sandbox accounts**: Some non-production environments may modify snapshot access for isolation. Validate account purpose before escalating.
+
+If the action was expected, document the change approval and reconcile against internal audit or change-control systems.
+
+### Response and remediation:
+
+**1. Containment and validation**
+- Review and, if necessary, restore snapshot permissions using AWS Console or CLI (`modify-snapshot-attribute` with `add` parameters).  
+- Confirm that no additional snapshots or AMIs have had access removed.  
+- Restrict `ec2:ModifySnapshotAttribute` permissions to only trusted administrative roles.
+**2. Investigate for data destruction or persistence**
+- Determine if the same actor also deleted or copied snapshots (`DeleteSnapshot`, `CopySnapshot`).  
+- Review subsequent volume creation or image registration events that could indicate snapshot reuse.  
+- Identify whether any snapshot was shared to or copied by an external AWS account.
+**3. Strengthen detection and monitoring**
+- Enable AWS Config rules and Security Hub controls such as `ebs-snapshot-public-restorable-check`.  
+- Establish continuous monitoring for `ModifySnapshotAttribute` and `DeleteSnapshot` operations.  
+- Correlate future detections with user identity and source IP context to identify recurring behavior.
+**4. Recovery and hardening**
+- Verify that critical snapshots and backups are retained and encrypted.  
+- Implement backup immutability with AWS Backup Vault Lock or S3 Object Lock for long-term protection.  
+- Apply service control policies (SCPs) to prevent unauthorized modification of snapshot sharing attributes.  
+- Conduct a post-incident review to identify the root cause and strengthen least-privilege enforcement for EBS management roles.
+
+### Additional information
+
+- **[AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**: guidance for investigating unauthorized access to modify account settings.  
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/)**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services
+- **AWS Documentation**  
+  - [EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html)  
+  - [ModifySnapshotAttribute API Reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)
+"""
+references = [
+    "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html",
+    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html",
+]
+risk_score = 47
+rule_id = "713e0f5f-caf7-4dc2-88a7-3561f61f262a"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS EC2",
+    "Use Case: Threat Detection",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+info where event.dataset == "aws.cloudtrail"  
+  and event.action == "ModifySnapshotAttribute"
+  and event.outcome == "success"
+  and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION")
+  and stringContains (aws.cloudtrail.request_parameters, "remove=")
+'''
+
+[[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 = "T1490"
+name = "Inhibit System Recovery"
+reference = "https://attack.mitre.org/techniques/T1490/"
+
+
+[rule.threat.tactic]
+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_efs_filesystem_or_mount_deleted.toml

@@ -0,0 +1,95 @@
+[metadata]
+creation_date = "2021/08/27"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Austin Songer"]
+description = """
+Detects when an EFS File System or Mount is deleted. An adversary could break any file system using the mount target
+that is being deleted, which might disrupt instances or applications using those mounts. The mount must be deleted prior
+to deleting the File System, or the adversary will be unable to delete the File System.
+"""
+false_positives = [
+    """
+    File System or Mount being deleted may be performed by a system administrator. Verify whether the user identity,
+    user agent, and/or hostname should be making changes in your environment. File System Mount deletion by unfamiliar
+    users 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 = "AWS EFS File System or Mount 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, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating AWS EFS File System or Mount Deleted
+
+Amazon Elastic File System (EFS) provides scalable file storage for use with AWS cloud services and on-premises resources. Adversaries may target EFS by deleting file systems or mount targets, disrupting applications reliant on these resources. The detection rule monitors AWS CloudTrail logs for successful deletion events, signaling potential malicious activity aimed at data destruction or service disruption.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the deletion event by examining the user identity information in the logs.
+- Check the event time and correlate it with other activities in the AWS environment to determine if there are any related suspicious actions or patterns.
+- Investigate the source IP address and location from which the deletion request was made to assess if it aligns with expected access patterns or if it appears anomalous.
+- Verify if there were any recent changes to IAM policies or roles that might have inadvertently granted permissions to delete EFS resources.
+- Assess the impact of the deletion by identifying which applications or services were using the deleted EFS file system or mount target and determine if there are any disruptions.
+- Contact the user or team responsible for the AWS account to confirm if the deletion was intentional and authorized, or if it was potentially malicious.
+
+### False positive analysis
+
+- Routine maintenance activities by system administrators may trigger deletion events. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or cloud management tools that manage EFS resources might delete mounts or file systems as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts.
+- Development or testing environments often involve frequent creation and deletion of resources. Exclude these environments from the rule to prevent unnecessary alerts.
+- Scheduled cleanup jobs that remove unused or temporary file systems can cause false positives. Document these jobs and configure exceptions based on their execution schedule.
+- Ensure that any third-party services or integrations with AWS that manage EFS resources are accounted for, and their actions are excluded if they are part of expected behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected EFS file system to prevent further unauthorized deletions or access. This can be done by modifying the security group rules to deny all traffic temporarily.
+- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess whether the action was authorized.
+- Revoke or adjust permissions for the identified IAM user or role to prevent further unauthorized actions. Ensure that least privilege principles are applied.
+- Restore the deleted EFS file system or mount from the most recent backup, if available, to minimize data loss and service disruption.
+- Notify the incident response team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.
+- Conduct a post-incident review to identify any gaps in security controls or processes that allowed the unauthorized deletion, and implement necessary improvements.
+- Enhance monitoring and alerting for similar events by ensuring that all critical AWS resources have appropriate logging and alerting configured, focusing on deletion and modification actions.
+
+## Setup
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://docs.aws.amazon.com/efs/latest/ug/API_DeleteFileSystem.html",
+    "https://docs.aws.amazon.com/efs/latest/ug/API_DeleteMountTarget.html",
+]
+risk_score = 47
+rule_id = "536997f7-ae73-447d-a12d-bff1e8f5f0a0"
+severity = "medium"
+tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Impact", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:aws.cloudtrail and event.provider:elasticfilesystem.amazonaws.com and
+event.action:(DeleteMountTarget or DeleteFileSystem) and event.outcome:success
+'''
+
+
+[[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/"
+