One interesting thing when using smart card authentication is that you can still use username and passwords even if the smart card is required. There have been many examples and articles about that you can still use Pass the Hash since the NT Hash is still in use.

This is just another twist on it focusing on the clear text password.

The support for using smart card has existed a long time in Windows, it was implemented in MS KILE as a Kerberos extension in Windows 2000 and is called PKINIT. The purpose was to get rid of using passwords and offer a strong authentication with 2 factors (not to mitigate Pass the Hash and Pass the Ticket etc).

Kerberos vs. NTLM

One interesting thing with the implementation of smart cards in Windows is that its only supported in Kerberos. NTLM doesn’t understand smart card authentication. With that said, it doesn’t mean that you can’t use NTLM anymore.

Quick intro Kerberos:
I’m not going to go thru everything about Kerberos, if your unfamiliar with it you can get more basic understanding here: What Is Kerberos Authentication and How the Kerberos Version 5 Authentication Protocol Works

Microsoft documentation states when a user authenticates with a smart card the process is:

1. After the user inserts a smart card, the Windows logon service (WINLOGON) dispatches this event to the GINA.
2. The user is prompted to enter a PIN (rather than a username and password).
3. The GINA sends the PIN to the Local Security Authority (LSA). Note: There is no logon domain information required, because the user is logged on with a User Principal Name (UPN).
4. The LSA uses the PIN to access the smart card and extract the certificate with the user’s public key.
5. The Kerberos security service provider sends the signed user’s certificate with the user’s private key to the KDC.
6. The KDC compares the UPN in the certificate with the UPN on the user object in the directory. The KDC also verifies the signature on the certificate to ensure that it was issued by a CA that’s trusted in the Active Directory forest, such as an Enterprise CA.
7. The KDC encrypts the logon session key and the TGT for the ticket granting service with the public key from the client certificate. This step ensures that only the client with the appropriate private key can decrypt the logon session key.
8. The client decrypts the logon session key and presents the TGT to the ticket granting service. After this process is complete, all other communication in Kerberos uses symmetric encryption.

If you read the documentation How the Kerberos Version 5 Authentication Protocol Works it is also stated that in the KRB_AS_REP message the NT Hash is sent to the client:

Field: Pre-authentication data

For the KRB_AS_REP message, this field will normally be empty.
One exception is if the client logged on with a smart card. In this case, because the user did not enter a name and password, the LSA does not have the user’s password. So, the user’s NTLM password and credentials are passed back to the LSA in this field (hashed and encrypted with the user’s key).

With this you can still use NTLM authentication to services in the background and one example could be:

Say that you have logged on using a smart card and go to a share on the network based on the IP address. If there is no IP SPN configured Kerberos won’t work and it will fall back to NTLM and you will be able to access the share (if you have the right permissions) with a SSO experience.

SMARTCARD_REQUIRED

If you have enrolled a smart card to a user, you have the option to configure if the user is required to use a smart card or if he will be allowed to use a password.

On the user account you can set the flag: SMARTCARD_REQUIRED – 0x40000 in the userAccountControl attribute.

If you don’t set that flag the user has the option to authenticate with a username and passwords (if the user is aware of the password) or the smart card.

When setting the SMARTCARD_REQUIRED flag the domain controller will wipe the existing keys (passwords) and generate a new random NT Hash on the user account. The pwdLastSet value will be updated to the current system time.

Default Keys in the database (ntds.dit)
 

Key after SMARTCARD_REQUIRED is set, only a new NT Hash exists

If we do a PW Reset all keys will be created and stored
 

The reason I added a picture of when a user has the smart card bit set and we do a password reset is that here it gets interesting.
If you know the password on that account, you can still use it to authenticate in some scenarios and skip the smart card even if its required.

And here is an important thing to note, in the ADUC the flag is named: Smart card is required for interactive logon.
This can be interpreted as the smart card is only required when performing an interactive logon and hopefully a remote interactive logon.

Different logon types:

Logon Type	Logon Title	Description
2	Interactive	A user logged on to this computer.
3	Network	A user or computer logged on to this computer from the network.
4	Batch	Batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention.
5	Service	A service was started by the Service Control Manager.
7	Unlock	This workstation was unlocked.
8	NetworkCleartext	A user logged on to this computer from the network. The user’s password was passed to the authentication package in its unhashed form. The built-in authentication packages all hash credentials before sending them across the network. The credentials do not traverse the network in plaintext (also called cleartext).
10	RemoteInteractive	A user logged on to this computer remotely using Terminal Services or Remote Desktop.

Source: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4624

When authenticating using the Kerberos protocol, the KDC will read the users userAccountControl attribute and if the flag SMARTCARD_REQUIRED is set it will deny any KRB_AS_REQ if the smart card logon data is not included and you will get a KDC_ERR_POLICY error.
This will scope all KRB_AS_REQ independent on what logon type you use, you still won’t get a TGT and will therefore not be able to get TGSTs to perform any logon type.

An example is that Active Directory Federation Services only supports Kerberos and you will get the following event IDs:

Event ID 4768 Audit Failure on Domain Controller

Result Code: 0xC = KDC policy rejects request

Event ID 4625 Audit Failure on ADFS

Pass the Hash or Use the Password

When setting SMARTCARD_REQUIRED the system generates a random password automatically as showed earlier, this makes it possible to still use NTLM (and default that password is never changed). The idea is that the user isn’t supposed to know about the password. But if we can perform a password reset on the user object we are now aware of the password.

Every object in Active Directory has a Security Descriptor with an Access Control List (ACL). The ACL has Access Control Entries dictating who can do what on what kind of object and its attributes.

If we can calculate the effective permissions allowing us to use the extended right “Force change password” aka Password Reset, we can now move around the network as that user. We could also combine this with modifying the userAccountControl attribute (if your allowed Write Account Restrictions) and disable SMARTCARD_REQUIRED and perform a password reset, the user won’t be given any notice. But there is a bigger chance that attribute is monitored. How many monitors password resets on Smart Card only accounts?

If we know the password we could hash it with a tool like DSInternals and use the PtH technique. Or we can try and authenticate with the clear text password.

A few examples where it works:

Test-Credentials

We can use this nice little script Test-Credentials and verify it with the username and password.

The result will say true and if we look at the event logs on the DC we will see a failed Kerberos authentication and a success NTLM authentication, and a Logon Success with the logon type 3 (Network Logon). So that seems to work with username and password with NTLM.

Runas

Runas is a nice little built-in tool in Windows which you can use to run as another user.

If we run the command: runas /netonly /user:demo.secid.se\tony powershell.exe we will open a new PowerShell instance and have Tonys credentials loaded and if we try to list the DCs C$ he will be authenticated and we will see a failed Kerberos authentication and then a succeeded NTLM authentication.

Remote Desktop Restricted Admin Mode (RDPRA)

RDPRA is a nice feature introduced in Windows 8.1 and Windows Server 2012R2 to help mitigate different credential theft techniques. You can read more about it in a previous post I wrote.

When you start Remote Desktop Connection with RDPRA use the /restrictedadmin switch, it will default to your logged-on user and you get a SSO experience. We can change that and choose to connect with another user. This will also work with username and password even if SMARTCARD_REQUIRED is set, it will try Kerberos first and the fall back to NTLM.

Note: Remote Credential Guard won’t work since it only supports Kerberos.

Event log on destination server

Summary

To make this clear, you don’t need to be local admin on a computer and being able to dump/insert the hashes in this scenario, or even perform Pass the Hash, the system takes care of it for you. All you need is to get some code running in the context of a delegated admin that has the Password Reset permission on your target users in the domain. When that is done you just need network connectivity and you can move around.

Mitigations:

A few things you can do is to audit who can reset the password by analysing the effective permissions on the objects. Set up event auditing and trigger alarms when a password reset is performed on a smartcard only account.

Some use a scheduled script that enrols the NT Hash on the smart card users on a regular basis. If you have Windows Server 2016 Domain Functional Level you can enable Expire Passwords On Smart Card Only Accounts and the NT Hash will be automatically changed according to password policy when authenticating. This doesn’t necessarily stop an attacker but can disrupt the movement and make some noise.

Fun fact: If Expire Passwords On Smart Card Only Accounts enabled and you set the pwdLastSet attribute to 0 (aka User must change password at next logon) on a user with SMARTCARD_REQUIRED, the NT Hash will be enrolled when the user authenticates the next time. If Expire Password feature isn’t enabled, nothing will happen when resetting the pwdLastSet attribute.

Other stuff you can do is to enable AMA or use the Protected Users group.

Authentication Mechanism Assurance (AMA)

Authentication Mechanism Assurance is a cool featured introduced in Windows Server 2008R2.
With AMA a administrator can link group membership from a specific certificate issuance policy which is included in the certificate template.
When a certificate-based, smartcard logon is performed with AMA enabled, the group membership is added to the user’s access token during logon. If he uses a certificate from another template or use username and password the group membership won’t be added in the access token.
The cool thing is that the group will always look empty and you cant add any users in it by modifying its members attribute.

You will need to have permissions on the specific OID stored in “CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=X” and remove the link.

Backlink from the group

NTLM will still work, but the beauty of this is that NTLM doesn’t understand AMA, it’s part of the PKINIT extension in Kerberos. So, when using the password or PtH, the attacker will never get the desired group membership protected by AMA.

If you want to test AMA, here’s MS Getting started guide:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd378897(v=ws.10)

Protected User group

Another way is to disable NTLM which could be a big job. Luckily in Widnows Server 2012 R2 a new group was introduced called Protected Users. When a user is added to that group and the Domain Functional Level is at Windows Server 2012 R2 the DCs will apply some non-configurable rules and one of them is to deny NTLM. This is a good starting point to protect administrators.

If the domain functional level is Windows Server 2012 R2 , members of the group can no longer:

• Authenticate by using NTLM authentication
• Use Data Encryption Standard (DES) or RC4 cipher suites in Kerberos pre-authentication
• Be delegated by using unconstrained or constrained delegation
• Renew user tickets (TGTs) beyond the initial 4-hour lifetime

One problem I have encountered is the combination with SMARTCARD_REQUIRED  and Protected Users group is that you will get a few errors in the Security and System logs.

System event log:
Log Name:      System
Source:        Microsoft-Windows-Kerberos-Key-Distribution-Center
Date:          2018-08-25 22:13:48
Event ID:      14
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DC01.demo.secid.se

Description:
While processing an AS request for target service krbtgt, the account tony did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18  17  23  24  -135  3. The accounts available etypes : 23  -133  -128. Changing or resetting the password of tony will generate a proper key.

The Security event log will show a failed Kerberos pre-authentication:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          2018-08-25 22:13:48
Event ID:      4771
Task Category: Kerberos Authentication Service
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      DC01.demo.secid.se
Description:
Kerberos pre-authentication failed.

Account Information:
Security ID: DEMO\tony
Account Name: tony

Service Information:
Service Name:                            krbtgt/DEMO.SECID.SE

Network Information:
Client Address: ::ffff:172.16.1.100
Client Port: 49472

Additional Information:
Ticket Options: 0x40810010
Failure Code: 0xE
Pre-Authentication Type: 0

Certificate Information:
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:

And after that you will see a success event for Kerberos pre-authentication. The reason is that when enabling SMARTCARD_REQUIRED on an account as shown earlier all the keys except the NT Hash will be removed and the NT Hash will be autogenerated by the system.

The keys are used in the negotiation of encryption levels used in the Kerberos protocol. AES keys was introduced in Windows Vista and Windows Server 2008. Older systems only supported DES and RC4 and it used the NT Hash as its key.

If we look at the network traffic in a Kerberos AS exchange the client first send a KRB_AS_REQ without PA data but provides supported Etypes:

PA-PK-AS isn’t suggested and the KDC will check for supported Etypes and here the problem starts. Since it only has the NT Hash it will be a conflict with the Protected Users group since it denies weaker encryption than AES. This will result in the event IDs mentioned earlier and we can see the error message: KRB_ERROR  – KDC_ERR_ETYPE_NOSUPP (14) in the network traffic.

The client will then send a new KRB_AS_REQ with PA data using PA-PK-AS (PKINIT) and everything will be ok. The user wont notice anything, it will just be annoying events in the logs.

If we set a password on the account, AES keys will be generated and you won’t get this events and the AS exchange with pre-authentication will have its natural flow where you instead for a KDC_ERR_ETYPE_NOSUPP error message, you will get KDC_ERR_PREAUTH_REQUIRED (25):

The client will redo the KRB_AS_REQ with PKINIT and the KRB_AS_REP will work and it will be encrypted with AES using the public key from the smart card certificate.

And that’s all folks!

Another option to deny NTLM is by using msDS-AuthNPolicies. But this is for Another day.