AWS KMS Customer Managed Key Disabled or Scheduled for Deletion
Identifies attempts to disable or schedule the deletion of an AWS customer managed KMS Key. Disabling or scheduling a KMS key for deletion removes the ability to decrypt data encrypted under that key and can permanently destroy access to critical resources. Adversaries may use these operations to cause irreversible data loss, disrupt business operations, impede incident response, or hide evidence of prior activity. Because KMS keys often protect sensitive or regulated data, any modification to their lifecycle should be considered highly sensitive and investigated promptly.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2022/09/21"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2025/12/05"
6
7[rule]
8author = ["Xavier Pich"]
9description = """
10Identifies attempts to disable or schedule the deletion of an AWS customer managed KMS Key. Disabling or scheduling a
11KMS key for deletion removes the ability to decrypt data encrypted under that key and can permanently destroy access to
12critical resources. Adversaries may use these operations to cause irreversible data loss, disrupt business operations,
13impede incident response, or hide evidence of prior activity. Because KMS keys often protect sensitive or regulated
14data, any modification to their lifecycle should be considered highly sensitive and investigated promptly.
15"""
16false_positives = [
17 """
18 A customer managed KMS key may be disabled or scheduled for deletion by a system administrator. Verify whether the
19 user identity, user agent, and/or hostname should be making changes in your environment. Key deletions by unfamiliar
20 users should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
21 """,
22]
23from = "now-6m"
24index = ["filebeat-*", "logs-aws.cloudtrail-*"]
25language = "kuery"
26license = "Elastic License v2"
27name = "AWS KMS Customer Managed Key Disabled or Scheduled for Deletion"
28note = """## Triage and analysis
29
30> **Disclaimer**:
31> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance.
32> 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 KMS Customer Managed Key Disabled or Scheduled for Deletion
35
36AWS KMS keys underpin encryption for S3, EBS, RDS, Secrets Manager, Lambda, and numerous other AWS services. Disabling a KMS key or scheduling its deletion immediately disrupts encryption and decryption workflows, and, once deleted, renders all data encrypted with that key unrecoverable.
37
38Because these operations are rare, highly privileged, and tightly controlled in mature environments, they should be treated as high-risk, destructive actions when performed unexpectedly. Adversaries may disable or delete KMS keys to sabotage recovery, impede forensic analysis, or destroy evidence after exfiltration.
39
40
41#### Possible investigation steps
42
43- **Identify the actor and authentication context**
44 - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine the caller.
45 - Check `source.ip`, `source.geo` fields, and `user_agent.original` to determine whether the action originated from an expected network path or automation platform.
46 - Compare the actor and access key to historical usage patterns.
47
48- **Determine what key was affected and its criticality**
49 - Inspect `aws.cloudtrail.resources.arn` to identify the KMS key.
50 - Determine:
51 - The services and data protected by the key (e.g., RDS, EBS, S3, Secrets Manager).
52 - The environment (prod vs. dev).
53 - Owner or application team.
54
55- **Understand the scope and intent of the change**
56 - For `DisableKey`, determine whether a dependent service immediately began failing or experienced decryption errors.
57 - For `ScheduleKeyDeletion`, examine the `PendingWindowInDays` value within `aws.cloudtrail.request_parameters`.
58 - Check whether the key was previously rotated, enabled/disabled, or had its policy recently modified.
59
60- **Correlate with surrounding events**
61 - Look for:
62 - IAM policy changes granting new KMS privileges.
63 - Access anomalies involving the same principal.
64 - File system, database, or backup deletions near the same timeframe.
65 - S3, EBS, or RDS resources showing encryption failures.
66 - Determine whether other keys were modified in the same window (possible broader sabotage attempt).
67
68- **Validate intent with owners**
69 - Confirm with the application, data, or security owners:
70 - Whether deactivation or scheduled deletion was requested.
71 - Whether the key was being replaced, migrated, or retired.
72
73### False positive analysis
74
75- **Planned key lifecycle activities**
76 - Some organizations disable KMS keys before rotation, migration, or decommissioning.
77 - Scheduled deletion during infrastructure teardown may be expected in CI/CD-driven ephemeral environments.
78
79- **Configuration errors**
80 - Misapplied tags or incorrect CloudFormation teardown workflows can unintentionally disable or schedule deletion of KMS keys.
81
82If any of the above conditions apply, consider adjusting rule exceptions based on IAM principal, environment tag, or automation role.
83
84### Response and remediation
85
86- **Contain and validate**
87 - Immediately confirm whether the key disablement or deletion schedule was intentional.
88 - If unauthorized, cancel scheduled deletion (`CancelKeyDeletion`) and re-enable the key (`EnableKey`) as appropriate.
89 - Rotate credentials or access keys used by the actor if compromise is suspected.
90
91- **Assess impact**
92 - Identify all AWS services and data encrypted with the affected KMS key.
93 - Review logs and service metrics for failures involving:
94 - EBS volume attachments
95 - RDS instance decryption
96 - S3 object access
97 - Secrets Manager retrieval
98 - Lambda environment variable decryption
99
100- **Investigate for compromise**
101 - Review CloudTrail activity for the principal:
102 - Permission escalations
103 - Unusual STS role assumptions
104 - S3, EC2, RDS destructive behavior
105 - Look for preceding data access or exfiltration attempts.
106
107- **Strengthen controls**
108 - Restrict AWS KMS lifecycle permissions (`kms:DisableKey`, `kms:ScheduleKeyDeletion`) to a very small privileged set.
109 - Use AWS Organizations SCPs to prevent KMS key deletion in production accounts.
110 - Enable AWS Config rules for KMS key state monitoring.
111 - Require MFA for administrators capable of key management.
112
113- **Post-incident improvement**
114 - Update runbooks to include KMS lifecycle change approvals.
115 - Implement tagging standards to designate high-risk keys.
116 - Enhance monitoring for key policy modifications or changes to principal permissions.
117
118### Additional information
119- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**
120- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)**
121- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
122"""
123references = [
124 "https://docs.aws.amazon.com/cli/latest/reference/kms/disable-key.html",
125 "https://docs.aws.amazon.com/cli/latest/reference/kms/schedule-key-deletion.html",
126]
127risk_score = 47
128rule_id = "6951f15e-533c-4a60-8014-a3c3ab851a1b"
129severity = "medium"
130tags = [
131 "Domain: Cloud",
132 "Data Source: AWS",
133 "Data Source: Amazon Web Services",
134 "Data Source: AWS KMS",
135 "Use Case: Log Auditing",
136 "Tactic: Impact",
137 "Resources: Investigation Guide",
138]
139timestamp_override = "event.ingested"
140type = "query"
141
142query = '''
143event.dataset: "aws.cloudtrail"
144 and event.provider: "kms.amazonaws.com"
145 and event.action: ("DisableKey" or "ScheduleKeyDeletion")
146 and event.outcome: "success"
147'''
148
149
150[[rule.threat]]
151framework = "MITRE ATT&CK"
152[[rule.threat.technique]]
153id = "T1485"
154name = "Data Destruction"
155reference = "https://attack.mitre.org/techniques/T1485/"
156
157
158[rule.threat.tactic]
159id = "TA0040"
160name = "Impact"
161reference = "https://attack.mitre.org/tactics/TA0040/"
162
163[rule.investigation_fields]
164field_names = [
165 "@timestamp",
166 "user.name",
167 "user_agent.original",
168 "source.ip",
169 "aws.cloudtrail.user_identity.arn",
170 "aws.cloudtrail.user_identity.type",
171 "aws.cloudtrail.user_identity.access_key_id",
172 "aws.cloudtrail.resources.arn",
173 "aws.cloudtrail.resources.type",
174 "event.action",
175 "event.outcome",
176 "cloud.account.id",
177 "cloud.region",
178 "aws.cloudtrail.request_parameters",
179 "aws.cloudtrail.response_elements",
180]
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 KMS Customer Managed Key Disabled or Scheduled for Deletion
AWS KMS keys underpin encryption for S3, EBS, RDS, Secrets Manager, Lambda, and numerous other AWS services. Disabling a KMS key or scheduling its deletion immediately disrupts encryption and decryption workflows, and, once deleted, renders all data encrypted with that key unrecoverable.
Because these operations are rare, highly privileged, and tightly controlled in mature environments, they should be treated as high-risk, destructive actions when performed unexpectedly. Adversaries may disable or delete KMS keys to sabotage recovery, impede forensic analysis, or destroy evidence after exfiltration.
Possible investigation steps
-
Identify the actor and authentication context
- Review
aws.cloudtrail.user_identity.arnandaws.cloudtrail.user_identity.access_key_idto determine the caller. - Check
source.ip,source.geofields, anduser_agent.originalto determine whether the action originated from an expected network path or automation platform. - Compare the actor and access key to historical usage patterns.
- Review
-
Determine what key was affected and its criticality
- Inspect
aws.cloudtrail.resources.arnto identify the KMS key. - Determine:
- The services and data protected by the key (e.g., RDS, EBS, S3, Secrets Manager).
- The environment (prod vs. dev).
- Owner or application team.
- Inspect
-
Understand the scope and intent of the change
- For
DisableKey, determine whether a dependent service immediately began failing or experienced decryption errors. - For
ScheduleKeyDeletion, examine thePendingWindowInDaysvalue withinaws.cloudtrail.request_parameters. - Check whether the key was previously rotated, enabled/disabled, or had its policy recently modified.
- For
-
Correlate with surrounding events
- Look for:
- IAM policy changes granting new KMS privileges.
- Access anomalies involving the same principal.
- File system, database, or backup deletions near the same timeframe.
- S3, EBS, or RDS resources showing encryption failures.
- Determine whether other keys were modified in the same window (possible broader sabotage attempt).
- Look for:
-
Validate intent with owners
- Confirm with the application, data, or security owners:
- Whether deactivation or scheduled deletion was requested.
- Whether the key was being replaced, migrated, or retired.
- Confirm with the application, data, or security owners:
False positive analysis
-
Planned key lifecycle activities
- Some organizations disable KMS keys before rotation, migration, or decommissioning.
- Scheduled deletion during infrastructure teardown may be expected in CI/CD-driven ephemeral environments.
-
Configuration errors
- Misapplied tags or incorrect CloudFormation teardown workflows can unintentionally disable or schedule deletion of KMS keys.
If any of the above conditions apply, consider adjusting rule exceptions based on IAM principal, environment tag, or automation role.
Response and remediation
-
Contain and validate
- Immediately confirm whether the key disablement or deletion schedule was intentional.
- If unauthorized, cancel scheduled deletion (
CancelKeyDeletion) and re-enable the key (EnableKey) as appropriate. - Rotate credentials or access keys used by the actor if compromise is suspected.
-
Assess impact
- Identify all AWS services and data encrypted with the affected KMS key.
- Review logs and service metrics for failures involving:
- EBS volume attachments
- RDS instance decryption
- S3 object access
- Secrets Manager retrieval
- Lambda environment variable decryption
-
Investigate for compromise
- Review CloudTrail activity for the principal:
- Permission escalations
- Unusual STS role assumptions
- S3, EC2, RDS destructive behavior
- Look for preceding data access or exfiltration attempts.
- Review CloudTrail activity for the principal:
-
Strengthen controls
- Restrict AWS KMS lifecycle permissions (
kms:DisableKey,kms:ScheduleKeyDeletion) to a very small privileged set. - Use AWS Organizations SCPs to prevent KMS key deletion in production accounts.
- Enable AWS Config rules for KMS key state monitoring.
- Require MFA for administrators capable of key management.
- Restrict AWS KMS lifecycle permissions (
-
Post-incident improvement
- Update runbooks to include KMS lifecycle change approvals.
- Implement tagging standards to designate high-risk keys.
- Enhance monitoring for key policy modifications or changes to principal permissions.
Additional information
- AWS IR Playbooks
- AWS Customer Playbook Framework
- Security Best Practices: AWS Knowledge Center – Security Best Practices.
References
Related rules
- AWS CloudWatch Log Group Deletion
- AWS CloudWatch Log Stream Deletion
- AWS CloudTrail Log Updated
- AWS S3 Bucket Enumeration or Brute Force
- AWS EFS File System Deleted