MS14-068: Vulnerability in (Active Directory) Kerberos Could Allow Elevation of Privilege

Active Directory leverages the Kerberos protocol for authentication. The vulnerability patches an issue with how the Domain Controller validates group membership in Kerberos tickets (hint: the ticket is always validated by the DC if the checksum is set to certain values). Microsoft KB3011780 patches this issue.

According to Microsoft: “When this security bulletin was issued, Microsoft was aware of limited, targeted attacks that attempt to exploit this vulnerability.”

Note that Windows Server 2012 impact is less vulnerable than previous Windows versions (i.e., it’s much harder to exploit on Windows Server 2012/2012R2), but all Domain Controllers should be patched ASAP, starting with DCs running Windows Server 2008R2 and below. Patch servers next and workstations last to support “defense-in-depth.” Additionally, Azure Active Directory doesn’t expose Kerberos over any external interface and is not affected by this vulnerability.

MS14-068 References:

Get Domain Controller patch status with this sample PowerShell script: Get-DCPatchStatus (rename file extension to .ps1)

Exploiting MS14-068:

As of December 4th, 2014, there is Proof of Concept (POC) code posted that exploits MS14-068 by Sylvain Monné by using Python to interact with an unpatched DC generating the invalid Kerberos ticket and then Mimikatz to use the ticket.
UPDATE: I have successfully tested the MS14-068 exploit in my lab and posted detailed information including WireShark pcaps and DC event logs.

Kerberos TGT PAC Invalid PAC Signature Checksum validation Issues in MS14-068:

Benjamin Delpy (author of Mimikatz) describes the actual vulnerability with how the PAC signature is checked during his presentation at Passwords 2014 (2 video from the top). I extracted the relevant slide from this presentation (shown below).
There were issues with PAC signature validation in 2011, so going back and looking at MS11-013 is a good start to dig in and see what the actual issue is with MS14-068’s issue with invalid PAC signature checksum validation.

According to his presentation, Benjamin notes the following:

  • Before the MS11-013 patch, the PAC signature was valid if the checksum size was less than or equal to 20 (checksum <= 20)
  • After the MS11-013 patch, the PAC signature was valid if the checksum size was less than or equal to 20 (checksum <= 20) and the checksum is KEYED.
  • After MS14-068 patch, Microsoft added an additional verification step to ensure the checksum type is KRB_CHECKSUM_HMAC_MD5 (or AES in NT6)



Here’s how Kerberos works (in a nutshell):

Ticket Granting Ticket (aka logon ticket)

1. Joe User logs on with his Active Directory user name and password to a domain-joined computer (usually a workstation). The computer takes the user’s password and runs a one way function (OWF) creating a hash of the password (typically the NTLM hash). Hashing the password is like taking a steak and running it through a meat grinder. The ground beef that is the result can never be reassembled back into the same steak we started with.
This is used to  handle all Kerberos requests for the user (as well as other authentication methods such as NTLM).

2. Kerberos authentication is initiated by sending a timestamp (PREAUTH data) encrypted with the user’s password-based encryption key (password NTLM hash).

3. The user account ( requests a Kerberos service ticket (TGT) with PREAUTH data (Kerberos Authentication Service Request or AS-REQ).

4. The Domain Controller’s Kerberos service (KDC) receives the authentication request, validates the data, and replies with a TGT (Kerberos AS-REP). The TGT has a Privileged Attribute Certificate (PAC) which contains all the security groups in which the user is a member. The TGT is encrypted and signed by the KDC service account (KRBTGT) and only the domain KRBTGT account can read the data in the TGT.
[The vulnerability exists where the PAC is not correctly validated and the exploit requests a TGT without a PAC]

At this point, the user has a valid TGT which contains the users group membership and is used to prove the user is who they claim to be in further conversations with a Domain Controller (KDC). The TGT is sent to the Domain Controller every time a resource ticket is requested.

Ticket Granting Service ticket (aka resource access ticket)

5. When the user wants to access an AD resource (a file share for example), the user’s TGT from step 4 is presented to a Domain Controller (KDC) as proof of identity with a request for a resource ticket to a specific resource (Service Principal Name). The DC determines if the TGT is valid by checking the TGT’s signature and if valid, generates a resource access ticket (TGS) signed/encrypted with the KRBTGT account and a part encrypted with the Kerberos service account’s session key which the destination service uses to validate the TGS.
Note: The DC doesn’t validate the user has the appropriate access to the service, it only validates the TGT and builds a TGS based on the TGT information.

6. The resource service ticket (TGS) is sent to the user by the Domain Controller and is used for authentication to the resource. At this point, all communication has been between the user’s computer and the Domain Controller (KDC).

7. The user’s computer sends the user’s resource service ticket (TGS) to the service on the resource computer. If the destination service is a file share, the TGS is presented to the CIFS service for access.

8. The destination service (CIFS in this example) validates the TGS by ensuring it can decrypt the TGS component encrypted with the service’s session key. The service may send the TGS to a DC (KDC) to validate the PAC to ensure the user’s group membership presented is accurate. The service reviews the user’s group membership to determine what level of access, if any, the user has to the resource.

PAC Validation
described in the blog post Understanding Microsoft Kerberos PAC Validation:

The Privilege Account Certificate (PAC) is an extension element of the authorization-data field contained in the client’s Kerberos ticket. The PAC structure is defined in [MS-PAC] and conveys authorization data provided by domain controllers (DCs) in an Active Directory-enabled domain. It contains information such as security identifiers, group membership, user profile information, and password credentials.

Note: This does not solve the Golden Ticket or Silver Ticket issues since those are technically valid Kerberos tickets.

The Kerberos Golden Ticket is a valid TGT Kerberos ticket since it is encrypted/signed by the domain Kerberos account (KRBTGT). This crafted TGT requires an attacker to have the Active Directory domain’s KRBTGT password hash (typically dumped from a Domain Controller). Mimikatz fully supports generating Golden Tickets.

The Kerberos Silver Ticket is a valid Ticket Granting Service (TGS) Kerberos ticket since it is encrypted/signed by the service account configured with a Service Principal Name for each server the Kerberos-authenticating service runs on. While a Golden ticket is encrypted/signed with the KRBTGT, a Silver Ticket is encrypted/signed by the service account (computer account credential extracted from the computer’s local SAM or service account credential). We know from the Golden Ticket attack (described above) that the PAC isn’t validated for TGTs until they are older than 20 minutes. Most services don’t validate the PAC (by sending the TGS to the Domain Controller for PAC validation), so a valid TGS generated with the service account password hash can include a PAC that is entirely fictitious – even claiming the user is a Domain Admin without challenge or correction. Mimikatz fully supports generating Silver Tickets.

Since service tickets are identical in format to TGTs albeit with a different service name, all you need to do is specify a different service name and use the RC4 (NTLM hash) of the account password (either the computer account for default services or the actual account) and you can now issue service tickets for the requested service.  Note:  You can also use the AES keys if you happen to have them instead of the NTLM key and it will still work ;-)

It is worth noting, that services like MSSQL, Sharepoint, etc will only allow you to play with those services.  The computer account will allow access to CIFS, service creation, and a whole host of other activities on the targeted computer.  You can leverage the computer account into a shell with PSEXEC and you will be running as system on that particular computer.  Lateral movement is then a matter of doing whatever you need to do from there :-)

MS14-068 Executive Summary:

This issue described in MS14-068 involves either creating or modifying an existing, valid Kerberos ticket with a modified PAC and invalid checksum. Since the KDC service on Domain Controllers perform PAC validation, a TGS with a PAC can be sent to the DC requesting validation and apparently, pre-MS14-068 patch, the DC validates the invalid PAC. This enables an attacker on a computer in the AD domain with a valid AD credential to effectively spoof any user in the domain (and likely the forest) since the PAC contains SIDs (group or user SIDs). This means that an attacker can bypass all resource ACLs on the network by spoofing credentials for any user in Active Directory.

Note: After installing the update, for Windows 2008R2 and above, the 4769 Kerberos Service Ticket Operation event log can be used to detect attackers attempting to exploit this vulnerability. This is a high volume event, so it is advisable to only log failures (this will significantly reduce the number of events generated). [From Microsoft Security Bulletin MS14-068 – Critical Vulnerability in Kerberos Could Allow Elevation of Privilege]

CERT describes the issue in CWE-347: Improper Verification of Cryptographic Signature

The Microsoft Windows Kerberos KDC fails to properly check for valid signatures in the Privilege Attribute Certificate (PAC) included with the Kerberos ticket request. A domain user may forge the information contained in the PAC to request higher user privileges than should be allowed. Since the KDC does not verify the signature correctly, it will award the user the requested privileges, effectively making the user a domain administrator and allowing complete compromise of the entire domain.

This is FAR worse than the Golden Ticket issue since an attacker doesn’t need the (usually difficult to obtain) KRBTGT acount password hash.
In other words, you need to apply the MS14-068 patch to all Domain Controllers in your forest ASAP!

From Microsoft Security Bulletin MS14-068 – Critical Vulnerability in Kerberos Could Allow Elevation of Privilege: 

This security update resolves a privately reported vulnerability in Microsoft Windows Kerberos KDC that could allow an attacker to elevate unprivileged domain user account privileges to those of the domain administrator account. An attacker could use these elevated privileges to compromise any computer in the domain, including domain controllers. An attacker must have valid domain credentials to exploit this vulnerability. The affected component is available remotely to users who have standard user accounts with domain credentials; this is not the case for users with local account credentials only.

A remote elevation of privilege vulnerability exists in implementations of Kerberos KDC in Microsoft Windows. The vulnerability exists when the Microsoft Kerberos KDC implementations fail to properly validate signatures, which can allow for certain aspects of a Kerberos service ticket to be forged. Microsoft received information about this vulnerability through coordinated vulnerability disclosure. When this security bulletin was issued, Microsoft was aware of limited, targeted attacks that attempt to exploit this vulnerability. Note that the known attacks did not affect systems running Windows Server 2012 or Windows Server 2012 R2. The update addresses the vulnerability by correcting signature verification behavior in Windows implementations of Kerberos.


What might an attacker use the vulnerability to do?
An attacker could use this vulnerability to elevate an unprivileged domain user account to a domain administrator account. An attacker that successfully exploited this vulnerability could impersonate any user on the domain, including domain administrators, and join any group. By impersonating the domain administrator, the attacker could install programs; view, change or delete data; or create new accounts on any domain-joined system.

How could an attacker exploit the vulnerability?
An authenticated domain user could send the Kerberos KDC a forged Kerberos ticket which claims the user is a domain administrator. Kerberos KDC improperly validates the forged ticket signature when processing requests from the attacker, allowing the attacker to access any resource on the network with the identity of a domain administrator.

What systems are primarily at risk from the vulnerability?
Domain controllers that are configured to act as a Kerberos Key Distribution Center (KDC) are primarily at risk.

Further technical detail is provided in a blog post by Joe Bialek on the Microsoft Security Research and Defense Blog:

CVE-2014-6324 allows remote elevation of privilege in domains running Windows domain controllers. An attacker with the credentials of any domain user can elevate their privileges to that of any other account on the domain (including domain administrator accounts).

The exploit found in-the-wild targeted a vulnerable code path in domain controllers running on Windows Server 2008R2 and below. Microsoft has determined that domain controllers running 2012 and above are vulnerable to a related attack, but it would be significantly more difficult to exploit. Non-domain controllers running all versions of Windows are receiving a “defense in depth” update but are not vulnerable to this issue.

CVE-2014-6324 fixes an issue in the way Windows Kerberos validates the PAC in Kerberos tickets. Prior to the update it was possible for an attacker to forge a PAC that the Kerberos KDC would incorrectly validate. This allows an attacker to remotely elevate their privilege against remote servers from an unprivileged authenticated user to a domain administrator.

Detection Guidance

Companies currently collecting event logs from their domain controllers may be able to detect signs of exploitation pre-update. Please note that this logging will only catch known exploits; there are known methods to write exploits that will bypass this logging.

The key piece of information to note in this log entry is that the “Security ID” and “Account Name” fields do not match even though they should. In the screenshot above, the user account “nonadmin” used this exploit to elevate privileges to “TESTLAB\Administrator”.

After installing the update, for Windows 2008R2 and above, the 4769 Kerberos Service Ticket Operation event log can be used to detect attackers attempting to exploit this vulnerability. This is a high volume event, so it is advisable to only log failures (this will significantly reduce the number of events generated).

After installing the update, exploitation attempts will result in the “Failure Code” of “0xf” being logged. Note that this error code can also be logged in other extremely rare circumstances. So, while there is a chance that this event log could be generated in non-malicious scenarios, there is a high probability that an exploitation attempt is the cause of the event.


PAC Validation Detail

Decrypting the PAC

As described in Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources:

The PAC is generated by the KDC under the following conditions:

  • During an AS request that has been validated with pre-authentication.
  • During a TGS request when the client has no PAC and the target is a service in the domain or a ticket granting service (referral ticket).

The PAC contains two digital signatures: one using the key of the server, and one using the key of the KDC. The signatures are present for two reasons. First, the signature with the server’s key is present to prevent a client from generating their own PAC and sending it to the KDC as encrypted authorization data to be included in tickets. Second, the signature with the KDC’s key is present to prevent an untrusted service from forging a ticket to itself with an invalid PAC. The two signatures are sent in PAC_INFO_BUFFERs of type PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM respectively.

The fields are defined as follows:

  • SignatureType — This field contains the type of checksum used to create a signature. The checksum must be a keyed checksum.
  • Signature — This field consists of an array of bytes containing the checksum data. The length of bytes may be determined by the wrapping PAC_INFO_BUFFER structure.

For the server’s checksum, the key used to generate the signature should be the same key used to encrypt the ticket. Thus, if the enc_tkt_in_skey option is used, the session key from the server’s TGT should be used. The Key used to encrypt ticket-granting tickets is used to generate the KDC’s checksum.

The checksums are computed as follows:

  1. The complete PAC is built, including space for both checksums
  2. The data portion of both checksums is zeroed.
  3. The entire PAC structure is checksummed with the server’s key, and the result is stored in the server’s checksum structure.
  4. The server’s checksum is then checksummed with the KDC’s key.
  5. The checksum with the KDC key is stored in the KDC’s checksum structure.
Security Considerations

Before the PAC data is used for access control, the PAC_SERVER_CHECKSUM signature MUST be checked. This will verify that the provider of the PAC data knows the server’s secret key.

Validation of the PAC_PRIVSVR_CHECKSUM is OPTIONAL. It is used to verify that the PAC was issued from the KDC and not placed in the ticket by someone other than the KDC with access to the service key.

Caution must be used with accepting the SIDs present in the logon-info part of the PAC. Only SIDs from a domain that is authoritative for a particular domain’s SIDs should be used in the construction of access tokens. If a SID is found to be from outside of a domain’s authoritative SID namespace, it MUST be ignored for purposes of access control.

From the MSDN Protocol Reference 4.2: Kerberos PAC Validation:

  1. The client tries to access a resource requiring Kerberos authentication. The client sends an AP-REQ message to request authentication from the server.

  2. The server passes the PAC to the operating system to receive an access token. The server operating system forwards the PAC signature in the AP-REQ to the domain controller for verification in a KERB_VERIFY_PAC message.

  3. The domain controller verifies the signature on the response and returns the result to the server. The error is returned as the appropriate RPC status code.

  4. The server verifies the AP-REQ, and sends an AP-REP if the verification is successful.




(Visited 21,090 times, 1 visits today)