Azure Kubernetes Events Deleted
Identifies when events are deleted in Azure Kubernetes. Kubernetes events are objects that log any state changes. Example events are a container creation, an image pull, or a pod scheduling on a node. An adversary may delete events in Azure Kubernetes in an attempt to evade detection.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2021/06/24"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Austin Songer"]
9description = """
10Identifies when events are deleted in Azure Kubernetes. Kubernetes events are objects that log any state changes.
11Example events are a container creation, an image pull, or a pod scheduling on a node. An adversary may delete events in
12Azure Kubernetes in an attempt to evade detection.
13"""
14false_positives = [
15 """
16 Events deletions may be done by a system or network administrator. Verify whether the username, hostname, and/or
17 resource name should be making changes in your environment. Events deletions by unfamiliar users or hosts should be
18 investigated. If known behavior is causing false positives, it can be exempted from the rule.
19 """,
20]
21from = "now-25m"
22index = ["filebeat-*", "logs-azure*"]
23language = "kuery"
24license = "Elastic License v2"
25name = "Azure Kubernetes Events Deleted"
26note = """## Triage and analysis
27
28> **Disclaimer**:
29> 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.
30
31### Investigating Azure Kubernetes Events Deleted
32
33Azure Kubernetes Service (AKS) manages containerized applications using Kubernetes, which logs events like state changes. These logs are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impairing defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs, flagging successful deletion operations to alert security teams of potential evasion tactics.
34
35### Possible investigation steps
36
37- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE" and ensure the event outcome is marked as "Success".
38- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs.
39- Investigate the timeline of events leading up to and following the deletion to identify any suspicious activities or patterns, such as unauthorized access attempts or configuration changes.
40- Check for any other related alerts or anomalies in the Azure environment that might indicate a broader attack or compromise.
41- Assess the impact of the deleted events by determining which Kubernetes resources or operations were affected and if any critical logs were lost.
42- Review access controls and permissions for the user or service principal involved to ensure they align with the principle of least privilege and adjust if necessary.
43- Consider implementing additional monitoring or alerting for similar deletion activities to enhance detection and response capabilities.
44
45### False positive analysis
46
47- Routine maintenance activities by authorized personnel may trigger deletion events. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
48- Automated scripts or tools used for log rotation or cleanup might delete events as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts by whitelisting their associated service accounts or IP addresses.
49- Misconfigured applications or services that inadvertently delete logs can cause false positives. Review application configurations and adjust them to prevent unnecessary deletions, and exclude these applications from alerts if they are verified as non-threatening.
50- Test environments often generate log deletions during setup or teardown processes. Exclude these environments from monitoring or create specific rules that differentiate between production and test environments to avoid unnecessary alerts.
51
52### Response and remediation
53
54- Immediately isolate the affected Azure Kubernetes cluster to prevent further unauthorized access or tampering with logs.
55- Conduct a thorough review of recent activity logs and access permissions for the affected cluster to identify any unauthorized access or privilege escalation.
56- Restore deleted Kubernetes events from backups or snapshots if available, to ensure continuity in monitoring and auditing.
57- Implement stricter access controls and audit logging for Kubernetes event deletion operations to prevent unauthorized deletions in the future.
58- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
59- Escalate the incident to the incident response team if there is evidence of broader compromise or if the deletion is part of a larger attack campaign.
60- Review and update incident response plans to incorporate lessons learned from this event, ensuring quicker detection and response to similar threats in the future.
61
62## Setup
63
64The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
65references = [
66 "https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkubernetes",
67]
68risk_score = 47
69rule_id = "8b64d36a-1307-4b2e-a77b-a0027e4d27c8"
70severity = "medium"
71tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
72timestamp_override = "event.ingested"
73type = "query"
74
75query = '''
76event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE" and
77event.outcome:(Success or success)
78'''
79
80
81[[rule.threat]]
82framework = "MITRE ATT&CK"
83[[rule.threat.technique]]
84id = "T1562"
85name = "Impair Defenses"
86reference = "https://attack.mitre.org/techniques/T1562/"
87[[rule.threat.technique.subtechnique]]
88id = "T1562.001"
89name = "Disable or Modify Tools"
90reference = "https://attack.mitre.org/techniques/T1562/001/"
91
92
93
94[rule.threat.tactic]
95id = "TA0005"
96name = "Defense Evasion"
97reference = "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 Azure Kubernetes Events Deleted
Azure Kubernetes Service (AKS) manages containerized applications using Kubernetes, which logs events like state changes. These logs are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impairing defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs, flagging successful deletion operations to alert security teams of potential evasion tactics.
Possible investigation steps
- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE" and ensure the event outcome is marked as "Success".
- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs.
- Investigate the timeline of events leading up to and following the deletion to identify any suspicious activities or patterns, such as unauthorized access attempts or configuration changes.
- Check for any other related alerts or anomalies in the Azure environment that might indicate a broader attack or compromise.
- Assess the impact of the deleted events by determining which Kubernetes resources or operations were affected and if any critical logs were lost.
- Review access controls and permissions for the user or service principal involved to ensure they align with the principle of least privilege and adjust if necessary.
- Consider implementing additional monitoring or alerting for similar deletion activities to enhance detection and response capabilities.
False positive analysis
- Routine maintenance activities by authorized personnel may trigger deletion events. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
- Automated scripts or tools used for log rotation or cleanup might delete events as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts by whitelisting their associated service accounts or IP addresses.
- Misconfigured applications or services that inadvertently delete logs can cause false positives. Review application configurations and adjust them to prevent unnecessary deletions, and exclude these applications from alerts if they are verified as non-threatening.
- Test environments often generate log deletions during setup or teardown processes. Exclude these environments from monitoring or create specific rules that differentiate between production and test environments to avoid unnecessary alerts.
Response and remediation
- Immediately isolate the affected Azure Kubernetes cluster to prevent further unauthorized access or tampering with logs.
- Conduct a thorough review of recent activity logs and access permissions for the affected cluster to identify any unauthorized access or privilege escalation.
- Restore deleted Kubernetes events from backups or snapshots if available, to ensure continuity in monitoring and auditing.
- Implement stricter access controls and audit logging for Kubernetes event deletion operations to prevent unauthorized deletions in the future.
- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
- Escalate the incident to the incident response team if there is evidence of broader compromise or if the deletion is part of a larger attack campaign.
- Review and update incident response plans to incorporate lessons learned from this event, ensuring quicker detection and response to similar threats in the future.
Setup
The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
References
Related rules
- Azure Event Hub Deletion
- AWS SQS Queue Purge
- Azure Alert Suppression Rule Created or Modified
- Azure Application Credential Modification
- Azure Automation Runbook Deleted