AWS EFS File System Deleted

Identifies the deletion of an Amazon EFS file system using the "DeleteFileSystem" API operation. Deleting an EFS file system permanently removes all stored data and cannot be reversed. This action is rare in most environments and typically limited to controlled teardown workflows. Adversaries with sufficient permissions may delete a file system to destroy evidence, disrupt workloads, or impede recovery efforts.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2021/08/27"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/11/26"
  6
  7[rule]
  8author = ["Austin Songer", "Elastic"]
  9description = """
 10Identifies the deletion of an Amazon EFS file system using the "DeleteFileSystem" API operation. Deleting an EFS file
 11system permanently removes all stored data and cannot be reversed. This action is rare in most environments and
 12typically limited to controlled teardown workflows. Adversaries with sufficient permissions may delete a file system to
 13destroy evidence, disrupt workloads, or impede recovery efforts.
 14"""
 15false_positives = [
 16    """
 17    Legitimate teardown or environment decommissioning processes may delete EFS file systems. Verify whether the calling
 18    user, role, automation system, or CI/CD workflow is expected to perform destructive actions in the affected account.
 19    File system deletions by unfamiliar identities, from unusual IP addresses, or occurring outside approved change
 20    windows should be carefully reviewed. If known automation routinely deletes ephemeral test file systems, consider
 21    adding scoped exceptions.
 22    """,
 23]
 24from = "now-6m"
 25index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 26language = "kuery"
 27license = "Elastic License v2"
 28name = "AWS EFS File System Deleted"
 29note = """## Triage and analysis
 30
 31> **Disclaimer**:
 32> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 
 33> While every effort has been made to ensure its quality, validate and adapt it to suit your operational needs.
 34
 35### Investigating AWS EFS File System Deleted
 36
 37Amazon Elastic File System (EFS) provides scalable, shared file storage used by EC2, container workloads, analytics jobs, and other persistent applications. Deleting an EFS file system (`DeleteFileSystem`) permanently removes all stored data and cannot be recovered. Mount targets must already be deleted, but those operations are common and do not themselves indicate malicious behavior. This rule focuses exclusively on the irreversible destructive event, which may signal intentional data destruction, ransomware preparation, or a post-compromise cleanup effort.
 38
 39#### Possible investigation steps
 40
 41- **Identify the actor and calling context**
 42  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.
 43  - Check `source.ip`, `user_agent.original`, and whether the call originated via console, IAM role, STS session, or long-lived IAM key.
 44  - Verify whether this principal typically manages EFS resources or teardown activities.
 45
 46- **Determine what was deleted**
 47  - Inspect `aws.cloudtrail.request_parameters` to identify the deleted file system ID.
 48  - Map the resource to:
 49    - Application or owner team
 50    - Environment classification (prod / dev / test)
 51    - Dependency surfaces (EC2 instances, ECS tasks, Lambda, analytics pipelines)
 52
 53- **Reconstruct timeline and intent**
 54  - Use `@timestamp` to correlate with:
 55    - Recent `UpdateFileSystem` events (e.g., deletion protection, lifecycle policies)
 56    - IAM policy or trust policy changes
 57    - EC2 or container runtime disruption shortly before deletion
 58    - Unexpected regional activity or off-hours execution
 59  - Determine if mount target deletions occurred immediately beforehand (expected lifecycle) or unexpectedly earlier (possibly suspicious when paired with other anomalies).
 60
 61- **Correlate with broader account activity**
 62  - Pivot in CloudTrail on:
 63    - The same access key or session
 64    - The same EFS file system ID
 65  - Look for:
 66    - Privilege escalation (new policy attachments, role assumptions)
 67    - Lateral movement (SSM sessions, unusual EC2 access)
 68    - Signs of cleanup or anti-forensics (CloudWatch log group deletions, RDS snapshot deletions)
 69    - Network isolation actions (security-group or NACL updates)
 70
 71- **Validate with owners**
 72  - Confirm with application or infrastructure teams:
 73    - Whether the deletion was planned, approved, or part of an environment teardown
 74    - Whether a migration or infrastructure rotation is in progress
 75    - Whether the deleted file system contained production or sensitive workloads
 76
 77### False positive analysis
 78
 79- **Expected teardown activity**
 80  - Some pipelines (Terraform, CloudFormation, CDK, custom IaC) delete file systems as part of environment rotation or decommissioning.
 81  - Add exceptions for known automation roles or environment tags (e.g., `Environment=Dev`).
 82
 83- **Ephemeral test environments**
 84  - Development, QA, or integration test accounts may routinely create and destroy EFS file systems.
 85  - Suppress events for non-production accounts where destructive operations are normal.
 86
 87- **Automated housekeeping**
 88  - Internal tooling or lifecycle processes may remove unused EFS resources.
 89  - Identify automation roles and use exceptions based on `aws.cloudtrail.user_identity.arn` or `user_agent.original`.
 90
 91### Response and remediation
 92
 93- **Contain and secure**
 94  - If unauthorized, revoke or disable the credentials used for the deletion.
 95  - Review CloudTrail for additional destructive or privilege-escalating operations from the same actor.
 96  - Validate whether any associated compute workloads (EC2, ECS, Lambda) show compromise indicators.
 97
 98- **Assess impact**
 99  - Identify workloads impacted by the file system deletion.
100  - Determine whether alternate backups exist (EFS-to-EFS Backup, AWS Backup vaults).
101  - Evaluate operational disruption and data-loss implications, especially for compliance-bound data.
102
103- **Recover (if possible)**
104  - Restore from AWS Backup if a protected resource existed.
105  - Rebuild infrastructure dependencies that relied on the deleted file system.
106
107- **Hardening and prevention**
108  - Restrict use of `elasticfilesystem:DeleteFileSystem` to tightly controlled IAM roles.
109  - Use IAM conditions (e.g., `aws:PrincipalArn`, `aws:SourceIp`, `aws:RequestedRegion`) to limit destructive operations.
110  - Ensure AWS Backup policies include EFS resources with sufficient retention.
111  - Use AWS Config or Security Hub controls to detect:
112    - EFS file systems without backup plans
113    - Unexpected changes to file system policies
114
115### Additional information
116- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
117- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
118- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
119"""
120references = [
121    "https://docs.aws.amazon.com/efs/latest/ug/API_DeleteFileSystem.html",
122    "https://docs.aws.amazon.com/efs/latest/ug/API_DeleteMountTarget.html",
123]
124risk_score = 47
125rule_id = "536997f7-ae73-447d-a12d-bff1e8f5f0a0"
126severity = "medium"
127tags = [
128    "Domain: Cloud",
129    "Data Source: AWS",
130    "Data Source: Amazon Web Services",
131    "Data Source: AWS EFS",
132    "Tactic: Impact",
133    "Resources: Investigation Guide",
134]
135timestamp_override = "event.ingested"
136type = "query"
137
138query = '''
139event.dataset: "aws.cloudtrail" 
140    and event.provider: "elasticfilesystem.amazonaws.com" 
141    and event.action: "DeleteFileSystem" 
142    and event.outcome: "success"
143'''
144
145
146[[rule.threat]]
147framework = "MITRE ATT&CK"
148[[rule.threat.technique]]
149id = "T1485"
150name = "Data Destruction"
151reference = "https://attack.mitre.org/techniques/T1485/"
152
153
154[rule.threat.tactic]
155id = "TA0040"
156name = "Impact"
157reference = "https://attack.mitre.org/tactics/TA0040/"
158
159[rule.investigation_fields]
160field_names = [
161    "@timestamp",
162    "user.name",
163    "user_agent.original",
164    "source.ip",
165    "aws.cloudtrail.user_identity.arn",
166    "aws.cloudtrail.user_identity.type",
167    "aws.cloudtrail.user_identity.access_key_id",
168    "target.entity.id",
169    "event.action",
170    "event.outcome",
171    "cloud.account.id",
172    "cloud.region",
173    "aws.cloudtrail.request_parameters"
174]

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 EFS File System Deleted

Amazon Elastic File System (EFS) provides scalable, shared file storage used by EC2, container workloads, analytics jobs, and other persistent applications. Deleting an EFS file system (DeleteFileSystem) permanently removes all stored data and cannot be recovered. Mount targets must already be deleted, but those operations are common and do not themselves indicate malicious behavior. This rule focuses exclusively on the irreversible destructive event, which may signal intentional data destruction, ransomware preparation, or a post-compromise cleanup effort.

Possible investigation steps

  • Identify the actor and calling context

    • Review aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.access_key_id.
    • Check source.ip, user_agent.original, and whether the call originated via console, IAM role, STS session, or long-lived IAM key.
    • Verify whether this principal typically manages EFS resources or teardown activities.
  • Determine what was deleted

    • Inspect aws.cloudtrail.request_parameters to identify the deleted file system ID.
    • Map the resource to:
      • Application or owner team
      • Environment classification (prod / dev / test)
      • Dependency surfaces (EC2 instances, ECS tasks, Lambda, analytics pipelines)
  • Reconstruct timeline and intent

    • Use @timestamp to correlate with:
      • Recent UpdateFileSystem events (e.g., deletion protection, lifecycle policies)
      • IAM policy or trust policy changes
      • EC2 or container runtime disruption shortly before deletion
      • Unexpected regional activity or off-hours execution
    • Determine if mount target deletions occurred immediately beforehand (expected lifecycle) or unexpectedly earlier (possibly suspicious when paired with other anomalies).
  • Correlate with broader account activity

    • Pivot in CloudTrail on:
      • The same access key or session
      • The same EFS file system ID
    • Look for:
      • Privilege escalation (new policy attachments, role assumptions)
      • Lateral movement (SSM sessions, unusual EC2 access)
      • Signs of cleanup or anti-forensics (CloudWatch log group deletions, RDS snapshot deletions)
      • Network isolation actions (security-group or NACL updates)
  • Validate with owners

    • Confirm with application or infrastructure teams:
      • Whether the deletion was planned, approved, or part of an environment teardown
      • Whether a migration or infrastructure rotation is in progress
      • Whether the deleted file system contained production or sensitive workloads

False positive analysis

  • Expected teardown activity

    • Some pipelines (Terraform, CloudFormation, CDK, custom IaC) delete file systems as part of environment rotation or decommissioning.
    • Add exceptions for known automation roles or environment tags (e.g., Environment=Dev).
  • Ephemeral test environments

    • Development, QA, or integration test accounts may routinely create and destroy EFS file systems.
    • Suppress events for non-production accounts where destructive operations are normal.
  • Automated housekeeping

    • Internal tooling or lifecycle processes may remove unused EFS resources.
    • Identify automation roles and use exceptions based on aws.cloudtrail.user_identity.arn or user_agent.original.

Response and remediation

  • Contain and secure

    • If unauthorized, revoke or disable the credentials used for the deletion.
    • Review CloudTrail for additional destructive or privilege-escalating operations from the same actor.
    • Validate whether any associated compute workloads (EC2, ECS, Lambda) show compromise indicators.
  • Assess impact

    • Identify workloads impacted by the file system deletion.
    • Determine whether alternate backups exist (EFS-to-EFS Backup, AWS Backup vaults).
    • Evaluate operational disruption and data-loss implications, especially for compliance-bound data.
  • Recover (if possible)

    • Restore from AWS Backup if a protected resource existed.
    • Rebuild infrastructure dependencies that relied on the deleted file system.
  • Hardening and prevention

    • Restrict use of elasticfilesystem:DeleteFileSystem to tightly controlled IAM roles.
    • Use IAM conditions (e.g., aws:PrincipalArn, aws:SourceIp, aws:RequestedRegion) to limit destructive operations.
    • Ensure AWS Backup policies include EFS resources with sufficient retention.
    • Use AWS Config or Security Hub controls to detect:
      • EFS file systems without backup plans
      • Unexpected changes to file system policies

Additional information

References

Related rules

to-top