Potential Kubernetes Impersonation via Kubectl Flags
Adversaries may perform unauthorized impersonation within Kubernetes clusters by executing the 'kubectl' command-line tool with sensitive flags like '--as' or '--token' to escalate privileges or bypass access controls.
What's new
- 1. new product Sep 19, 13:11 via elastic
Adversaries targeting containerized environments may exploit the 'kubectl' command-line interface to perform unauthorized impersonation. By utilizing specific flags such as '--as', '--as-group', '--as-uid', '--token', or '--kubeconfig', an attacker can assume the identity of another user or service account within a Kubernetes cluster. This technique allows adversaries to leverage valid accounts or stolen authentication materials to escalate privileges, bypass existing access controls, and move laterally across the cluster. This activity is often detected when 'kubectl' is executed from unconventional or high-risk locations, such as temporary directories ('/tmp', '/var/tmp') or via shell scripts, which may indicate that the command is being invoked by automated malicious payloads rather than an interactive administrator session. Organizations should monitor process execution logs for these specific flags to identify potentially malicious cluster interactions.
Attack Chain
- An adversary gains initial access to a Linux or macOS container host.
- The attacker discovers existing 'kubeconfig' files or sensitive tokens on the filesystem.
- The attacker locates the 'kubectl' binary on the host or downloads a malicious version.
- The attacker initiates 'kubectl' execution from a suspicious location like '/tmp/' or via an automated shell script.
- The attacker executes 'kubectl' with impersonation flags (e.g., --as, --token) to assume elevated privileges of a target service account.
- The adversary uses the impersonated identity to query or modify cluster resources.
- The objective is to achieve unauthorized persistence, exfiltrate sensitive cluster data, or deploy malicious pods.
Impact
Successful impersonation in a Kubernetes environment can result in full cluster compromise, unauthorized access to sensitive application secrets, data exfiltration from persistent volumes, and the deployment of persistent malicious workloads. This threat is particularly significant in environments where role-based access control (RBAC) relies on service account tokens that are vulnerable to theft.
Recommendation
- Deploy the provided detection rule to identify 'kubectl' executions involving impersonation flags.
- Audit Kubernetes RBAC policies to ensure that the "impersonate" verb is strictly limited to authorized administrative service accounts.
- Implement strict filesystem integrity monitoring on nodes to detect unauthorized execution from temporary directories ('/tmp', '/var/tmp', '/dev/shm').
- Revoke and rotate credentials associated with identified impersonation events if they do not align with known CI/CD pipeline activity.
- Enable container-aware logging to correlate 'kubectl' process executions with specific Kubernetes API server audit logs.
Immediate actions
Deploy kubectl impersonation detection rule
Threat Hunt
Search for historical process starts of kubectl with --as, --token, or --kubeconfig arguments
Data: process_creation logs
Mitigations
Audit Kubernetes RBAC permissions for 'impersonate' verb
T1078
Detection coverage 1
Detect Potential Impersonation Attempt via Kubectl
mediumDetects kubectl process execution with impersonation flags such as --as, --token, or --kubeconfig, often initiated from suspicious parent processes or locations.
Detection queries are available on the platform. Get full rules →