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/03/05"
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", "-cl") and process.args like ("*echo *", "*printf *") and
75process.args like (
76 "*/etc/cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", "*/etc/update-motd.d*",
77 "*/etc/ld.so*", "*/etc/sudoers*", "*base64 *", "*base32 *", "*base16 *", "*/etc/profile*",
78 "*/dev/shm/*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*" , "*~/.ssh/*", "*xxd *",
79 "*/etc/shadow*", "* /tmp/*", "* /var/tmp/*", "* /dev/shm/* ", "* ~/*", "* /home/*",
80 "* /run/*", "* /var/run/*", "*|*sh", "*|*python*", "*|*php*", "*|*perl*", "*|*busybox*",
81 "*/var/www/*", "*>*", "*;*", "*chmod *", "*rm *", "*openssl enc*"
82) and container.id like "?*"
83'''
84
85[[rule.threat]]
86framework = "MITRE ATT&CK"
87
88[[rule.threat.technique]]
89id = "T1543"
90name = "Create or Modify System Process"
91reference = "https://attack.mitre.org/techniques/T1543/"
92
93[[rule.threat.technique]]
94id = "T1053"
95name = "Scheduled Task/Job"
96reference = "https://attack.mitre.org/techniques/T1053/"
97
98[[rule.threat.technique.subtechnique]]
99id = "T1053.003"
100name = "Cron"
101reference = "https://attack.mitre.org/techniques/T1053/003/"
102
103[[rule.threat.technique]]
104id = "T1037"
105name = "Boot or Logon Initialization Scripts"
106reference = "https://attack.mitre.org/techniques/T1037/"
107
108[[rule.threat.technique]]
109id = "T1546"
110name = "Event Triggered Execution"
111reference = "https://attack.mitre.org/techniques/T1546/"
112
113[[rule.threat.technique.subtechnique]]
114id = "T1546.004"
115name = "Unix Shell Configuration Modification"
116reference = "https://attack.mitre.org/techniques/T1546/004/"
117
118[rule.threat.tactic]
119id = "TA0003"
120name = "Persistence"
121reference = "https://attack.mitre.org/tactics/TA0003/"
122
123[[rule.threat]]
124framework = "MITRE ATT&CK"
125
126[[rule.threat.technique]]
127id = "T1543"
128name = "Create or Modify System Process"
129reference = "https://attack.mitre.org/techniques/T1543/"
130
131[[rule.threat.technique]]
132id = "T1053"
133name = "Scheduled Task/Job"
134reference = "https://attack.mitre.org/techniques/T1053/"
135
136[[rule.threat.technique.subtechnique]]
137id = "T1053.003"
138name = "Cron"
139reference = "https://attack.mitre.org/techniques/T1053/003/"
140
141[rule.threat.tactic]
142id = "TA0004"
143name = "Privilege Escalation"
144reference = "https://attack.mitre.org/tactics/TA0004/"
145
146[[rule.threat]]
147framework = "MITRE ATT&CK"
148
149[[rule.threat.technique]]
150id = "T1053"
151name = "Scheduled Task/Job"
152reference = "https://attack.mitre.org/techniques/T1053/"
153
154[[rule.threat.technique.subtechnique]]
155id = "T1053.003"
156name = "Cron"
157reference = "https://attack.mitre.org/techniques/T1053/003/"
158
159[rule.threat.tactic]
160id = "TA0002"
161name = "Execution"
162reference = "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 Exploitation Detected via Defend for Containers
- Pod or Container Creation with Suspicious Command-Line
- Decoded Payload Piped to Interpreter Detected via Defend for Containers
- Direct Interactive Kubernetes API Request by Unusual Utilities