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/attachaccess, 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
- Payload Execution via Shell Pipe Detected by Defend for Containers
- Web Server Exploitation Detected via Defend for Containers
- File Download Detected via Defend for Containers
- File Creation and Execution Detected via Defend for Containers
- System Path File Creation and Execution Detected via Defend for Containers