Kubernetes Events Deleted

 1[metadata]
 2creation_date = "2025/06/27"
 3integration = ["kubernetes"]
 4maturity = "production"
 5updated_date = "2025/07/07"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious
11activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it
12harder for defenders to investigate and respond to incidents.
13"""
14index = ["logs-kubernetes.audit_logs-*"]
15language = "eql"
16license = "Elastic License v2"
17name = "Kubernetes Events Deleted"
18note = """ ## Triage and analysis
19
20> **Disclaimer**:
21> 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.
22
23### Investigating Kubernetes Events Deleted
24Kubernetes, 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.
25
26### Possible investigation steps
27
28- Review the audit logs to identify the source of the deletion request by examining the `kubernetes.audit.user.username` field to determine which user or service account initiated the delete action.
29- Check the `kubernetes.audit.sourceIPs` field to trace the IP address from which the deletion request originated, which can help identify potential unauthorized access.
30- Investigate the `kubernetes.audit.objectRef.namespace` field to understand which namespace the deleted events belonged to, as this can provide context on the affected applications or services.
31- Analyze the timeline of events leading up to the deletion by reviewing other audit logs with similar `kubernetes.audit.verb` values to identify any suspicious activities or patterns.
32- 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.
33- Cross-reference the deletion event with other security alerts or logs to identify any correlated activities that might indicate a broader attack or misconfiguration.
34
35### False positive analysis
36
37- 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.
38- 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.
39- 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.
40- 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.
41
42### Response and remediation
43
44- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or tampering with event logs.
45- Review and restore any deleted Kubernetes events from backup logs or snapshots to ensure a complete audit trail is available for further investigation.
46- 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.
47- Implement stricter logging and monitoring policies to ensure that any future deletions of Kubernetes events are detected and alerted in real-time.
48- 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.
49- 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.
50- 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.
51"""
52risk_score = 21
53rule_id = "33c27b4e-8ec6-406f-b8e5-345dc024aa97"
54severity = "low"
55tags = [
56    "Data Source: Kubernetes",
57    "Domain: Kubernetes",
58    "Use Case: Threat Detection",
59    "Tactic: Defense Evasion",
60    "Resources: Investigation Guide",
61    ]
62timestamp_override = "event.ingested"
63type = "eql"
64query = '''
65any where host.os.type == "linux" and event.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb == "delete" and
66kubernetes.audit.objectRef.resource == "events" and kubernetes.audit.stage == "ResponseComplete"
67'''
68
69[[rule.threat]]
70framework = "MITRE ATT&CK"
71
72[[rule.threat.technique]]
73id = "T1070"
74name = "Indicator Removal"
75reference = "https://attack.mitre.org/techniques/T1070/"
76
77[[rule.threat.technique.subtechnique]]
78id = "T1070.004"
79name = "File Deletion"
80reference = "https://attack.mitre.org/techniques/T1070/004/"
81
82[rule.threat.tactic]
83id = "TA0005"
84name = "Defense Evasion"
85reference = "https://attack.mitre.org/tactics/TA0005/"