AWS EKS Events Deleted
This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/08/03"
3integration = ["aws"]
4maturity = "production"
5min_stack_comments = "The AWS integration adds the aws.eks_audit data stream in package 8.9.0, which requires Kibana 9.6.0 or later."
6min_stack_version = "9.6.0"
7updated_date = "2026/10/20"
8
9[rule]
10author = ["Elastic"]
11description = """
12This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or
13misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to
14investigate and respond to incidents.
15"""
16false_positives = [
17 """
18 Administrators may delete Kubernetes Event objects during routine troubleshooting or cleanup. Confirm the actor,
19 scope, and timing before treating the activity as malicious.
20 """,
21]
22from = "now-6m"
23index = ["logs-aws.eks_audit-*"]
24language = "kuery"
25license = "Elastic License v2"
26name = "AWS EKS Events Deleted"
27note = """## Triage and analysis
28
29> **Disclaimer**:
30> 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.
31
32### Investigating AWS EKS Events Deleted
33Kubernetes, a container orchestration platform, logs events to track activities within the cluster. These events are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impeding incident response. The detection rule identifies deletions of Kubernetes events, signaling potential defense evasion attempts by matching specific audit log attributes, thus alerting security teams to investigate further.
34
35### Possible investigation steps
36
37- Review the audit logs to identify the source of the deletion request by examining the `aws.eks.audit.user.username` field to determine which user or service account initiated the delete action.
38- Check the `aws.eks.audit.sourceIPs` field to trace the IP address from which the deletion request originated, which can help identify potential unauthorized access.
39- Investigate the `aws.eks.audit.objectRef.namespace` field to understand which namespace the deleted events belonged to, as this can provide context on the affected applications or services.
40- Analyze the timeline of events leading up to the deletion by reviewing other audit logs with similar `aws.eks.audit.verb` values to identify any suspicious activities or patterns.
41- Assess the role and permissions of the user or service account involved in the deletion to determine if they had legitimate access or if there was a potential privilege escalation.
42- Cross-reference the deletion event with other security alerts or logs to identify any correlated activities that might indicate a broader attack or misconfiguration.
43
44### False positive analysis
45
46- Routine maintenance activities may involve the deletion of Kubernetes events, such as during cluster upgrades or cleanup tasks. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks.
47- Automated scripts or tools that manage Kubernetes resources might delete events as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by whitelisting their service accounts or IP addresses.
48- Misconfigured applications or services might inadvertently delete events. Regularly review and update configurations to ensure they align with best practices, and consider excluding specific applications if they are known to cause benign deletions.
49- Development and testing environments often have more frequent event deletions as part of iterative testing processes. Implement separate monitoring rules or thresholds for these environments to reduce noise in alerts.
50
51### Response and remediation
52
53- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or tampering with event logs.
54- Review and restore any deleted Kubernetes events from backup logs or snapshots to ensure a complete audit trail is available for further investigation.
55- Conduct a thorough review of access controls and permissions within the Kubernetes environment to identify and revoke any unauthorized access that may have led to the deletion of events.
56- Implement stricter logging and monitoring policies to ensure that any future deletions of Kubernetes events are detected and alerted in real-time.
57- Escalate the incident to the security operations center (SOC) for a comprehensive analysis of potential breaches and to determine if additional systems or data were affected.
58- Coordinate with the incident response team to conduct a root cause analysis and identify any vulnerabilities or misconfigurations that allowed the event deletion to occur.
59- Update and reinforce security policies and procedures to prevent similar incidents, including enhancing detection capabilities for defense evasion tactics as outlined in MITRE ATT&CK."""
60risk_score = 21
61rule_id = "9f717eba-243c-5e10-bfca-9cd8c4ed60f1"
62setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
63into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
64pipelines normalize each audit record under `aws.eks.audit.*`.
65
66Enable the `audit` control-plane log type on the EKS cluster, send its
67CloudWatch log group through the AWS integration, and confirm events carry
68`data_stream.dataset: aws.eks_audit` and
69`cloud.provider: aws` before enabling this rule.
70"""
71severity = "low"
72tags = [
73 "Domain: Cloud",
74 "Domain: Containers",
75 "Platform: AWS",
76 "Platform: Kubernetes",
77 "Data Source: AWS",
78 "Data Source: Amazon Web Services",
79 "Data Source: Kubernetes API Server Audit Logs",
80 "Service: AWS EKS",
81 "Use Case: Threat Detection",
82 "Tactic: Defense Evasion",
83 "Rule Type: Custom Query (KQL)",
84 "Resources: Investigation Guide",
85 "Profile: Beta",
86]
87timestamp_override = "event.ingested"
88type = "query"
89
90query = '''
91data_stream.dataset:"aws.eks_audit" and
92aws.eks.audit.verb:("delete" or "deletecollection") and
93aws.eks.audit.objectRef.resource:"events" and
94aws.eks.audit.stage:"ResponseComplete" and
95not user.name:"system:serviceaccount:kube-system:namespace-controller"
96'''
97
98
99[[rule.threat]]
100framework = "MITRE ATT&CK"
101[[rule.threat.technique]]
102id = "T1070"
103name = "Indicator Removal"
104reference = "https://attack.mitre.org/techniques/T1070/"
105[[rule.threat.technique.subtechnique]]
106id = "T1070.004"
107name = "File Deletion"
108reference = "https://attack.mitre.org/techniques/T1070/004/"
109
110
111
112[rule.threat.tactic]
113id = "TA0005"
114name = "Defense Evasion"
115reference = "https://attack.mitre.org/tactics/TA0005/"
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 EKS Events Deleted
Kubernetes, a container orchestration platform, logs events to track activities within the cluster. These events are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impeding incident response. The detection rule identifies deletions of Kubernetes events, signaling potential defense evasion attempts by matching specific audit log attributes, thus alerting security teams to investigate further.
Possible investigation steps
- Review the audit logs to identify the source of the deletion request by examining the
aws.eks.audit.user.usernamefield to determine which user or service account initiated the delete action. - Check the
aws.eks.audit.sourceIPsfield to trace the IP address from which the deletion request originated, which can help identify potential unauthorized access. - Investigate the
aws.eks.audit.objectRef.namespacefield to understand which namespace the deleted events belonged to, as this can provide context on the affected applications or services. - Analyze the timeline of events leading up to the deletion by reviewing other audit logs with similar
aws.eks.audit.verbvalues to identify any suspicious activities or patterns. - Assess the role and permissions of the user or service account involved in the deletion to determine if they had legitimate access or if there was a potential privilege escalation.
- Cross-reference the deletion event with other security alerts or logs to identify any correlated activities that might indicate a broader attack or misconfiguration.
False positive analysis
- Routine maintenance activities may involve the deletion of Kubernetes events, such as during cluster upgrades or cleanup tasks. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks.
- Automated scripts or tools that manage Kubernetes resources might delete events as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by whitelisting their service accounts or IP addresses.
- Misconfigured applications or services might inadvertently delete events. Regularly review and update configurations to ensure they align with best practices, and consider excluding specific applications if they are known to cause benign deletions.
- Development and testing environments often have more frequent event deletions as part of iterative testing processes. Implement separate monitoring rules or thresholds for these environments to reduce noise in alerts.
Response and remediation
- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or tampering with event logs.
- Review and restore any deleted Kubernetes events from backup logs or snapshots to ensure a complete audit trail is available for further investigation.
- Conduct a thorough review of access controls and permissions within the Kubernetes environment to identify and revoke any unauthorized access that may have led to the deletion of events.
- Implement stricter logging and monitoring policies to ensure that any future deletions of Kubernetes events are detected and alerted in real-time.
- Escalate the incident to the security operations center (SOC) for a comprehensive analysis of potential breaches and to determine if additional systems or data were affected.
- Coordinate with the incident response team to conduct a root cause analysis and identify any vulnerabilities or misconfigurations that allowed the event deletion to occur.
- Update and reinforce security policies and procedures to prevent similar incidents, including enhancing detection capabilities for defense evasion tactics as outlined in MITRE ATT&CK.
Related rules
- AWS EKS Secret get or list from Node or Pod Service Account
- AWS EKS Secret get or list with Suspicious User Agent
- AWS EKS Secrets List Across Cluster or Sensitive Namespaces
- AWS EKS Service Account Token Created via TokenRequest API
- AWS EKS Pod Exec Cloud Instance Metadata Access