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/02/10"
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: Container",
64 "OS: Linux",
65 "Use Case: Threat Detection",
66 "Tactic: Persistence",
67 "Tactic: Execution",
68 "Tactic: Privilege Escalation",
69 "Resources: Investigation Guide",
70]
71timestamp_override = "event.ingested"
72type = "eql"
73query = '''
74file where event.type != "deletion" and
75/* open events currently only log file opens with write intent */
76event.action in ("creation", "rename", "open") and (
77 file.path like (
78
79 // Cron & Anacron Jobs
80 "/etc/cron.allow", "/etc/cron.deny", "/etc/cron.d/*", "/etc/cron.hourly/*", "/etc/cron.daily/*",
81 "/etc/cron.weekly/*", "/etc/cron.monthly/*", "/etc/crontab", "/var/spool/cron/crontabs/*",
82 "/var/spool/anacron/*",
83
84 // At Job
85 "/var/spool/cron/atjobs/*", "/var/spool/atjobs/*",
86
87 // Sudoers
88 "/etc/sudoers*"
89 ) or
90 (
91 // Systemd Service/Timer
92 file.path like (
93 "/etc/systemd/system/*", "/etc/systemd/user/*", "/usr/local/lib/systemd/system/*",
94 "/lib/systemd/system/*", "/usr/lib/systemd/system/*", "/usr/lib/systemd/user/*",
95 "/home/*/.config/systemd/user/*", "/home/*/.local/share/systemd/user/*",
96 "/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*"
97 ) and
98 file.extension in ("service", "timer")
99 ) or
100 (
101 // Shell Profile Configuration
102 file.path like ("/etc/profile.d/*", "/etc/zsh/*") or (
103 file.path like ("/home/*/*", "/etc/*", "/root/*") and
104 file.name in (
105 "profile", "bash.bashrc", "bash.bash_logout", "csh.cshrc", "csh.login", "config.fish", "ksh.kshrc",
106 ".bashrc", ".bash_login", ".bash_logout", ".bash_profile", ".bash_aliases", ".zprofile", ".zshrc",
107 ".cshrc", ".login", ".logout", ".kshrc"
108 )
109 )
110 )
111) and container.id like "?*" and
112not process.name in ("apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf", "apk", "pacman", "rpm", "dpkg")
113'''
114
115[[rule.threat]]
116framework = "MITRE ATT&CK"
117
118[[rule.threat.technique]]
119id = "T1543"
120name = "Create or Modify System Process"
121reference = "https://attack.mitre.org/techniques/T1543/"
122
123[[rule.threat.technique]]
124id = "T1053"
125name = "Scheduled Task/Job"
126reference = "https://attack.mitre.org/techniques/T1053/"
127
128[[rule.threat.technique.subtechnique]]
129id = "T1053.003"
130name = "Cron"
131reference = "https://attack.mitre.org/techniques/T1053/003/"
132
133[[rule.threat.technique]]
134id = "T1037"
135name = "Boot or Logon Initialization Scripts"
136reference = "https://attack.mitre.org/techniques/T1037/"
137
138[[rule.threat.technique]]
139id = "T1546"
140name = "Event Triggered Execution"
141reference = "https://attack.mitre.org/techniques/T1546/"
142
143[[rule.threat.technique.subtechnique]]
144id = "T1546.004"
145name = "Unix Shell Configuration Modification"
146reference = "https://attack.mitre.org/techniques/T1546/004/"
147
148[rule.threat.tactic]
149id = "TA0003"
150name = "Persistence"
151reference = "https://attack.mitre.org/tactics/TA0003/"
152
153[[rule.threat]]
154framework = "MITRE ATT&CK"
155
156[[rule.threat.technique]]
157id = "T1543"
158name = "Create or Modify System Process"
159reference = "https://attack.mitre.org/techniques/T1543/"
160
161[[rule.threat.technique]]
162id = "T1053"
163name = "Scheduled Task/Job"
164reference = "https://attack.mitre.org/techniques/T1053/"
165
166[[rule.threat.technique.subtechnique]]
167id = "T1053.003"
168name = "Cron"
169reference = "https://attack.mitre.org/techniques/T1053/003/"
170
171[[rule.threat.technique]]
172id = "T1548"
173name = "Abuse Elevation Control Mechanism"
174reference = "https://attack.mitre.org/techniques/T1548/"
175
176[[rule.threat.technique.subtechnique]]
177id = "T1548.003"
178name = "Sudo and Sudo Caching"
179reference = "https://attack.mitre.org/techniques/T1548/003/"
180
181[rule.threat.tactic]
182id = "TA0004"
183name = "Privilege Escalation"
184reference = "https://attack.mitre.org/tactics/TA0004/"
185
186[[rule.threat]]
187framework = "MITRE ATT&CK"
188
189[[rule.threat.technique]]
190id = "T1053"
191name = "Scheduled Task/Job"
192reference = "https://attack.mitre.org/techniques/T1053/"
193
194[[rule.threat.technique.subtechnique]]
195id = "T1053.003"
196name = "Cron"
197reference = "https://attack.mitre.org/techniques/T1053/003/"
198
199[rule.threat.tactic]
200id = "TA0002"
201name = "Execution"
202reference = "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
- Web Server Child Shell Spawn Detected via Defend for Containers
- Pod or Container Creation with Suspicious Command-Line
- File Download Detected via Defend for Containers
- Payload Execution via Shell Pipe Detected by Defend for Containers