Execute through remote Task Scheduler

Needs: Task Scheduler RPC reachability, effective task-creation rights and the required administrative output access

Shell commands

# Baseline
impacket-atexec 'DOMAIN/USER:PASSWORD@TARGET_HOST' "cmd.exe /c hostname & whoami"
impacket-atexec -hashes :NT_HASH 'DOMAIN/USER@TARGET_HOST' "cmd.exe /c hostname & whoami"

Kerberos

ATExec creates and deletes a scheduled task and normally retrieves output from ADMIN$\Temp. It is a one-shot command mechanism, not an interactive shell; task-scheduler RPC and administrative share access must both work.

# Kerberos
export KRB5CCNAME="$PWD/USER.ccache"
impacket-atexec -k -no-pass -dc-ip DC_IP 'DOMAIN/USER@TARGET_HOST' "cmd.exe /c hostname & whoami"

Verify → Verify the actual task effect/principal and destination, not task registration alone.

If it fails → Dynamic RPC filtering, task authorization or denied output share can break different phases. More detail ↓

If → then

A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
Needs: A functioning execution primitive and an observable output or controlled side effect
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
A credential appears valid but the destination's usable access is unknown → Match route, destination service and effective authorization
Needs: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

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

Explanation & examples

Execute through remote Task Scheduler

USE WHEN: The identity has remote task rights and a compatible output path
STARTING ACCESS: Identified authentication material, destination service reachability and a candidate authorized identity
RESULT: A verified one-shot remote task command effect

Recognize the clue

Use destination RPC/SMB evidence and effective administrative/task rights to investigate Task Scheduler as a one-shot execution consumer.

Test-NetConnection TARGET -Port 135
Test-NetConnection TARGET -Port 445

SYNTHETIC EXAMPLE OUTPUT

135: reachable
445: reachable
Remote task creation and output ACLs: not yet known

Means: The required network services are candidates; a task cannot be assumed creatable from port results.

Confirm: Check negotiated RPC reachability, task-create permission, actual principal and administrative output channel.

After validation: Task creation/execution and the bounded effect are verified: choose ATExec.
Ruled out in this context: The account lacks remote task rights: reject this method while retaining other service access.
Still inconclusive: A task-run request accepted without process/effect evidence is inconclusive.

Troubleshooting: Dynamic RPC filtering, task authorization or denied output share can break different phases.

ATExec creates and deletes a scheduled task and normally retrieves output from ADMIN$\Temp. It is a one-shot command mechanism, not an interactive shell; task-scheduler RPC and administrative share access must both work.

Kerberos:

Why it works

Remote task creation and file-based output retrieval are separate operations. ATExec is not a full interactive shell; task principal and execution result must be checked.

Worked example · hypothetical

Observation: the identity can create tasks on the destination. Test: run a bounded hostname/identity command and inspect output. Illustrative output: the correct host responds under the task principal. Interpretation: decide whether one-shot execution is sufficient or a session is needed.

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

Study guide ↗Full procedure ↗Cheatsheet ↗