1

I have been researching kerberos and ntlm for the last couple of days and still got one thing unresolved.

After an interactive logon with kerberos, you will have in the cached credentials both kerberos tickets and ntlm hashes. I figured winlogon/lsass are responsible for calculating the NTHash from the plain password and saving it to lsass memory regardless of the kerberos authentication.

My question is, how the saving of the NTHash is preformed when a smartcard authentication takes place? Of course no plain text password in this case

Thanks, and if i stated wrong info please comment and correct me.

Eran Nahshon
  • 23
  • 4

1 Answers1

2

When you do a PKINIT authentication to the KDC an additional field is included in the krbtgt response in the PAC called PAC_CREDENTIAL_INFO. This includes supplemental credentials for your logon such as the NTLM hash and the data is encrypted to the PK (DH) session key. The PAC is stuffed into the TGT where it's unreadable by the client.

The client then requests a service ticket to the workstation, asking for the workstation ticket, using the TGT it just received. KDC obliges, and copies the PAC from the TGT into the service ticket, including the supplemental credential data. The client receives the ticket and can now decrypt the PAC. The client still has the DH session key from earlier, so it decrypts the encrypted supplemental credentials and if it contains the NTLM hash it processes as it normally would if it were a password logon.

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/2f9cae55-350a-423e-a692-1d16659e544a

Steve
  • 15,155
  • 3
  • 37
  • 66
  • Thanks for the perfect answer. The DH Session key is just the session key of the AS-Rep? Is it relevant that the key is derived via diffie-hellman? – Eran Nahshon Apr 06 '21 at 16:42
  • Or does the DH Key is used for the exchabge of the real .session key? – Eran Nahshon Apr 06 '21 at 16:49
  • It always uses the AS session key, but the suppl creds are only included in PKInit flows. PKInit can use straight DH, RSA, or ECDH to do key agreement, but the most common form in the real world is straight DH. The agreed key is then ran through a `string2key` function that concats some nonces with it and hashes it down using SHA1 or SHA256. This string2key'ed key is the encrypting key. – Steve Apr 06 '21 at 17:19