By Tal Be'ery | March 6, 2014

Recently, we were approached by a customer that claimed to be immune to Pass-the-Hash and Pass-the-Ticket attacks, as they were using Windows Smart Card Logon. Ten minutes later, we had demonstrated these specific attacks on their “immune” environment, thus taking complete control over it.

This story made us realize that although on the face of it, Smart Card Logon in Windows seems like a good upgrade to the security of the authentication process, recommended by the PCI-DSS (Payment Card Industry-Data Security Standard) regulation, a deeper look reveals it has also a bad side to it as it provides a false sense of security in regards to credential theft from malware infected machines. To add insult to injury, Windows Smart Card logon has a truly ugly side to it, as it generates an “everlasting” hash, thus providing less security than the regular password-only logon process against Pass-the-Hash attacks.

This matter is so grave, that organizations may find themselves in a “PCI’s Catch 22″ situation: Implementing PCI’s recommended Smart Card Logon for Windows may be in breach of another PCI requirement: to change passwords on a regular basis.

How Windows Smart Card Logon Works

Smart Card Logon enables users to log in to the Windows system using a Smart Card and Personal Identification Number (PIN), instead of using the traditional user name and password login mechanism.

Windows logon with an optional Smart Card authentication. The user can choose to authenticate with either a Smart Card (denoted by a Smart Card icon) or a Password (denoted by the key icon)

Windows Logon with an optional Smart Card authentification. The user can choose to authenticate with either a Smart Card (denoted by a Smart Card icon) or a Password (denoted by the key icon)

A Smart Card is a credit card sized plastic plate, with an embedded integrated circuit chip that provides memory and a processing unit. The security of a Smart Card stems from the fact that its memory cannot be directly read, therefore making it ideal to store secret data. Even indirect access to the smart card is protected from misuse through a PIN, known only to the smart card’s owner.

The Smart Cards used in Windows environment store users’ certificates and private keys in their protected memory and their processing unit can perform public key cryptography operations, such as digital signing and key exchange.

Windows supports logging on with a Smart Card by using extensions to the Kerberos v5 protocol. Instead of typing a password, a user inserts the Smart Card to a reader that is attached to a computer to initiate the logon sequence. The user is then prompted to enter the PIN for the Smart Card. If the user’s PIN is valid, then the Smart Card’s stored certificate is validated against the Domain Controller by using extensions to the Kerberos v5 protocol. If the Domain Controller is able to validate the certificate, the user is logged on and granted rights and permissions to their account.

The Good: Reducing Repudiation Risks on Non-Compromised Machines

PCI-DSS (Requirements 8.2, 8.3) defines two-factor authentication as an authentication method which requires that two of the following three authentication methods:

  • Something you know, such as a password or passphrase.
  • Something you have, such as a token device or smart card.
  • Something you are, such as a biometric.

Since Smart Card includes an embedded private key (“something you have”) and requires PIN identification (“something you know”) it is a true two-factor authentication mechanism. Therefore, Smart Card Logon can reduce the risk of a user’s identity theft, since a potential imposter needs to steal two orthogonal factors in order to masquerade as the legitimate user.

As a result, the PCI-DSS recommends two-factor authentication for internal network access as a “compensating control” that can be used as a substitute for other controls when they are not applicable.

The Bad: a False Sense of Security

The problem starts when Smart Card Logon is perceived to provide protection in cases which it does not; most specifically malware attacks. The source of the error is very much understandable. The Smart Card is a detached physical device that protects its inner secrets and should be immune to a malware residing on the machine. Microsoft’s documentation states exactly that: “Because cryptographic operations are isolated from the operating system, Smart Cards are not susceptible to attacks on the operating system (such as buffer overflow attacks and memory dump attacks, which might reveal private keys or other cryptographic secrets).” It is likely that a reader following the guidelines presumes it is safe to logon to a malware infected machine with a Smart Card as no credentials are left on the machine once the card has been removed.

However, in Windows environment this logical argument is completely false. Smart Card’s secrets are indeed beyond the reach of a memory residing malware. However, both of the Windows supported authentication protocols, NTLM and Kerberos, create some memory stored tokens, namely the NTLM hash and the Kerberos ticket, to support the Single Sign on (SSO) authentication paradigm. These memory residing tokens, are generated during the process of every logon, including Smart Card logon. Consequently, Smart Card logon’s users are every bit as exposed as password logon users to Pass-the-Hash and Pass-the-Ticket attacks which allows the attacker to abuse the victim’s credentials and steal their identity long after the Smart Card has been removed from the infected machine.

The Ugly: Smart Card’s Generated NTLM Hash Never Expires

Smart Card’s Pass-the-Hash perils does not stop at its false sense of security. In order to support systems that require NTLM authentication, Windows needs to generate an NTLM hash. Since Smart Card does not have a password to derive the hash from, Windows engineer decided to artificially generate an NTLM hash for Smart Card users. The problem: this token, which is password equivalent, NEVER EXPIRES. This is not a implementation bug, as a Microsoft’s official white paper states it explicitly: “If the account has been configured with the attribute Smart Card required for interactive logon, then the NT hash is a random value calculated when that attribute was enabled for the account. This password hash is provided to the client computer during the smartcard logons process by the domain controller. This password hash that is automatically generated when the attribute is set does not change

Therefore, a malware that was able to grab the NTLM hash of a Smart Card’s user, steals her identity forever. The victim would have been better off had she used a password to login to the infected machine, as at least that password would have been expired eventually (typically after 90 days) and the malware would have lost the grip on her identity.

This Windows behavior seems to be in breach of the PCI-DSS regulation, as it violates requirement 8.2.4: “Change user passwords/passphrases at least every 90 days.”

Therefore, implementing Windows Smart Card authentication should be weighed very carefully by the security team and must be compensated with additional security controls to mitigate Pass-the-Hash and Pass-the-Ticket attacks.

  • Jim Harrison

    PCI also accommodates the fact that when SC or biometric auth is the only console login used, the password is deemed to be functionally irrelevant, since it is never known to a human and cannot be obtained in plain-text form.
    The way this article is written presumes design goals not in evidence. SC auth was never intended to mitigate PTH attacks. The password that is auto-generated by AD is ridiculously long, absurdly random and entirely unusable by humans. A OWF is used to generate the hash that is stored, and the password is immediately discarded and memory zeroed.
    I’m not saying that there aren’t valid concerns for PTH mitigation (there are!), but you don’t help anyone by comparing apples to alligators and arguing that they fail to make a motorcycle.

    • Tal Be’ery

      Hi Jim,

      Thanks for commenting.

      I could not agree more with your statement that solving PtH with SC auth is “comparing apples to alligators and arguing that they fail to make a motorcycle.” The problem is that there are people out there, trying to make these motorcycles. And as often happens with security design issues, it seems to work until it faces a real challenge and by then it is too late.

      Plus, you cannot ignore the fact, that as a by-product of the way SC auth is implemented in Windows, it aggravates the PtH situation. It doesn’t matter how random the password is, at the end of the day it translates into an NTLM hash. And when the NTLM hash is constant, the PtH attacker gets constant access.

      • Michael

        Windows Server 2012 R2 and Windows 8.1 with LSA Protection enabled, and the hashes and passwords are not vulnerable for PTH and PTP anymore

        • Tal Be’ery

          Hi Michael,

          Thank you for commenting.

          It’s true that Microsoft had enhanced the security of Windows 8.1 with the addition of several features, including “LSA protection”, but it certainly does not stop PtH and PtT attacks.

          Specifically “LSA protection” prevents code injection to the LSASS process by non-protected processes. (See )
          However, it does not prevent attackers from stealing the hashes and tickets by using other methods.

          You can validate it by downloading WCE and running it on your Windows 8.1 machine. (Or read about it in )

          In fact, in one of our coming blogs we will show that Windows 8,1 exposes even *MORE* attack surface for PtH and PtT attacks than older versions, so stay tuned :)

    • jasonlpopp

      Jim Harrison -it’s been a while post MS. I hope things are going well. :)

  • John

    H Tal,

    So, what you are referring to as far as the ever-lasting hash, is the behavior of the “Smart Card required for interactive logon” (SCRIL) bit on user accounts. You are 100% correct regarding that behavior, however it is pretty easily mitigated, at least to a point of being more secure than passwords expiring in 90 days. If you toggle the SCRIL bit, it changes the hash, making it quite easy to implement a script that does that and having it run once a day in the middle of the night (or whatever time works best for you user base to try and avoid flipping the bit while there are active sessions for that account).

    That still may not be great and definitely not the level of protection most people think they are getting from smart cards, but it is better than using passwords that only change once every 90/60/30 days…


    • Tal Be’ery


      Thank you for the great response.

      SCRIL toggling is indeed a way to get out of the everlasting NTLM hash problem. However, SCRIL toggling script is a script, not a refined built-in AD feature and therefore:

      a. Scripts tend to have “rough edges”: e.g. the changing of the hash will break active NTLM sessions, as you had hinted, therefore the necessity to do it “in the middle of the night”. This of course quite a problem for a multinational, multi-timezoned organization.

      b. It’s an “opt-in” security model, and security should be “opt-out”. Currently, the user has to be proactive about the everlasting NTLM hash problem. First, to know it exists, then search for the SCRIL toggling script and apply it.

      • John

        Absolutely! It is not ideal and definitely requires some more work and careful planning, but if you’re going to implement smart cards, then it is a necessity to mitigate the otherwise never changing hash. I only use smart cards in this fashion for Admin accounts and explicitly with the scripted SCRIL bit flip in place.
        BTW, thanks for the prompt response!

  • Pingback: #SmartCard #Logon: The Good, the Bad and the Ug...

  • Lavie

    Hi Tal,

    Nice article.

    Although this is important it is an infrastructure issue, the smartcard is only the authentication device and this attack will work on every think the generate a authenticated credential token.

    Using a smartcard on a windows domain with legacy support will of course cause the worst case scenario you mentioned of stealing the NTLM Hash.

    On modern domains or if you set it up the NTLM becomes fallback only or removed and then the attack surface is limited to the Kerberos ticket lifetime (which is also configurable) while the card is in te reader and the user was asked to insert his PIN (which should be noticeable to an educated user)

    All of those settings are of course playing with fire if you don’t fine tune it,
    but still the problem is in the infrastructure….


    • Tal Be’ery

      Hi Lavie,

      Thank you for commenting.

      I totally agree that the problem lies in the Infrastructure, i.e. Windows domains and Active Directory, and not in the Smart Cards themselves. However, the existing infrastructure is a given constraint, as 95 percent of Fortune 1000 companies currently use Windows domain with Active Directory ( ).

      Disabling NTLM: Setting the domain policy to accept only Kerberos authentication would certainly solve Pass-the-Hash attacks but it is not a viable option for most organizations, as there are many legacy systems within the domain that support NTLM authentication only.

      If NTLM is disabled, the attack surface is indeed the lifetime of a Kerberos ticket plus its renewal period. The default for the lifetime is 10 hours, but the ticket can be renewed for a week. (Microsoft says that the changing of defaults is not recommended I think that a week is quite a lot of time. Note, that once the Kerberos ticket is stolen the card presence becomes irrelevant: it does not need to be in the reader and the user does not have to input his PIN.