Suspicious Echo or Printf Execution Detected via Defend for Containers
This rule detects the execution of the echo/printf command to write data to potential persistence files, decode base64/32/16 and hex content or establish connections to a potential C2. The echo/printf commands are used to display a line of text or write data to a file. Threat actors may abuse the echo/printf commands to write data to files or file descriptors that are executed (by other processes or services) to establish persistence or escalate privileges.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/02/10"
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/10"
8
9[rule]
10author = ["Elastic"]
11description = """
12This rule detects the execution of the echo/printf command to write data to potential persistence files, decode base64/32/16 and
13hex content or establish connections to a potential C2. The echo/printf commands are used to display a line of text or write data
14to a file. Threat actors may abuse the echo/printf commands to write data to files or file descriptors that are executed (by
15other processes or services) to establish persistence or escalate privileges.
16"""
17from = "now-6m"
18index = ["logs-cloud_defend.process*"]
19interval = "5m"
20language = "eql"
21license = "Elastic License v2"
22name = "Suspicious Echo or Printf Execution Detected via Defend for Containers"
23note = """## Triage and analysis
24
25> **Disclaimer**:
26> 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.
27
28### Investigating Suspicious Echo or Printf Execution Detected via Defend for Containers
29
30This rule flags interactive shell commands that invoke echo or printf with patterns used to write or stage data into sensitive paths, decode encoded payloads, or reach out via /dev/tcp. Attackers use these lightweight built-ins to avoid dropping tools while creating persistence or privilege escalation by modifying cron, rc.local, sudoers, ld.so preload, or SSH authorized_keys. In a container, a common pattern is execing into a pod and running `sh -c 'printf <base64> | base64 -d > /etc/cron.d/job; chmod +x …'` to implant a scheduled backdoor.
31
32### Possible investigation steps
33
34- Review the full command line, parent/child process tree, and session metadata to determine who initiated the interactive exec and whether it was an expected administrative action.
35- Extract any encoded strings or redirected output from the command and safely decode/pretty-print it to identify dropped scripts, keys, cron entries, or additional staging commands.
36- Inspect the referenced destination paths (and their symlink targets) for recent modifications, unexpected permissions/ownership changes, and persistence artifacts such as cron jobs, rc.local edits, ld.so preload configs, sudoers changes, or SSH authorized_keys additions.
37- Determine whether the write target resides on a mounted volume shared with the host or other pods, and assess blast radius by checking for the same artifact across replicas/namespaces and CI/CD deployment history.
38- Correlate around the execution time for follow-on activity such as outbound connections (including /dev/tcp usage), subsequent interpreter launches, or cleanup actions, and contain by isolating/pausing the workload if malicious behavior is confirmed.
39
40### False positive analysis
41
42- An administrator interactively execs into a container during troubleshooting and uses `echo`/`printf` with redirection (and possibly `chmod`) to make a temporary or emergency change in paths like `/etc/profile`, `/etc/update-motd.d`, `/etc/ssh*`, or `~/.ssh/*` to restore access or correct misconfiguration.
43- A developer interactively execs into a container to create and run a short diagnostic artifact by using `echo`/`printf` to write into `/tmp` or `/dev/shm`, decode embedded `base64`/hex content, or validate network reachability via `/dev/tcp`, which can resemble staging/persistence behavior.
44
45### Response and remediation
46
47- Isolate the affected pod/container by removing it from service (scale to zero or cordon/deny ingress-egress) and, if needed, pause it to preserve the filesystem state before it can overwrite or delete staged artifacts.
48- Capture and preserve evidence by exporting the full shell command string and taking a filesystem snapshot/copy of any touched paths such as `/etc/cron*`, `/etc/rc.local`, `/etc/init.d`, `/etc/ld.so*`, `/etc/sudoers*`, and `~/.ssh/authorized_keys`, plus any files created in `/tmp`, `/var/tmp`, or `/dev/shm`.
49- Eradicate persistence by removing unauthorized cron entries, rc.local/init scripts, sudoers/ld.so preload modifications, and injected SSH keys, then rotate any exposed credentials and redeploy the workload from a known-good image rather than “cleaning” the live container.
50- Recover safely by rebuilding the image with patched dependencies, rolling out a fresh deployment, and validating that no replicas or shared volumes contain the same dropped scripts/keys or modified configuration files.
51- Escalate immediately to incident response if the command decodes payloads (base64/base32/hex), writes into system startup/auth paths, invokes an interpreter via a pipe (e.g., `| sh/python/perl/php`), or uses `/dev/tcp` for outbound connectivity, as these indicate active staging or C2 behavior.
52- Harden against recurrence by restricting interactive exec access, enforcing read-only root filesystems and least-privilege mounts, blocking writes to sensitive paths via policy, and adding egress controls to prevent `/dev/tcp`-style callbacks."""
53references = [
54 "https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
55]
56risk_score = 73
57rule_id = "d9bfa475-270d-4b07-93cb-b1f49abe13da"
58severity = "high"
59tags = [
60 "Data Source: Elastic Defend for Containers",
61 "Domain: Container",
62 "OS: Linux",
63 "Use Case: Threat Detection",
64 "Tactic: Persistence",
65 "Tactic: Execution",
66 "Tactic: Privilege Escalation",
67 "Resources: Investigation Guide",
68]
69timestamp_override = "event.ingested"
70type = "eql"
71query = '''
72process where event.type == "start" and event.action == "exec" and process.interactive == true and
73process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
74process.args in ("-lc", "-c") and process.args like ("*echo *", "*printf *") and process.args like (
75 "*/etc/cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", "*/etc/update-motd.d*",
76 "*/etc/ld.so*", "*/etc/sudoers*", "*base64 *", "*base32 *", "*base16 *", "*/etc/profile*",
77 "*/dev/shm/*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*" , "*~/.ssh/*", "*xxd *",
78 "*/etc/shadow*", "* /tmp/*", "* /var/tmp/*", "* /dev/shm/* ", "* ~/*", "* /home/*",
79 "* /run/*", "* /var/run/*", "*|*sh", "*|*python*", "*|*php*", "*|*perl*", "*|*busybox*",
80 "*/var/www/*", "*>*", "*;*", "*chmod *", "*rm *", "*openssl enc*"
81) and container.id like "?*"
82'''
83
84[[rule.threat]]
85framework = "MITRE ATT&CK"
86
87[[rule.threat.technique]]
88id = "T1543"
89name = "Create or Modify System Process"
90reference = "https://attack.mitre.org/techniques/T1543/"
91
92[[rule.threat.technique]]
93id = "T1053"
94name = "Scheduled Task/Job"
95reference = "https://attack.mitre.org/techniques/T1053/"
96
97[[rule.threat.technique.subtechnique]]
98id = "T1053.003"
99name = "Cron"
100reference = "https://attack.mitre.org/techniques/T1053/003/"
101
102[[rule.threat.technique]]
103id = "T1037"
104name = "Boot or Logon Initialization Scripts"
105reference = "https://attack.mitre.org/techniques/T1037/"
106
107[[rule.threat.technique]]
108id = "T1546"
109name = "Event Triggered Execution"
110reference = "https://attack.mitre.org/techniques/T1546/"
111
112[[rule.threat.technique.subtechnique]]
113id = "T1546.004"
114name = "Unix Shell Configuration Modification"
115reference = "https://attack.mitre.org/techniques/T1546/004/"
116
117[rule.threat.tactic]
118id = "TA0003"
119name = "Persistence"
120reference = "https://attack.mitre.org/tactics/TA0003/"
121
122[[rule.threat]]
123framework = "MITRE ATT&CK"
124
125[[rule.threat.technique]]
126id = "T1543"
127name = "Create or Modify System Process"
128reference = "https://attack.mitre.org/techniques/T1543/"
129
130[[rule.threat.technique]]
131id = "T1053"
132name = "Scheduled Task/Job"
133reference = "https://attack.mitre.org/techniques/T1053/"
134
135[[rule.threat.technique.subtechnique]]
136id = "T1053.003"
137name = "Cron"
138reference = "https://attack.mitre.org/techniques/T1053/003/"
139
140[rule.threat.tactic]
141id = "TA0004"
142name = "Privilege Escalation"
143reference = "https://attack.mitre.org/tactics/TA0004/"
144
145[[rule.threat]]
146framework = "MITRE ATT&CK"
147
148[[rule.threat.technique]]
149id = "T1053"
150name = "Scheduled Task/Job"
151reference = "https://attack.mitre.org/techniques/T1053/"
152
153[[rule.threat.technique.subtechnique]]
154id = "T1053.003"
155name = "Cron"
156reference = "https://attack.mitre.org/techniques/T1053/003/"
157
158[rule.threat.tactic]
159id = "TA0002"
160name = "Execution"
161reference = "https://attack.mitre.org/tactics/TA0002/"
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 Echo or Printf Execution Detected via Defend for Containers
This rule flags interactive shell commands that invoke echo or printf with patterns used to write or stage data into sensitive paths, decode encoded payloads, or reach out via /dev/tcp. Attackers use these lightweight built-ins to avoid dropping tools while creating persistence or privilege escalation by modifying cron, rc.local, sudoers, ld.so preload, or SSH authorized_keys. In a container, a common pattern is execing into a pod and running sh -c 'printf <base64> | base64 -d > /etc/cron.d/job; chmod +x …' to implant a scheduled backdoor.
Possible investigation steps
- Review the full command line, parent/child process tree, and session metadata to determine who initiated the interactive exec and whether it was an expected administrative action.
- Extract any encoded strings or redirected output from the command and safely decode/pretty-print it to identify dropped scripts, keys, cron entries, or additional staging commands.
- Inspect the referenced destination paths (and their symlink targets) for recent modifications, unexpected permissions/ownership changes, and persistence artifacts such as cron jobs, rc.local edits, ld.so preload configs, sudoers changes, or SSH authorized_keys additions.
- Determine whether the write target resides on a mounted volume shared with the host or other pods, and assess blast radius by checking for the same artifact across replicas/namespaces and CI/CD deployment history.
- Correlate around the execution time for follow-on activity such as outbound connections (including /dev/tcp usage), subsequent interpreter launches, or cleanup actions, and contain by isolating/pausing the workload if malicious behavior is confirmed.
False positive analysis
- An administrator interactively execs into a container during troubleshooting and uses
echo/printfwith redirection (and possiblychmod) to make a temporary or emergency change in paths like/etc/profile,/etc/update-motd.d,/etc/ssh*, or~/.ssh/*to restore access or correct misconfiguration. - A developer interactively execs into a container to create and run a short diagnostic artifact by using
echo/printfto write into/tmpor/dev/shm, decode embeddedbase64/hex content, or validate network reachability via/dev/tcp, which can resemble staging/persistence behavior.
Response and remediation
- Isolate the affected pod/container by removing it from service (scale to zero or cordon/deny ingress-egress) and, if needed, pause it to preserve the filesystem state before it can overwrite or delete staged artifacts.
- Capture and preserve evidence by exporting the full shell command string and taking a filesystem snapshot/copy of any touched paths such as
/etc/cron*,/etc/rc.local,/etc/init.d,/etc/ld.so*,/etc/sudoers*, and~/.ssh/authorized_keys, plus any files created in/tmp,/var/tmp, or/dev/shm. - Eradicate persistence by removing unauthorized cron entries, rc.local/init scripts, sudoers/ld.so preload modifications, and injected SSH keys, then rotate any exposed credentials and redeploy the workload from a known-good image rather than “cleaning” the live container.
- Recover safely by rebuilding the image with patched dependencies, rolling out a fresh deployment, and validating that no replicas or shared volumes contain the same dropped scripts/keys or modified configuration files.
- Escalate immediately to incident response if the command decodes payloads (base64/base32/hex), writes into system startup/auth paths, invokes an interpreter via a pipe (e.g.,
| sh/python/perl/php), or uses/dev/tcpfor outbound connectivity, as these indicate active staging or C2 behavior. - Harden against recurrence by restricting interactive exec access, enforcing read-only root filesystems and least-privilege mounts, blocking writes to sensitive paths via policy, and adding egress controls to prevent
/dev/tcp-style callbacks.
References
Related rules
- Modification of Persistence Relevant Files Detected via Defend for Containers
- Web Server Child Shell Spawn Detected via Defend for Containers
- Pod or Container Creation with Suspicious Command-Line
- File Download Detected via Defend for Containers
- Payload Execution via Shell Pipe Detected by Defend for Containers