Fake Privilege Attribute Certificate or PAC abuse
Short blog on how MS14-068 works with a small example
In this blog we will take a look at the MS14-068 vulnerability better known as Fake Privilege Attribute Certificate abuse with a small Hackthebox machine example
Executive Summary
On 2014 Microsoft disclosed a new Active Directory Kerberos vulnerability 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. When this security bulletin was issued, Microsoft was aware of limited, targeted attacks that attempt to exploit this vulnerability.
What is PAC ?
The Privileged Attribute Certificate (PAC) is an extension to Kerberos tickets that contains useful information about a userโs privileges. This information is added to Kerberos tickets by a domain controller when a user authenticates within an Active Directory domain. When users use their Kerberos tickets to authenticate to other systems, the PAC can be read and used to determine their level of privileges without reaching out to the domain controller to query for that information
PAC Validation is a feature that can be enabled or disabled on a Windows system. When enabled, the PAC of a user authenticating to that system will be checked against Active Directory to make sure it is valid. So this is basically put in place to avoid forged PACs.
This can be enabled with the registry key ValidateKdcPacSignature found here: [HKLMSYSTEMCurrentControlSetControlLsaKerberosParameters]
Setting this to 0 will turn off PAC Validation.
PACs contain very sensitive information and therefore have been the target of several Active Directory attack techniques like golden and silver tickets.
MS14-068
MS14-068 or CVE-2014-6324 is a critical active directory vulnerability that lets an attacker to forge a golden ticket without any special privilege. As per the CVE -
The Kerberos Key Distribution Center (KDC) in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, and Windows Server 2012 Gold and R2 allows remote authenticated domain users to obtain domain administrator privileges via a forged signature in a ticket, as exploited in the wild in November 2014, aka "Kerberos Checksum Vulnerability."
Simply stated, the vulnerability enables an attacker to modify an existing, valid, domain user logon token (Kerberos Ticket Granting Ticket, TGT, ticket) by adding the false statement that the user is a member of Domain Admins (or other sensitive group) and the Domain Controller (DC) will validate that (false) claim enabling attacker improper access to any domain (in the AD forest) resource on the network. This is all done without changing the members of existing AD groups.
When a user logs on with domain credentials for the first time, the user name and password are validated by the Domain Controller and the DC enumerates the userโs group membership and logon restrictions. A domain logon token (TGT) is created with this data and provided to the user.
One of the benefits of Kerberos is that the user doesnโt have to re-authenticate to the Domain Controller to access resources on the domain, the user simply presents the logon token (TGT) to the DC and receives a resource access token (Kerberos Ticket Granting Service, TGS, ticket). The user then provides the resource access token (generated by the DC and specific to the user) to the server hosting the service the user wishes to access. The resource access token includes the userโs information including the userโs group membership enabling the resource to determine if the user should be granted access and what level of rights the user has.
The issue here is that core to this functionality is that the DC trusts all non-expired logon tickets (valid for 10 hours by default) since they are signed by the domainโs Kerberos account (KRBTGT). In other words, Kerberos tickets signed by a (writable) DC on the network are inherently trusted as correct since they are signed by the DCโs Kerberos service account (KRBTGT). When the DC receives an access request for a service on the network, the userโs token (TGT) is supposed to be validated by checking the signature to ensure the userโs claim is a valid one.
For example
Logon Token (TGT): โI am Joe User and I am a member of the following groups: Domain Users, Domain Admins.โ
The Domain Controller should validate the claim that Joe is a member of these groups (also called PAC validation), not by enumerating group membership again (which was done before the ticket was generated), but by validating the cryptographic signature on the token which was signed by the domainโs Kerberos account (KRBTGT) and for which only a Domain Controller in that domain knows the credentials. This is done for improved efficiency โ since the work was already done by a DC and signed by that DC that it was performed; another DC takes the claim at face value and doesnโt attempt to enumerate the userโs group membership again.
The vulnerability introduces a scenario where an attacker can modify an existing Kerberos user logon token (TGT) changing the group membership claim to include a higher-privileged group.
Logon Token (TGT): โI am Joe User and I am a member of the following groups: Domain Users, Limited Access Users Domain Admins, Special Project Users, Executive Access, Super Secret Share Access.โ
Since the DC doesnโt properly validate the signature associated with the claim (the attacker modified the Kerberos ticket and changed the checksum to be invalid), the DC accepts Joeโs token and associated group membership and generates a resource access token (TGS) which includes the group membership included in the logon token (TGT).
At this point, the attacker has a valid user token with a claim that the user is a member of groups that do not have the user listed as a member in AD. However, since the user token states the user is a member of these groups and the Domain Controller generates this token based on the userโs actual group membership at the time of token generation, the user is treated as if he is a member of these groups by all domain resources.
An attacker can take the modified user logon token (TGT) and present it to gain access to any resource on the network by requesting resource access tokens (TGS). The resource accepts the resource access token since it is signed by the DC and even if the resource requests validation of the group membership (because itโs cautious), a DC will validate it. The resource then allows the users access to the level of permissions configured on the resource appropriate to the userโs group membership.
This enables an attacker on a computer in the AD domain with a valid AD credential to effectively impersonate any user in the domain since the PAC contains user or group Security Identifiers (SIDs). This means that an attacker can bypass all configured resource ACLs which limit access on the network by spoofing credentials for any user in Active Directory.
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.
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.
Practical Example
In this part we will see a practical example of exploiting MS14-068
HackTheBox Mantis
In this scenario we will be taking a look at machine on HackTheBox called Mantis.
Scenario -> The attacker has already gained initial foothold and have the credentials for the user we're targeting. To know how we got to this point refer the below walkthrough
pageHackTheBox - MantisWe will be exploiting this vulnerability remotely as we already have credentials. To make this attack more efficient there is an impacket script called goldenpac.py
Also the kali linux has an already built-in script called "impacket-golenpac" to avoid potential python2 errors
The syntax to perform the attack is as follows
The command is self explanatory
This results in the shell as "nt authority\system" in the Domain Controller(For this example) although it can be abused to access various resources in the network.
P.S -> I will be updating this blog to add various scenarios to abuse MS14-068 ๐
Thank You for reading ๐ฅ
References
Last updated