Kubectl Secrets Enumeration Across All Namespaces

This rule detects the use of the "kubectl get secrets --all-namespaces" command, which enumerates secret resources across the entire Kubernetes cluster. Attackers may use this command to identify accessible secrets in multiple namespaces, aiding credential discovery, privilege escalation, or lateral movement.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/03/26"
  3integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel", "cloud_defend"]
  4maturity = "production"
  5min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
  6min_stack_version = "9.3.0"
  7updated_date = "2026/03/26"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the use of the "kubectl get secrets --all-namespaces" command, which enumerates secret resources
 13across the entire Kubernetes cluster. Attackers may use this command to identify accessible secrets in multiple
 14namespaces, aiding credential discovery, privilege escalation, or lateral movement.
 15"""
 16from = "now-9m"
 17index = [
 18    "auditbeat-*",
 19    "endgame-*",
 20    "logs-auditd_manager.auditd-*",
 21    "logs-crowdstrike.fdr*",
 22    "logs-endpoint.events.process*",
 23    "logs-sentinel_one_cloud_funnel.*",
 24    "logs-cloud_defend.process*",
 25]
 26language = "eql"
 27license = "Elastic License v2"
 28name = "Kubectl Secrets Enumeration Across All Namespaces"
 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 Kubectl Secrets Enumeration Across All Namespaces
 35
 36Kubectl allows users to query Kubernetes resources from the command line. Adversaries may use "kubectl get secrets --all-namespaces" or "kubectl get secrets -A" to enumerate secret objects across the cluster and identify valuable targets for credential access or privilege escalation. The detection rule identifies this broad secret discovery activity by monitoring kubectl executions that request secrets from all namespaces.
 37
 38### Possible investigation steps
 39
 40- Review the full process command line to confirm whether the command used "get secrets --all-namespaces" or the short form "-A", and determine whether additional output modifiers such as "-o yaml" or "-o json" were used.
 41- Identify the user account and host that launched the kubectl command and determine whether this activity aligns with approved administrative or automation workflows.
 42- Correlate the event with Kubernetes audit logs to determine what secret resources were listed and whether subsequent access, read, or modification activity followed.
 43- Examine related kubectl activity from the same user or host, especially commands involving "auth can-i", "--as", "--token", or kubeconfig changes, which may indicate privilege probing or impersonation.
 44- Investigate whether the same session later accessed sensitive resources, exported command output, or connected to external destinations that could indicate staging or exfiltration of discovered information.
 45
 46### False positive analysis
 47
 48- Cluster administrators or platform engineers may legitimately enumerate secrets across namespaces during troubleshooting, audits, or migration work. Create exceptions for known users, hosts, or automation contexts where appropriate.
 49- CI/CD or compliance tooling may run kubectl commands with "-A" to inventory cluster resources. Review these tools and exclude their specific execution patterns if they are expected.
 50- Security assessment or validation activity may intentionally enumerate secrets to verify access controls. Coordinate with security teams to document those activities and reduce unnecessary alerts.
 51- Development or lab environments may generate this behavior during testing. Consider environment-specific tuning if this activity is expected outside production.
 52
 53### Response and remediation
 54
 55- Validate whether the user or service account that executed the command should have cluster-wide visibility into secrets, and revoke or reduce permissions if the access is not justified.
 56- Review Kubernetes audit logs and API activity to determine whether any listed secrets were subsequently read, exported, or abused.
 57- Rotate any credentials, tokens, or certificates associated with sensitive secrets that may have been exposed to an unauthorized actor.
 58- Investigate adjacent activity from the same host or identity, including kubeconfig access, impersonation flags, direct API usage, or suspicious network connections.
 59- Escalate to incident response if the activity is unauthorized, originated from an unusual workstation, or was followed by secret reads, pod creation, or changes to RBAC bindings.
 60"""
 61references = [
 62    "https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get",
 63]
 64risk_score = 47
 65rule_id = "a87d49f0-24ae-4d6e-a0b4-5fd2f6188d6a"
 66setup = """## Setup
 67
 68This rule requires data coming in from Elastic Defend.
 69
 70### Elastic Defend Integration Setup
 71Elastic 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.
 72
 73#### Prerequisite Requirements:
 74- Fleet is required for Elastic Defend.
 75- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 76
 77#### The following steps should be executed in order to add the Elastic Defend integration on a Linux or macOS system:
 78- Go to the Kibana home page and click "Add integrations".
 79- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 80- Click "Add Elastic Defend".
 81- Configure the integration name and optionally add a description.
 82- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 83- 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).
 84- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 85- 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.
 86For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 87- Click "Save and Continue".
 88- 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.
 89For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 90"""
 91severity = "medium"
 92tags = [
 93  "Domain: Endpoint",
 94  "Domain: Container",
 95  "Domain: Kubernetes",
 96  "OS: Linux",
 97  "OS: macOS",
 98  "Use Case: Threat Detection",
 99  "Tactic: Discovery",
100  "Tactic: Credential Access",
101  "Data Source: Elastic Defend",
102  "Data Source: Elastic Endgame",
103  "Data Source: Auditd Manager",
104  "Data Source: Crowdstrike",
105  "Data Source: SentinelOne",
106  "Data Source: Elastic Defend for Containers",
107  "Resources: Investigation Guide",
108]
109timestamp_override = "event.ingested"
110type = "eql"
111query = '''
112process where host.os.type in ("linux", "macos") and event.type == "start" and
113event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
114process.name == "kubectl" and process.args in ("get", "describe") and process.args in ("secret", "secrets") and
115process.args in ("--all-namespaces", "-A")
116'''
117
118[[rule.threat]]
119framework = "MITRE ATT&CK"
120
121[[rule.threat.technique]]
122id = "T1613"
123name = "Container and Resource Discovery"
124reference = "https://attack.mitre.org/techniques/T1613/"
125
126[rule.threat.tactic]
127id = "TA0007"
128name = "Discovery"
129reference = "https://attack.mitre.org/tactics/TA0007/"
130
131[[rule.threat]]
132framework = "MITRE ATT&CK"
133
134[[rule.threat.technique]]
135id = "T1552"
136name = "Unsecured Credentials"
137reference = "https://attack.mitre.org/techniques/T1552/"
138
139[rule.threat.tactic]
140id = "TA0006"
141name = "Credential Access"
142reference = "https://attack.mitre.org/tactics/TA0006/"

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 Kubectl Secrets Enumeration Across All Namespaces

Kubectl allows users to query Kubernetes resources from the command line. Adversaries may use "kubectl get secrets --all-namespaces" or "kubectl get secrets -A" to enumerate secret objects across the cluster and identify valuable targets for credential access or privilege escalation. The detection rule identifies this broad secret discovery activity by monitoring kubectl executions that request secrets from all namespaces.

Possible investigation steps

  • Review the full process command line to confirm whether the command used "get secrets --all-namespaces" or the short form "-A", and determine whether additional output modifiers such as "-o yaml" or "-o json" were used.
  • Identify the user account and host that launched the kubectl command and determine whether this activity aligns with approved administrative or automation workflows.
  • Correlate the event with Kubernetes audit logs to determine what secret resources were listed and whether subsequent access, read, or modification activity followed.
  • Examine related kubectl activity from the same user or host, especially commands involving "auth can-i", "--as", "--token", or kubeconfig changes, which may indicate privilege probing or impersonation.
  • Investigate whether the same session later accessed sensitive resources, exported command output, or connected to external destinations that could indicate staging or exfiltration of discovered information.

False positive analysis

  • Cluster administrators or platform engineers may legitimately enumerate secrets across namespaces during troubleshooting, audits, or migration work. Create exceptions for known users, hosts, or automation contexts where appropriate.
  • CI/CD or compliance tooling may run kubectl commands with "-A" to inventory cluster resources. Review these tools and exclude their specific execution patterns if they are expected.
  • Security assessment or validation activity may intentionally enumerate secrets to verify access controls. Coordinate with security teams to document those activities and reduce unnecessary alerts.
  • Development or lab environments may generate this behavior during testing. Consider environment-specific tuning if this activity is expected outside production.

Response and remediation

  • Validate whether the user or service account that executed the command should have cluster-wide visibility into secrets, and revoke or reduce permissions if the access is not justified.
  • Review Kubernetes audit logs and API activity to determine whether any listed secrets were subsequently read, exported, or abused.
  • Rotate any credentials, tokens, or certificates associated with sensitive secrets that may have been exposed to an unauthorized actor.
  • Investigate adjacent activity from the same host or identity, including kubeconfig access, impersonation flags, direct API usage, or suspicious network connections.
  • Escalate to incident response if the activity is unauthorized, originated from an unusual workstation, or was followed by secret reads, pod creation, or changes to RBAC bindings.

References

Related rules

to-top