Why Are Smart Cards Attackers’ Favorite Persistence Tool?

Want create site? Find Free WordPress Themes and plugins.

Active Directory Security Myth Busters - Smart Cards and 2FA

When hit by an APT attack, many companies implement smart cards and/or other two-factor authentication mechanisms as a reactionary measure. But thinking that these solutions will prevent credential theft is a big mistake. Attackers can bypass these protection mechanisms with clever techniques.

Nowadays, adversaries in the form of self-spreading malware or APT campaigns utilize Pass-the-Hash, a technique that allows them to escalate privileges in the domain. When Pass-the-Hash is not handy, they will use other techniques such as Pass-the-Ticket or Kerberoasting.

In this experiment, we will perform the four most common credential theft attacks on a domain-connected PC with both smart card and 2FA enabled.

Clear text password theft
Pass the hash attack
Pass the ticket attack
Process token manipulation attack

Pass The Smart Card Hash

A smart card is a piece of specialized cryptographic hardware that contains its CPU, memory, and operating system.

When authenticating a user with a smart card and PIN (Personal Identification Number) code in an Active Directory network (which is 90% of all networks), the Domain Controller returns an NTLM hash. The hash is calculated based on a randomly selected string. Presenting this hash to the DC identifies you as that user.

This hash can be reused and replayed without the need of the smart card. It is stored in the LSASS process inside the endpoint memory, and it’s easily readable by any adversary who has managed to compromise the endpoint using tools like Mimikatz, WCE, or even just dumping the memory of the LSASS process using the Task Manager. This hash exists in the memory because it’s crucial for single sign-on (SSO) support.

This is how smart card logon works:

The user inserts his smart card and enters his own PIN in a logon window.
The smart card subsystem authenticates the user as the owner of the smart card and retrieves the certificate from the card.
The smart card client sends the certificate to the KDC (Kerberos Key Distribution Center) on the DC.
The KDC verifies the Smart Card Logon Certificate, retrieves the associated user of this certificate, and builds a Kerberos TGT for that user.
The KDC returns encrypted TGT back to the client.
The smart card decrypts the TGT and retrieves the NTLM hash from the negotiation.

Presenting only the TGT or the NTLM hash from now on will get you authenticated.

During standard logon, the NTLM hash is calculated using the user’s password. Because the smart card doesn’t contain a password, the hash is only calculated when you set the attribute to “smart card required for interactive logon”. GPO can force users to change their passwords periodically. This “feature” exposes huge persistency security risk. Once the smart card user’s computer is compromised, an attacker can grab the hash generated from the smart card authentication. Now he has a hash with unlimited lifetime—and worse, lifetime persistency on your domain because the hash will never change as long as “Smart Card Logon” is forced on that user.

However, Microsoft offers a solution for the smart card persistence problem: they will rotate the hashes of your smart card account every 60 days. But it is only applicable if your Domain functionality level is Windows Server 2016.

Smart cards can’t protect against Pass-the-Hash, and their hash never changes.

Pass-The-2FA Hash

During authentication with some third-party 2FA, the hash is calculated from the user’s managed password. And because the password is managed, it is changed frequently and sometimes even immediately.

In some cases, 2FA managed to mitigate Pass-the-Hash attempts because the hash was calculated using the OTP (one-time password). Therefore, the hash won’t be valid anymore, and the adversary who stole it won’t be able to authenticate with it.

Other vendors like AuthLite mitigated Pass-The-Hash attempts because the cached hash of 2F sessions is manipulated by AuthLite, so stealing the hash in the memory is useless. There’s still additional verification in the DC, and the OTP must be forwarded to AuthLite before authenticating as a 2FA token.

Depending on the 2FA solution you have, you probably won’t be able to Pass-the-Hash.

Pass-the-Ticket With Smart Card And 2FA

Exporting all of the cached Kerberos tickets of our privileged user, and injecting his KRBTGT Ticket bypasses the defense of any smart card and 2-FA solution.

The reason behind it is that a TGT ticket presents a “post-authentication user session”, so we’re already authenticated as a 2-FA token, and there’s no way to identify that the TGT was reused by a malicious actor.
As long as the TGT hasn’t expired, the ticket will stay valid.

Smart cards and 2FA can’t protect against Pass-the-Ticket.

Token Manipulation With Smart Card And 2FA

Assuming you, as an attacker, have a running process with local administrator privileges, you can steal the token of any running process and use it for your own process. As a result, you can impersonate any user that exists in the machine without even stealing credentials.

Because the tokens are already authenticated, 2FA and smart cards won’t be able to protect them. Using Mimikatz or Invoke-TokenManipulation, you can impersonate the 2FA admin privileged user and steal his privileges.

Smart cards and 2FA can’t protect against token manipulation.

Clear Text Passwords Theft With Smart Card And 2FA

Choosing the attribute “smart card required for interactive logon” means your password won’t be supported anymore. Therefore, there’s no technique to steal clear text passwords in order to authenticate.

Smart cards only mitigate clear text password theft.