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

[New/Tuning] Misc. New D4C Rules and Tunings (#5692)

Browse Source 
* Updated kubernetes.audit.requestObject.spec.containers.image type of text to Keyword

* [New/Tuning] Misc. New D4C Rules and Tunings

* Added IGs for High Severity Rules

* Apply suggestion from @Aegrah

* ++

* Update discovery_privilege_boundary_enumeration_from_interactive_process.toml

* ++

* Update rules/integrations/cloud_defend/credential_access_service_account_token_or_cert_read.toml

Co-authored-by: Samirbous <64742097+Samirbous@users.noreply.github.com>

* Update rules/integrations/cloud_defend/discovery_service_account_namespace_read.toml

Co-authored-by: Samirbous <64742097+Samirbous@users.noreply.github.com>

* Update execution_interactive_file_creation_followed_by_execution.toml

* Some updates based on feedback

* Rule name changes

* ++

---------

Co-authored-by: Samirbous <64742097+Samirbous@users.noreply.github.com>
This commit is contained in:
Ruben Groenewoud
2026-02-09 16:58:27 +01:00
committed by GitHub
parent 2b5472a9b3
commit 229f3adf75
14 changed files with 1275 additions and 19 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
+138
View File
@@ -0,0 +1,138 @@
[metadata]
creation_date = "2026/02/06"
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"
[rule]
author = ["Elastic"]
description = """
This rule detects the download of files from inside a container. The files are downloaded using the "curl" or
"wget" command-line tools. Adversaries may use these tools to download files from the internet to gain access to
sensitive data or communicate with C2 servers.
"""
false_positives = [
"""
There is a potential for false positives if the files are downloaded for legitimate purposes, such as debugging or
troubleshooting, or if the files are downloaded from a known benign source. It is important to investigate any
alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate
container activity.
""",
]
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "File Download 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 File Download Detected via Defend for Containers
This rule flags an interactive session inside a Linux container that runs curl or wget to pull content from a URL or IP and immediately writes a new file, signaling hands-on retrieval of tools, payloads, or data. It matters because attackers often use on-demand downloads to stage second-phase execution and establish application-layer command-and-control without baking artifacts into images. A common pattern is an operator execing into a running container, fetching a script or binary from paste/CDN infrastructure, then saving it for rapid follow-on execution.
### Possible investigation steps
- Attribute the interactive session to an initiator by correlating the container exec/attach event with Kubernetes audit logs or Docker daemon logs to identify the user/service account, source IP, and access path.
- Inspect the created file’s full path, size, magic/format, and hash, then retrieve it from the container or node filesystem for static analysis and malware scanning.
- Pivot on the download destination (domain/IP/URL path) to review outbound connection telemetry, DNS/TLS indicators, and threat reputation, and determine whether the endpoint is expected for this workload.
- Review subsequent container activity after the download for follow-on actions such as chmod, interpreter execution, new processes, cron modifications, credential access, or lateral movement attempts.
- Validate whether the container/image and namespace normally permit interactive access and external downloads, and if not, assess for compromised credentials, exposed exec permissions, or a misconfigured runtime policy.
### False positive analysis
- A developer or SRE may exec into a running container for interactive troubleshooting and use curl or wget to fetch a diagnostic script, configuration file, or test payload from an internal HTTP endpoint, resulting in a new file creation event.
- An operator may interactively run curl or wget to download a patch, certificate bundle, or updated artifact into the container during an emergency fix or recovery workflow, especially in minimal images lacking package managers, which can appear indistinguishable from attacker staging.
### Response and remediation
- Immediately isolate the affected pod/container by applying a deny-all egress policy and, if possible, pausing or cordoning the hosting node to stop additional downloads and outbound C2 traffic.
- Capture and preserve the downloaded artifact(s) created by curl/wget (path, timestamps, hashes) plus the interactive shell history/command line, then delete the file(s) from the container and revoke any injected tools or scripts.
- Terminate the interactive session and rotate credentials used to exec/attach (Kubernetes user/service account tokens, kubeconfig, SSH keys) and invalidate any newly created access (added users, API tokens, or modified secrets/config).
- Redeploy the workload from a known-good image and configuration, then scan the node and cluster for persistence or reuse of the same URL/IP and hashes across other containers, blocking them at egress and proxy/IDS.
- Escalate to incident response immediately if the downloaded file is executed, connects to an unapproved external host, modifies startup paths (entrypoint/cron), or if the exec user is unknown or high-privileged.
- Harden by removing exec/attach permissions from non-admin roles, enforcing runtime policies that block interactive curl/wget and restrict outbound traffic to approved destinations, and ensuring images include required tools so ad-hoc downloads are unnecessary."""
references = [
"https://heilancoos.github.io/research/2025/12/16/kubernetes.html#kubelet-api",
"https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster",
"https://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/"
]
risk_score = 47
rule_id = "a8b08d2d-6dfe-453f-87d1-11d5fc3ec746"
severity = "medium"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Command and Control",
"Tactic: Execution",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.interactive == true and (
(
(process.name == "curl" or process.args in ("curl", "/bin/curl", "/usr/bin/curl", "/usr/local/bin/curl")) and
process.args in ("-o", "-O", "--output", "--remote-name", "--remote-name-all", "--output-dir")
) 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)
)
) and (
process.args like~ "*http*" or
process.args regex~ ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}[:/]{1}.*"
) and container.id like "?*"
'''
[[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.technique.subtechnique]]
name = "Web Protocols"
id = "T1071.001"
reference = "https://attack.mitre.org/techniques/T1071/001/"
[[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]]
name = "Unix Shell"
id = "T1059.004"
reference = "https://attack.mitre.org/techniques/T1059/004/"
rules/integrations/cloud_defend/credential_access_service_account_token_or_cert_read.toml
+27 -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/01/27"
updated_date = "2026/02/06"
[rule]
author = ["Elastic"]
@@ -22,7 +22,7 @@ false_positives = [
""",
]
from = "now-6m"
index = ["logs-cloud_defend.file*"]
index = ["logs-cloud_defend.file*", "logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
@@ -71,10 +71,31 @@ tags = [
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "change" and event.action == "open" and file.path in (
"/var/run/secrets/kubernetes.io/serviceaccount/token", "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
) and
process.interactive == true and container.id like "*"
any where host.os.type == "linux" and process.interactive == true and container.id like "*" and (
(event.category == "file" and event.type == "change" and event.action == "open" and
file.path in (
"/var/run/secrets/kubernetes.io/serviceaccount/token",
"/var/run/secrets/kubernetes.io/serviceaccount/ca.crt",
"/run/secrets/kubernetes.io/serviceaccount/token",
"/run/secrets/kubernetes.io/serviceaccount/ca.crt"
)) or
(event.category == "process" and event.type == "start" and event.action == "exec" and
(
process.name in ("cat", "head", "tail", "more", "less", "sed", "awk") or
process.args in (
"cat", "/bin/cat", "/usr/bin/cat", "/usr/local/bin/cat",
"head", "/bin/head", "/usr/bin/head", "/usr/local/bin/head",
"tail", "/bin/tail", "/usr/bin/tail", "/usr/local/bin/tail",
"more", "/bin/more", "/usr/bin/more", "/usr/local/bin/more",
"less", "/bin/less", "/usr/bin/less", "/usr/local/bin/less",
"sed", "/bin/sed", "/usr/bin/sed", "/usr/local/bin/sed",
"awk", "/bin/awk", "/usr/bin/awk", "/usr/local/bin/awk"
)
) and process.args like (
"*/run/secrets/kubernetes.io/serviceaccount/token*",
"*/run/secrets/kubernetes.io/serviceaccount/ca.crt*"
))
)
'''
[[rule.threat]]
rules/integrations/cloud_defend/defense_evasion_deletion_of_shell_cmdline_history.toml
+103
View File
@@ -0,0 +1,103 @@
[metadata]
creation_date = "2026/02/06"
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"
[rule]
author = ["Elastic"]
description = """
This rule detects the deletion of shell command-line history files inside a container. The shell command-line history
files are used to store the command-line history for the shell. Adversaries may delete these files to cover their tracks
or evade detection.
"""
from = "now-6m"
index = ["logs-cloud_defend.file*", "logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Shell Command-Line History Deletion 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 Shell Command-Line History Deletion Detected via Defend for Containers
This rule detects attempts during interactive sessions to delete, truncate, or disable shell command history files inside containers, a common tactic to erase evidence and impede investigations. An attacker uses kubectl exec to open an interactive bash shell in a running pod, then symlinks /root/.bash_history to /dev/null to prevent future commands from being recorded while performing reconnaissance or credential access.
### Possible investigation steps
- Correlate the container to its pod, namespace, and owning workload, and pull Kubernetes audit logs for exec/attach around the alert time to identify the caller identity, source IP, and user-agent and validate business justification.
- Reconstruct the interactive session timeline by reviewing adjacent process telemetry before and after the history suppression to surface reconnaissance, credential access, data staging, or tooling downloads the actor may be hiding.
- Examine shell configs and filesystem state for persistent history suppression (e.g., HISTFILE/HISTSIZE/HISTCONTROL in /etc/profile.d or .bashrc/.zshrc, or history files symlinked to /dev/null) and compare timestamps/owners to distinguish image defaults from live tampering.
- Assess runtime context for impact by confirming the session’s user/UID, effective capabilities, mounted secrets or tokens, and writable volumes, and checking for privilege escalation or access to sensitive data.
- If unauthorized, isolate the pod and capture volatile evidence (filesystem tarball, /proc, environment variables, shell rc files), rotate any exposed credentials, and hunt for similar events across pods/namespaces and the same source IP or identity.
### False positive analysis
- An authorized operator opens an interactive shell in a container for troubleshooting and intentionally clears or disables history (e.g., history -c, rm/truncate ~/.bash_history, or export HISTFILE=/dev/null) to avoid recording sensitive commands.
- The container image’s interactive shell startup configuration automatically disables history (e.g., HISTFILESIZE=0, unset HISTFILE, or linking ~/.bash_history to /dev/null), so a normal debug login triggers the alert.
### Response and remediation
- Isolate the affected pod by applying a temporary NetworkPolicy to block egress, remove pods/exec and pods/attach permissions from the caller, and terminate any interactive shells that executed rm, history -c, or truncate on ~/.bash_history or linked it to /dev/null.
- Eradicate changes by removing any ~/.bash_history symlink to /dev/null, recreating /root/.bash_history and /home/*/.bash_history with correct ownership and 600 permissions, and restoring HISTFILE/HISTFILESIZE/HISTCONTROL in /etc/profile.d, .bashrc, and .zshrc to expected values.
- Recover by rebuilding and redeploying the workload from a trusted image, rotating any secrets or tokens accessed during the session (service account token, cloud provider credentials, SSH keys), and validating that new shells now persist command history.
- Escalate to incident response if the exec caller identity is unknown or unauthorized, if privileged actions (kubectl with cluster-admin, sudo, or reading /var/run/secrets/kubernetes.io/serviceaccount) occurred after history deletion, or if multiple pods/namespaces show coordinated history suppression.
- Harden by restricting kubectl exec/attach to break-glass roles via RBAC, enforcing admission controls to block images or init scripts that unset HISTFILE or link ~/.bash_history to /dev/null, and adding runtime policy to deny rm/truncate of history files and alert on history -c."""
risk_score = 73
rule_id = "cebabc1e-1145-4e39-b04b-34d621ee1e2c"
severity = "high"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Defense Evasion",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
any where host.os.type == "linux" and event.category in ("file", "process") and process.interactive == true and container.id like "?*" and (
(event.category == "file" and event.type == "deletion" and file.name in (".bash_history", ".sh_history", ".zsh_history")) or
(event.category == "process" and event.type == "start" and event.action == "exec" and (
(
(
process.args in (
"rm", "/bin/rm", "/usr/bin/rm", "/usr/local/bin/rm",
"echo", "/bin/echo", "/usr/bin/echo", "/usr/local/bin/echo"
) or
(process.args in ("ln", "/bin/ln", "/usr/bin/ln", "/usr/local/bin/ln") and process.args == "-sf" and process.args == "/dev/null") or
(process.args in ("truncate", "/bin/truncate", "/usr/bin/truncate", "/usr/local/bin/truncate") and process.args == "-s0")
) and process.args like ("*.bash_history*", "*.sh_history*", "*.zsh_history*")
) or
(process.name == "history" and process.args == "-c") or
(process.args == "export" and process.args in ("HISTFILE=/dev/null", "HISTFILESIZE=0")) or
(process.args == "unset" and process.args == "HISTFILE") or
(process.args == "set" and process.args == "history" and process.args == "+o")
)
)
)
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
name = "Defense Evasion"
id = "TA0005"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[rule.threat.technique]]
name = "Indicator Removal"
id = "T1070"
reference = "https://attack.mitre.org/techniques/T1070/"
[[rule.threat.technique.subtechnique]]
name = "Clear Command History"
id = "T1070.003"
reference = "https://attack.mitre.org/techniques/T1070/003/"
rules/integrations/cloud_defend/defense_evasion_interactive_process_execution_from_suspicious_directory.toml
+114
View File
@@ -0,0 +1,114 @@
[metadata]
creation_date = "2026/02/06"
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"
[rule]
author = ["Elastic"]
description = """
This rule detects the execution of an interactive process from a suspicious directory inside a container.
The suspicious directories are /tmp, /dev/shm, /var/tmp, /run, /var/run, /mnt, /media, and /boot.
Adversaries may use these directories to execute malicious code or exfiltrate data.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Suspicious Interactive 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
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.
### Possible investigation steps
- Pivot to Kubernetes API server audit logs to find pod/exec or attach events around the alert and map them to the initiating user, source IP, and service account.
- Determine if the binary or script was introduced post-deploy by listing transient directories in the container and comparing artifacts against the image layers or build manifest.
- Review process lineage and TTY/PTY session details to confirm an interactive shell and identify the parent or invocation method, such as a shell or reverse-shell stager.
- Capture live network activity from the container to spot external callbacks, tunnels, or exfil destinations, and isolate the pod if suspicious connections are present.
- Assess the pod’s service account, RBAC permissions, and security context for elevated privileges or host namespace access to gauge impact and prioritize containment.
### False positive analysis
- An engineer performing authorized troubleshooting opens an interactive shell and runs a known diagnostic binary staged in /tmp or /dev/shm to avoid altering the image, leading to an interactive exec from a transient path.
- A mounted volume under /mnt or /media holds legitimate utilities, and an authorized user starts one interactively for maintenance or configuration, triggering the rule despite expected operations.
### Response and remediation
- Immediately contain by applying a deny-all egress NetworkPolicy to the affected pod, killing the interactive process whose executable resides under /tmp, /dev/shm, /var/tmp, /run, /var/run, /mnt, /media, or /boot, and blocking further kubectl exec/attach to it.
- Eradicate by terminating and redeploying the pod from a trusted image, scanning and cleaning any mounted volumes under /mnt or /media, and removing staged binaries or scripts found in transient paths like /tmp, /var/tmp, /run, and /var/run.
- Recover by rotating credentials the pod could access (service account token, mounted secrets, API keys), validating application behavior post-redeploy, and restoring network access only to approved destinations.
- Escalate to incident response immediately if you observe a shell or tunneling tool launched from /tmp or /dev/shm, evidence of exfiltration via outbound connections, privileged or hostPID/hostNetwork settings, or writes touching /boot.
- Harden by disabling kubectl exec for production workloads, enforcing readOnlyRootFilesystem with seccomp and AppArmor, mounting /tmp and /dev/shm with noexec,nodev,nosuid, and using admission policy to allowlist executable paths and deny interactive TTYs."""
risk_score = 73
rule_id = "279e272a-91d9-4780-878c-bfcac76e6e31"
severity = "high"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Defense Evasion",
"Tactic: Execution",
"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.executable like (
"/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/*", "/var/run/*", "/mnt/*", "/media/*", "/boot/*"
) and container.id like "?*"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
name = "Defense Evasion"
id = "TA0005"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[rule.threat.technique]]
name = "Reflective Code Loading"
id = "T1620"
reference = "https://attack.mitre.org/techniques/T1620/"
[[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/"
rules/integrations/cloud_defend/defense_evasion_potential_evasion_via_encoded_payload.toml
+123
View File
@@ -0,0 +1,123 @@
[metadata]
creation_date = "2026/02/06"
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"
[rule]
author = ["Elastic"]
description = """
This rule detects the interactive execution of potential defense evasion techniques via encoded payloads
inside a container. Attackers may use base64 encoding/decoding to obfuscate data, such as command and
control traffic or payloads, to evade detection by host- or network-based security controls.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Encoded Payload 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 Encoded Payload Detected via Defend for Containers
This rule flags interactive runs of common encoding/decoding tools and language one-liners inside Linux containers, a frequent way to hide commands or payloads from basic inspection. It matters because obfuscated content can bypass simple detections and enable in-container execution, staging, or covert command-and-control. A typical pattern is an attacker exec’ing into a running container, pasting a base64 blob, decoding it with base64/openssl or a Python/Perl/Ruby snippet, then piping the result into sh or writing a dropper for immediate execution.
### Possible investigation steps
- Identify the decoded artifact by correlating the decode process with adjacent interactive commands (pipes, redirects, file writes) and recover the resulting plaintext/script from file system, shell history, or captured stdout/stderr.
- Determine what executed next by building a short timeline of subsequent process starts in the same container/session (e.g., sh/bash, curl/wget, chmod, execution of newly created files) and assess whether the decoded content was run.
- Validate whether the interactive session is expected by reviewing who initiated the container exec/attach (user, source IP, kube-apiserver/audit logs) and whether it aligns with approved operational access patterns.
- Check for persistence or lateral movement attempts by looking for creation/modification of cron entries, new users/SSH keys, altered entrypoints, mounted secrets access, or unexpected network connections from the container after the decode.
- Contain and scope by snapshotting the container image/filesystem for forensic preservation, then searching other workloads/namespaces for the same encoded blob, hash, or command pattern to identify spread or repeated operator activity.
### False positive analysis
- A developer or SRE may interactively exec into a container to quickly decode base64/hex configuration snippets, certificates, or API responses (e.g., Kubernetes secrets) for troubleshooting, which matches the rule’s interactive decode patterns.
- An on-call engineer may run interactive one-liners in python/perl/ruby or use openssl/xxd inside a container to validate encodings, inspect binary payloads, or test application parsing behavior during incident triage, creating benign decode activity that resembles obfuscation.
### Response and remediation
- Quarantine the affected workload by isolating the pod/container from the network and preventing further interactive exec/attach (cordon the node if needed) while preserving the running container state for evidence.
- Capture and retain forensic artifacts including the decoded output/script, any newly written files, shell history and stdout/stderr from the interactive session, and a snapshot of the container filesystem/image for offline analysis and hash extraction.
- Eradicate by deleting and redeploying the pod from a known-good image, removing any malicious files or altered entrypoints/configmaps/secrets discovered during review, and rotating any credentials or tokens that the container could access.
- Escalate immediately to IR/Cloud Security if the decoded content triggers execution (piped into sh/bash), pulls remote payloads (curl/wget), or results in outbound connections to unknown hosts, or if similar decode activity is found across multiple namespaces.
- Harden by enforcing RBAC to restrict exec/attach, enabling admission controls to block privileged pods and risky host mounts, reducing image toolsets (remove base64/openssl/xxd where feasible), and adding egress controls to limit outbound traffic to approved destinations."""
risk_score = 47
rule_id = "227cf26a-88d1-4bcb-bf4c-925e5875abcf"
severity = "medium"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Defense Evasion",
"Tactic: Execution",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.interactive == true and (
(process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and process.args like~ "*-*d*") or
(process.name == "xxd" and process.args like~ ("-*r*", "-*p*")) or
(process.name == "openssl" and process.args == "enc" and process.args in ("-d", "-base64", "-a")) or
(process.name like "python*" and (
(process.args == "base64" and process.args in ("-d", "-u", "-t")) or
(process.args == "-c" and process.args like "*base64*" and process.args like "*b64decode*")
)) or
(process.name like "perl*" and process.args like "*decode_base64*") or
(process.name like "ruby*" and process.args == "-e" and process.args like "*Base64.decode64*")
) and container.id like "?*"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"
[[rule.threat.technique]]
id = "T1140"
name = "Deobfuscate/Decode Files or Information"
reference = "https://attack.mitre.org/techniques/T1140/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[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]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[rule.threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"
[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
rules/integrations/cloud_defend/discovery_kubelet_certificate_file_access.toml
+18 -4
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/02"
updated_date = "2026/02/06"
[rule]
author = ["Elastic"]
@@ -16,7 +16,7 @@ to gain access to the cluster. There is a current limitation in the defend for c
file open events from being logged for file open events without write intent.
"""
from = "now-6m"
index = ["logs-cloud_defend.file*"]
index = ["logs-cloud_defend.file*", "logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
@@ -39,8 +39,22 @@ tags = [
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "change" and event.action == "open" and
file.path like "/var/lib/kubelet/pki/*" and process.interactive == true and container.id like "?*"
any where host.os.type == "linux" and process.interactive == true and container.id like "*" and (
(event.category == "file" and event.type == "change" and event.action == "open" and file.path like "/var/lib/kubelet/pki/*") or
(event.category == "process" and event.type == "start" and event.action == "exec" and
(
process.name in ("cat", "head", "tail", "more", "less", "sed", "awk") or
process.args in (
"cat", "/bin/cat", "/usr/bin/cat", "/usr/local/bin/cat",
"head", "/bin/head", "/usr/bin/head", "/usr/local/bin/head",
"tail", "/bin/tail", "/usr/bin/tail", "/usr/local/bin/tail",
"more", "/bin/more", "/usr/bin/more", "/usr/local/bin/more",
"less", "/bin/less", "/usr/bin/less", "/usr/local/bin/less",
"sed", "/bin/sed", "/usr/bin/sed", "/usr/local/bin/sed",
"awk", "/bin/awk", "/usr/bin/awk", "/usr/local/bin/awk"
)
) and process.args like "*/var/lib/kubelet/pki/*")
)
'''
[[rule.threat]]
rules/integrations/cloud_defend/discovery_kubelet_pod_discovery_via_builtin_utilities.toml
+97
View File
@@ -0,0 +1,97 @@
[metadata]
creation_date = "2026/02/06"
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"
[rule]
author = ["Elastic"]
description = """
This rule detects the use of built-in utilities to discover running pods on a Kubernetes cluster. The utilities used
are du, nice, find, locate, and ls. These utilities are commonly used to discover running pods on a Kubernetes cluster.
The "/var/lib/kubelet/pods" directory is the default location for Kubelet pod information.
"""
from = "now-6m"
index = ["logs-cloud_defend.file*", "logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Kubelet Pod Discovery 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 Kubelet Pod Discovery Detected via Defend for Containers
This rule detects interactive use of common Linux utilities (ls, find, du, locate, nice) repeatedly targeting the Kubelet pods directory, including direct access to `/var/lib/kubelet/pods/*`. This matters because enumerating that path reveals pod IDs, volumes, and runtime artifacts that can accelerate container and cluster discovery. A typical pattern is an attacker in a compromised container running `ls /var/lib/kubelet/pods/` followed by `find /var/lib/kubelet/pods -maxdepth 2` to map workloads and hunt for mounted secrets.
### Possible investigation steps
- Identify the originating workload (pod/namespace/node) and how the interactive session was obtained (e.g., kubectl exec, SSH to node, or container runtime attach) to determine whether access was expected.
- Review the container’s security context and mounts to confirm whether `/var/lib/kubelet` was exposed via hostPath/privileged settings and assess whether this indicates a node breakout risk.
- Correlate the discovery activity with nearby events for follow-on actions such as reading service account tokens, kubeconfig files, or secrets/volumes under pod directories that would indicate credential harvesting.
- Validate the actor by mapping the involved user/service account to recent Kubernetes API audit activity and RBAC permissions to determine whether the behavior aligns with normal administration.
- Check for persistence or lateral movement attempts from the same container or node (new processes, outbound connections, package/tool downloads, or cron/systemd changes) to scope impact beyond discovery.
### False positive analysis
- An interactive troubleshooting session by a cluster administrator inside a privileged/host-mounted container uses `ls`, `find`, or `du` against `/var/lib/kubelet/pods/*` multiple times to confirm pod volume mounts, disk usage, or pod UID-to-workload mapping during an incident or maintenance window.
- An engineer running an interactive shell on the node or in a hostPID/hostPath-enabled container repeatedly inspects `/var/lib/kubelet/pods/*` with built-in utilities to validate kubelet behavior (e.g., orphaned pod directories, cleanup after pod churn, or verifying that expected pods are present) as part of routine operational checks.
### Response and remediation
- Contain by terminating the interactive session and isolating the originating pod (scale to zero or delete) and, if the container had hostPath access to `/var/lib/kubelet` or was privileged/hostPID, cordon and drain the node to stop further inspection of `/var/lib/kubelet/pods/*`.
- Scope and eradicate by reviewing recent commands and file reads under `/var/lib/kubelet/pods/` for access to mounted secrets, service account tokens, kubeconfig files, or pod volume contents, and remove any dropped tools/scripts or unauthorized cron/systemd changes on the affected node.
- Recover by rotating potentially exposed Kubernetes credentials (service account tokens, kubeconfigs, cloud/IAM keys) used by the affected workload and redeploying the application from a known-good image after validating no unexpected containers, DaemonSets, or mounts remain.
- Escalate to incident response immediately if you confirm reads of token/secret material within pod directories, discovery occurs from a privileged or host-mounted container, or you observe follow-on actions such as outbound connections, new binaries, or attempts to exec into additional pods/namespaces.
- Harden by eliminating unnecessary hostPath mounts to `/var/lib/kubelet` (and other node paths), enforcing non-root and read-only root filesystems, disabling interactive shells in production where feasible, and applying admission controls to block privileged/hostPID containers and restrict debug tooling to approved break-glass workflows."""
references = [
"https://heilancoos.github.io/research/2025/12/16/kubernetes.html#kubelet-api",
"https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster",
"https://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/"
]
risk_score = 21
rule_id = "f596175f-b8fd-43ac-b9e9-ea2a96bb55d8"
severity = "low"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Discovery",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence by container.id, user.id with maxspan=5s
[any where host.os.type == "linux" and event.category in ("file", "process") and process.interactive == true and container.id like "*" and (
(event.category == "file" and event.type == "change" and event.action == "open" and file.path like "/var/lib/kubelet/pods/*") or
(event.category == "process" and event.type == "start" and event.action == "exec" and (
(process.name in ("du", "nice", "find", "locate", "ls")) or
(process.args in (
"du", "/bin/du", "/usr/bin/du", "/usr/local/bin/du",
"nice", "/bin/nice", "/usr/bin/nice", "/usr/local/bin/nice",
"find", "/bin/find", "/usr/bin/find", "/usr/local/bin/find",
"locate", "/bin/locate", "/usr/bin/locate", "/usr/local/bin/locate",
"ls", "/bin/ls", "/usr/bin/ls", "/usr/local/bin/ls"
))
) and process.args like "*/var/lib/kubelet/pods/*")
)] with runs=5
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1613"
name = "Container and Resource Discovery"
reference = "https://attack.mitre.org/techniques/T1613/"
[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"
rules/integrations/cloud_defend/discovery_privilege_boundary_enumeration_from_interactive_process.toml
+109
View File
@@ -0,0 +1,109 @@
[metadata]
creation_date = "2026/02/06"
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"
[rule]
author = ["Elastic"]
description = """
This rule detects the execution of the "id", "whoami", "capsh", "getcap", and "lsns" commands inside a container.
These commands are used to enumerate the privilege boundary of the container, which can be used by an adversary to
gain information about the container and the services running inside it.
"""
false_positives = [
"""
There is a potential for false positives if the "id", "whoami", "capsh", "getcap", or "lsns" commands are used for legitimate purposes,
such as debugging or troubleshooting. For example, an operator may use the "id" command to verify the identity of the current user, or
the "whoami" command to verify the current user. It is important to investigate any alerts generated by this rule to determine if they
are indicative of malicious activity or part of legitimate container activity.
""",
]
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Interactive Privilege Boundary Enumeration 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 Interactive Privilege Boundary Enumeration Detected via Defend for Containers
This detects an interactive session inside a Linux container running common identity and capability discovery tools (id, whoami, capsh, getcap, lsns) to map what privileges and namespace isolation the container actually has. This matters because attackers use this early in an intrusion to judge whether they can escalate within the container or pivot toward a host escape. A typical pattern is an attacker landing a shell through a vulnerable web service and immediately checking user context and Linux capabilities before attempting privilege abuse.
### Possible investigation steps
- Identify the impacted workload (pod/task/service), node, and cluster context, then correlate with Kubernetes audit logs or container runtime events to determine whether the interactive session originated from an operator action (e.g., exec) or an unexpected access path.
- Review surrounding process activity from the same container to find follow-on commands indicating escalation or lateral movement attempts, such as spawning shells, modifying permissions, inspecting mounts, or downloading tooling.
- Attribute the session to an identity by mapping the initiating user/service account and source to recent admin/CI activity, and flag anomalies like first-time access, unusual geolocation, or access outside change windows.
- Evaluate escape and blast-radius risk by confirming the container’s effective privileges and isolation, including privileged mode, added capabilities, host namespace sharing, and sensitive host mounts or sockets.
- If activity is suspicious, preserve evidence (processes, mounts, network connections, recent file changes) and consider isolating the pod/node or rotating credentials before remediation actions that would destroy artifacts.
### False positive analysis
- A platform engineer or developer attaches an interactive shell to a running container for routine troubleshooting and runs `id`/`whoami` to confirm the effective user and group context before making configuration changes.
- During a planned hardening or validation task, an operator interactively inspects container capability and namespace settings using `capsh`/`getcap`/`lsns` to verify the workload is running with the intended privilege boundaries.
### Response and remediation
- Contain the incident by terminating the interactive session and quarantining the affected pod/container (or cordoning the node) while preserving container filesystem, running processes, mounts, and active network connections for evidence.
- Eradicate by removing any unauthorized shells, binaries, or scripts dropped during the session, revoking/rotating credentials used to access the container (service account tokens, registry creds, app secrets), and rebuilding/redeploying the workload from a known-good image.
- Recover by restoring the service with clean images and validated configuration, then verify no persistence remains by checking for unexpected running processes, modified entrypoints, altered file permissions, or new cron/systemd artifacts within the container image/build context.
- Escalate to the incident response/on-call security team immediately if the container is privileged, has hostPath mounts or access to the container runtime socket, shares host namespaces, or if follow-on behavior appears (e.g., attempts to access `/proc/1`, `/var/run/docker.sock`, `nsenter`, or outbound downloads).
- Harden by disabling or tightly restricting interactive exec/attach for production workloads, enforcing least-privilege securityContext (drop capabilities, runAsNonRoot, read-only root filesystem), and preventing host mounts/sockets via admission controls and policy (Pod Security Admission/Gatekeeper/Kyverno).
- Improve detection and prevention by alerting on interactive shells and suspicious tooling in containers, adding egress allowlists to limit tool download/pivoting, and ensuring audit logging is enabled for Kubernetes exec events and container runtime actions."""
risk_score = 21
rule_id = "737626a2-4dca-4195-8ecd-68ef96fd1bad"
severity = "low"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Discovery",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.interactive == true and (
(process.name in ("id", "whoami", "capsh", "getcap", "lsns")) or
(process.args in (
"id", "/bin/id", "/usr/bin/id", "/usr/local/bin/id",
"whoami", "/bin/whoami", "/usr/bin/whoami", "/usr/local/bin/whoami",
"capsh", "/bin/capsh", "/usr/bin/capsh", "/usr/local/bin/capsh",
"getcap", "/bin/getcap", "/usr/bin/getcap", "/usr/local/bin/getcap",
"lsns", "/bin/lsns", "/usr/bin/lsns", "/usr/local/bin/lsns"
) and
/* default exclusion list to not FP on default multi-process commands */
not process.args in (
"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"
)
)
) and container.id like "?*"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1613"
name = "Container and Resource Discovery"
reference = "https://attack.mitre.org/techniques/T1613/"
[[rule.threat.technique]]
id = "T1082"
name = "System Information Discovery"
reference = "https://attack.mitre.org/techniques/T1082/"
[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"
rules/integrations/cloud_defend/discovery_service_account_namespace_read.toml
+23 -5
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/01/27"
updated_date = "2026/02/06"
[rule]
author = ["Elastic"]
@@ -21,7 +21,7 @@ false_positives = [
""",
]
from = "now-6m"
index = ["logs-cloud_defend.file*"]
index = ["logs-cloud_defend.file*", "logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
@@ -70,9 +70,27 @@ tags = [
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "change" and event.action == "open" and
file.path == "/var/run/secrets/kubernetes.io/serviceaccount/namespace" and
process.interactive == true and container.id like "*"
any where host.os.type == "linux" and process.interactive == true and container.id like "*" and (
(event.category == "file" and event.type == "change" and event.action == "open" and
file.path in (
"/var/run/secrets/kubernetes.io/serviceaccount/namespace",
"/run/secrets/kubernetes.io/serviceaccount/namespace"
)) or
(event.category == "process" and event.type == "start" and event.action == "exec" and
(
process.name in ("cat", "head", "tail", "more", "less", "sed", "awk") or
process.args in (
"cat", "/bin/cat", "/usr/bin/cat", "/usr/local/bin/cat",
"head", "/bin/head", "/usr/bin/head", "/usr/local/bin/head",
"tail", "/bin/tail", "/usr/bin/tail", "/usr/local/bin/tail",
"more", "/bin/more", "/usr/bin/more", "/usr/local/bin/more",
"less", "/bin/less", "/usr/bin/less", "/usr/local/bin/less",
"sed", "/bin/sed", "/usr/bin/sed", "/usr/local/bin/sed",
"awk", "/bin/awk", "/usr/bin/awk", "/usr/local/bin/awk"
)
) and process.args like "*/run/secrets/kubernetes.io/serviceaccount/namespace*"
)
)
'''
[[rule.threat]]
rules/integrations/cloud_defend/execution_interactive_file_creation_followed_by_execution.toml
+103
View File
@@ -0,0 +1,103 @@
[metadata]
creation_date = "2026/02/06"
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"
[rule]
author = ["Elastic"]
description = """
This rule detects when an interactive process creates a file inside of a running container, followed by its execution.
This could indicate a potential container breakout attempt, an attacker's attempt to gain unauthorized access to the
underlying host, or to evade detection by security controls.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*", "logs-cloud_defend.file*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "File Creation and 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 File Creation and Execution Detected via Defend for Containers
This detects an interactive session inside a running Linux container creating a new file and then executing it moments later, a pattern that often signals hands-on intrusion rather than routine automation. Attackers commonly use an `exec` shell into a pod/container to drop a small script or ELF payload (for reverse shell, credential theft, or host discovery) and run it immediately to establish control or stage a breakout attempt.
### Possible investigation steps
- Correlate the alert time with container runtime and Kubernetes audit logs to identify who started the interactive session (user/service account), from where (source IP), and via what mechanism (kubectl exec/attach, docker exec).
- Acquire the newly created file from the container filesystem, record hash/size/permissions, and analyze its contents to determine whether it is a script, ELF payload, or staged dropper.
- Reconstruct the execution chain by reviewing the process tree and interactive shell artifacts (TTY, environment, shell history) to understand the operator’s commands before and after running the file.
- Inspect the container’s network activity immediately following execution (DNS lookups, new outbound connections, unusual ports/destinations) to confirm or rule out command-and-control or payload download behavior.
- Validate whether the activity indicates privilege escalation or breakout by checking the node and container for access to sensitive host interfaces (e.g., docker.sock, hostPath mounts, /proc probing) and contain the workload if present.
### False positive analysis
- A developer or SRE uses an interactive shell in the container to create or modify a script/binary for debugging (e.g., `cat`/heredoc/vim writing to `/tmp` or the app directory) and then immediately runs it to reproduce an issue or validate a fix.
- An operator performs interactive break-glass maintenance by manually writing a short helper script (log collection, configuration validation, one-off remediation) inside the container and executing it right after creation to restore service during an incident.
### Response and remediation
- Immediately isolate the affected workload by cordoning and draining the node or applying a deny-all network policy to the pod/namespace, then terminate the interactive session and stop the container to prevent further execution.
- Preserve evidence by snapshotting the container filesystem and collecting the created file and any adjacent artifacts (shell history, temp directories, downloaded tools), then compute hashes and submit the file for malware analysis.
- Eradicate by deleting the compromised pod/container and redeploying from a known-good image, rotating any credentials that may have been exposed in the container environment, and blocking the observed outbound destinations if C2 behavior is present.
- Escalate to incident response immediately if the executed file attempts host interaction (e.g., accesses docker.sock, /proc, hostPath mounts) or if you observe new privileged containers, node-level processes, or lateral movement to other pods/namespaces.
- Harden by restricting interactive exec/attach to a small admin group with MFA, enforcing Pod Security/Admission policies to disallow privileged/host mounts, and enabling runtime controls to block execution from writable paths like /tmp and /dev/shm."""
risk_score = 47
rule_id = "b799720e-40d0-4dd6-9c9c-4f193a6ed643"
severity = "medium"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Execution",
"Tactic: Command and Control",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence by container.id, user.id with maxspan=3s
[file where host.os.type == "linux" and event.type == "creation" and process.interactive == true and container.id like "?*" and
file.path like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*") and
not process.name in ("apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf", "apk", "pacman", "rpm", "dpkg")] by file.path
[process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.interactive == true and container.id like "?*"] by process.executable
'''
[[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/"
rules/integrations/cloud_defend/execution_interactive_file_creation_in_system_binary_locations.toml
+115
View File
@@ -0,0 +1,115 @@
[metadata]
creation_date = "2026/02/06"
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"
[rule]
author = ["Elastic"]
description = """
This rule detects when an interactive process creates a file inside of a system binary location, inside of a running
container. The system binary locations are /etc, /root, /bin, /usr/bin, /usr/local/bin, and /entrypoint. Adversaries
may use these locations to create files that can be used to execute commands on the underlying host, or to evade
detection by security controls.
"""
from = "now-6m"
index = ["logs-cloud_defend.file*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "System Path File Creation and 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 System Path File Creation and Execution Detected via Defend for Containers
This detects an interactive session in a running Linux container creating new files under system binary paths like /etc, /root, /bin, /usr/bin, /usr/local/bin, or /entrypoint, which often signals an attempt to tamper with execution flow or hide tooling. Attackers commonly gain a shell, then use curl/wget (or a busybox variant) from a writable staging area to drop a new executable into /usr/local/bin or overwrite an entrypoint script to ensure their code runs on start.
### Possible investigation steps
- Capture the created file’s metadata (owner, permissions, timestamps) and contents/hash, then determine whether it is an executable/script or a modification to startup/auth/config behavior.
- Compare the file and its path against the container image baseline (layer diff) to confirm it was introduced at runtime and identify the interactive command that created it.
- Review the interactive session context (TTY, user, entry method) and surrounding command activity to assess intent and whether secrets or credentials were accessed.
- Pivot to related activity from the same session such as outbound connections, additional downloads to writable staging areas, or subsequent execution of the new file to gauge impact and scope.
- Check for persistence or host-impact setup by inspecting entrypoint/service definitions, PATH hijacks, mounted host paths, and any new cron/systemd/profile changes within the container.
### False positive analysis
- A container administrator troubleshooting interactively may use curl/wget (including via busybox wget) to fetch configuration or helper scripts and write them into /etc, /root, or /entrypoint to quickly test startup or runtime behavior changes.
- An interactive maintenance session may execute a script staged in /tmp or /dev/shm that drops a small wrapper binary or symlink into /usr/local/bin or /usr/bin to temporarily add debugging utilities or adjust PATH-resolved command behavior during incident response.
### Response and remediation
- Isolate the impacted container by removing it from service and blocking its egress, then preserve the container filesystem (or take a snapshot) so the created artifacts under /etc, /root, /bin, /usr/bin, /usr/local/bin, or /entrypoint can be analyzed.
- Identify and remove the dropped or modified file(s) and any related persistence (e.g., altered /entrypoint script, PATH-hijacking binaries, modified shell profiles), then stop any processes launched from writable staging paths like /tmp, /dev/shm, /var/tmp, /run, /var/run, or /mnt.
- Redeploy the workload from a known-good image and verified configuration (including entrypoint and mounted volumes), rotate any secrets or tokens that could have been accessed in the interactive session, and validate the new pod/container does not recreate files in system binary locations.
- Escalate immediately to the incident response team if the created file is executable, replaces an entrypoint, initiates outbound downloads or connections, or if multiple containers show similar drops in system binary paths suggesting broader compromise.
- Harden by enforcing non-root, read-only root filesystem, and disallowing interactive exec into production containers, then restrict outbound network access and block write access to system binary locations via security policies and runtime controls."""
risk_score = 47
rule_id = "05a50000-9886-4695-ad33-3f990dc142e2"
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 = '''
file where host.os.type == "linux" and event.type == "creation" and process.interactive == true and
file.path like (
"/etc/*", "/root/*", "/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/entrypoint*"
) and (
process.name like ("wget", "curl") or
(process.name == "busybox" and process.args == "wget") or
process.executable like ("/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/*", "/var/run/*", "/mnt/*")
) and container.id like "?*"
'''
[[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/execution_suspicious_interactive_interpreter_command_execution.toml
+158
View File
@@ -0,0 +1,158 @@
[metadata]
creation_date = "2026/02/06"
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"
[rule]
author = ["Elastic"]
description = """
This rule detects when an interactive process executes a suspicious interpreter command inside a container.
These commands are commonly used by attackers to execute malicious code or exfiltrate data.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Suspicious Interpreter 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 Interpreter Execution Detected via Defend for Containers
This detection flags an interactive session inside a Linux container launching Perl, PHP, Lua, Python, or Ruby with inline code execution and high-risk functions commonly used for spawning processes, decoding payloads, or opening network connections. It matters because attackers often abuse these one-liners to run malware or exfiltrate data without dropping files, blending into normal admin shell activity. A common pattern is a `python -c` one-liner that base64-decodes a second-stage script and executes it, then initiates an outbound socket for command-and-control.
### Possible investigation steps
- Review the full inline interpreter code and decode any embedded payloads (e.g., base64/zlib/rot13) to determine its intent, IOCs, and whether it fetches or launches a second stage.
- Identify the originating interactive session and actor by correlating the container’s TTY/exec session metadata with orchestrator audit logs (e.g., Kubernetes exec/attach) to determine who/what initiated it and from where.
- Assess whether the container image, entrypoint, and recent deployment changes are expected for this workload, and check for signs of container escape attempts or host access (mounted sockets, privileged flags, hostPath mounts).
- Pivot from the alert time to related activity in the same container for child processes, file writes, cron/systemd modifications, and persistence artifacts that indicate follow-on actions beyond a one-liner.
- Check for unexpected outbound connections or DNS lookups from the container around execution time, and validate any contacted domains/IPs against threat intel and known-good service dependencies.
### False positive analysis
- A developer or SRE opens an interactive shell in the container to troubleshoot and runs a quick inline one-liner (e.g., `python -c`/`php -r`/`ruby -e`) to test network connectivity, decode/transform a string (base64/zlib), or call a subprocess for diagnostics, which matches the suspicious function patterns.
- During an interactive container exec session, an administrator performs emergency maintenance or incident response actions using an interpreter one-liner to fetch configuration/state, invoke system utilities, or validate service behavior (e.g., `socket.connect`, `os.system`, `curl_exec`, `IO.popen`), producing a benign but high-risk inline command signature.
### Response and remediation
- Quarantine the affected workload by scaling it to zero or cordoning the node and blocking egress for the namespace while preserving the pod and container filesystem for evidence capture.
- Terminate the interactive session and kill the interpreter process tree, then collect the full command line, any decoded inline payload, and any retrieved scripts or binaries from the container for malware analysis.
- Hunt and remove follow-on artifacts by searching the container for newly created executables, modified startup scripts, cron entries, webshells, or injected environment variables, and redeploy from a known-good image rather than “cleaning” the live container.
- Rotate credentials and secrets exposed to the container (service account tokens, API keys, database passwords) and invalidate active sessions if the one-liner performed network calls, decoded payloads, or spawned subprocesses.
- Escalate to the incident response team if the inline code includes base64/zlib decoding, establishes a socket connection, downloads a second stage, or any similar activity is observed across multiple pods/namespaces.
- Harden against recurrence by restricting `exec/attach` access, enforcing least-privilege pod security (no privileged, no host mounts, read-only root filesystem), and using egress allowlists plus image signing/admission controls to block unauthorized images and interactive debug containers."""
risk_score = 47
rule_id = "cd24c340-b778-44bd-ab69-2f739bd70ce1"
severity = "medium"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Execution",
"Tactic: Command and Control",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.interactive == true and
process.parent.executable != null and (
(
process.executable like ("/bin/perl*", "/usr/bin/perl*", "/usr/local/bin/perl*") and
process.args == "-e" and process.args like~ (
"*system(*", "*exec(*", "*IO.popen(*", "*Open3.popen3(*", "*spawn(*", "*eval(*",
"*load(*IO::*", "*load(*Marshal*", "*load(*Fiddle*", "*load(*Zlib*", "*load(*Base64*",
"*zlib.inflate(*", "*zlib.deflate(*", "*zlib.decompress(*", "*zlib.uncompress(*", "*zlib.compress(*",
"*Marshal.load(*", "*Fiddle.dlopen(*", "*Fiddle::Function.new(*", "*base64*", "*zlib*",
"*net/http*", "*socket.new*", "*open-uri*", "*pack(*"
)
) or
process.executable like ("/bin/php*", "/usr/bin/php*", "/usr/local/bin/php*") and
process.args == "-r" and process.args like~ (
"*exec(*", "*system(*", "*shell_exec(*", "*passthru(*", "*proc_open(*", "*pcntl_exec(*", "*popen(*",
"*eval(*", "*assert(*", "*create_function(*", "*preg_replace(*e*", "*include(*", "*require(*",
"*base64_decode(*", "*gzinflate(*", "*gzuncompress(*", "*str_rot13(*", "*urldecode(*", "*chr(*",
"*ord(*", "*strrev(*", "*strtr(*", "*pack(*", "*unpack(*", "*curl_exec(*", "*curl_multi_exec(*",
"*file_get_contents(*", "*fopen(*", "*fsockopen(*", "*pfsockopen(*", "*stream_socket_client(*",
"*socket_create(*", "*socket_connect(*", "*socket_write(*", "*socket_read(*", "*mail(*",
"*move_uploaded_file(*"
) or
process.executable like ("/bin/lua*", "/usr/bin/lua*", "/usr/local/bin/lua*") and
process.args == "-e" and process.args like~ (
"*os.execute(*", "*io.popen(*", "*load(*", "*loadstring(*", "*require(*", "*dofile(*",
"*package.loadlib(*", "*base64.decode(*", "*base64.encode(*", "*zlib.inflate(*",
"*zlib.deflate(*", "*zlib.decompress(*", "*zlib.compress(*", "*socket.bind(*",
"*socket.connect(*", "*socket.receive(*", "*socket.send(*", "*socket.tcp(*",
"*socket.udp(*", "*socket.listen(*", "*socket.accept(*", "*net.http.request(*",
"*net.http.get(*", "*net.http.post(*", "*http.request(*", "*http.get(*", "*http.post(*"
) or
process.executable like ("/bin/python*", "/usr/bin/python*", "/usr/local/bin/python*") and
process.args == "-c" and process.args like~ (
"*exec(*base64*", "*exec(*decode(*", "*exec(*marshal*", "*exec(*pickle*", "*eval(*exec(*",
"*eval(*", "*subprocess.popen(*", "*subprocess.run(*", "*pickle.loads(*", "*marshal.loads(*",
"*binascii*", "*os.system(*", "*os.popen(*", "*pty.*", "*dup2*", "*fileno()*", "*connect(*",
"*bind(*", "*execve(*", "*base64*", "*base32*", "*base16*", "*base85*", "*decode(*",
"*zlib.*", "*[::-1]*", "*socket.socket(*", "*socket.connect(*", "*socket.bind(*"
) or
process.executable like ("/bin/ruby*", "/usr/bin/ruby*", "/usr/local/bin/ruby*") and
process.args like "-e*" and process.args like~ (
"*system(*", "*exec(*", "*IO.popen(*", "*Open3.popen3(*", "*spawn(*", "*eval(*", "*load(*",
"*Marshal.load(*", "*Fiddle.dlopen(*", "*Fiddle::Function.new(*", "*base64*", "*zlib*",
"*net/http*", "*socket*", "*open-uri*", "*pack(*", "*unpack(*"
)
) and container.id like "?*"
'''
[[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]]
name = "Unix Shell"
id = "T1059.004"
reference = "https://attack.mitre.org/techniques/T1059/004/"
[[rule.threat.technique.subtechnique]]
name = "Python"
id = "T1059.006"
reference = "https://attack.mitre.org/techniques/T1059/006/"
[[rule.threat.technique.subtechnique]]
name = "Lua"
id = "T1059.011"
reference = "https://attack.mitre.org/techniques/T1059/011/"
[[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.technique.subtechnique]]
name = "Web Protocols"
id = "T1071.001"
reference = "https://attack.mitre.org/techniques/T1071/001/"
rules/integrations/cloud_defend/execution_tool_installation.toml
+5 -4
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/01/27"
updated_date = "2026/02/06"
[rule]
author = ["Elastic"]
@@ -70,7 +70,7 @@ tags = [
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.interactive == true and (
(process.name in ("apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf") and process.args == "install") or
(process.name == "apk" and process.args == "add") or
(process.name == "pacman" and process.args like "-*S*") or
@@ -78,8 +78,9 @@ process where host.os.type == "linux" and event.type == "start" and event.action
) and process.args like (
"curl", "wget", "socat", "busybox", "openssl", "torsocks",
"netcat", "netcat-openbsd", "netcat-traditional", "ncat", "tor",
"python*", "perl", "node", "nodejs", "ruby", "lua"
) and process.interactive == true and container.id like "*"
"python*", "perl", "node", "nodejs", "ruby", "lua", "bash", "sh",
"dash", "zsh", "fish", "tcsh", "csh", "ksh"
) and container.id like "?*"
'''
[[rule.threat]]
rules/integrations/cloud_defend/persistence_suspicious_webserver_child_process_execution.toml
+142
View File
@@ -0,0 +1,142 @@
[metadata]
creation_date = "2026/02/06"
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"
[rule]
author = ["Elastic"]
description = """
This rule detects the exploitation of a web server through the execution of a suspicious process by common web server
user accounts. Attackers may upload a web shell to a web server to maintain access to the system.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Web Server Child Shell Spawn 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 Web Server Child Shell Spawn Detected via Defend for Containers
This rule flags Linux container activity where a web server (or typical web-service account) spawns an interactive shell to run a command string, a strong indicator of web app exploitation rather than normal request handling. It matters because this pattern commonly marks initial foothold and post-exploitation execution that can lead to persistence and lateral movement from the service container. A typical attacker flow drops a web shell or abuses RCE to launch `sh -c` and pull or run a secondary payload (e.g., reverse shell).
### Possible investigation steps
- Capture the full executed command line and decode/normalize any obfuscation (base64, hex, URL encoding) to determine the operator intent and any payload retrieval or reverse-shell behavior.
- Correlate the execution timestamp with web access/error logs and ingress/WAF events to identify the triggering request path, parameters, and source IP/user-agent indicating RCE or web-shell invocation.
- Inspect recent file and permission changes in the container’s application and web directories (including temp and upload paths) to identify newly dropped scripts/binaries, cron entries, or modified server configs.
- Review container and orchestration context (image tag/digest, recent deploys, exec sessions, and Kubernetes events) to determine whether the activity aligns with a legitimate rollout or represents in-container compromise.
- Check network telemetry for the container around the event for suspicious outbound connections, DNS lookups, or downloads, then pivot to any contacted hosts to assess command-and-control or staging infrastructure.
### False positive analysis
- A web application or server-side script running under the web-service account legitimately invokes `sh -c` (e.g., to run maintenance tasks like log rotation, cache rebuilds, file conversions, or templating/asset compilation) from a web directory such as `/var/www/*`, causing the web server to spawn a shell child process.
- During container startup or a deployment/health-check routine, the web server process launches a shell via `sh -c` to perform initialization (e.g., environment substitution, dynamic configuration generation, permission fixes, or calling bundled helper scripts), which can resemble exploitation when the parent is a web server and the child is a shell.
### Response and remediation
- Immediately isolate the affected container/pod from inbound and outbound traffic (quarantine namespace/security group or apply a deny-all NetworkPolicy) and stop the workload to prevent further `sh -c` execution and potential C2.
- Preserve evidence by exporting the container filesystem and logs (web access/error logs, application logs, and process output) and capture the exact shell command string and any downloaded payloads or newly created files in web roots, temp, and upload directories.
- Eradicate by removing any identified web shells/backdoors and reverting unauthorized changes, then rebuild and redeploy the service from a known-good image digest while rotating secrets exposed to the container (service tokens, database creds, API keys).
- Recover by validating application integrity and behavior post-redeploy (no unexpected shell spawns, no abnormal outbound connections, clean health checks) and monitor the previously contacted IPs/domains for further callbacks from other workloads.
- Escalate to incident response and platform security immediately if the shell command indicates payload retrieval, reverse shell activity, credential access, or if similar `sh -c` executions are observed across multiple containers/namespaces.
- Harden by removing shell binaries from runtime images where feasible, enforcing non-root and read-only filesystems, restricting egress to required destinations only, disabling risky interpreter execution paths in the web app, and adding WAF/RCE protections for the identified vulnerable endpoint."""
risk_score = 47
rule_id = "497a7091-0ebd-44d7-88c4-367ab4d4d852"
severity = "medium"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Execution",
"Tactic: Command and Control",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
process.parent.name in (
"apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn",
"uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn",
"daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-cgi",
"php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl"
) or
process.parent.name like "php-fpm*" or
user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or
user.id in ("33", "498", "48") or
(process.parent.name == "java" and process.parent.working_directory like "/u0?/*") or
process.parent.working_directory like "/var/www/*"
) and (
(process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox")) or
(process.args in (
"bash", "/bin/bash", "/usr/bin/bash", "/usr/local/bin/bash",
"dash", "/bin/dash", "/usr/bin/dash", "/usr/local/bin/dash",
"sh", "/bin/sh", "/usr/bin/sh", "/usr/local/bin/sh",
"tcsh", "/bin/tcsh", "/usr/bin/tcsh", "/usr/local/bin/tcsh",
"csh", "/bin/csh", "/usr/bin/csh", "/usr/local/bin/csh",
"zsh", "/bin/zsh", "/usr/bin/zsh", "/usr/local/bin/zsh",
"ksh", "/bin/ksh", "/usr/bin/ksh", "/usr/local/bin/ksh",
"fish", "/bin/fish", "/usr/bin/fish", "/usr/local/bin/fish",
"busybox", "/bin/busybox", "/usr/bin/busybox", "/usr/local/bin/busybox"
))
) and process.args == "-c" and container.id like "?*"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
name = "Persistence"
id = "TA0003"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat.technique]]
id = "T1505"
name = "Server Software Component"
reference = "https://attack.mitre.org/techniques/T1505/"
[[rule.threat.technique.subtechnique]]
id = "T1505.003"
name = "Web Shell"
reference = "https://attack.mitre.org/techniques/T1505/003/"
[[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/"