Execute through uploaded service creation using PsExec
Needs: SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context
Shell commands
# Baseline
# Password
impacket-psexec 'DOMAIN/USER:PASSWORD@TARGET'
# NT hash / Pass-the-Hash
impacket-psexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'
Kerberos cache
Need: SMB 445/139, writable administrative share and Service Control Manager rights. Impacket uploads a RemCom service binary, creates/starts a service and communicates over named pipes. Verify the returned identity; the service context is commonly SYSTEM.
# Kerberos cache
export KRB5CCNAME="$PWD/USER.ccache"
impacket-psexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP 'DOMAIN/USER@TARGET_HOST'
Windows commands
REM Baseline
PsExec64.exe -accepteula \\TARGET_HOST -u DOMAIN\USER -p PASSWORD cmd.exe
The official PsExec binary is not built into Windows. It requires remote administrative access and creates the PSEXESVC service/artifacts. Avoid putting real passwords in retained shell history; an existing authorized network credential context is preferable.
Verify → Verify destination and represented execution identity, not only service creation or tool success.
If it fails → Share write, SCM access, service start, endpoint controls and pipe communication can fail independently. More detail ↓
Explanation & examples
Execute through uploaded service creation using PsExec
- USE WHEN
- A destination grants administrative-share write and service-control rights
- STARTING ACCESS
- Identified authentication material, destination service reachability and a candidate authorized identity
- RESULT
- A service-backed remote execution channel with verified resulting identity
Recognize the clue
From an accepted SMB identity inspect the required administrative share and the separate ability to create/start services on that host.
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares
Authentication: accepted
ADMIN$: READ,WRITE
SCM create/start: not yet verifiedMeans: Administrative-share control is one PsExec prerequisite, not proof of every service/pipe operation.
Confirm: Validate actual SCM rights, binary compatibility, service start and named-pipe path; check the final execution identity.
- After validation
- All share/SCM/pipe conditions hold and remote effect is observed: use the service-upload method.
- Ruled out in this context
- ADMIN$ is unwritable or SCM creation is denied: reject this specific PsExec route.
- Still inconclusive
- A tool's admin label alone leaves exact method authorization unresolved.
Troubleshooting: Share write, SCM access, service start, endpoint controls and pipe communication can fail independently.
Need: SMB 445/139, writable administrative share and Service Control Manager rights. Impacket uploads a RemCom service binary, creates/starts a service and communicates over named pipes. Verify the returned identity; the service context is commonly SYSTEM.
Kerberos cache:
The target parameter uses the hostname matching the CIFS/HOST SPN; -target-ip separates connection routing from Kerberos naming.
The official PsExec binary is not built into Windows. It requires remote administrative access and creates the PSEXESVC service/artifacts. Avoid putting real passwords in retained shell history; an existing authorized network credential context is preferable.
Why it works
PsExec creates a service and communicates through its service/pipes. Its service execution identity can differ from the authenticated account; the official Windows tool and Impacket implementation have distinct artifacts/options.
Worked example · hypothetical
Observation: the identity can write the required administrative share and create services. Test: execute a minimal hostname/identity command. Illustrative output: the service channel returns SYSTEM on the intended host. Interpretation: verify token/network state and re-enumerate.
New identity, privilege, host or route? Re-enumerate → All topic tasks →