New Rule

[AAtashGar]

Attackers (and some red-team tools/living-off-the-land binaries) increasingly abuse systemd timers as a persistence mechanism because:

• They are less monitored than traditional cron or classic systemd services
• They run with the privileges of the creating user (often root)
• They are enabled instantly with a simple symlink

These two directories are the most common locations where symlinks for enabled timers are placed:

• /lib/systemd/system/timers.target.wants/ → system/package-provided timers
• /etc/systemd/system/timers.target.wants/ → locally created or overridden timers

Example log when a malicious timer is enabled

type=SYSCALL msg=audit(1731951234.567:12345): arch=c000003e syscall=188 success=yes exit=0 a0=55aa12345678 a1=55bb87654321 a2=0 a3=7f89abc12345 items=1 ppid=1234 pid=5678 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="ln" exe="/usr/bin/ln" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="systemtimer_systemd"
type=CWD msg=audit(1731951234.567:12345): cwd="/root"
type=PATH msg=audit(1731951234.567:12345): item=0 name="/etc/systemd/system/timers.target.wants/evil.timer" inode=123456 dev=08:01 mode=120777 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0

With these rules, any new or modified symlink in the timers.target.wants directories will be logged and can be alerted on with a simple Sigma rule (I can provide one if wanted).