Control a script, binary or configuration consumed by a privileged job/service
Needs: Effective object control, actual privileged consumer identity, correct path/environment and an available schedule/restart trigger
Shell commands
# Baseline
crontab -l 2>/dev/null
cat /etc/crontab
cat /etc/anacrontab 2>/dev/null
atq 2>/dev/null
ls -la /etc/cron.* /var/spool/cron 2>/dev/null
grep -RniE 'CRON|CMD' /var/log/syslog /var/log/cron* 2>/dev/null | tail -n 100
systemctl list-timers --all
systemctl list-unit-files --type=service
systemctl list-units --type=service --state=running
systemctl cat UNIT
systemctl show UNIT -p User -p Group -p ExecStart -p WorkingDirectory -p EnvironmentFiles
# Observe short-lived commands
./pspy64
./pspy64 -pf -i 1000
# Baseline
namei -l /PATH/TO/OBJECT
stat /PATH/TO/OBJECT /PATH/TO/PARENT
getfacl -p /PATH/TO/OBJECT /PATH/TO/PARENT 2>/dev/null
Prove: exact object is controllable → job/service consumes it → process runs as a higher identity → schedule/restart/other trigger is available. A writable unit still needs a privileged reload/restart or automatic trigger. Cron uses a different/minimal environment.
Verify → Verify the consumer's resulting effect and identity; editing a file without an observed trigger is incomplete.
If it fails → Wrong path, service sandbox, missing trigger or another effective identity breaks the chain. Use process observation and permission checks. More detail ↓
Explanation & examples
Control a script, binary or configuration consumed by a privileged job/service
- USE WHEN
- Root-owned cron, systemd or recurring process activity uses a controllable object
- STARTING ACCESS
- A verified Linux foothold with a known effective UID, groups and filesystem context
- RESULT
- Verified execution or a useful file operation under the job/service identity
Recognize the clue
Inspect actual cron/systemd definitions and running processes, then follow their action paths into permission checks.
cat /etc/crontab
systemctl list-timers --all
ps auxww
* * * * * root /opt/APP/backup.sh
Script path: /opt/APP/backup.shMeans: The schedule explicitly names a privileged consumer and an exact file to inspect.
Confirm: Observe the actual command and UID with pspy or inspect the unit with systemctl cat/show. Run namei -l, stat and getfacl on the consumed path and parents; identify the timer, restart or invocation before changing the file.
- After validation
- The controlled object is consumed at a confirmed privileged trigger: choose the job/service method.
- Ruled out in this context
- The real job runs as the same low user: reject privilege gain through that action.
- Still inconclusive
- A stale job file without observed activity/usable trigger leaves execution unresolved.
Troubleshooting: Wrong path, service sandbox, missing trigger or another effective identity breaks the chain. Use process observation and permission checks.
Observe short-lived commands:
Validate every referenced script, binary, configuration, environment file, plugin and parent:
Prove: exact object is controllable → job/service consumes it → process runs as a higher identity → schedule/restart/other trigger is available. A writable unit still needs a privileged reload/restart or automatic trigger. Cron uses a different/minimal environment.
Apply the same proof to backup, logrotate, package-maintenance and custom housekeeping hooks: configuration visibility or a writable output is insufficient unless a higher-privileged consumer interprets attacker-controlled input.
Why it works
Writable scripts and service units become useful only when the privileged consumer actually reads them. A timer schedule and a right to restart a service are different triggers.
Worked example · hypothetical
Observation: root runs a backup script on a timer. Test: prove the exact script path and effective write rights, then observe a controlled effect at its scheduled trigger. Illustrative output: a root-owned marker appears. Interpretation: privileged consumption is confirmed.
New identity, privilege, host or route? Re-enumerate → All topic tasks →