Encoded Payload Detected via Defend for Containers
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.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/02/06"
3integration = ["cloud_defend"]
4maturity = "production"
5min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
6min_stack_version = "9.3.0"
7updated_date = "2026/02/06"
8
9[rule]
10author = ["Elastic"]
11description = """
12This rule detects the interactive execution of potential defense evasion techniques via encoded payloads
13inside a container. Attackers may use base64 encoding/decoding to obfuscate data, such as command and
14control traffic or payloads, to evade detection by host- or network-based security controls.
15"""
16from = "now-6m"
17index = ["logs-cloud_defend.process*"]
18interval = "5m"
19language = "eql"
20license = "Elastic License v2"
21name = "Encoded Payload Detected via Defend for Containers"
22note = """## Triage and analysis
23
24> **Disclaimer**:
25> 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.
26
27### Investigating Encoded Payload Detected via Defend for Containers
28
29This 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.
30
31### Possible investigation steps
32
33- 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.
34- 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.
35- 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.
36- 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.
37- 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.
38
39### False positive analysis
40
41- 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.
42- 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.
43
44### Response and remediation
45
46- 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.
47- 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.
48- 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.
49- 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.
50- 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."""
51risk_score = 47
52rule_id = "227cf26a-88d1-4bcb-bf4c-925e5875abcf"
53severity = "medium"
54tags = [
55 "Data Source: Elastic Defend for Containers",
56 "Domain: Container",
57 "OS: Linux",
58 "Use Case: Threat Detection",
59 "Tactic: Defense Evasion",
60 "Tactic: Execution",
61 "Resources: Investigation Guide",
62]
63timestamp_override = "event.ingested"
64type = "eql"
65query = '''
66process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.interactive == true and (
67 (process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and process.args like~ "*-*d*") or
68 (process.name == "xxd" and process.args like~ ("-*r*", "-*p*")) or
69 (process.name == "openssl" and process.args == "enc" and process.args in ("-d", "-base64", "-a")) or
70 (process.name like "python*" and (
71 (process.args == "base64" and process.args in ("-d", "-u", "-t")) or
72 (process.args == "-c" and process.args like "*base64*" and process.args like "*b64decode*")
73 )) or
74 (process.name like "perl*" and process.args like "*decode_base64*") or
75 (process.name like "ruby*" and process.args == "-e" and process.args like "*Base64.decode64*")
76) and container.id like "?*"
77'''
78
79[[rule.threat]]
80framework = "MITRE ATT&CK"
81
82[[rule.threat.technique]]
83id = "T1027"
84name = "Obfuscated Files or Information"
85reference = "https://attack.mitre.org/techniques/T1027/"
86
87[[rule.threat.technique]]
88id = "T1140"
89name = "Deobfuscate/Decode Files or Information"
90reference = "https://attack.mitre.org/techniques/T1140/"
91
92[rule.threat.tactic]
93id = "TA0005"
94name = "Defense Evasion"
95reference = "https://attack.mitre.org/tactics/TA0005/"
96
97[[rule.threat]]
98framework = "MITRE ATT&CK"
99
100[[rule.threat.technique]]
101id = "T1059"
102name = "Command and Scripting Interpreter"
103reference = "https://attack.mitre.org/techniques/T1059/"
104
105[[rule.threat.technique.subtechnique]]
106id = "T1059.004"
107name = "Unix Shell"
108reference = "https://attack.mitre.org/techniques/T1059/004/"
109
110[[rule.threat.technique]]
111id = "T1204"
112name = "User Execution"
113reference = "https://attack.mitre.org/techniques/T1204/"
114
115[[rule.threat.technique.subtechnique]]
116id = "T1204.002"
117name = "Malicious File"
118reference = "https://attack.mitre.org/techniques/T1204/002/"
119
120[rule.threat.tactic]
121id = "TA0002"
122name = "Execution"
123reference = "https://attack.mitre.org/tactics/TA0002/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating 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.
Related rules
- Suspicious Interactive Process Execution Detected via Defend for Containers
- System Path File Creation and Execution Detected via Defend for Containers
- File Execution Permission Modification Detected via Defend for Containers
- File Creation and Execution Detected via Defend for Containers
- File Download Detected via Defend for Containers