Suspicious Interpreter Execution Detected via Defend for Containers

This rule detects when an interactive process executes a suspicious interpreter command inside a container. These commands are commonly used by attackers to execute malicious code or exfiltrate data.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/02/06"
  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/02/06"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects when an interactive process executes a suspicious interpreter command inside a container.
 13These commands are commonly used by attackers to execute malicious code or exfiltrate data.
 14"""
 15from = "now-6m"
 16index = ["logs-cloud_defend.process*"]
 17interval = "5m"
 18language = "eql"
 19license = "Elastic License v2"
 20name = "Suspicious Interpreter Execution 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 Suspicious Interpreter Execution Detected via Defend for Containers
 27
 28This detection flags an interactive session inside a Linux container launching Perl, PHP, Lua, Python, or Ruby with inline code execution and high-risk functions commonly used for spawning processes, decoding payloads, or opening network connections. It matters because attackers often abuse these one-liners to run malware or exfiltrate data without dropping files, blending into normal admin shell activity. A common pattern is a `python -c` one-liner that base64-decodes a second-stage script and executes it, then initiates an outbound socket for command-and-control.
 29
 30### Possible investigation steps
 31
 32- Review the full inline interpreter code and decode any embedded payloads (e.g., base64/zlib/rot13) to determine its intent, IOCs, and whether it fetches or launches a second stage.  
 33- Identify the originating interactive session and actor by correlating the container’s TTY/exec session metadata with orchestrator audit logs (e.g., Kubernetes exec/attach) to determine who/what initiated it and from where.  
 34- Assess whether the container image, entrypoint, and recent deployment changes are expected for this workload, and check for signs of container escape attempts or host access (mounted sockets, privileged flags, hostPath mounts).  
 35- Pivot from the alert time to related activity in the same container for child processes, file writes, cron/systemd modifications, and persistence artifacts that indicate follow-on actions beyond a one-liner.  
 36- Check for unexpected outbound connections or DNS lookups from the container around execution time, and validate any contacted domains/IPs against threat intel and known-good service dependencies.
 37
 38### False positive analysis
 39
 40- A developer or SRE opens an interactive shell in the container to troubleshoot and runs a quick inline one-liner (e.g., `python -c`/`php -r`/`ruby -e`) to test network connectivity, decode/transform a string (base64/zlib), or call a subprocess for diagnostics, which matches the suspicious function patterns.  
 41- During an interactive container exec session, an administrator performs emergency maintenance or incident response actions using an interpreter one-liner to fetch configuration/state, invoke system utilities, or validate service behavior (e.g., `socket.connect`, `os.system`, `curl_exec`, `IO.popen`), producing a benign but high-risk inline command signature.
 42
 43### Response and remediation
 44
 45- Quarantine the affected workload by scaling it to zero or cordoning the node and blocking egress for the namespace while preserving the pod and container filesystem for evidence capture.  
 46- Terminate the interactive session and kill the interpreter process tree, then collect the full command line, any decoded inline payload, and any retrieved scripts or binaries from the container for malware analysis.  
 47- Hunt and remove follow-on artifacts by searching the container for newly created executables, modified startup scripts, cron entries, webshells, or injected environment variables, and redeploy from a known-good image rather than “cleaning” the live container.  
 48- Rotate credentials and secrets exposed to the container (service account tokens, API keys, database passwords) and invalidate active sessions if the one-liner performed network calls, decoded payloads, or spawned subprocesses.  
 49- Escalate to the incident response team if the inline code includes base64/zlib decoding, establishes a socket connection, downloads a second stage, or any similar activity is observed across multiple pods/namespaces.  
 50- Harden against recurrence by restricting `exec/attach` access, enforcing least-privilege pod security (no privileged, no host mounts, read-only root filesystem), and using egress allowlists plus image signing/admission controls to block unauthorized images and interactive debug containers."""
 51risk_score = 47
 52rule_id = "cd24c340-b778-44bd-ab69-2f739bd70ce1"
 53severity = "medium"
 54tags = [
 55    "Data Source: Elastic Defend for Containers",
 56    "Domain: Container",
 57    "OS: Linux",
 58    "Use Case: Threat Detection",
 59    "Tactic: Execution",
 60    "Tactic: Command and Control",
 61    "Resources: Investigation Guide",
 62]
 63timestamp_override = "event.ingested"
 64type = "eql"
 65query = '''
 66process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.interactive == true and
 67process.parent.executable != null and (
 68  (
 69    process.executable like ("/bin/perl*", "/usr/bin/perl*", "/usr/local/bin/perl*") and
 70    process.args == "-e" and process.args like~ (
 71      "*system(*", "*exec(*", "*IO.popen(*", "*Open3.popen3(*", "*spawn(*", "*eval(*",
 72      "*load(*IO::*", "*load(*Marshal*", "*load(*Fiddle*", "*load(*Zlib*", "*load(*Base64*",
 73      "*zlib.inflate(*", "*zlib.deflate(*", "*zlib.decompress(*", "*zlib.uncompress(*", "*zlib.compress(*",
 74      "*Marshal.load(*", "*Fiddle.dlopen(*", "*Fiddle::Function.new(*", "*base64*", "*zlib*", 
 75      "*net/http*", "*socket.new*", "*open-uri*", "*pack(*"
 76    )
 77  ) or
 78  process.executable like ("/bin/php*", "/usr/bin/php*", "/usr/local/bin/php*") and
 79  process.args == "-r" and process.args like~ (
 80    "*exec(*", "*system(*", "*shell_exec(*", "*passthru(*", "*proc_open(*", "*pcntl_exec(*", "*popen(*", 
 81    "*eval(*", "*assert(*", "*create_function(*", "*preg_replace(*e*", "*include(*", "*require(*",
 82    "*base64_decode(*", "*gzinflate(*", "*gzuncompress(*", "*str_rot13(*", "*urldecode(*", "*chr(*", 
 83    "*ord(*", "*strrev(*", "*strtr(*", "*pack(*", "*unpack(*", "*curl_exec(*", "*curl_multi_exec(*",
 84    "*file_get_contents(*", "*fopen(*", "*fsockopen(*", "*pfsockopen(*", "*stream_socket_client(*",
 85    "*socket_create(*", "*socket_connect(*", "*socket_write(*", "*socket_read(*", "*mail(*",
 86    "*move_uploaded_file(*"
 87  ) or
 88  process.executable like ("/bin/lua*", "/usr/bin/lua*", "/usr/local/bin/lua*") and
 89  process.args == "-e" and process.args like~ (
 90    "*os.execute(*", "*io.popen(*", "*load(*", "*loadstring(*", "*require(*", "*dofile(*",
 91    "*package.loadlib(*", "*base64.decode(*", "*base64.encode(*", "*zlib.inflate(*",
 92    "*zlib.deflate(*", "*zlib.decompress(*", "*zlib.compress(*", "*socket.bind(*",
 93    "*socket.connect(*", "*socket.receive(*", "*socket.send(*", "*socket.tcp(*",
 94    "*socket.udp(*", "*socket.listen(*", "*socket.accept(*", "*net.http.request(*",
 95    "*net.http.get(*", "*net.http.post(*", "*http.request(*", "*http.get(*", "*http.post(*"
 96  ) or
 97  process.executable like ("/bin/python*", "/usr/bin/python*", "/usr/local/bin/python*") and
 98  process.args == "-c" and process.args like~ (
 99    "*exec(*base64*", "*exec(*decode(*", "*exec(*marshal*", "*exec(*pickle*", "*eval(*exec(*",
100    "*eval(*", "*subprocess.popen(*", "*subprocess.run(*", "*pickle.loads(*", "*marshal.loads(*",
101    "*binascii*", "*os.system(*", "*os.popen(*", "*pty.*", "*dup2*", "*fileno()*", "*connect(*",
102    "*bind(*", "*execve(*", "*base64*", "*base32*", "*base16*", "*base85*", "*decode(*",
103    "*zlib.*", "*[::-1]*", "*socket.socket(*", "*socket.connect(*", "*socket.bind(*"
104  ) or
105  process.executable like ("/bin/ruby*", "/usr/bin/ruby*", "/usr/local/bin/ruby*") and
106  process.args like "-e*" and process.args like~ (
107    "*system(*", "*exec(*", "*IO.popen(*", "*Open3.popen3(*", "*spawn(*", "*eval(*", "*load(*",
108    "*Marshal.load(*", "*Fiddle.dlopen(*", "*Fiddle::Function.new(*", "*base64*", "*zlib*", 
109    "*net/http*", "*socket*", "*open-uri*", "*pack(*", "*unpack(*"
110  )
111) and container.id like "?*"
112'''
113
114[[rule.threat]]
115framework = "MITRE ATT&CK"
116
117  [rule.threat.tactic]
118  name = "Execution"
119  id = "TA0002"
120  reference = "https://attack.mitre.org/tactics/TA0002/"
121
122  [[rule.threat.technique]]
123  id = "T1059"
124  name = "Command and Scripting Interpreter"
125  reference = "https://attack.mitre.org/techniques/T1059/"
126
127    [[rule.threat.technique.subtechnique]]
128    name = "Unix Shell"
129    id = "T1059.004"
130    reference = "https://attack.mitre.org/techniques/T1059/004/"
131
132    [[rule.threat.technique.subtechnique]]
133    name = "Python"
134    id = "T1059.006"
135    reference = "https://attack.mitre.org/techniques/T1059/006/"
136
137    [[rule.threat.technique.subtechnique]]
138    name = "Lua"
139    id = "T1059.011"
140    reference = "https://attack.mitre.org/techniques/T1059/011/"
141
142[[rule.threat]]
143framework = "MITRE ATT&CK"
144
145  [rule.threat.tactic]
146  name = "Command and Control"
147  id = "TA0011"
148  reference = "https://attack.mitre.org/tactics/TA0011/"
149
150  [[rule.threat.technique]]
151  name = "Application Layer Protocol"
152  id = "T1071"
153  reference = "https://attack.mitre.org/techniques/T1071/"
154
155    [[rule.threat.technique.subtechnique]]
156    name = "Web Protocols"
157    id = "T1071.001"
158    reference = "https://attack.mitre.org/techniques/T1071/001/"

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 Suspicious Interpreter Execution Detected via Defend for Containers

This detection flags an interactive session inside a Linux container launching Perl, PHP, Lua, Python, or Ruby with inline code execution and high-risk functions commonly used for spawning processes, decoding payloads, or opening network connections. It matters because attackers often abuse these one-liners to run malware or exfiltrate data without dropping files, blending into normal admin shell activity. A common pattern is a python -c one-liner that base64-decodes a second-stage script and executes it, then initiates an outbound socket for command-and-control.

Possible investigation steps

  • Review the full inline interpreter code and decode any embedded payloads (e.g., base64/zlib/rot13) to determine its intent, IOCs, and whether it fetches or launches a second stage.
  • Identify the originating interactive session and actor by correlating the container’s TTY/exec session metadata with orchestrator audit logs (e.g., Kubernetes exec/attach) to determine who/what initiated it and from where.
  • Assess whether the container image, entrypoint, and recent deployment changes are expected for this workload, and check for signs of container escape attempts or host access (mounted sockets, privileged flags, hostPath mounts).
  • Pivot from the alert time to related activity in the same container for child processes, file writes, cron/systemd modifications, and persistence artifacts that indicate follow-on actions beyond a one-liner.
  • Check for unexpected outbound connections or DNS lookups from the container around execution time, and validate any contacted domains/IPs against threat intel and known-good service dependencies.

False positive analysis

  • A developer or SRE opens an interactive shell in the container to troubleshoot and runs a quick inline one-liner (e.g., python -c/php -r/ruby -e) to test network connectivity, decode/transform a string (base64/zlib), or call a subprocess for diagnostics, which matches the suspicious function patterns.
  • During an interactive container exec session, an administrator performs emergency maintenance or incident response actions using an interpreter one-liner to fetch configuration/state, invoke system utilities, or validate service behavior (e.g., socket.connect, os.system, curl_exec, IO.popen), producing a benign but high-risk inline command signature.

Response and remediation

  • Quarantine the affected workload by scaling it to zero or cordoning the node and blocking egress for the namespace while preserving the pod and container filesystem for evidence capture.
  • Terminate the interactive session and kill the interpreter process tree, then collect the full command line, any decoded inline payload, and any retrieved scripts or binaries from the container for malware analysis.
  • Hunt and remove follow-on artifacts by searching the container for newly created executables, modified startup scripts, cron entries, webshells, or injected environment variables, and redeploy from a known-good image rather than “cleaning” the live container.
  • Rotate credentials and secrets exposed to the container (service account tokens, API keys, database passwords) and invalidate active sessions if the one-liner performed network calls, decoded payloads, or spawned subprocesses.
  • Escalate to the incident response team if the inline code includes base64/zlib decoding, establishes a socket connection, downloads a second stage, or any similar activity is observed across multiple pods/namespaces.
  • Harden against recurrence by restricting exec/attach access, enforcing least-privilege pod security (no privileged, no host mounts, read-only root filesystem), and using egress allowlists plus image signing/admission controls to block unauthorized images and interactive debug containers.

Related rules

to-top