# Persistence via Cron Job Modification

- **Severity:** High
- **Signature ID:** `7c1e9f2a-4d3b-4a86-9f10-2b5c8e6d41af`
- **MITRE ATLAS:** AML.T0050 (Command and Scripting Interpreter)
- **OWASP:** LLM06 (Excessive Agency)

## Summary

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.

## 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.

## References

- https://attack.mitre.org/techniques/T1053/003/
- https://atlas.mitre.org/techniques/AML.T0050
- https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

---
Source: https://www.netzilo.com/threats/cron-persistence