Kubernetes User Exec into Pod

 1[metadata]
 2creation_date = "2022/05/17"
 3integration = ["kubernetes"]
 4maturity = "production"
 5updated_date = "2025/01/15"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec'
11command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An
12adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has
13permissions to, including secrets.
14"""
15false_positives = [
16    """
17    An administrator may need to exec into a pod for a legitimate reason like debugging purposes. Containers built from
18    Linux and Windows OS images, tend to include debugging utilities. In this case, an admin may choose to run commands
19    inside a specific container with kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ...
20    ${ARGN}. For example, the following command can be used to look at logs from a running Cassandra pod: kubectl exec
21    cassandra --cat /var/log/cassandra/system.log . Additionally, the -i and -t arguments might be used to run a shell
22    connected to the terminal: kubectl exec -i -t cassandra -- sh
23    """,
24]
25index = ["logs-kubernetes.*"]
26language = "kuery"
27license = "Elastic License v2"
28name = "Kubernetes User Exec into Pod"
29note = """## Triage and analysis
30
31> **Disclaimer**:
32> 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.
33
34### Investigating Kubernetes User Exec into Pod
35
36Kubernetes allows users to execute commands within a pod using the 'exec' command, facilitating temporary shell sessions for legitimate management tasks. However, adversaries can exploit this to gain unauthorized access, potentially exposing sensitive data. The detection rule identifies such misuse by monitoring audit logs for specific patterns, such as allowed 'exec' actions on pods, indicating possible malicious activity.
37
38### Possible investigation steps
39
40- Review the Kubernetes audit logs to identify the user who executed the 'exec' command by examining the event.dataset field for "kubernetes.audit_logs".
41- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed and determine if the user had legitimate access.
42- Investigate the kubernetes.audit.objectRef.resource and kubernetes.audit.objectRef.subresource fields to verify that the action involved a pod and the 'exec' subresource.
43- Analyze the context of the pod involved, including its purpose and the data it has access to, to assess the potential impact of the unauthorized access.
44- Correlate the event with other logs or alerts to identify any suspicious patterns or repeated unauthorized access attempts by the same user or IP address.
45- Review the user's activity history to determine if there are other instances of unusual or unauthorized access attempts within the Kubernetes environment.
46
47### False positive analysis
48
49- Routine administrative tasks by DevOps teams can trigger the rule when they use 'exec' for legitimate management purposes. To handle this, create exceptions for specific user accounts or roles that are known to perform these tasks regularly.
50- Automated scripts or tools that use 'exec' for monitoring or maintenance can also cause false positives. Identify these scripts and whitelist their associated service accounts or IP addresses.
51- Scheduled jobs or cron tasks that require 'exec' to perform updates or checks within pods may be flagged. Exclude these by setting up time-based exceptions for known maintenance windows.
52- Development environments where frequent testing and debugging occur using 'exec' can lead to alerts. Implement environment-specific exclusions to reduce noise from non-production clusters.
53
54### Response and remediation
55
56- Immediately isolate the affected pod to prevent further unauthorized access or data exposure. This can be done by applying network policies or temporarily scaling down the pod.
57- Review the audit logs to identify the user or service account responsible for the 'exec' command and assess whether the access was legitimate or unauthorized.
58- Revoke or adjust permissions for the identified user or service account to prevent further unauthorized 'exec' actions. Ensure that only necessary permissions are granted following the principle of least privilege.
59- Conduct a thorough investigation of the pod's environment to identify any potential data exposure or tampering. Check for unauthorized changes to configurations, secrets, or data within the pod.
60- If unauthorized access is confirmed, rotate any exposed secrets or credentials that the pod had access to, and update any affected systems or services.
61- Escalate the incident to the security operations team for further analysis and to determine if additional systems or pods have been compromised.
62- Enhance monitoring and alerting for similar 'exec' actions in the future by ensuring that audit logs are continuously reviewed and that alerts are configured to notify the security team of any suspicious activity.
63
64## Setup
65
66The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
67references = [
68    "https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/",
69    "https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/",
70]
71risk_score = 47
72rule_id = "14de811c-d60f-11ec-9fd7-f661ea17fbce"
73severity = "medium"
74tags = ["Data Source: Kubernetes", "Tactic: Execution", "Resources: Investigation Guide"]
75timestamp_override = "event.ingested"
76type = "query"
77
78query = '''
79event.dataset : "kubernetes.audit_logs"
80  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
81  and kubernetes.audit.verb:"create"
82  and kubernetes.audit.objectRef.resource:"pods"
83  and kubernetes.audit.objectRef.subresource:"exec"
84'''
85
86
87[[rule.threat]]
88framework = "MITRE ATT&CK"
89[[rule.threat.technique]]
90id = "T1609"
91name = "Container Administration Command"
92reference = "https://attack.mitre.org/techniques/T1609/"
93
94
95[rule.threat.tactic]
96id = "TA0002"
97name = "Execution"
98reference = "https://attack.mitre.org/tactics/TA0002/"