Kubectl Permission Discovery

  1[metadata]
  2creation_date = "2025/06/17"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/07/07"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects the use of the "kubectl auth --can-i" command, which is used to check permissions in Kubernetes clusters.
 11Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing
 12them to gain unauthorized access or escalate privileges.
 13"""
 14from = "now-9m"
 15index = [
 16    "logs-endpoint.events.process*",
 17]
 18language = "eql"
 19license = "Elastic License v2"
 20name = "Kubectl Permission Discovery"
 21note = """ ## Triage and analysis
 22
 23> **Disclaimer**:
 24> 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.
 25
 26### Investigating Kubectl Permission Discovery
 27
 28Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit the "kubectl auth can-i" command to probe for permission misconfigurations, potentially leading to unauthorized access or privilege escalation. The detection rule identifies this activity by monitoring specific command executions on Linux systems, flagging potential misuse for further investigation.
 29
 30### Possible investigation steps
 31
 32- Review the process execution details to confirm the use of the "kubectl auth can-i" command, focusing on the process name "kubectl" and arguments "auth" and "can-i".
 33- Identify the user account associated with the execution of the command to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access.
 34- Check the timing and frequency of the command execution to assess whether it corresponds with routine operations or suggests suspicious behavior.
 35- Investigate the source IP address or hostname from which the command was executed to verify if it originates from a known and trusted environment.
 36- Examine related logs and events around the time of the alert to identify any subsequent actions that might indicate privilege escalation or unauthorized access attempts.
 37- Cross-reference the alert with any recent changes or incidents in the Kubernetes cluster to determine if the command execution is part of a broader security concern.
 38
 39### False positive analysis
 40
 41- Routine administrative checks by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or roles that regularly perform these checks as part of their job duties.
 42- Automated scripts or monitoring tools that verify permissions as part of their normal operation may cause false positives. Identify these scripts and whitelist their execution paths or associated service accounts.
 43- Development and testing environments where developers frequently check permissions might lead to alerts. Consider excluding these environments from the rule or adjusting the risk score for these specific contexts.
 44- Scheduled audits or compliance checks that involve permission verification can be mistaken for malicious activity. Document these activities and set up time-based exceptions to prevent unnecessary alerts during known audit periods.
 45
 46### Response and remediation
 47
 48- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or privilege escalation.
 49- Revoke any suspicious or unauthorized credentials or tokens identified during the investigation to prevent further misuse.
 50- Conduct a thorough review of the Kubernetes Role-Based Access Control (RBAC) configurations to identify and rectify any permission misconfigurations.
 51- Implement stricter access controls and least privilege principles for Kubernetes users and service accounts to minimize the risk of unauthorized access.
 52- Monitor for any additional suspicious activity or anomalies in the cluster, focusing on access patterns and command executions.
 53- Escalate the incident to the security operations team for further analysis and to determine if additional clusters or systems are affected.
 54- Update detection and monitoring systems to enhance visibility and alerting for similar permission discovery attempts in the future.
 55"""
 56references = [
 57    "https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/",
 58    ]
 59risk_score = 21
 60rule_id = "1600f9e2-5be6-4742-8593-1ba50cd94069"
 61setup = """## Setup
 62
 63This rule requires data coming in from Elastic Defend.
 64
 65### Elastic Defend Integration Setup
 66Elastic 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.
 67
 68#### Prerequisite Requirements:
 69- Fleet is required for Elastic Defend.
 70- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 71
 72#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 73- Go to the Kibana home page and click "Add integrations".
 74- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 75- Click "Add Elastic Defend".
 76- Configure the integration name and optionally add a description.
 77- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 78- 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).
 79- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 80- 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.
 81For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 82- Click "Save and Continue".
 83- 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.
 84For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 85"""
 86severity = "low"
 87tags = [
 88    "Domain: Endpoint",
 89    "Domain: Container",
 90    "Domain: Kubernetes",
 91    "OS: Linux",
 92    "Use Case: Threat Detection",
 93    "Tactic: Discovery",
 94    "Data Source: Elastic Defend",
 95    "Resources: Investigation Guide",
 96]
 97timestamp_override = "event.ingested"
 98type = "eql"
 99query = '''
100process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
101process.name == "kubectl" and process.args == "auth" and process.args == "can-i"
102'''
103
104[[rule.threat]]
105framework = "MITRE ATT&CK"
106
107[[rule.threat.technique]]
108id = "T1613"
109name = "Container and Resource Discovery"
110reference = "https://attack.mitre.org/techniques/T1613/"
111
112[rule.threat.tactic]
113id = "TA0007"
114name = "Discovery"
115reference = "https://attack.mitre.org/tactics/TA0007/"