Persistence via Cron Job Modification
This detects an AI agent writing to or modifying scheduled task files (cron jobs) on a Linux system. Attackers use cron persistence to make sure a malicious command keeps running even after a reboot or session ends, and an AI agent with shell access can be tricked or directed into doing this.
How the attack works
The agent runs a command that writes to the crontab system, either by using crontab in install/edit/remove mode, by writing directly into system cron directories like /etc/cron.d or /var/spool/cron, or by using a file-write tool call aimed at those same locations. The rule also catches cases where the scheduled job itself contains a downloader or shell command, such as a `@reboot` line that fetches and runs a script. Any of these on their own is enough to trigger the detection — it does not require a longer chain of events. Read-only actions like listing or viewing existing cron jobs are excluded; only actions that add, change, or execute cron entries count.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7c1e9f2a-4d3b-4a86-9f10-2b5c8e6d41af
- Severity
- High
Why it matters
Successful cron persistence lets an attacker's code survive reboots and keep running unattended, giving them a durable foothold on the machine without needing to re-exploit it. This is one step of a larger intrusion — the rule flags the persistence mechanism itself, not the initial compromise or subsequent actions.
What you can do
- →Review any cron job created or modified by an AI agent to confirm it was explicitly requested by an operator and matches an expected schedule and command.
- →Restrict which paths and commands an AI agent is allowed to write to, and require approval before it can touch /etc/crontab, /etc/cron.d, /etc/cron.*, or /var/spool/cron.
- →Treat any cron entry with `@reboot` or an unfamiliar 5-field schedule pointing to a downloader or shell interpreter as high priority for investigation.
- →Expect and allow known legitimate patterns (backup jobs, log rotation, cert renewal, config-management runs) but require them to go through the operator's normal deployment process rather than ad hoc agent writes.
Known benign look-alikes
- DevOps/SRE agents legitimately scheduling backups, log rotation, or certificate renewal at the operator's explicit request (`crontab -e`, a new /etc/cron.d/ file).
- Container image build steps (Dockerfile RUN lines) that append a job to /etc/crontab after installing cron — the narrow filter_cron_package_install suppression covers the common form, but multi-stage builds may still surface.
- Configuration-management runs (Ansible/Chef/Puppet/Salt) rendering cron files onto a host during a normal deployment task.
- CI teardown or bootstrap scripts running `crontab -r` to clear a scratch runner.
- Backup/restore workflows that dump with `crontab -l > file` and restore with `crontab file` or `cat file | crontab -`.
- Agents authoring documentation, tutorials, or detection content about cron persistence — mostly suppressed by filter_manpage and filter_security_doc.