Environment Variable Enumeration Detected via Defend for Containers

This rule detects the execution of the "env" or "printenv" commands inside a container. The "env" command is used to display all the environment variables for the current shell, and the "printenv" command is used to print the values of environment variables. These commands are used to enumerate the environment variables of the container, which can be used by an adversary to gain information about the container and the services running inside it.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/01/21"
  3integration = ["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/01/27"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the execution of the "env" or "printenv" commands inside a container. The "env" command is used
 13to display all the environment variables for the current shell, and the "printenv" command is used to print the
 14values of environment variables. These commands are used to enumerate the environment variables of the container,
 15which can be used by an adversary to gain information about the container and the services running inside it.
 16"""
 17false_positives = [
 18    """
 19    There is a potential for false positives if the "env" or "printenv" commands are used for legitimate purposes,
 20    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
 21    if they are indicative of malicious activity or part of legitimate container activity.
 22    """,
 23]
 24from = "now-6m"
 25index = ["logs-cloud_defend.process*"]
 26interval = "5m"
 27language = "eql"
 28license = "Elastic License v2"
 29name = "Environment Variable Enumeration Detected via Defend for Containers"
 30note = """ ## Triage and analysis
 31
 32> **Disclaimer**:
 33> 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.
 34
 35### Investigating Environment Variable Enumeration Detected via Defend for Containers
 36
 37This rule flags interactive execution of env or printenv inside a Linux container, a common discovery step to expose environment variables that frequently store credentials, tokens, and service configuration. A typical pattern: after gaining shell access to a pod, the attacker lists variables to harvest cloud keys, Kubernetes service account tokens, database URLs, and internal endpoints, enabling authenticated API calls, lateral movement within the cluster, or exfiltration via trusted services.
 38
 39### Possible investigation steps
 40
 41- Correlate with Kubernetes audit logs (exec/attach or debug) to identify the initiator identity, source IP, and command, and confirm whether the session was expected.
 42- Review the pod/container context (namespace, deployment, image digest/tag, node, and service account) and compare against baselines to catch unusual targets or ephemeral/privileged debug containers.
 43- Retrieve the enumerated variables to spot high-risk secrets such as cloud credentials, database passwords, or tokens, and immediately rotate/disable any discovered keys while reviewing provider audit logs for post-alert use.
 44- Trace subsequent activity within the container after the event for credential usage or exfiltration, including access to 169.254.169.254/metadata, calls to Kubernetes/cloud APIs, outbound network connections, or tooling like curl, wget, base64, and grep.
 45- Pivot to related signals on the same pod or node around the timestamp (new shells, service account token file reads, package installs, or suspicious downloads) to determine if this is part of a broader compromise.
 46
 47### False positive analysis
 48
 49- An operator opens an interactive shell in a container during routine troubleshooting and runs env or printenv to verify configuration, service endpoints, feature flags, or propagated secrets.
 50- Interactive shell initialization or entrypoint scripts in certain base images automatically invoke env or printenv upon TTY login to display or log variables, producing this event in benign sessions.
 51
 52### Response and remediation
 53
 54- Quarantine the affected pod where env/printenv was run by deleting the pod to drop the interactive session, applying a deny-all egress NetworkPolicy targeting its labels, and temporarily blocking kubectl exec/attach to that workload.
 55- Immediately rotate any secrets exposed in that container’s environment (cloud access keys, database passwords, API tokens, Kubernetes service account token), revoke active sessions at providers, and invalidate cached credentials on dependent services.
 56- Redeploy the application from a verified image digest with a fresh service account and newly issued secrets, and remove debug images or shell entrypoints that enabled interactive access.
 57- Escalate to incident response if env output contained credentials or the pod’s IP contacted 169.254.169.254, cloud/Kubernetes APIs, or external endpoints after the enumeration, indicating possible secret use or exfiltration.
 58- Replace environment-based secret injection with a secrets manager or projected volumes, set automountServiceAccountToken to false where not required, right-size RBAC for the workload, and block egress to the metadata service and the internet.
 59- Enforce preventive controls by disabling kubectl exec/attach for production (break-glass only with approval), enabling admission policies to block images with shells or package managers, and adding runtime rules to alert on interactive env/printenv followed by curl/wget/base64 or token file reads.
 60"""
 61risk_score = 21
 62rule_id = "f66a6869-d4c7-4d20-ab13-beefd03b63b4"
 63severity = "low"
 64tags = [
 65    "Data Source: Elastic Defend for Containers",
 66    "Domain: Container",
 67    "OS: Linux",
 68    "Use Case: Threat Detection",
 69    "Tactic: Discovery",
 70    "Resources: Investigation Guide",
 71]
 72timestamp_override = "event.ingested"
 73type = "eql"
 74query = '''
 75process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
 76  process.name in ("env", "printenv") or
 77  (
 78    /* Account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
 79    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
 80    process.args in (
 81      "env", "/bin/env", "/usr/bin/env", "/usr/local/bin/env",
 82      "printenv", "/bin/printenv", "/usr/bin/printenv", "/usr/local/bin/printenv"
 83    ) and
 84    /* default exclusion list to not FP on default multi-process commands */
 85    not process.args in (
 86      "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
 87      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
 88      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
 89      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
 90    )
 91  )
 92) and
 93process.interactive == true and container.id like "*"
 94'''
 95
 96[[rule.threat]]
 97framework = "MITRE ATT&CK"
 98
 99[[rule.threat.technique]]
100id = "T1613"
101name = "Container and Resource Discovery"
102reference = "https://attack.mitre.org/techniques/T1613/"
103
104[[rule.threat.technique]]
105id = "T1082"
106name = "System Information Discovery"
107reference = "https://attack.mitre.org/techniques/T1082/"
108
109[rule.threat.tactic]
110id = "TA0007"
111name = "Discovery"
112reference = "https://attack.mitre.org/tactics/TA0007/"

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 Environment Variable Enumeration Detected via Defend for Containers

This rule flags interactive execution of env or printenv inside a Linux container, a common discovery step to expose environment variables that frequently store credentials, tokens, and service configuration. A typical pattern: after gaining shell access to a pod, the attacker lists variables to harvest cloud keys, Kubernetes service account tokens, database URLs, and internal endpoints, enabling authenticated API calls, lateral movement within the cluster, or exfiltration via trusted services.

Possible investigation steps

  • Correlate with Kubernetes audit logs (exec/attach or debug) to identify the initiator identity, source IP, and command, and confirm whether the session was expected.
  • Review the pod/container context (namespace, deployment, image digest/tag, node, and service account) and compare against baselines to catch unusual targets or ephemeral/privileged debug containers.
  • Retrieve the enumerated variables to spot high-risk secrets such as cloud credentials, database passwords, or tokens, and immediately rotate/disable any discovered keys while reviewing provider audit logs for post-alert use.
  • Trace subsequent activity within the container after the event for credential usage or exfiltration, including access to 169.254.169.254/metadata, calls to Kubernetes/cloud APIs, outbound network connections, or tooling like curl, wget, base64, and grep.
  • Pivot to related signals on the same pod or node around the timestamp (new shells, service account token file reads, package installs, or suspicious downloads) to determine if this is part of a broader compromise.

False positive analysis

  • An operator opens an interactive shell in a container during routine troubleshooting and runs env or printenv to verify configuration, service endpoints, feature flags, or propagated secrets.
  • Interactive shell initialization or entrypoint scripts in certain base images automatically invoke env or printenv upon TTY login to display or log variables, producing this event in benign sessions.

Response and remediation

  • Quarantine the affected pod where env/printenv was run by deleting the pod to drop the interactive session, applying a deny-all egress NetworkPolicy targeting its labels, and temporarily blocking kubectl exec/attach to that workload.
  • Immediately rotate any secrets exposed in that container’s environment (cloud access keys, database passwords, API tokens, Kubernetes service account token), revoke active sessions at providers, and invalidate cached credentials on dependent services.
  • Redeploy the application from a verified image digest with a fresh service account and newly issued secrets, and remove debug images or shell entrypoints that enabled interactive access.
  • Escalate to incident response if env output contained credentials or the pod’s IP contacted 169.254.169.254, cloud/Kubernetes APIs, or external endpoints after the enumeration, indicating possible secret use or exfiltration.
  • Replace environment-based secret injection with a secrets manager or projected volumes, set automountServiceAccountToken to false where not required, right-size RBAC for the workload, and block egress to the metadata service and the internet.
  • Enforce preventive controls by disabling kubectl exec/attach for production (break-glass only with approval), enabling admission policies to block images with shells or package managers, and adding runtime rules to alert on interactive env/printenv followed by curl/wget/base64 or token file reads.

Related rules

to-top