Intro
Most of the modern organizations today use Active Directory for managing organization resources and permissions.
As you may expect, this is a field that was widely researched from a security perspective, adn at the point of writing this article, the typical AD environment is a joyful playground for an adversary actor.
Despite all the fuckups that became trivial for both attackers and defenders, I wouldn’t bet that AD will be gone in the near future. If we’ll add a little bit of encryption concepts on top, it gets wayyy better 😊
Today I will present an attack that got (by me, of course) the name “Anderson PAC”. The attack objective is to obtain the user’s NTHash without touching lsass.exe.
In order to utilize the attack we will get our hands dirty with a variety of AD Technologies and perform a deep-dive to authentication protocols, especially when involving digital certificates (and smartcards) – a rising topic that is worth your attention.
The article aims to people that have basic AD background and are familiar with cryptography concepts, authentication and domain attacks.
Let’s start with a question – Why do smartcards exist?
It’s one of many cases in which a better solution for a common problem is formed to overcome the drawbacks of the existing solutions. The problem is providing an easy and secure authentication mechanism in the AD environment. In most of the AD networks, each user has a password that he uses to login to machines in the domain and for accessing domain resources. A password (as well as the human beings using it) has several issues when it comes to security:
- Easy to forget.
- Breakable hash (NetNTLMv1 for example).
- Requires maintenance and rotating.
- Prone to password-guessing attacks.
Of course, all the above can be solved (partially perhaps) with strong password policy and forcing password rotation often, but it remains an old and dirty practice to maintain in medium-large organizations.
Fortunately, plain passwords are not the only solution providing proof of identity at big scales, there are other alternatives as the main one is authentication using Smartcards and/or Biometric Measures.
At the user end, all he has to remember is a simple 6-digits pin code or simply using his finger/face for biometric recognition. Under the hood the authentication takes place using Certificates and corresponding Private keys issued by the CA server of the network for a particular user.
This kind of authentication is also referred to as PKINIT Kerberos (Public Key for Initial Authentication in Kerberos).
CA Server – Certificate Authority, a server which functions as a “Source of truth” for issuing digital certificates for all kinds of usage. All the entities in the organization in which the CA Server is deployed trusts the CA Server, so the certificates it issues are used as authenticity proof, optionally creating trust models across other CA for other networks.
Common usage: HTTPS Certificates, Authentication Certificates (both users and computers)
I will elaborate on PKINIT Kerberos later in the article, focusing on the difference between PKINIT Kerberos extension and classic Kerberos.
How does the AD determine which users authenticate with smartcards?
Smartcards enforcement does not apply to all of the organization, but it is a configuration on a per-user basis. That’s how it looks in the dsa.msc GUI interface:
Or using simple Ldap query:
# Check if user is SmartCard enforced. if the query returns output,
# it is enforced. (Can append! before userAccountControl).
$results = ([adsisearcher"(&(objectCategory=user) (userAccountControl:1.2.840.113556.1.4.803:=262144))").FindAll()
I will make a short overview of the Kerberos protocol inner workings for an appetizer before diving into the main course. For those of you who feel familiar with the topic, feel free to skip this part. And for those of you who are unfamiliar with Kerberos, I recommend reading this article before moving on.
The participating actors are the Client, the Server and the KDC.
The Key Distribution Center is the server that runs on the domain controller and handles incoming Kerberos requests. The KDC contains two sub-services, each responsible for different phases in the Kerberos procedure.
- AS – Authentication Server. As its name implies, it is responsible for the authentication part, which is the first part of the full Kerberos process. Authentication is meant to verify the user’s identity, mostly using a password that is used as a shared secret between the two parties.
- TGS – Ticket Granting Service, sub service that is responsible for issuing tickets for different services in the domain. After the user is authenticated, he requests tickets to different services, and those tickets are used for accessing the resources.
The whole Kerberos process is divided into 3 parts, each of them in the form of Request-Response. Let’s dig in.
- KRB_AS_REQ – the request that the client sends the server for authentication.
The proof of identity will be inserted to the pre-authentication field,
and it is basically a timestamp encrypted with the user’s password Hash. This authenticator also provides proof of identity, and prevents replay attacks as the KDC rejects all requests in which the timestamp is not in the last 5 minutes.
- KRB_AS_REP – after the request is delivered, the KDC will search the user in the NTDS.DIT database and will try to decrypt the authenticator with the corresponding hash of the user.
If the decryption succeeded, the KDC is forming an answer.
It generates a session key and forms the PAC (structure which contains further details about the user). The KDC answer is divided into two parts – the TGT, an opaque blob containing the session key and the PAC (encrypted with krbtgt’s hash) and the TGS session key, encrypted with the user’s password hash.
- KRB_TGS_REQ – after the client gets the TGT and the session key, he stores them in memory for later use – issuing requests to services across the organization.
When access to a service is needed, the client sends a TGS request. The client presents the TGT with an authenticator (timestamp encrypted with the session key from the previous phases) and tells the TGS which service he wants to get access to using SPN (Service Principal Name – each service that supports Kerberos must have an SPN registered).
- KRB_TGS_REP – the TGS sub-service gets the request, and starts from decrypting the TGT, ensuring its validity. From the TGT he obtains the session key, which is used to validate the authenticator (having the TGT is not sufficient for the user, proof of holding the corresponding session key is required). If both checks are good, then the user proved he got authenticated
in the AS phase, so the TGS is forming the response. The TGS performs a lookup for the SPN, and if he finds it, he takes the SPN’s service account hash and creates a service ticket.
The service ticket contains a fresh session key (referred to as Service session key) and the user’s PAC, encrypted with the service account hash. This service ticket is sent with the service session key encrypted with the TGS Session key back to the user.
- KRB_AP_REQ – after the client decrypts the service session key, he caches it with the service ticket for later use. When accessing the service that was previously requested, the client generates a request containing the service ticket, and an authenticator encrypted with the service session key. The server will get the request and decrypt the ticket. The server trusts the decrypted data as the encryption key is known only to the server and the KDC.
The server will obtain the service session key and then will try to authenticate the authenticator. If successful, the server can be sure the request originates from an authenticated user. After validation occurs, the server will grant access to the resources according to the user authorization data (from the PAC) and permissions.
- KRB_AP_REP – optional. That message is meant to provide mutual authentication, assuring the server’s authenticity to the client. This message is an authenticator encrypted with the service session key. If the client successfully validated the authenticator, that means that the server managed to decrypt the service ticket, which means that he holds the service account hash, thus he is not an imposter.
In interactive logon there is a slight difference. The “service” we ask for is our machine (Host SPN to our machine). The service session key goes into the service ticket with the user’s PAC, and all this is encrypted with the computer account password hash of the machine.
After recalling the inner workings of Kerberos protocol, let’s examine the differences between Classic Kerberos and PKINIT Kerberos, in which we are interested in order to perform the attack.
Before starting, I will point out one important emphasis. The difference lies only in the initial authentication. Afterwards, the TGT will be used in the same manner for both mechanisms, and NTLM will be used to provide SSO experience.
Remember that Kerberos in its essence does not support a-symmetric encryption. It uses symmetric encryption with password hash as the key and session keys that are exchanged along the process. So, there are a couple of adjustments to be made for Kerberos to support private/public keys. And this is the PKINIT Kerberos mentioned earlier.
Classic Kerberos relies upon the fact that shared secrets exist between the Client and the KDC, so each of the parties verifies the identity of the other. Knowing the secret and carrying out the authentication process is sufficient to confirm the authenticity of both parties. Similar kind of mutual authentication takes place in the KRB_AP phases (steps 5-6). With a-symmetric encryption, the absence of a shared secret is a problem. Then how will we prove our identity to the DC?
In regular Kerberos, the pre-authentication field in the AS_REQ message will contain an authenticator – timestamp encrypted with the user’s password hash.
In PKINIT Kerberos, the pre-authentication field in the AS_REQ message will contain a value of the type PA-PK-AS-REQ which contains a cryptographic proof of identity. How does it work? The user has two things in order to carry out the authentication:
- Digital Certificate holding the username and his corresponding public key. This certificate was issued from the CA server.
- Private key matching to the public key from the certificate. This key must be treated in a secret and secure manner, otherwise the whole process is compromised. The private key is used to prove that the user is indeed the entity that issued the certificate from the CA.
So how does the client prove his identity to the DC? He will send in the pre-auth field the certificate together with timestamp encrypted with the private key (again, for replay attacks remediation). The DC will receive these and will validate as follows:
- First the DC will verify the digital certificate using a list of CA Public Keys it holds. This list is all the public keys of the CA servers that it trusts. Each CA has a private key which is used to sign the certificates, and the trusting entities hold the public key for the verification of these.
- Afterwards, the DC will obtain the public key from the certificate itself (do not confuse with the CA public key. This public key is unique for each certificate). This key is used for decrypting the authenticator (remember? Asymmetric encryption magic!).
- If all succeeded, the user proved holding the private key, thus he is the one issued the certificate. If the time in the timestamp is fit, then the KDC will generate a TGT (according to the username stated in the certificate) and return it to the user. From now on, all Kerberos messages are as usual.
An example for certificate used to authentication:
Okay, so we got that PKINIT Kerberos works with a certificate and a private key. Those are used to prove the user’s identity. But how these two are saved in a secure manner, and still will allow authentication in every domain-joined machine? We are hardly able to remember a password, surely not a certificate. That’s when the smartcard kicks in.
A Smartcard is a small hardware device, containing x.509 certificate, and private keys. The private keys are not accessible either for writing or reading from the machine context. In addition, the smartcard is able to perform basic cryptographic actions, so the private key is never saved anywhere on the machine.
The OS uses API calls to interact with the smartcard, issuing requests to cryptographic actions using the private key, and only the result is returned. But “there ain’t no such thing as a free lunch” when it comes to smartcards. The smartcard will perform these cryptographic operations only after the correct pincode is provided.
After providing pincode (or biometric info) which is valid, an AS_REQ message of the type of PA-PK_AS-REQ that has in the pre-auth field a certificate and authenticator with the private key (again, each certificate contains a public key. The private key on the smartcard) is sent. From now on the rest of the Kerberos messages are handled in the standard way.
Now that we have a solid grasp on PKINIT Kerberos, we will try to figure out how to obtain persistence over a user. From an adversary perspective, when dealing with regular authentication, if the password/password’s hash is discovered, then it’s practically game over until the next password change. When dealing with smartcards, it’s more complicated.
To answer the question above, we need to remember the equivalent of Kerberos, good old NTLM.
In NTLM, the user’s hash is used to calculate a response to a challenge received from the server, and this is the proof of identity. But now, we don’t have passwords. Only certificates and their private keys. So, is there any kind of PKINIT NTLM? The answer is no.
Then maybe NTLM is not enabled for smartcards users? This is of course not true, as NTLM is crucial for legacy systems and backwards compatibility. Thus, smartcard users have to use NTLM, and it does happen.
The way that NTLM is still possible is that the KDC generates NTHash to every smartcard enforced user, for NTLM usage. Not only this, this NTHash is useful only to perform NTLM, as Kerberos is based on PKINIT.
Let’s understand better the meaning of NTHash. Regular NTHash is just unsalted MD4 on the plaintext password. Now we do not hold a password, but as stated above, there is an NTHash. The KDC appears to generate the NTHash randomly in each user enforcement.
That means that every time the enforcement checkbox is checked, an NTHash is randomly generated to enable NTLM for the enforced user.
We’ll observe how user get two different Hashes, even that all that happened between the two pictures is not checking and checking the checkbox:
After:
By default, the NTHash of an enforced user is never changed unless it is actively rotated, or in case that enforcement is removed and returned. That makes it even more persistent than a regular password that has an expiry date. That means – enforced user’s NTHash is a high value asset for an attacker.
How can rotation still be forced? For domain functional level 2016, it is possible to configure auto-rolling of the NTHash for smartcard users. Otherwise, alternative solutions in the shape of scripts exist (link in the end of the article).
A small example to demonstrate which data is saved on a user in the DC end when the user enforced and when not. Before the enforcement, the user has NTHash, LMHash, AES Keys for Kerberos and NTLM.
No enforcement:
After enforcing, only NTHash is saved for the user:
I hope I managed to Illustrate the value of enforced user’s NTHash. Now let’s figure how we get it 😊
Tl;dr – extracting NTHash without touching lsass.exe memory for smartcard users.
It’s all nice and interesting, but that’s not the reason we gathered here today. I will examine techniques that enable adversaries to get victim’s NTHash without lsass.exe being involved.
The scenario is of an attacker that obtains a foothold on the victim’s machine, but the machine has some mitigations applied such as LSA Protection and/or Cred Guard that prevents traditional credential theft methods. The Anderson PAC attack enables quiet and elegant bypass for that problem, based on network traffic only, exploiting the PKINIT Kerberos mechanism. The attack result is of course the long-awaited NTHash.
The pincode of the smartcard is mandatory.
How did it all start?
During my research of smartcard authentication, I understood how Kerberos is held in the PKINIT way with certificates and private keys. You should know this as well if you made it this far. Another thing you know for sure, is that smartcard enforced user support NTLM as well.
The combination of the two leaves us with a gap. I have noticed in my lab experiments that after smartcard authentication, I could use mimikatz to simply get the NTHash from the lsass.exe memory (with no mitigations applied of course) even though the NTHash has nothing to do with PKINIT Kerberos!
How did it get there?
Confused? So was I. But remain calm, we will soon uncover this mystery. We do understand how the NTHashes are assigned but the main question is – how do they get to the user’s machine? In regular Kerberos login a password provided and saved by the NTLM provider in lsass.exe.
In smartcard Kerberos, the machine does not have a way to know the NTHas, so there are only two possible explanations left. The DC passes this information during the PKINIT Kerberos somehow (as the DC is the only entity knowing this secret), or this information arrives on angels’ wings in a magical way.
The NTHash traveling
I tried my luck on stackexchange. I won’t keep you in suspense, the first answer is correct. In a sentence – during the PKINIT Kerberos exchange, inside the service ticket, there is a PAC field containing the NTHash. Which service ticket are we talking about? The Host service ticket!
Relevant only to PKINIT Kerberos. In regular Kerberos there is no need to provide the NTHash, and it is indeed not found in the PAC.
Host ticket?
Quick reminder about host tickets, and why they make this attack possible. The host ticket is a service ticket for a default SPN, and it is required when interactive logon occurs. This is excellent, as the ticket is encrypted with the computer account hash for the wanted machine.
The machine that the service ticket is requested can be decided by the attacker, so if the service ticket is for a machine that the attacker compromised, he can decrypt the ticket.
Getting computer account hash is relatively easy, and does not even require memory reading, as all the details saved in the registry. If the attacker couldn’t compromise any machine for any reason, he can add a new Computer account with impacket’s addComputer.py (enabled by default to unprivileged users).
hax0r@SDB-Kali-2020-3:~$ python3 /usr/share/doc/python3 imacket/examples/addcomputer.py sdb.secret/caspit:Bb123456 -computer-name ERAN$
Impacket v0.9.23 - Copyright 2021 SecureAuth Corporation
[*] Successfully add machine account ERAN$ with password LV869HHqYivQA2JXrNY1ixIKWGefKqo8.We assume that the host service ticket is for a compromised machine, thus is decryptable. We will see later what waits after the decryption.
Bonus that I won’t elaborate on – it is possible to request a U2U service ticket instead of a host ticket. That way we can decrypt the ticket without the need of machine compromise. The credit for that trick is for the security researcher Elad Shamir.
I have mentioned many times along the article the term PAC. The PAC, Privilege Attribute Certificate is a component of Kerberos tickets which is responsible among other things for user authorization.
Further than authentication, Kerberos can provide authorization, that means that the KDC gathers all the SIDs and group memberships for the user, and stuffs it in the PAC. This data is later used to form an access token, representing the user’s permissions and privileges.
- Authentication – verification of authenticity, proof of identity.
- Authorization – describing the identity of the entity for permissions checks.
All this data is packed into the PAC, then goes into the TGT. Why the TGT? so the DC could take this PAC from the TGT and copy it to future service tickets. When these will open on the target file server for example, it will read the PAC to form the access token.
In addition to this authorization data, the PAC also contains an Additional Credential Information field (remember this 😊), and a couple of irrelevant details.
This picture demonstrates the TGT structure in a great way. You can see that the PAC contains details about the user, as well as signatures on the PAC data.
In practice, the PAC is more as shown in the picture. It contains a struct of the type AD-ID-RELEVANT, which in turn contains a struct of the type AD-WIN2K-PAC. Those function as wrappers, and the structs that they wrap are where our interest lies.
The PACTYPE structure is the header of the PAC and following are the PAC_INFO_BUFFER array, each of them points to a buffer and describes which data type will be found in that buffer, so the PAC could store various types of data.
- PACTYPE – used as a header before the PAC_INFO_BUFFER and is not so interesting to be honest. The cBuffers indicates the number of the PAC_INFO_BUFFERs, and the Buffers is the array of PAC_INFO_BUFFERs.
- PAC_INFO_BUFFER – used as the header of the info buffer. Contains the buffer size, its offset and the buffer type. The buffer type describes which data is written to this buffer.
In the table we can see most of the interesting buffer types. 0x1 is authorization information (Sids for example), 0x2 is additional credential information, and 0x6-0x7 are checksum and so on.
I hope your alarm went off now, but even if it didn’t, let’s rollback a little bit and remember why we dug in all those PAC structures in the first place – that is because we want to find the PAC buffer that will hold the NTHash we are chasing. In practice, we must traverse all the PAC_INFO_BUFFERS until we’ll find a buffer of type 0x2, which will hold the PAC Credentials.
This struct of the PAC is meant for passing credentials to alternative protocols (random example – NTLM) than what was used for the initial authentication (PKINIT Kerberos). I was very upset to find out that the struct I was luring for has been encrypted again inside the PAC! That means that this struct is encrypted twice, first inside the PAC and then another time with the whole ticket. I will solve that later on.
PAC_CREDENTIAL_INFO – the outer structure, using as the header. This struct isn’t encrypted and contains details about the encryption of the rest of the data (encryption algorithm that was used) and the encrypted data itself.
The common encryption types are RC4 and AES256_CTS_HMAC_SHA1_96. Their values are 0x17 and 0x12 in accordance. The encrypted data is the struct PAC_CREDENTIAL_DATA.
PAC_CREDENTIAL_DATA (encrypted) – contains an array of CRED_SUPPLEMENTAL_SECPKG, and the number of items in the array.
CRED_SUPPLEMENTAL_SECPKG – contains the package name to which the credential belongs, and a pointer to the credentials as well as the size.
NTLM_SUPPLEMENTAL_CREDENTIAL – as his name implies. Contains additional credentials for NTLM authentication. Bull’s Eye! Now we will take the NtPassword. That’s the holy grail right there.
How to decrypt the PAC_CREDENTIAL_DATA?
A debt I owe from early on. I stated that the PAC_CREDENTIAL_DATA is encrypted twice. The second encryption is solved as we hold the machine account hash.
So now we must decrypt the first encryption, which in the original flow is encrypted by the KDC and decrypted by the client, but in PKINIT the DC and the client don’t share any secret! So what key is used to encrypt this blob?
It appears that there is a key exchange using Diffie-Helman in the AS-REQ-REP, and it is called AS Replay key. This key is used to encrypt the PAC_CREDENTIAL_DATA inside the service ticket.
Since the NTHash is relevant only when PKINIT Kerberos is used for interactive logon, then the host service ticket will be requested immediately after the AS_REP is received.
The client saves aside the AS Replay key and will use it to decrypt the PAC_CREDENTIAL_DATA when he gets the TGS_REP, and the resulted supplemental credentials are saved as the AS Replay key is thrown away. The meaning of it is that holding a service ticket is not sufficient, we will need to get a hold on the AS Replay key as wll.
We conclude that it would be necessary to initiate the PKINIT TGT request, so we can get a hold on the AS Replay key, and after that request the service ticket to the compromised host, and then decrypt our way (the ticket itself and then the PAC_CREDENTIAL_DATA) to the beloved NTHash.
To get the AS Replay key we can edit Rubeus’ askTGT function to print the Replay Key.
key = pkAsReq.Agreement.GenerateKey(pkAsRep.DHRepInfo.KDCDHKeyInfo.SubjectPublicKey.DepadLeft(),new byte[0], pkAsRep.DHRepInfo.ServerDHNonce, GetKeySize(etype));
//OFIR ADDED THIS
Console.WriteLine("\r\n[*] AS-Reply Key: {0}\r\n", Convert.ToBase64String(key));
Yes, I know that it is complicated. All the structs and the encryption keys got me blurry too, and I believe the best way to understand is by example. We first ask TGT with askTGT, and with the edited Rubeus version we get the AS Replay key and save it aside for later use. With the TGT we’ll ask for a host service ticket to the host of our choice, of course a host that we hold the credentials of. So, let’s start decrypting!
To the next magic I’ll use decryptKerbTicket.py straight out of github to decrypt the host service ticket with the computer account’s hash.
*(from my experience, decryptKerbTicket.py required python2.7 and impacket 9.18 to work well)
I will now take the decrypted ticket from the output and continue.
It is possible to examine in hxd the PAC structure, and even some of the values:
Black – the PACTYPE (you can notice the two first fields – the number of PAC_INFO_BUFFERs which is 6 and version which is 0).
Red – the PAC_INFO_BUFFER of the KERB_VALIDATION_INFO (type 1, size 0x1D8, offset 0x68). Contains SIDs and authorization data.
Blue – the PAC_INFO_BUFFER of the PAC_CREDENTIAL_INFO (type 2, size 0x90, offset 0x240). This is the direction we are heading.
Now we’ll go to offset 0x240 and take buffer of the size 0x90:
You can see in the picture above the version – 0x00000000, the encryption type – 0x00000017 (RC4). Following, all the bytes between the orange marks is the encrypted blob, or more accurately – the PAC_CREDENTIALS_DATA. We take this blob and decrypt it with simple python script based upon imapcket, using the AS Replay key from the beginning:
Now all that is left is some encoding stuff (not in the article scope), but we can now notice the package name bytes (NTLM) and the bytes sequence that is highlighted below is the NTHash we searched for!
All the binary tickets and script utilizing the attack can be found in the next github repository: https://github.com/e99ran/Anderson_PAC.py
The technique demonstrated above is useful in every scenario of PKINIT logon, not only when a smartcard is involved.
Recently, Israeli Security Researcher named Elad Shamir published a tool that enables compromising user given permissions to write to his AD attributes. In summary – this method leverages the Windows Hello mechanism that enables biometric authentication in environments with no CA server.
Windows Hello works by generating key-pair to each user, saving the public key in the AD as an attribute for the user, and the private key is saved at the user end as the secret. This resembles SSH authentication. The authentication of Windows Hello, if you happen to wonder, is PKINIT Kerberos, and with the attack described in that article, it’s possible to obtain the user’s NTHash at any moment, even if he changes his password!
Another use-case is if we managed to attack an ADCS server (Microsoft implementation for CA Server, mostly in domain environments), and issue a certificate behalf other user in the domain. We can use that certificate to obtain his NTHash with the Anderson PAC technique at any moment.
Further reading
The tool elad shamir published
https://github.com/eladshamir/Whisker.
A comprehensive whitepaper on ADCS attacks
https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf
A tool that can leverage NTLM Relay attack to issue a certificate:
https://github.com/bats3c/ADCSPwn
After I have finished my research, I have discovered that Benjamin delpy already implemented this technique in kekeo, but didn’t bother to write in anywhere (you really thought different?) besides the next twit:
Summing up
We have talked in this article about advanced technique for obtaining NTHash without reading memory, its use-cases and the circumstances that make this attack possible.
This method stayed under the radar in the last few years, and when I conducted this research there was barely even documentation for that topic. Ever since, the certificates attack vector in AD got more and more relevant, and a couple of amazing research papers and tools have been published. The latest tools you can use are PKINIT Tools of Dirkjan or Rubeus in his latest version (2.0).
In general, the ADCS field is getting interesting, and it may be the future of AD attacks. I hope I have managed to give you a solid starting point to learning this field, and if I didn’t, I sure hope at least it was interesting.
Eran Nachshon, Pentester in AD environments and Security researcher. I want to thank my teammate Ofir Tal, who helped me a lot during this research, and he is also a top-level guy.
If you have any questions or comments, you can slide into my DM in twitter or by mailing me at eerann9@gmail.com
Bibliography
[MS-PAC]: Privilege Attribute Certificate Data Structure | Microsoft Docs
RFC 4556 – Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
Decrypt kerberos tickets and parse out authorization data · GitHub
about NTHash Rolling for PKINIT Users:
Comments are closed