System Path File Creation and Execution Detected via Defend for Containers
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.
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 when an interactive process creates a file inside of a system binary location, inside of a running
13container. The system binary locations are /etc, /root, /bin, /usr/bin, /usr/local/bin, and /entrypoint. Adversaries
14may use these locations to create files that can be used to execute commands on the underlying host, or to evade
15detection by security controls.
16"""
17from = "now-6m"
18index = ["logs-cloud_defend.file*"]
19interval = "5m"
20language = "eql"
21license = "Elastic License v2"
22name = "System Path File Creation and Execution Detected via Defend for Containers"
23note = """## Triage and analysis
24
25> **Disclaimer**:
26> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
27
28### Investigating System Path File Creation and Execution Detected via Defend for Containers
29
30This 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.
31
32### Possible investigation steps
33
34- 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.
35- 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.
36- Review the interactive session context (TTY, user, entry method) and surrounding command activity to assess intent and whether secrets or credentials were accessed.
37- 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.
38- 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.
39
40### False positive analysis
41
42- 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.
43- 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.
44
45### Response and remediation
46
47- 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.
48- 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.
49- 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.
50- 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.
51- 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."""
52risk_score = 47
53rule_id = "05a50000-9886-4695-ad33-3f990dc142e2"
54severity = "medium"
55tags = [
56 "Data Source: Elastic Defend for Containers",
57 "Domain: Container",
58 "OS: Linux",
59 "Use Case: Threat Detection",
60 "Tactic: Execution",
61 "Tactic: Command and Control",
62 "Tactic: Defense Evasion",
63 "Resources: Investigation Guide",
64]
65timestamp_override = "event.ingested"
66type = "eql"
67query = '''
68file where host.os.type == "linux" and event.type == "creation" and process.interactive == true and
69file.path like (
70 "/etc/*", "/root/*", "/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/entrypoint*"
71) and (
72 process.name like ("wget", "curl") or
73 (process.name == "busybox" and process.args == "wget") or
74 process.executable like ("/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/*", "/var/run/*", "/mnt/*")
75) and container.id like "?*"
76'''
77
78[[rule.threat]]
79framework = "MITRE ATT&CK"
80
81[rule.threat.tactic]
82name = "Execution"
83id = "TA0002"
84reference = "https://attack.mitre.org/tactics/TA0002/"
85
86[[rule.threat.technique]]
87id = "T1059"
88name = "Command and Scripting Interpreter"
89reference = "https://attack.mitre.org/techniques/T1059/"
90
91[[rule.threat.technique.subtechnique]]
92id = "T1059.004"
93name = "Unix Shell"
94reference = "https://attack.mitre.org/techniques/T1059/004/"
95
96[[rule.threat]]
97framework = "MITRE ATT&CK"
98
99[rule.threat.tactic]
100name = "Command and Control"
101id = "TA0011"
102reference = "https://attack.mitre.org/tactics/TA0011/"
103
104[[rule.threat.technique]]
105name = "Application Layer Protocol"
106id = "T1071"
107reference = "https://attack.mitre.org/techniques/T1071/"
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111
112[rule.threat.tactic]
113name = "Defense Evasion"
114id = "TA0005"
115reference = "https://attack.mitre.org/tactics/TA0005/"
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.
Related rules
- Encoded Payload Detected via Defend for Containers
- File Creation and Execution Detected via Defend for Containers
- File Download Detected via Defend for Containers
- Suspicious Interactive Process Execution Detected via Defend for Containers
- Suspicious Interpreter Execution Detected via Defend for Containers