Potential Kubeletctl Execution

ELASTIC detection rule by Elastic · Elastic License v2

Detects the execution of kubeletctl on Linux hosts. Kubeletctl is a command-line tool that can be used to interact with the Kubelet API directly, simplifying access to Kubelet endpoints that can be used for discovery and, in some cases, lateral movement within Kubernetes environments.

[metadata]
creation_date = "2026/04/28"
integration = ["endpoint", "auditd_manager"]
maturity = "production"
updated_date = "2026/04/28"

[rule]
author = ["Elastic"]
description = """
Detects the execution of kubeletctl on Linux hosts. Kubeletctl is a command-line tool that can be used to interact with
the Kubelet API directly, simplifying access to Kubelet endpoints that can be used for discovery and, in some cases,
lateral movement within Kubernetes environments.
"""
false_positives = [
    """
    Administrators or developers may execute kubeletctl during legitimate troubleshooting or incident response to validate
    Kubelet API connectivity or enumerate pods. Confirm the user/session and change window before escalating.
    """,
]
from = "now-9m"
index = ["auditbeat-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Kubeletctl Execution"
note = """## 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 Potential Kubeletctl Execution

This alert flags kubeletctl execution on a Linux host. Kubeletctl provides direct access to the node’s Kubelet API and can
be used to enumerate pods and nodes and attempt actions such as exec/attach/portForward. A common attacker pattern is
running `kubeletctl scan` to find reachable Kubelet endpoints, then using `pods` or `exec/attach` for follow-on access.

### Possible investigation steps

- Review the full command line to identify the intended operation (scan/pods/exec/attach/portForward) and the target
  Kubelet endpoint (node IP/hostname and port via `-s`/`--server`).
- Correlate with host and container telemetry for connections to Kubelet ports (commonly 10250/10255) and look for
  scanning patterns across multiple nodes.
- Check whether Kubernetes credentials were accessed or used (service account tokens, kubeconfigs, client certs) and
  correlate with Kubernetes audit logs for follow-on actions.

### False positive analysis

- Approved operational debugging or incident response activity that uses kubeletctl for diagnostics.

### Response and remediation

- Restrict access to Kubelet ports at the network layer and harden Kubelet authentication/authorization.
- Rotate/revoke any exposed Kubernetes credentials and investigate for follow-on discovery or execution attempts.
"""
references = [
    "https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster",
    "https://github.com/cyberark/kubeletctl",
]
risk_score = 47
rule_id = "f7a131f8-44b7-4957-99a4-e6c54d93d816"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "Domain: Container",
    "Domain: Kubernetes",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Discovery",
    "Data Source: Elastic Defend",
    "Data Source: Auditd Manager",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "executed") and 
(
  process.name == "kubeletctl" or
  (process.args in ("run", "exec", "scan", "pods", "runningpods", "attach", "portForward", "cri", "pid2pod") and process.args:("*:10250*", "*:10255*"))
)
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1613"
name = "Container and Resource Discovery"
reference = "https://attack.mitre.org/techniques/T1613/"

[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

[[rule.threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"

[[rule.threat.technique]]
id = "T1609"
name = "Container Administration Command"
reference = "https://attack.mitre.org/techniques/T1609/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

06b2d7d6-6cfb-49c7-b6f0-3eb81c6135fd

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion