Azure Kubernetes Pods Deleted
Identifies the deletion of Azure Kubernetes Pods. Adversaries may delete a Kubernetes pod to disrupt the normal behavior of the environment.
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 the deletion of Azure Kubernetes Pods. Adversaries may delete a Kubernetes pod to disrupt the normal behavior
11of the environment.
12"""
13false_positives = [
14 """
15 Pods may be deleted by a system administrator. Verify whether the user identity, user agent, and/or hostname should
16 be making changes in your environment. Pods deletions by unfamiliar users or hosts should be investigated. If known
17 behavior is causing false positives, it can be exempted from the rule.
18 """,
19]
20from = "now-25m"
21index = ["filebeat-*", "logs-azure*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "Azure Kubernetes Pods Deleted"
25note = """## Triage and analysis
26
27> **Disclaimer**:
28> 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.
29
30### Investigating Azure Kubernetes Pods Deleted
31
32Azure Kubernetes Service (AKS) enables the deployment, management, and scaling of containerized applications using Kubernetes. Pods, the smallest deployable units in Kubernetes, can be targeted by adversaries to disrupt services or evade detection. Malicious actors might delete pods to cause downtime or hide their activities. The detection rule monitors Azure activity logs for successful pod deletion operations, alerting security teams to potential unauthorized actions that could impact the environment's stability and security.
33
34### Possible investigation steps
35
36- Review the Azure activity logs to confirm the details of the pod deletion event, focusing on the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE" and ensuring the event outcome is marked as "Success".
37- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs.
38- Check the timeline of events leading up to the pod deletion to identify any unusual or unauthorized access patterns or activities.
39- Investigate the specific Kubernetes cluster and namespace where the pod deletion occurred to assess the potential impact on services and applications.
40- Cross-reference the deleted pod's details with recent changes or deployments in the environment to determine if the deletion was part of a legitimate maintenance or deployment activity.
41- Consult with the relevant application or infrastructure teams to verify if the pod deletion was authorized and necessary, or if it indicates a potential security incident.
42
43### False positive analysis
44
45- Routine maintenance or updates by authorized personnel can lead to legitimate pod deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
46- Automated scaling operations might delete pods as part of normal scaling activities. Identify and exclude these operations by correlating with scaling events or using tags that indicate automated processes.
47- Development and testing environments often experience frequent pod deletions as part of normal operations. Consider excluding these environments from alerts by using environment-specific identifiers or tags.
48- Scheduled job completions may result in pod deletions once tasks are finished. Implement rules to recognize and exclude these scheduled operations by matching them with known job schedules or identifiers.
49
50### Response and remediation
51
52- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules temporarily.
53- Review the Azure activity logs to identify the source of the deletion request, including the user or service principal involved, and verify if the action was authorized.
54- Recreate the deleted pods using the latest known good configuration to restore services and minimize downtime.
55- Conduct a thorough security assessment of the affected cluster to identify any additional unauthorized changes or indicators of compromise.
56- Implement stricter access controls and role-based access management to ensure only authorized personnel can delete pods in the future.
57- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected.
58- Enhance monitoring and alerting for similar activities by integrating with a Security Information and Event Management (SIEM) system to detect and respond to unauthorized pod deletions promptly.
59
60## Setup
61
62The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
63references = [
64 "https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkubernetes",
65]
66risk_score = 47
67rule_id = "83a1931d-8136-46fc-b7b9-2db4f639e014"
68severity = "medium"
69tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Asset Visibility", "Tactic: Impact", "Resources: Investigation Guide"]
70timestamp_override = "event.ingested"
71type = "query"
72
73query = '''
74event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE" and
75event.outcome:(Success or success)
76'''
77
78
79[[rule.threat]]
80framework = "MITRE ATT&CK"
81
82[rule.threat.tactic]
83id = "TA0040"
84name = "Impact"
85reference = "https://attack.mitre.org/tactics/TA0040/"
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 Pods Deleted
Azure Kubernetes Service (AKS) enables the deployment, management, and scaling of containerized applications using Kubernetes. Pods, the smallest deployable units in Kubernetes, can be targeted by adversaries to disrupt services or evade detection. Malicious actors might delete pods to cause downtime or hide their activities. The detection rule monitors Azure activity logs for successful pod deletion operations, alerting security teams to potential unauthorized actions that could impact the environment's stability and security.
Possible investigation steps
- Review the Azure activity logs to confirm the details of the pod deletion event, focusing on the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE" and ensuring 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.
- Check the timeline of events leading up to the pod deletion to identify any unusual or unauthorized access patterns or activities.
- Investigate the specific Kubernetes cluster and namespace where the pod deletion occurred to assess the potential impact on services and applications.
- Cross-reference the deleted pod's details with recent changes or deployments in the environment to determine if the deletion was part of a legitimate maintenance or deployment activity.
- Consult with the relevant application or infrastructure teams to verify if the pod deletion was authorized and necessary, or if it indicates a potential security incident.
False positive analysis
- Routine maintenance or updates by authorized personnel can lead to legitimate pod deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
- Automated scaling operations might delete pods as part of normal scaling activities. Identify and exclude these operations by correlating with scaling events or using tags that indicate automated processes.
- Development and testing environments often experience frequent pod deletions as part of normal operations. Consider excluding these environments from alerts by using environment-specific identifiers or tags.
- Scheduled job completions may result in pod deletions once tasks are finished. Implement rules to recognize and exclude these scheduled operations by matching them with known job schedules or identifiers.
Response and remediation
- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules temporarily.
- Review the Azure activity logs to identify the source of the deletion request, including the user or service principal involved, and verify if the action was authorized.
- Recreate the deleted pods using the latest known good configuration to restore services and minimize downtime.
- Conduct a thorough security assessment of the affected cluster to identify any additional unauthorized changes or indicators of compromise.
- Implement stricter access controls and role-based access management to ensure only authorized personnel can delete pods in the future.
- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected.
- Enhance monitoring and alerting for similar activities by integrating with a Security Information and Event Management (SIEM) system to detect and respond to unauthorized pod deletions promptly.
Setup
The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
References
Related rules
- AWS Deletion of RDS Instance or Cluster
- AWS RDS Instance/Cluster Stoppage
- AWS RDS Snapshot Deleted
- Azure Blob Container Access Level Modification
- Azure Resource Group Deletion