MS14-068 References:
- AD Kerberos Privilege Elevation Vulnerability: The Issue
- Detailed Explanation of MS14-068
- MS14-068 Exploit POC with the Python Kerberos Exploitation Kit (aka PyKEK)
- Exploiting MS14-068 Vulnerable Domain Controllers Successfully with the Python Kerberos Exploitation Kit (PyKEK)
This post shows the packet captures I performed using WireShark on the Domain Controllers during stage 1 and stage 2 of the attack.
Microsoft KB3011780 patches this issue.
Here are the full packet captures:
Stage 1 – Using PyKEK to inject a forged PAC into a valid TGT: ADSecurityOrg-MS14068-Exploit-KRBPackets
Stage 2 – Using Mimikatz to leverage the forged TGT into the user session & connect to the unpatched Domain Controller’s admin$ share: ADSecurityOrg-MS14068-Exploit-KRBPackets-TGTInjection-And-DC-AdminShare-Access
Note: Using the information posted here, it may be possible to create a Snort signature that can identify active MS14-068 exploitation on a network by looking at the TGS-REQ Kerberos packet that states “include-pac: False” (additionally, the AS-REQ packet earlier in the conversation also states “include-pac: False”)
Stage 1 Attack Packets: PyKEK requests and modifies a TGT
.The Python script performs a TGT request (Kerberos Authentication Service Request aka AS-REQ) and instead of requesting a TGT with a PAC (default AS-REQ), PyKEK requests a TGT with no PAC from the Domain Controller.
Once the script receives the valid TGT without a PAC from the DC, the script generates a PAC (with the group membership listed above) packages it in encrypted authorization data as part of a TGS request to the DC (Kerberos Ticket Granting Service Request aka TGS-REQ) to obtain another TGT (a new one with the PyKEK generated PAC).
“The vulnerable KDC will verify it with MD5 and give you another TGT with a PAC in it”.
This is the TGT that PyKEK saves to the ccache file used for stage 2.Since PyKEK communicates with the Domain Controller for valid TGTs, the TGT is a valid ticket (other than the forged PAC it includes). To summarize, there are two TGTs involved in the process: the original one without a PAC as a result of the first AS-REQ and a second one the DC delivers in the TGS-REP with the PyKEK generated PAC.
NOTE: The TGT is technically not modified by PyKEK since it is encrypted by the KDC account (KRBTGT). The process the script uses results in a valid TGT with the PAC PyKEK created that is accepted by an unpatched DC. The genius part of this is that PyKEK uses the Kerberos AS & TGS exchanges to forge a PAC and have the DC place it into a new user TGT. Then when the TGT is presented later on in Stage 2 for a valid TGS, the PAC is accepted and its values carried on into the new TGS for a Kerberos service in AD.
From the post entitled “Exploiting MS14-068 Vulnerable Domain Controllers Successfully with the Python Kerberos Exploitation Kit (PyKEK)“
c:\Temp\pykek> ms14-068.py -u darthsidious@lab.adsecurity.org -p TheEmperor99! -s S-1-5-21-1473643419-774954089-2222329127-1110 -d adsdc02.lab.adsecurity.org
[+] Building AS-REQ for adsdc02.lab.adsecurity.org… Done!
[+] Sending AS-REQ to adsdc02.lab.adsecurity.org… Done!
Stage 1 Packet #1: TGT request (AS-REQ) with no PAC.
Recent Comments