Detect Systemd Timers in Elastic Security
Adversaries may abuse systemd timers to perform task scheduling for initial or recurring execution of malicious code. Systemd timers are unit files with file extension .timer that control services. Timers can be set to run on a calendar event or after a time span relative to a starting point. Each .timer file must have a corresponding .service file with the same name. Privileged timers are written to /etc/systemd/system/ and /usr/lib/systemd/system while user level timers are written to ~/.config/systemd/user/. Adversaries may use systemd timers to execute malicious code at system startup or on a scheduled basis for persistence, and may leverage root-level timer paths to maintain privileged persistence.
MITRE ATT&CK
- Technique
- T1053 Scheduled Task/Job
- Sub-technique
- T1053.006 Systemd Timers
- Canonical reference
- https://attack.mitre.org/techniques/T1053/006/
Elastic Detection Query
any where
(
event.category == "process" and event.type == "start" and
process.name == "systemctl" and
process.args : ("*.timer") and
process.args : ("enable", "start", "link", "daemon-reload")
) or
(
event.category == "file" and
event.type in ("creation", "change") and
file.name : ("*.timer", "*.service") and
file.path : (
"/etc/systemd/system/*",
"/usr/lib/systemd/system/*",
"/lib/systemd/system/*",
"*/.config/systemd/user/*"
)
)Detects abuse of systemd timers (T1053.006) by monitoring for systemctl commands enabling, starting, or linking .timer units and for creation or modification of .timer/.service files in privileged system-level or user-level systemd directories. Covers both initial persistence installation and re-arming after daemon-reload.
Data Sources
Required Tables
False Positives & Tuning
- Package managers (apt, dnf, pacman) writing timer units to /usr/lib/systemd/system/ during software installation or upgrade scriptlets
- Configuration management tools such as Ansible, Chef, or Puppet legitimately deploying application-specific timer units to systemd directories during scheduled provisioning runs
- System administrators manually enabling standard maintenance timers (e.g., logrotate.timer, fstrim.timer, apt-daily.timer) via systemctl after OS hardening or initial server setup
Other platforms for T1053.006
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Create and Enable a Privileged Systemd Timer for Persistence
Expected signal: Auditd: SYSCALL openat/write events for /etc/systemd/system/argus-test.timer and /etc/systemd/system/argus-test.service creation. Process creation events for 'systemctl daemon-reload', 'systemctl enable argus-test.timer', 'systemctl start argus-test.timer'. Syslog: systemd entries showing 'argus-test.timer' enabled and started. After 1 minute: process creation for /bin/bash /tmp/argus_payload.sh spawned with parent=systemd.
- Test 2Create User-Level Systemd Timer for Unprivileged Persistence
Expected signal: File creation events for ~/.config/systemd/user/argus-user-test.timer and ~/.config/systemd/user/argus-user-test.service. Process creation events for 'systemctl --user daemon-reload', 'systemctl --user enable', 'systemctl --user start'. User journal entries: 'journalctl --user -u argus-user-test.timer' shows activation. On calendar trigger: process creation for /bin/bash /tmp/user_payload.sh with parent process systemd (user instance).
- Test 3Deploy Systemd Timer with Base64-Encoded Payload in ExecStart
Expected signal: File creation events for /etc/systemd/system/argus-encoded-test.service and /etc/systemd/system/argus-encoded-test.timer. The service unit file content contains 'base64 -d | bash' in ExecStart — detectable via file content inspection. Syslog: systemctl enable/start events. Process creation: /bin/bash spawned by systemd with base64 decode pipe pattern visible in command line arguments.
- Test 4Simulate Remote Systemd Timer Activation via SSH
Expected signal: File creation for unit files in /etc/systemd/system/. Process creation: systemctl enable and start commands. If run via SSH: /var/log/auth.log shows SSH session from source IP, with subsequent systemctl commands in the same session. Syslog: 'argus-remote-test.timer' enabled and started entries. Auditd: EXECVE records for systemctl with timer arguments.
References (12)
- https://attack.mitre.org/techniques/T1053/006/
- https://wiki.archlinux.org/index.php/Systemd/Timers
- https://www.tecmint.com/control-systemd-services-on-remote-linux-server/
- https://www.bleepingcomputer.com/news/security/malware-found-in-arch-linux-aur-package-repository/
- https://gist.github.com/campuscodi/74d0d2e35d8fd9499c76333ce027345a
- https://lists.archlinux.org/pipermail/aur-general/2018-July/034153.html
- https://www.hybrid-analysis.com/sample/28553b3a9d2ad4361d33d29ac4bf771d008e0073cec01b5561c6348a608f8dd7?environmentId=300
- http://man7.org/linux/man-pages/man1/systemd.1.html
- https://www.freedesktop.org/software/systemd/man/systemd.timer.html
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1053.006/T1053.006.md
- https://github.com/SigmaHQ/sigma/tree/master/rules/linux
- https://pberba.github.io/security/2022/01/30/linux-threat-hunting-for-persistence-systemd-timers-and-cron/
Unlock Pro Content
Get the full detection package for T1053.006 including response playbook, investigation guide, and atomic red team tests.