Modification of Persistence Relevant Files Detected via Defend for Containers
This rule detects attempts from within a Linux container to create or modify files commonly used for persistence on native Linux systems, including cron jobs, systemd units, sudoers files, and shell profile configurations. While many of these mechanisms do not provide reliable persistence in typical containerized workloads, such modifications are unusual and may indicate persistence attempts, privilege abuse, or preparation for container escape, especially when performed outside normal image build or package management processes.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/02/10"
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/09/18"
8
9[rule]
10author = ["Elastic"]
11description = """
12This rule detects attempts from within a Linux container to create or modify files commonly used for
13persistence on native Linux systems, including cron jobs, systemd units, sudoers files, and shell
14profile configurations. While many of these mechanisms do not provide reliable persistence in typical
15containerized workloads, such modifications are unusual and may indicate persistence attempts, privilege
16abuse, or preparation for container escape, especially when performed outside normal image build or
17package management processes.
18"""
19from = "now-6m"
20index = ["logs-cloud_defend.file*"]
21interval = "5m"
22language = "eql"
23license = "Elastic License v2"
24name = "Modification of Persistence Relevant Files Detected via Defend for Containers"
25note = """## Triage and analysis
26
27> **Disclaimer**:
28> 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.
29
30### Investigating Modification of Persistence Relevant Files Detected via Defend for Containers
31
32This detection flags a process inside a Linux container creating or modifying files tied to host-style persistence and privilege control, such as cron schedules, systemd units, sudoers, or shell startup profiles. These changes rarely belong in normal container runtime behavior, so they often signal an attacker staging long-lived execution, escalating privileges, or preparing an escape path. A common pattern is dropping a new `/etc/cron.d/*` entry that periodically launches a payload or backconnects.
33
34### Possible investigation steps
35
36- Review the modifying process’s full command line, parent/ancestor chain, effective UID, and container entrypoint to determine whether it aligns with expected runtime behavior or indicates an interactive shell/exploit.
37- Pull the before/after contents of the changed file and look for execution hooks (cron command, systemd ExecStart, sudoers NOPASSWD, or shell profile stagers), then extract any referenced binaries, users, paths, or URLs for follow-on hunting.
38- Determine whether the container is privileged or has elevated capabilities and sensitive host mounts (e.g., `/etc`, `/var/run/docker.sock`, `/proc`, `/sys`) that would make the change meaningful for host persistence or escape attempts.
39- Correlate the modification time with nearby activity from the same container (process spawns, tool downloads, outbound connections, and interactive access such as `kubectl exec`) to reconstruct the sequence and probable entry vector.
40- Check for the same change across replicas/nodes and in the image/build pipeline, and if the modification is unapproved, isolate and redeploy from a known-good image while preserving artifacts for analysis.
41
42### False positive analysis
43
44- An application container running as root updates shell startup files (e.g., `/root/.bashrc`, `/etc/profile.d/*`) at runtime to enforce environment variables, PATH changes, or interactive defaults for troubleshooting, triggering a write/open event without any persistence intent.
45- A container startup/entrypoint script generates or adjusts cron/systemd-related files (e.g., `/etc/cron.d/*`, `/etc/systemd/system/*.service`) to schedule internal maintenance tasks or align configuration on first boot, causing file creations/renames outside package-manager processes.
46
47### Response and remediation
48
49- Quarantine the affected workload by scaling the deployment to zero or applying a deny-all egress policy, and isolate the node if the container was privileged or had host filesystem mounts that could make the persistence change impact the host.
50- Preserve evidence by exporting the modified persistence-related file(s) (e.g., `/etc/cron.d/*`, `/etc/sudoers*`, systemd unit/timer, shell profile) and collecting the writing process binary, command line, environment, and a short window of process and network activity from the container.
51- Eradicate by deleting or reverting the unauthorized cron/systemd/sudoers/profile changes, removing any referenced payload binaries/scripts, revoking any newly added users/keys/tokens, and rotating credentials used by the container or mounted into it.
52- Recover by redeploying the service from a known-good image and clean configuration (ConfigMaps/Secrets), validating that no persistence files are modified at runtime and that outbound connections and scheduled executions return to expected behavior.
53- Escalate to incident response immediately if the change grants passwordless sudo, drops a new systemd unit/timer or cron job that executes a network-capable command, or if the container is privileged/has `/var/run/docker.sock` or host `/etc` mounted, as this may indicate attempted host persistence or escape.
54- Harden by enforcing read-only root filesystem and non-root execution, restricting capabilities/privileged mode and sensitive host mounts, and adding policy controls to block writes to `/etc/cron*`, `/etc/sudoers*`, systemd paths, and shell profiles outside the image build pipeline."""
55references = [
56 "https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
57]
58risk_score = 21
59rule_id = "f246e70e-5e20-4006-8460-d72b023d6adf"
60severity = "low"
61tags = [
62 "Data Source: Elastic Defend for Containers",
63 "Domain: Containers",
64 "OS: Linux",
65 "Use Case: Threat Detection",
66 "Tactic: Persistence",
67 "Tactic: Execution",
68 "Tactic: Privilege Escalation",
69 "Resources: Investigation Guide",
70 "Noise: Unknown",
71 "Performance: Normal",
72 "Rule Type: Event Correlation (EQL)",
73 "Platform: Linux",
74]
75timestamp_override = "event.ingested"
76type = "eql"
77query = '''
78file where event.type != "deletion" and
79/* open events currently only log file opens with write intent */
80event.action in ("creation", "rename", "open") and (
81 file.path like (
82
83 // Cron & Anacron Jobs
84 "/etc/cron.allow", "/etc/cron.deny", "/etc/cron.d/*", "/etc/cron.hourly/*", "/etc/cron.daily/*",
85 "/etc/cron.weekly/*", "/etc/cron.monthly/*", "/etc/crontab", "/var/spool/cron/crontabs/*",
86 "/var/spool/anacron/*",
87
88 // At Job
89 "/var/spool/cron/atjobs/*", "/var/spool/atjobs/*",
90
91 // Sudoers
92 "/etc/sudoers*"
93 ) or
94 (
95 // Systemd Service/Timer
96 file.path like (
97 "/etc/systemd/system/*", "/etc/systemd/user/*", "/usr/local/lib/systemd/system/*",
98 "/lib/systemd/system/*", "/usr/lib/systemd/system/*", "/usr/lib/systemd/user/*",
99 "/home/*/.config/systemd/user/*", "/home/*/.local/share/systemd/user/*",
100 "/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*"
101 ) and
102 file.extension in ("service", "timer")
103 ) or
104 (
105 // Shell Profile Configuration
106 file.path like ("/etc/profile.d/*", "/etc/zsh/*") or (
107 file.path like ("/home/*/*", "/etc/*", "/root/*") and
108 file.name in (
109 "profile", "bash.bashrc", "bash.bash_logout", "csh.cshrc", "csh.login", "config.fish", "ksh.kshrc",
110 ".bashrc", ".bash_login", ".bash_logout", ".bash_profile", ".bash_aliases", ".zprofile", ".zshrc",
111 ".cshrc", ".login", ".logout", ".kshrc"
112 )
113 )
114 )
115) and container.id like "?*" and
116not process.name in ("apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf", "apk", "pacman", "rpm", "dpkg")
117'''
118
119[[rule.threat]]
120framework = "MITRE ATT&CK"
121
122[[rule.threat.technique]]
123id = "T1037"
124name = "Boot or Logon Initialization Scripts"
125reference = "https://attack.mitre.org/techniques/T1037/"
126
127[[rule.threat.technique]]
128id = "T1053"
129name = "Scheduled Task/Job"
130reference = "https://attack.mitre.org/techniques/T1053/"
131
132[[rule.threat.technique.subtechnique]]
133id = "T1053.002"
134name = "At"
135reference = "https://attack.mitre.org/techniques/T1053/002/"
136
137[[rule.threat.technique.subtechnique]]
138id = "T1053.003"
139name = "Cron"
140reference = "https://attack.mitre.org/techniques/T1053/003/"
141
142[[rule.threat.technique.subtechnique]]
143id = "T1053.006"
144name = "Systemd Timers"
145reference = "https://attack.mitre.org/techniques/T1053/006/"
146
147[[rule.threat.technique]]
148id = "T1543"
149name = "Create or Modify System Process"
150reference = "https://attack.mitre.org/techniques/T1543/"
151
152[[rule.threat.technique.subtechnique]]
153id = "T1543.002"
154name = "Systemd Service"
155reference = "https://attack.mitre.org/techniques/T1543/002/"
156
157[[rule.threat.technique]]
158id = "T1546"
159name = "Event Triggered Execution"
160reference = "https://attack.mitre.org/techniques/T1546/"
161
162[[rule.threat.technique.subtechnique]]
163id = "T1546.004"
164name = "Unix Shell Configuration Modification"
165reference = "https://attack.mitre.org/techniques/T1546/004/"
166
167[rule.threat.tactic]
168id = "TA0003"
169name = "Persistence"
170reference = "https://attack.mitre.org/tactics/TA0003/"
171
172[[rule.threat]]
173framework = "MITRE ATT&CK"
174
175[[rule.threat.technique]]
176id = "T1053"
177name = "Scheduled Task/Job"
178reference = "https://attack.mitre.org/techniques/T1053/"
179
180[[rule.threat.technique.subtechnique]]
181id = "T1053.002"
182name = "At"
183reference = "https://attack.mitre.org/techniques/T1053/002/"
184
185[[rule.threat.technique.subtechnique]]
186id = "T1053.003"
187name = "Cron"
188reference = "https://attack.mitre.org/techniques/T1053/003/"
189
190[[rule.threat.technique.subtechnique]]
191id = "T1053.006"
192name = "Systemd Timers"
193reference = "https://attack.mitre.org/techniques/T1053/006/"
194
195[[rule.threat.technique]]
196id = "T1543"
197name = "Create or Modify System Process"
198reference = "https://attack.mitre.org/techniques/T1543/"
199
200[[rule.threat.technique.subtechnique]]
201id = "T1543.002"
202name = "Systemd Service"
203reference = "https://attack.mitre.org/techniques/T1543/002/"
204
205[[rule.threat.technique]]
206id = "T1548"
207name = "Abuse Elevation Control Mechanism"
208reference = "https://attack.mitre.org/techniques/T1548/"
209
210[[rule.threat.technique.subtechnique]]
211id = "T1548.003"
212name = "Sudo and Sudo Caching"
213reference = "https://attack.mitre.org/techniques/T1548/003/"
214
215[rule.threat.tactic]
216id = "TA0004"
217name = "Privilege Escalation"
218reference = "https://attack.mitre.org/tactics/TA0004/"
219
220[[rule.threat]]
221framework = "MITRE ATT&CK"
222
223[[rule.threat.technique]]
224id = "T1053"
225name = "Scheduled Task/Job"
226reference = "https://attack.mitre.org/techniques/T1053/"
227
228[[rule.threat.technique.subtechnique]]
229id = "T1053.002"
230name = "At"
231reference = "https://attack.mitre.org/techniques/T1053/002/"
232
233[[rule.threat.technique.subtechnique]]
234id = "T1053.003"
235name = "Cron"
236reference = "https://attack.mitre.org/techniques/T1053/003/"
237
238[[rule.threat.technique.subtechnique]]
239id = "T1053.006"
240name = "Systemd Timers"
241reference = "https://attack.mitre.org/techniques/T1053/006/"
242
243[rule.threat.tactic]
244id = "TA0002"
245name = "Execution"
246reference = "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 Modification of Persistence Relevant Files Detected via Defend for Containers
This detection flags a process inside a Linux container creating or modifying files tied to host-style persistence and privilege control, such as cron schedules, systemd units, sudoers, or shell startup profiles. These changes rarely belong in normal container runtime behavior, so they often signal an attacker staging long-lived execution, escalating privileges, or preparing an escape path. A common pattern is dropping a new /etc/cron.d/* entry that periodically launches a payload or backconnects.
Possible investigation steps
- Review the modifying process’s full command line, parent/ancestor chain, effective UID, and container entrypoint to determine whether it aligns with expected runtime behavior or indicates an interactive shell/exploit.
- Pull the before/after contents of the changed file and look for execution hooks (cron command, systemd ExecStart, sudoers NOPASSWD, or shell profile stagers), then extract any referenced binaries, users, paths, or URLs for follow-on hunting.
- Determine whether the container is privileged or has elevated capabilities and sensitive host mounts (e.g.,
/etc,/var/run/docker.sock,/proc,/sys) that would make the change meaningful for host persistence or escape attempts. - Correlate the modification time with nearby activity from the same container (process spawns, tool downloads, outbound connections, and interactive access such as
kubectl exec) to reconstruct the sequence and probable entry vector. - Check for the same change across replicas/nodes and in the image/build pipeline, and if the modification is unapproved, isolate and redeploy from a known-good image while preserving artifacts for analysis.
False positive analysis
- An application container running as root updates shell startup files (e.g.,
/root/.bashrc,/etc/profile.d/*) at runtime to enforce environment variables, PATH changes, or interactive defaults for troubleshooting, triggering a write/open event without any persistence intent. - A container startup/entrypoint script generates or adjusts cron/systemd-related files (e.g.,
/etc/cron.d/*,/etc/systemd/system/*.service) to schedule internal maintenance tasks or align configuration on first boot, causing file creations/renames outside package-manager processes.
Response and remediation
- Quarantine the affected workload by scaling the deployment to zero or applying a deny-all egress policy, and isolate the node if the container was privileged or had host filesystem mounts that could make the persistence change impact the host.
- Preserve evidence by exporting the modified persistence-related file(s) (e.g.,
/etc/cron.d/*,/etc/sudoers*, systemd unit/timer, shell profile) and collecting the writing process binary, command line, environment, and a short window of process and network activity from the container. - Eradicate by deleting or reverting the unauthorized cron/systemd/sudoers/profile changes, removing any referenced payload binaries/scripts, revoking any newly added users/keys/tokens, and rotating credentials used by the container or mounted into it.
- Recover by redeploying the service from a known-good image and clean configuration (ConfigMaps/Secrets), validating that no persistence files are modified at runtime and that outbound connections and scheduled executions return to expected behavior.
- Escalate to incident response immediately if the change grants passwordless sudo, drops a new systemd unit/timer or cron job that executes a network-capable command, or if the container is privileged/has
/var/run/docker.sockor host/etcmounted, as this may indicate attempted host persistence or escape. - Harden by enforcing read-only root filesystem and non-root execution, restricting capabilities/privileged mode and sensitive host mounts, and adding policy controls to block writes to
/etc/cron*,/etc/sudoers*, systemd paths, and shell profiles outside the image build pipeline.
References
Related rules
- Suspicious Echo or Printf Execution Detected via Defend for Containers
- Ingress Tool Transfer Followed by Execution and Deletion Detected via Defend for Containers
- Mount Execution Detected via Defend for Containers
- Pod or Container Creation with Suspicious Command-Line
- Potential Kubeletctl Execution Detected via Defend for Containers