Control scheduled tasks, startup files or autostart consumers

Needs: Effective object control, a higher principal and a usable scheduled/logon/manual trigger

Scheduled tasks

REM Scheduled tasks
schtasks /query /fo LIST /v
schtasks /query /tn "\FOLDER\TASK" /xml

Scheduled tasks

# Scheduled tasks
Get-ScheduledTask | ForEach-Object {
  $t = $_
  [pscustomobject]@{
    TaskPath=$t.TaskPath; TaskName=$t.TaskName
    UserId=$t.Principal.UserId; RunLevel=$t.Principal.RunLevel
    Actions=($t.Actions | ForEach-Object { "$($_.Execute) $($_.Arguments) [wd=$($_.WorkingDirectory)]" }) -join '; '
  }
}

Scheduled tasks

REM Scheduled tasks
icacls "C:\Path\To\task-script.ps1"
icacls "C:\Path\To"
schtasks /run /tn "\FOLDER\TASK"

REM Run keys and startup consumers
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run
reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run
dir "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp"
dir "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup"

Need a modifiable consumed value/file plus a higher-privileged boot/logon/application trigger. A writable PATH directory matters only when a privileged consumer invokes an unqualified executable through that effective PATH.

Verify → Check the actual effect and token after the trigger; task-run acceptance alone is insufficient.

If it fails → Wrong principal, stale action, denied trigger or a different working directory can invalidate the candidate. More detail ↓

If → then

A privileged object appears writable or an ACL tool reports a useful right → Prove effective file, registry and service-object permissions
Needs: Correct trustee/token, object type and effective rights including parents and deny entries
A new Windows session or claimed administrator/SYSTEM transition → Establish Windows token, host and process context
Needs: A functioning command channel and the actual effective token/process context
Effective SERVICE_CHANGE_CONFIG on a higher-privileged service → Change a privileged service's executable configuration
Needs: Configuration-change right, accessible compatible payload path and a separate start/restart trigger

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Control scheduled tasks, startup files or autostart consumers

USE WHEN: A task/startup action consumes a writable command, file, directory or registry value
STARTING ACCESS: A verified Windows foothold with a known token, integrity level and groups
RESULT: Verified privileged task or startup execution

Recognize the clue

Enumerate task definitions and inspect the action, principal, arguments and working directory before permission-checking its files.

schtasks /query /fo LIST /v
schtasks /query /tn "\FOLDER\TASK" /xml

SYNTHETIC EXAMPLE OUTPUT

Principal: SYSTEM
Action: powershell.exe -File C:\APP\job.ps1
Trigger: scheduled
File control: inspect separately

Means: A named privileged task exposes a concrete consumer and action path to investigate.

Confirm: Read the task's exact action, principal and trigger with schtasks or Get-ScheduledTask. Check icacls on its file/parents and prove the stronger identity will consume the controlled path at a reachable trigger.

After validation: The controllable action is consumed under the expected higher token: select the task route.
Ruled out in this context: The real principal is the same low user: reject assumed elevation.
Still inconclusive: Task registration or run acceptance without process/effect evidence leaves execution unresolved.

Troubleshooting: Wrong principal, stale action, denied trigger or a different working directory can invalidate the candidate.

Scheduled tasks

Prove action, arguments, working directory, principal, actual trigger and effective ACL. RunLevel Highest means the configured principal's highest available token, not SYSTEM. /run success means the request was accepted; verify process/effect and last-run result.

Run keys and startup consumers

Need a modifiable consumed value/file plus a higher-privileged boot/logon/application trigger. A writable PATH directory matters only when a privileged consumer invokes an unqualified executable through that effective PATH.

Why it works

RunLevel Highest selects the configured principal's highest available token; it does not mean SYSTEM. A writable user startup entry usually runs as that user.

Worked example · hypothetical

Observation: a writable script is named in a scheduled task. Test: inspect principal, arguments, working directory and trigger. Illustrative output: the task runs as the same low user. Interpretation: it is not a local privilege escalation under that configuration.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗