AWS EC2 Encryption Disabled

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/06/05"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/10/16"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures
 11that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys.
 12Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by
 13default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection
 14before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or
 15ransomware-style attacks that depend on unencrypted volumes.
 16"""
 17false_positives = [
 18    """
 19    Disabling encryption may be done by a system or network administrator. Verify whether the user identity, user agent,
 20    and/or hostname should be making changes in your environment. Disabling encryption by unfamiliar users or hosts
 21    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
 22    """,
 23]
 24from = "now-6m"
 25index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 26language = "kuery"
 27license = "Elastic License v2"
 28name = "AWS EC2 Encryption Disabled"
 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. 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.
 33
 34### Investigating AWS EC2 Encryption Disabled
 35
 36Amazon Elastic Block Store (EBS) encryption ensures that all new EBS volumes and snapshots are encrypted at rest using AWS KMS keys.  
 37When encryption by default is disabled, new EBS volumes in the region will no longer inherit automatic encryption.  
 38This 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.
 39
 40#### Possible investigation steps
 41
 42**Identify the initiator and context**
 43- Review the `aws.cloudtrail.user_identity` fields to determine who or what performed the `DisableEbsEncryptionByDefault` action.  
 44  - Examine the `user_identity.type` (e.g., IAMUser, AssumedRole, Root, FederatedUser).  
 45  - Validate whether the actor is authorized to modify account-level encryption defaults.
 46- 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.
 47- Correlate with recent IAM activity such as `AttachUserPolicy`, `UpdateAccountPasswordPolicy`, or `PutAccountSetting` to identify potential privilege escalation or account misuse.
 48**Review the timing and scope**
 49- Compare the event `@timestamp` with other CloudTrail management events to determine if the encryption change occurred alongside other administrative modifications.  
 50- Investigate if similar actions were executed in other AWS regions, disabling encryption regionally may be part of a broader campaign.
 51- 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.
 52**Assess data exposure risk**
 53- Identify newly created or modified EBS volumes after the timestamp of this change.  
 54  - Query CloudTrail for `CreateVolume` or `CreateSnapshot` events without `Encrypted:true`.  
 55- Determine whether sensitive workloads, such as production databases or applications, rely on unencrypted EBS volumes.  
 56- Check for `CopySnapshot` or `ModifySnapshotAttribute` activity that could indicate data staging or exfiltration.
 57**Correlate related security events**
 58- Look for concurrent detections or GuardDuty findings involving IAM privilege misuse, credential exposure, or configuration tampering.  
 59- 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.
 60- Review AWS Config timeline to confirm whether encryption-by-default was re-enabled or remained off.
 61
 62### False positive analysis
 63
 64- **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.  
 65- **Infrastructure testing**: Non-production environments may disable encryption for cost or performance benchmarking. These should be tagged and excluded.  
 66- **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.
 67
 68If confirmed as expected, document the change request, implementation window, and user responsible for traceability.
 69
 70### Response and remediation
 71
 72**1. Containment and restoration**
 73- Re-enable EBS encryption by default in the affected region to restore protection for new volumes:
 74  - Via AWS Console: EC2 → Account Attributes → EBS encryption → Enable by default.  
 75  - Or via CLI/API: `enable-ebs-encryption-by-default`.  
 76- Audit recently created EBS volumes and snapshots.  
 77  - Identify any unencrypted resources and re-encrypt them using KMS keys or snapshot-copy encryption workflows.  
 78- Verify that AWS Config rules and Security Hub controls related to EBS encryption (`ec2-ebs-encryption-by-default-enabled`) are enabled and compliant.
 79**2. Investigate and scope**
 80- Review IAM policies to ensure only designated administrators have the `ec2:DisableEbsEncryptionByDefault` permission.  
 81- Check for other regional encryption settings (e.g., S3 default encryption) that may have been modified by the same user or automation role.  
 82- Examine whether any new IAM roles or policies were added that allow similar encryption or security modifications.
 83**3. Long-term hardening**
 84- Enable organization-level service control policies (SCPs) to prevent future disabling of encryption-by-default across accounts.  
 85- Establish AWS Config conformance packs or Security Hub standards to continuously monitor this setting.  
 86- Integrate detection correlation (e.g., link EBS encryption disablement with subsequent unencrypted `CreateVolume` events) for improved alert fidelity.
 87- Educate administrators on data protection implications and require change approvals for encryption-related settings.
 88**4. Recovery validation**
 89- After restoring encryption-by-default, validate the change in CloudTrail and AWS Config timelines.  
 90- Confirm that subsequent EBS volumes are created with `Encrypted:true`.  
 91- Conduct a short post-incident review to document root cause, impact, and lessons learned for compliance audits.
 92
 93### Additional information
 94
 95- **[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.  
 96- **[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
 97- **AWS Documentation: [EBS Encryption at Rest](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)**
 98"""
 99references = [
100    "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html",
101    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/disable-ebs-encryption-by-default.html",
102    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisableEbsEncryptionByDefault.html",
103]
104risk_score = 47
105rule_id = "bb9b13b2-1700-48a8-a750-b43b0a72ab69"
106severity = "medium"
107tags = [
108    "Domain: Cloud",
109    "Data Source: AWS",
110    "Data Source: Amazon Web Services",
111    "Data Source: AWS EC2",
112    "Tactic: Impact",
113    "Resources: Investigation Guide",
114]
115timestamp_override = "event.ingested"
116type = "query"
117
118query = '''
119event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:DisableEbsEncryptionByDefault and event.outcome:success
120'''
121
122
123[[rule.threat]]
124framework = "MITRE ATT&CK"
125[[rule.threat.technique]]
126id = "T1565"
127name = "Data Manipulation"
128reference = "https://attack.mitre.org/techniques/T1565/"
129[[rule.threat.technique.subtechnique]]
130id = "T1565.001"
131name = "Stored Data Manipulation"
132reference = "https://attack.mitre.org/techniques/T1565/001/"
133
134
135
136[rule.threat.tactic]
137id = "TA0040"
138name = "Impact"
139reference = "https://attack.mitre.org/tactics/TA0040/"
140
141[rule.investigation_fields]
142field_names = [
143    "@timestamp",
144    "user.name",
145    "user_agent.original",
146    "source.ip",
147    "aws.cloudtrail.user_identity.arn",
148    "aws.cloudtrail.user_identity.type",
149    "aws.cloudtrail.user_identity.access_key_id",
150    "event.action",
151    "event.outcome",
152    "cloud.account.id",
153    "cloud.region",
154    "aws.cloudtrail.response_elements",
155]

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

References

Related rules

to-top