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/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.
Related rules
- File Creation and Execution Detected via Defend for Containers
- File Download Detected via Defend for Containers
- System Path File Creation and Execution Detected via Defend for Containers
- Web Server Child Shell Spawn Detected via Defend for Containers
- Encoded Payload Detected via Defend for Containers