This method can only determine if a logon used Public Key Cryptography for Initial Authentication (PKINIT); successive locks / unlocks will continue to report the information from the initial logon.
According to this article: http://social.technet.microsoft.com/wiki/contents/articles/11844.find-out-if-a-smart-card-was-used-for-logon.aspx, a special security group is injected into the user’s access token when a smart card is used. Comparing the current user token group members between a password and smart card authenticated session revealed the group “NT Authority\This Organization Certificate” (S-1-5-65-1). (PowerShell for this below)
A search for S-1-5-65-1 returned this article: https://msdn.microsoft.com/en-us/library/cc980032.aspx, with the following information:
| THIS_ORGANIZATION_CERTIFICATE
S-1-5-65-1 |
A SID that indicates that the client’s Kerberos service ticket’s PAC contained a NTLM_SUPPLEMENTAL_CREDENTIAL structure (as specified in [MS-PAC] section 2.6.4). If the OTHER_ORGANIZATION SID is present, then this SID MUST NOT be present. <25> |
Following the link to section 2.6.4 leads to the description: “The PAC buffer type is included only when PKINIT [MS-PKCA] is used to authenticate the user”
So, by what I can find and test, the presence of “NT Authority\This Organization Certificate” (S-1-5-65-1) in the user’s access token groups positively indicates whether the initial authentication used PKINIT, e.g., smart card.
This can be tested with the following PowerShell code:
$objGroup = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-65-1")
([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups.Contains($objGroup)
WLS now uses a similar method with SessionMonitor. Any time a session changes, the AuthenticationType, CredentialProvider, and PKINIT will now be reported.
2015-11-18T07:16:54-06:00 [host] WLS_SessionMonitor: LogType=”WLS”, ApplicationName=””, AuthenticationType=”Kerberos”, BuildNumber=”0″, ClientAddress=””, ClientDirectory=””, ClientName=””, CredentialProvider=”Smartcard Credential Provider”, EncryptionLevel=”High”, HardwareId=”0″, InitialProgram=””, Message=”SessionUnlock”, PKINIT=”True”, ProductId=”0″, Protocol=”Console”, Resolution=”640×480″, SessionId=”10″, SessionName=”Console”, SourceAddress=””, SourceName=””, User=”[domain]\[user]”, WLSKey=”677″, WorkDirectory=””
For more information on WLS, click “WLS Information” at the top, or here: WLS Information
If you’d like additional information about WLS, send me a note via the contact form. WLS is currently available to US entities, but does require a signed license agreement.
digirati82 
Do you think it is possible to use this information to prevent pass-the-hash, or even track it, in token authenticated domains? I know that there would need to be exceptions based on the need for service accounts and other special accounts, but this could be useful information to at least identify malicious traffic inside of a network.
With a good logging infrastructure it is definitely possible to track anomalous account activity, and adding this information provides a way to further filter out legitimate activity. In environments where users are expected to log on with a smart card, especially if it’s not being enforced by the domain, it’s fairly easy to run a search for logons that did not use smart card and set an alert at an appropriate threshold. I’ve put in similar alerts for too many logon attempts (successful and unsuccessful) from a single source host to multiple destination hosts and as the transition to smart card only happens I expect the false positive rate to drop. Great question!