Virtual Smart Cards and password hashes in Active Directory 2016 Environments
The preface on this is to explore rotating password hashes in active directory 2016 environments and changes that were made to ease some of the administrative burden of getting password hashes to rotate after you set a privileged or non-privileged account to require a smart card for interactive authentication. This will also go into some strategies on securing privileged network accounts such as domain administrators.
First off, I’m sure I am not the first one to blog about this but wanted to show some steps involved in creating a virtual smart card in a Hyper-V based environment. You can do this even if your host physically doesn’t have a TPM based security chip. Here is the official Microsoft documentation on how to set up a virtual smart card:
I’ve already set up my ADCS template so I am going to run a simple command to provision a smart card. Make sure you have the TPM Checked in your Hyper-V environment.
Through an elevated command prompt window I’ll start the provisioning process for virtual smart card creation:
For a full breakdown of all tpmvscmgr.exe commands you can refer to the Microsoft Documentation here:
Once you execute the command you will be asked to create your pin and your virtual smart card will be created
From this point we now have a virtual smart card and I am ready to enroll it on my account with Active Directory Certificate Services. Below I’ve opened up a MMC console and added the Certificates console for my current user. The TPM Virtual Smart Card Logon is something that you will have to create in ADCS. The walkthrough guide I have linked goes over on how to do that.
Next I will get prompted for my PIN
After entering my pin the enrollment has succeeded.
From this point I can see my new created certificate for my account.
Lets see how this looks on first logon.
From the login screen select sign in options
Click on the security chip and enter your pin:
At this point you should be signed into your domain with your smart card. Pretty cool right?
So lets get to the issue that has been a problem prior to 2016 Active Directory environments. This demo account I have created has it’s password set on 9/22.
Next I am going to go ahead and mark this account to explicitly allow interactive logins with a smart card only.
A few docs on what this setting actually does:
So what happens here is the password will end up flipping to a 120 character value that is unknown to the user. To demonstrate this I’ll be turning wdigest on…disabling windows defender and running mimikatz…(Please don’t do this….ever)
Prior to 2016 once you selected to require smart cards for interactive authentication it would randomly rotate the password hash once. This presented some problems in pass the hash scenarios because even though it randomized the password it is static and administrators had to get creative in rotating this password hash on privileged accounts.
One of the interesting things that I’ve found… tweeted about…and even have seen other blog posts about it is this attribute on a 2016 domain controller.
Being able to have active directory automatically expire accounts such as these is definitely a good thing. The best way to take true advantage of this type of attribute is defining a fine grained password policy through the ADAC tool. In the tree view you can define a fine grained password policy in the password settings container.
From here I defined the password policy to expire passwords after 1 day as long as the users belong to a smart card users security group that I created in my lab AD environment.
Once I apply my user to the security group and run a gpupdate /force… I can see the setting has indeed taken effect.
The next day I login and do another mimikatz dump and I can see that the NTLM hash has indeed changed. So the above steps work as intended in 2016 environments.
Just because smart cards are used it still is not a full proof solution. There is some further work to do. We still have to worry about a few things:
You can still export Kerberos tickets:
Token manipulation is still an issue
Passing the hash is still an issue if obtained
How to fix some of these issues:
Token Impersonation: Mark your domain admin accounts as sensitive and cannot be delegated.
In order to have the least amount of problems with this setting I’d recommend that domain admin accounts only access domain controllers and nothing else. Use a different id for member servers in your environment. DA accounts should always be protected with smart cards for interactive authentication or some form of 2FA. If your DA accounts access other things such as sharepoint or other applications this setting could break some of those workflows. SANS digital forensics has an excellent blog (even though this one is old) its still relevant because not much has changed.
Credential Guard:
Credential guard was recently broken with the latest mimikatz update. Below illustrates how to effectively bypass credential guard and obtain passwords in plain text format.
Still enforce credential guard if you are running Windows 10 Enterprise SKU’s. There is no reason to stop. Virtualization based security for credential guard can be set in the following GPO path:
Computer Configuration\Administrative Templates\System\Device Guard\Turn on Virtualization Based Security
Enforce Debug privileges for Administrator accounts only.
One of the immediate things you will notice when invoking a mimikatz session is to invoke debug privileges. This is often required so that you can can extract password hashes and plain text passwords from memory. If you don’t give normal end users admin privileges it limits what you can do with mimikatz.
Protecting Domain Admins and Enterprise Admins for Member Servers and normal client workstations:
Enable these 4 GPO’s in user rights assignment. Putting Enterprise Admins and Domain admins in these 4 settings will effectively cut off these highly privileged accounts from logging into member servers and workstations that may have internet access or be compromised in some sort of fashion.
Obviously you do not enforce these settings in your privileged access workstation environment when you may be using these types of accounts to perform work.
Attempting to log into a workstation or member server with these four permissions set will result in the following error:
For devices that have smart cards assigned to them (whether physical or virtual) these permissions. These settings can be enforced from Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\
Another setting to think about is the previous logons to cache (in case the domain controller is not available. Most security baselines suggest at maximum 4 logons
So there should be a fine line on this setting and some things to think about. Member servers that may live in a always connected datacenter with redundant connections should have this setting marked to 0.
Desktops with privileged access should also have this marked to 0. Mobile devices and remote non privileged devices should have this set to 4 or less. Having cached credentials on a workstation or servers can lead breadcrumbs to account compromises. You can read more about that in one of my previous blogs on the protected users security group.
and abusing cached credentials:
Domain admins should be added to the protected users security group. As long as you are on a 2012 R2 domain or newer you will be able to utilize the security group to further protect DA credentials.
In conclusion I would also recommend Microsoft’s document on password-less strategies for Windows 10 Hello for business. Even if you don’t want to use Windows 10 hello I still use password-less strategies in my lab environment to reflect real work scenarios on getting away from using passwords. It’s helpful in detecting pitfalls and pain points you may experience doing this sort of thing.
Password-less Strategies in action:
Group policy enforcement of requiring the use of Smart Cards/Windows Hello for business and excluding the passwords credential provider in windows. Second screenshot shows Enabling rolling of expiring NTLM secrets during sign in. This is only available if your forest is on the server 2016 level.
Originally I got a good deal of this information together to present at security conferences. Hopefully next year I can present some of my strategies for securing virtual labs and real world exploitation scenarios around going passwordless.
