SmartCard and Pass-the-Hash

On a pretty consistent basis, SmartCard and Multi-factor Authentication (MFA) technologies are brought up when discussing Pass-the-Hash/Pass-the-Ticket with customers. Many customers believe they do not need to worry about such attacks as they have non-repudiation.

However, what Smartcard was set to solve was before Pass-the-Hash/Ticket (or Overpass-the-Hash) was a real thing! At that time, preventing users from providing their cleartext password to a fake website (i.e. waterhole attack) was the goal--how could we prevent that from happening? Here, hardware-backed authentication was born. There was no password to leak, as the user himself/herself didn't know it either! They simply had a pin, backed with hardware public key encryption.

But one small issue...

At that time, the threat was really loss of a plaintext password.  On the backend, a random NTLM hash was given to the user.  The NTLM hash stays the same--until the user changes their password. But if the user doesn't know their password, how would they change it? There lies part of the problem... but there was a larger previously unknown threat evolving...

"What Smartcard was set to solve was before Pass-the-Hash/Ticket (or Overpass-the-Hash) was a real thing"

Then, Pass-the-Hash became a thing which Mimikatz and Windows Credential Editor (WCE) made popular. Here, the adversary doesn't even care anymore about the entropy of the NTLM hash (or that the user doesn't even technically have a known cleartext password), they simply harvest the credentials in memory (NTLM hash, Kerberos TGT) and use it to inject it in other processes to masquerade as that user. But without a smartcard, how is that possible? Well, SmartCard Required for Interactive Logon (SCRIL) has two very important words in it: "Interactive Logon". Interactive Logons are only 2 types of logons that can occur:

What does this mean? I can steal the NTLM hash and move laterally with that credential via the other logon types! Don't try to prevent SCRIL-enabled users from only doing these two logons either—this will break things like allowing them to manage devices and be productive employees by automating some of their own tasks. Better yet, lets focus on the problem.

What a better way to do that then a quick video? :)

So now what do we do with this, knowing the actual risk?

Well first, first step is knowledge.  Next step, lets see how we can roll those NTLM hashes.  We will provide two solutions below.  And of course, we fully recommend our customers and anyone focused on targeted attacks to leverage Advanced Threat Analytics!

PowerShell Script

Here, a script is provided that discovers your Smartcard Required Interactive Logon (SCRIL) users, and turns the SCRIL-bit off and on. It is this time when the NTLM-hash is randomized.
https://blogs.technet.microsoft.com/poshchap/2015/05/08/security-focus-resetting-smart-card-is-required-for-interactive-logon/

Domain Functional Level 2016

Domain Functional Level (DFL) 2016 includes a new feature to help get past some of the limitations of the PowerShell script. This is fully supported by Microsoft and we recommend anyone who is using Smartcard Required for Interactive Logon (SCRIL) to turn this bit on!

For more on this:
/en-us/windows-server/security/credentials-protection-and-management/whats-new-in-credential-protection

 

Welp, that is the quick and dirty on this topic.  Please do check out Advanced Threat Analytics to discover this and other attacks in your environment by focusing on Identity.  Leave questions in the comments!