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
Can you 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 -
1. The user inserts his smart card and enters his own PIN in a logon window.
2. The smart card subsystem authenticates the users as the owner of the smart card, and retrieves the certificate from the card.
3. The smart card client sends the certificate to the KDC (Kerberos Key Distribution Center) on the DC.
4. The KDC verifies the Smart Card Logon Certificate , retrieves the associated User of this certificate and builds a Kerberos TGT for that user.
5. The KDC returns encrypted TGT back to the client.
6. 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”. Unlike passwords, GPO can force users to change their passwords periodically. This “feature” exposes huge persistence 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. Smart cards can’t protect against Pass-the-Hash, and their hash never changes.
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.
For example, during our test, AuthLite 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.
2FA solutions often require a lot of maintenance, whether it’s deploying it, forcing your users to adopt it, managing certificates, educating your users about how to manage their 2FA tokens, or even securing the operation required for managing 2FA users. However, even if you’ve managed to deal with all these issues, it is almost impossible to force your application and service accounts to work with your 2FA solutions. Depending on the 2FA solution you have, you probably won’t be able to Pass-the-Hash.
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.