Decoded Payload Piped to Interpreter Detected via Defend for Containers

This rule detects the execution of a base64 decoded payload to an interpreter inside a container. Attackers may use this technique to execute malicious code, while attempting to evade detection.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/03/05"
  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/03/05"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the execution of a base64 decoded payload to an interpreter inside a container. Attackers
 13may use this technique to execute malicious code, while attempting to evade detection.
 14"""
 15from = "now-6m"
 16index = ["logs-cloud_defend.process*"]
 17interval = "5m"
 18language = "eql"
 19license = "Elastic License v2"
 20name = "Decoded Payload Piped to Interpreter Detected via Defend for Containers"
 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 Decoded Payload Piped to Interpreter Detected via Defend for Containers
 27
 28This detection flags a container process that decodes an obfuscated payload (commonly base64 or similar) and immediately feeds the output into an interpreter, a high-signal pattern for fileless execution and defense evasion. Attackers use it to deliver short-lived scripts without writing them to disk, reducing forensic artifacts and bypassing simple content controls. A common pattern is echoing an encoded blob, decoding it, and piping it into `sh`/`bash` or `python` to run a downloader or backdoor inline.
 29
 30### Possible investigation steps
 31
 32- Correlate the paired exec events to reconstruct the full pipeline and determine whether it originated from an interactive exec session, the container entrypoint, or an orchestrated task.  
 33- Extract the encoded blob from the command invocation or captured stdin, decode it in an isolated environment, and assess the decoded script for downloader/backdoor logic, persistence attempts, or secret access.  
 34- Pivot from the interpreter execution to spawned children and concurrent outbound connections to identify second-stage payload retrieval, command-and-control, or lateral movement activity.  
 35- Validate workload legitimacy by reviewing the container’s image tag/digest and the owning pod/deployment, namespace, and service account, and compare against recent changes or redeploys for compromise indicators.  
 36- Look for post-execution artifacts in writable layers and mounted volumes (new scripts/binaries, modified init files, scheduled tasks), and if suspicious preserve evidence and rotate potentially exposed credentials.
 37
 38### False positive analysis
 39
 40- Containerized init/entrypoint or CI job logic decodes embedded base64 configuration or a small helper script at runtime (e.g., `base64 -d | sh` or `python -c ...b64decode...`) to avoid shipping plaintext in the image and to support templating across environments.  
 41- An operator troubleshooting a container uses an interactive exec session to paste an encoded one-liner that decodes and pipes into a shell or interpreter to quickly run diagnostics or apply a transient fix without creating files in the container filesystem.
 42
 43### Response and remediation
 44
 45- Immediately isolate or stop the affected container/pod and block further `kubectl exec`/interactive sessions into the workload while preserving the full command line, container image digest, and recent stdout/stderr logs for evidence.  
 46- Decode the observed base64/openssl/python/perl/ruby payload in a sandbox to identify its actions, then terminate any spawned interpreter children and remove any dropped binaries/scripts from writable layers and mounted volumes.  
 47- If the decoded script performs outbound retrieval or C2, quarantine the node or restrict egress for the namespace and rotate any secrets, tokens, or cloud credentials accessible to the container’s service account.  
 48- Rebuild and redeploy the workload from a known-good image (pin by digest), revoke the compromised image/tag from the registry, and validate the deployment manifests for unauthorized entrypoint/command changes.  
 49- Escalate to incident response if the payload includes credential access, lateral movement tooling, or creates persistence on the node (e.g., cron/systemd changes, modified kubelet paths), or if multiple containers show similar decode-to-interpreter pipelines.  
 50- Harden by enforcing admission controls to deny privileged containers and runtime `exec`, require read-only root filesystems and least-privilege service accounts, and add detections/blocks for decode-to-interpreter patterns and unexpected interpreters in production images.
 51"""
 52references = [
 53    "https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
 54]
 55risk_score = 73
 56rule_id = "0fb83aa0-3d17-41e9-b09c-56397bf7a7d9"
 57severity = "high"
 58tags = [
 59    "Data Source: Elastic Defend for Containers",
 60    "Domain: Container",
 61    "OS: Linux",
 62    "Use Case: Threat Detection",
 63    "Tactic: Defense Evasion",
 64    "Tactic: Execution",
 65    "Resources: Investigation Guide",
 66]
 67timestamp_override = "event.ingested"
 68type = "eql"
 69query = '''
 70sequence by process.parent.entity_id, container.id with maxspan=3s
 71  [process where event.type == "start" and event.action == "exec" and container.id like "?*" and (
 72    (
 73      (
 74        process.name in ("base64", "basez", "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16") or
 75        (
 76          process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
 77          process.args in ("base64", "basez", "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16")
 78        )
 79      ) and
 80      process.args like~ "*-*d*"
 81    ) or
 82    (
 83      process.name == "openssl" and
 84      process.args == "enc" and process.args in ("-d", "-base64", "-a", "-A")
 85    ) or
 86    (
 87      process.name like "python*" and (
 88        (process.args == "base64" and process.args in ("-d", "-u", "-t")) or
 89        (process.args == "-c" and process.args like "*base64*" and process.args like~ "*b64decode*")
 90      )
 91    ) or
 92    (
 93      process.name like "perl*" and
 94      process.args like~ "*decode_base64*"
 95    ) or
 96    (
 97      process.name like "ruby*" and
 98      process.args == "-e" and
 99      process.args like~ "*Base64.decode64*"
100    )
101  )]
102  [process where event.type == "start" and event.action == "exec" and process.name like (
103    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox",
104    "python*", "perl*", "ruby*", "lua*", "php*"
105  ) and
106  process.args like (
107    "-bash", "-dash", "-sh", "-tcsh", "-csh", "-zsh", "-ksh", "-fish", "-busybox",
108    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox",
109    "/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh", "/bin/csh",
110    "/bin/zsh", "/bin/ksh", "/bin/fish", "/bin/busybox",
111    "/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh",
112    "/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish",
113    "/usr/bin/busybox",
114    "*python*", "*perl*", "*ruby*", "*lua*", "*php*", "/dev/fd/*"
115  ) and
116  not (
117    process.working_directory like (
118      "/usr/local/zeek", "/opt/zeek", "/var/lib/docker/overlay2/*/opt/zeek", "/usr/local/zeek_old_install",
119      "/var/lib/docker/overlay2/*/usr/local/zeek", "/proc/self/fd/*/usr/local/zeek"
120    ) or
121    process.args in (
122      "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
123      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
124      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
125      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
126    )
127  )]
128'''
129
130[[rule.threat]]
131framework = "MITRE ATT&CK"
132
133  [rule.threat.tactic]
134  name = "Defense Evasion"
135  id = "TA0005"
136  reference = "https://attack.mitre.org/tactics/TA0005/"
137
138    [[rule.threat.technique]]
139    name = "Obfuscated Files or Information"
140    id = "T1027"
141    reference = "https://attack.mitre.org/techniques/T1027/"
142
143    [[rule.threat.technique]]
144    name = "Deobfuscate/Decode Files or Information"
145    id = "T1140"
146    reference = "https://attack.mitre.org/techniques/T1140/"
147
148[[rule.threat]]
149framework = "MITRE ATT&CK"
150
151  [rule.threat.tactic]
152  name = "Execution"
153  id = "TA0002"
154  reference = "https://attack.mitre.org/tactics/TA0002/"
155
156    [[rule.threat.technique]]
157    id = "T1059"
158    name = "Command and Scripting Interpreter"
159    reference = "https://attack.mitre.org/techniques/T1059/"
160
161      [[rule.threat.technique.subtechnique]]
162      name = "Unix Shell"
163      id = "T1059.004"
164      reference = "https://attack.mitre.org/techniques/T1059/004/"
165
166    [[rule.threat.technique]]
167    name = "User Execution"
168    id = "T1204"
169    reference = "https://attack.mitre.org/techniques/T1204/"
170
171      [[rule.threat.technique.subtechnique]]
172      name = "Malicious File"
173      id = "T1204.002"
174      reference = "https://attack.mitre.org/techniques/T1204/002/"

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 Decoded Payload Piped to Interpreter Detected via Defend for Containers

This detection flags a container process that decodes an obfuscated payload (commonly base64 or similar) and immediately feeds the output into an interpreter, a high-signal pattern for fileless execution and defense evasion. Attackers use it to deliver short-lived scripts without writing them to disk, reducing forensic artifacts and bypassing simple content controls. A common pattern is echoing an encoded blob, decoding it, and piping it into sh/bash or python to run a downloader or backdoor inline.

Possible investigation steps

  • Correlate the paired exec events to reconstruct the full pipeline and determine whether it originated from an interactive exec session, the container entrypoint, or an orchestrated task.
  • Extract the encoded blob from the command invocation or captured stdin, decode it in an isolated environment, and assess the decoded script for downloader/backdoor logic, persistence attempts, or secret access.
  • Pivot from the interpreter execution to spawned children and concurrent outbound connections to identify second-stage payload retrieval, command-and-control, or lateral movement activity.
  • Validate workload legitimacy by reviewing the container’s image tag/digest and the owning pod/deployment, namespace, and service account, and compare against recent changes or redeploys for compromise indicators.
  • Look for post-execution artifacts in writable layers and mounted volumes (new scripts/binaries, modified init files, scheduled tasks), and if suspicious preserve evidence and rotate potentially exposed credentials.

False positive analysis

  • Containerized init/entrypoint or CI job logic decodes embedded base64 configuration or a small helper script at runtime (e.g., base64 -d | sh or python -c ...b64decode...) to avoid shipping plaintext in the image and to support templating across environments.
  • An operator troubleshooting a container uses an interactive exec session to paste an encoded one-liner that decodes and pipes into a shell or interpreter to quickly run diagnostics or apply a transient fix without creating files in the container filesystem.

Response and remediation

  • Immediately isolate or stop the affected container/pod and block further kubectl exec/interactive sessions into the workload while preserving the full command line, container image digest, and recent stdout/stderr logs for evidence.
  • Decode the observed base64/openssl/python/perl/ruby payload in a sandbox to identify its actions, then terminate any spawned interpreter children and remove any dropped binaries/scripts from writable layers and mounted volumes.
  • If the decoded script performs outbound retrieval or C2, quarantine the node or restrict egress for the namespace and rotate any secrets, tokens, or cloud credentials accessible to the container’s service account.
  • Rebuild and redeploy the workload from a known-good image (pin by digest), revoke the compromised image/tag from the registry, and validate the deployment manifests for unauthorized entrypoint/command changes.
  • Escalate to incident response if the payload includes credential access, lateral movement tooling, or creates persistence on the node (e.g., cron/systemd changes, modified kubelet paths), or if multiple containers show similar decode-to-interpreter pipelines.
  • Harden by enforcing admission controls to deny privileged containers and runtime exec, require read-only root filesystems and least-privilege service accounts, and add detections/blocks for decode-to-interpreter patterns and unexpected interpreters in production images.

References

Related rules

to-top