hunting-scheduled-job-and-search-path-hijacks

Hunting scheduled-job and search-path hijacks: what runs, as whom, over what you can write

Automation escalates privilege quietly. A job runs on a timer as a privileged identity, and if anything it touches is writable by a lesser user, or if it resolves a command through a path or a wildcard that a lesser user can influence, that user's content runs as the job's identity. The bug is never the schedule; it is the trust the job places in a writable script, a writable directory on its search path, an unqualified command name, or a filename that a wildcard hands to a command as an option. You find it by listing every job, the identity it runs as, and every input it trusts, then checking which of those inputs a lesser user controls.

When to use

• You are auditing a host or image for local privilege escalation through automation.
• Periodic jobs, timers, or service-triggered scripts run as a privileged identity.
• Those jobs execute scripts, resolve commands by name, or expand wildcards over directories.

Scope check

Audit scheduled-job and path escalation only on hosts or images you own or are authorized to test, with an unprivileged account you may escalate from. If you can't name the authorization, stop.

The loop

1. Enumerate every job and the identity it runs as. Inventory periodic jobs, timers, and service-triggered scripts across every location they can be defined, system-wide and per-user, and record which identity each runs as. A job running as an unprivileged service account is a smaller prize than one running as root, but map them all; the identity sets the stakes.

2. List every input each job trusts. For each job, follow what it executes and reads: the job script itself, any script or config or data file it sources or parses, the directories it operates over, and the commands it launches. Each of these is an input the job trusts to be benign. The audit is which of those inputs a lesser user can change.

3. Check writability of scripts, configs, and directories. For every trusted input, check whether a lower-privileged user can write it: a job script that is group- or world-writable, a config sourced from a writable path, a directory the job writes into or globs over that a lesser user owns. A writable trusted input is a direct hijack; the lesser user plants content that runs as the job's identity.