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/03/05"
  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."""
 51references = [
 52    "https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
 53]
 54risk_score = 47
 55rule_id = "cd24c340-b778-44bd-ab69-2f739bd70ce1"
 56severity = "medium"
 57tags = [
 58    "Data Source: Elastic Defend for Containers",
 59    "Domain: Container",
 60    "OS: Linux",
 61    "Use Case: Threat Detection",
 62    "Tactic: Execution",
 63    "Tactic: Command and Control",
 64    "Resources: Investigation Guide",
 65]
 66timestamp_override = "event.ingested"
 67type = "eql"
 68query = '''
 69process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.interactive == true and
 70process.parent.executable != null and (
 71  (
 72    process.executable like ("/bin/perl*", "/usr/bin/perl*", "/usr/local/bin/perl*") and
 73    process.args == "-e" and process.args like~ (
 74      "*system(*", "*exec(*", "*IO.popen(*", "*Open3.popen3(*", "*spawn(*", "*eval(*",
 75      "*load(*IO::*", "*load(*Marshal*", "*load(*Fiddle*", "*load(*Zlib*", "*load(*Base64*",
 76      "*zlib.inflate(*", "*zlib.deflate(*", "*zlib.decompress(*", "*zlib.uncompress(*", "*zlib.compress(*",
 77      "*Marshal.load(*", "*Fiddle.dlopen(*", "*Fiddle::Function.new(*", "*base64*", "*zlib*", 
 78      "*net/http*", "*socket.new*", "*open-uri*", "*pack(*"
 79    )
 80  ) or
 81  process.executable like ("/bin/php*", "/usr/bin/php*", "/usr/local/bin/php*") and
 82  process.args == "-r" and process.args like~ (
 83    "*exec(*", "*system(*", "*shell_exec(*", "*passthru(*", "*proc_open(*", "*pcntl_exec(*", "*popen(*", 
 84    "*eval(*", "*assert(*", "*create_function(*", "*preg_replace(*e*", "*include(*", "*require(*",
 85    "*base64_decode(*", "*gzinflate(*", "*gzuncompress(*", "*str_rot13(*", "*urldecode(*", "*chr(*", 
 86    "*ord(*", "*strrev(*", "*strtr(*", "*pack(*", "*unpack(*", "*curl_exec(*", "*curl_multi_exec(*",
 87    "*file_get_contents(*", "*fopen(*", "*fsockopen(*", "*pfsockopen(*", "*stream_socket_client(*",
 88    "*socket_create(*", "*socket_connect(*", "*socket_write(*", "*socket_read(*", "*mail(*",
 89    "*move_uploaded_file(*"
 90  ) or
 91  process.executable like ("/bin/lua*", "/usr/bin/lua*", "/usr/local/bin/lua*") and
 92  process.args == "-e" and process.args like~ (
 93    "*os.execute(*", "*io.popen(*", "*load(*", "*loadstring(*", "*require(*", "*dofile(*",
 94    "*package.loadlib(*", "*base64.decode(*", "*base64.encode(*", "*zlib.inflate(*",
 95    "*zlib.deflate(*", "*zlib.decompress(*", "*zlib.compress(*", "*socket.bind(*",
 96    "*socket.connect(*", "*socket.receive(*", "*socket.send(*", "*socket.tcp(*",
 97    "*socket.udp(*", "*socket.listen(*", "*socket.accept(*", "*net.http.request(*",
 98    "*net.http.get(*", "*net.http.post(*", "*http.request(*", "*http.get(*", "*http.post(*"
 99  ) or
100  process.executable like ("/bin/python*", "/usr/bin/python*", "/usr/local/bin/python*") and
101  process.args == "-c" and process.args like~ (
102    "*exec(*base64*", "*exec(*decode(*", "*exec(*marshal*", "*exec(*pickle*", "*eval(*exec(*",
103    "*eval(*", "*subprocess.popen(*", "*subprocess.run(*", "*pickle.loads(*", "*marshal.loads(*",
104    "*binascii*", "*os.system(*", "*os.popen(*", "*pty.*", "*dup2*", "*fileno()*", "*connect(*",
105    "*bind(*", "*execve(*", "*base64*", "*base32*", "*base16*", "*base85*", "*decode(*",
106    "*zlib.*", "*[::-1]*", "*socket.socket(*", "*socket.connect(*", "*socket.bind(*"
107  ) or
108  process.executable like ("/bin/ruby*", "/usr/bin/ruby*", "/usr/local/bin/ruby*") and
109  process.args like "-e*" and process.args like~ (
110    "*system(*", "*exec(*", "*IO.popen(*", "*Open3.popen3(*", "*spawn(*", "*eval(*", "*load(*",
111    "*Marshal.load(*", "*Fiddle.dlopen(*", "*Fiddle::Function.new(*", "*base64*", "*zlib*", 
112    "*net/http*", "*socket*", "*open-uri*", "*pack(*", "*unpack(*"
113  )
114) and container.id like "?*"
115'''
116
117[[rule.threat]]
118framework = "MITRE ATT&CK"
119
120  [rule.threat.tactic]
121  name = "Execution"
122  id = "TA0002"
123  reference = "https://attack.mitre.org/tactics/TA0002/"
124
125  [[rule.threat.technique]]
126  id = "T1059"
127  name = "Command and Scripting Interpreter"
128  reference = "https://attack.mitre.org/techniques/T1059/"
129
130    [[rule.threat.technique.subtechnique]]
131    name = "Unix Shell"
132    id = "T1059.004"
133    reference = "https://attack.mitre.org/techniques/T1059/004/"
134
135    [[rule.threat.technique.subtechnique]]
136    name = "Python"
137    id = "T1059.006"
138    reference = "https://attack.mitre.org/techniques/T1059/006/"
139
140    [[rule.threat.technique.subtechnique]]
141    name = "Lua"
142    id = "T1059.011"
143    reference = "https://attack.mitre.org/techniques/T1059/011/"
144
145[[rule.threat]]
146framework = "MITRE ATT&CK"
147
148  [rule.threat.tactic]
149  name = "Command and Control"
150  id = "TA0011"
151  reference = "https://attack.mitre.org/tactics/TA0011/"
152
153  [[rule.threat.technique]]
154  name = "Application Layer Protocol"
155  id = "T1071"
156  reference = "https://attack.mitre.org/techniques/T1071/"
157
158    [[rule.threat.technique.subtechnique]]
159    name = "Web Protocols"
160    id = "T1071.001"
161    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.

References

Related rules

to-top