This rule detects the deletion of Kubernetes Event objects within AWS EKS control-plane audit logs. It queries the AWS EKS audit data stream (data_stream.dataset: aws.eks_audit) for records where the verb is delete or deletecollection, the resource is events, and the audit stage is ResponseComplete. An exception excludes deletions performed by the kube-system namespace’s namespace-controller service account to reduce benign noise. The AWS integration normalizes these audit records to the aws.eks.audit.* fields and requires that audit logs are enabled on the EKS cluster and routed through the integration, with data_stream.dataset: aws.eks_audit and cloud.provider: aws present. This rule maps to MITRE ATT&CK Defense Evasion (TA0005), specifically T1070 (Indicator Removal) and its subtechnique T1070.004 (File Deletion), since removing event logs is a classic method for attackers to erase traces and hinder incident response. The detection provides a targeted signal for potential defense-evasion activity or misconfigurations that remove traceability within Kubernetes events. Investigating deployments and activity around such deletions can reveal whether actors attempted to cover tracks, disable auditing, or misused permissions. The rule is valuable for security teams monitoring cloud-native environments and can help identify attempts to erase evidence across the Kubernetes control plane rather than within application logs alone. Possible investigation steps include: - Inspect aws.eks.audit.user.username to identify the actor initiating the deletion. - Review aws.eks.audit.sourceIPs to locate the origin of the request. - Examine aws.eks.audit.objectRef.namespace to determine which namespace the events belonged to. - Correlate with other audit records sharing similar aws.eks.audit.verb values to detect related suspicious activity. - Assess the permissions of the implicated user or service account for potential privilege escalation or abuse. - Cross-check with other security alerts to identify broader attack patterns or misconfigurations. False positives may arise from routine maintenance or cleanup tasks, automated scripts, misconfigurations, or development/test environments. To reduce noise, consider whitelisting known maintenance windows, service accounts, or IPs, and differentiating environments with separate rules. Remediation and response guidance includes isolating the cluster if needed, restoring any deleted event records from backups for a complete audit trail, reviewing access controls, enforcing stricter auditing and real-time alerting, coordinating with the SOC and IR teams for root-cause analysis, and updating policies to strengthen defenses against defense-evasion tactics as described in MITRE ATT&CK. Setup prerequisites emphasize enabling EKS control-plane audit logs, routing them through the AWS integration, and validating that data_stream.dataset: aws.eks_audit and cloud.provider: aws are present before enabling the rule.