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/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.
  • 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.

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/tcp for 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

to-top