Potential Impersonation Attempt via Kubectl

  1[metadata]
  2creation_date = "2025/06/19"
  3integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5updated_date = "2025/07/21"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects potential impersonation attempts via the "kubectl" command in Linux environments. It identifies
 11process events where "kubectl" is executed with arguments that suggest an attempt to impersonate another user or
 12group, such as using "--kubeconfig", "--token", "--as", or "--as-group". This could indicate an adversary trying
 13to gain unauthorized access or escalate privileges within a Kubernetes cluster. If this rule is triggered, in
 14conjunction with rules related to secret access or kubeconfig file discovery, it may indicate a potential
 15impersonation attempt.
 16"""
 17from = "now-9m"
 18index = [
 19    "auditbeat-*",
 20    "endgame-*",
 21    "logs-auditd_manager.auditd-*",
 22    "logs-endpoint.events.process*",
 23    "logs-sentinel_one_cloud_funnel.*",
 24]
 25language = "eql"
 26license = "Elastic License v2"
 27name = "Potential Impersonation Attempt via Kubectl"
 28note = """## Triage and analysis
 29
 30> **Disclaimer**:
 31> 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.
 32
 33### Investigating Potential Impersonation Attempt via Kubectl
 34
 35Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit kubectl by using specific arguments to impersonate users, gaining unauthorized access or escalating privileges. The detection rule identifies suspicious kubectl executions, focusing on arguments that suggest impersonation, such as those related to user identity and authentication, to flag potential misuse.
 36
 37### Possible investigation steps
 38
 39- Review the process arguments to confirm the presence of impersonation-related flags such as "--kubeconfig", "--token", "--as", "--as-group", or "--as-uid" to understand the scope of the impersonation attempt.
 40- Examine the parent process name and executable path to determine if the kubectl command was initiated from a suspicious location or script, such as "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", or "/home/*".
 41- Check the user account associated with the kubectl execution to assess whether it aligns with expected usage patterns or if it indicates potential unauthorized access.
 42- Investigate related alerts or logs for secret access or kubeconfig file discovery to identify if there is a broader pattern of suspicious activity that could indicate a coordinated impersonation attempt.
 43- Analyze the network activity associated with the kubectl execution to identify any unusual connections or data transfers that may suggest unauthorized access or data exfiltration.
 44
 45### False positive analysis
 46
 47- Legitimate administrative tasks: System administrators may use kubectl with impersonation arguments for legitimate purposes such as testing permissions or managing resources on behalf of other users. To handle this, create exceptions for known administrative accounts or specific IP addresses.
 48- Automation scripts: Automated scripts or CI/CD pipelines might use impersonation arguments to perform tasks across different environments. Review and whitelist these scripts by identifying their unique execution patterns or specific user accounts.
 49- Development and testing environments: Developers might use impersonation features in non-production environments for testing purposes. Exclude these environments by filtering based on environment-specific identifiers or network segments.
 50- Security tools: Some security tools or monitoring solutions may use impersonation arguments to audit or verify access controls. Identify these tools and exclude their processes by recognizing their signatures or execution paths.
 51- Frequent legitimate use cases: If certain teams or departments regularly use impersonation for valid reasons, consider creating role-based exceptions to reduce noise while maintaining security oversight.
 52
 53### Response and remediation
 54
 55- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or privilege escalation.
 56- Revoke any potentially compromised credentials, such as tokens or kubeconfig files, and issue new ones with updated security policies.
 57- Review and audit the Kubernetes RBAC (Role-Based Access Control) settings to ensure that only authorized users have the necessary permissions, and adjust roles and permissions as needed to minimize privilege escalation risks.
 58- Conduct a thorough investigation of the affected systems to identify any unauthorized changes or deployments made by the adversary, and roll back any malicious or suspicious configurations.
 59- Monitor for any further suspicious kubectl activity, especially those involving impersonation arguments, and set up alerts for any similar future attempts.
 60- Escalate the incident to the security operations team for a comprehensive review and to determine if additional security measures or incident response actions are required.
 61- Implement additional logging and monitoring for kubectl commands and Kubernetes API interactions to enhance detection capabilities for similar threats in the future.
 62"""
 63risk_score = 21
 64rule_id = "3c6685eb-9eaa-43a4-be1b-a7f9f1f5e63d"
 65setup = """## Setup
 66
 67This rule requires data coming in from Elastic Defend.
 68
 69### Elastic Defend Integration Setup
 70Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 71
 72#### Prerequisite Requirements:
 73- Fleet is required for Elastic Defend.
 74- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 75
 76#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 77- Go to the Kibana home page and click "Add integrations".
 78- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 79- Click "Add Elastic Defend".
 80- Configure the integration name and optionally add a description.
 81- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 82- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
 83- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 84- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
 85For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 86- Click "Save and Continue".
 87- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
 88For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 89"""
 90severity = "low"
 91tags = [
 92    "Domain: Endpoint",
 93    "Domain: Container",
 94    "Domain: Kubernetes",
 95    "OS: Linux",
 96    "Use Case: Threat Detection",
 97    "Tactic: Defense Evasion",
 98    "Tactic: Discovery",
 99    "Data Source: Elastic Endgame",
100    "Data Source: Elastic Defend",
101    "Data Source: Auditd Manager",
102    "Data Source: SentinelOne",
103    "Resources: Investigation Guide",
104]
105timestamp_override = "event.ingested"
106type = "eql"
107query = '''
108process where host.os.type == "linux" and event.type == "start" and
109event.action in ("exec", "exec_event", "start", "executed", "process_started") and
110process.name == "kubectl" and (
111  process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or
112  (
113    process.parent.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*") or
114    process.parent.name like (".*", "*.sh")
115  )
116) and process.args like~ ("--kubeconfig*", "--token*", "--as*", "--as-group*", "--as-uid*")
117'''
118
119[[rule.threat]]
120framework = "MITRE ATT&CK"
121
122[[rule.threat.technique]]
123id = "T1550"
124name = "Use Alternate Authentication Material"
125reference = "https://attack.mitre.org/techniques/T1550/"
126
127[[rule.threat.technique.subtechnique]]
128id = "T1550.001"
129name = "Application Access Token"
130reference = "https://attack.mitre.org/techniques/T1550/001/"
131
132[[rule.threat.technique]]
133id = "T1078"
134name = "Valid Accounts"
135reference = "https://attack.mitre.org/techniques/T1078/"
136
137[rule.threat.tactic]
138id = "TA0005"
139name = "Defense Evasion"
140reference = "https://attack.mitre.org/tactics/TA0005/"
141
142[[rule.threat]]
143framework = "MITRE ATT&CK"
144
145[[rule.threat.technique]]
146id = "T1552"
147name = "Unsecured Credentials"
148reference = "https://attack.mitre.org/techniques/T1552/"
149
150[[rule.threat.technique]]
151id = "T1528"
152name = "Steal Application Access Token"
153reference = "https://attack.mitre.org/techniques/T1528/"
154
155[rule.threat.tactic]
156id = "TA0006"
157name = "Credential Access"
158reference = "https://attack.mitre.org/tactics/TA0006/"