Defeating pass-the-hash attacks with two-factor authentication

Posted by:

root 6 years, 9 months ago

Implementing two-factor authentication for remote access is a great way to keep attackers out of your network.  Users' credentials are floating all around the internet.  But attackers can still get in your network through malware and other tools.  In the past, we described how two-factor authentication can be used at each stage of an attack to make detection easier and execution much harder:

• Implementing two-factor authentication for remote access will make intrusion much more difficult.
• Implementing two-factor authentication for privileged accounts will make escalation much more difficult.
• Implementing two-factor authentication at your outbound proxy will make exfiltration much more difficult.

The PCI Council is now requiring two-factor authentication for non-console administrative access. To see how easy the pass-the-hash attack is and to show how WiKID can mitigate it, we present the tale of two domain administrators. One uses a static password, the other uses the WiKID Native Active Directory 2FA protocol.

In our lab we setup two boxes: a windows domain server using Server 2012 and a PC running windows 10.  On the Win 10 box, download two tools:  Mimikatz and PStools.  We will use mimikatz to grab the hash and psexec to pass it to the AD server to get a console on it. 

Note that you will need to turn off Windows Defender as it will remove and quarantine Mimikatz.  Right click on the appropriate mimikatz.exe and choose Run as Administrator.  You need to be a local admin for the tool to work. 

Next, check that you have the appropropiate privileges by running:

privilege::debug

We do:

Let's have our two domain admins login to the box to do a bit of work.  The first domain admin logs in with their static AD password because, really, what's the point? The network is small and the users are pretty smart. Then our much more sophisticated domain admin logs in with a one-time passcode from their WiKID server, which has been setup to provide 2FA for AD logins, because he really likes to sleep well at night and knows that attackers are clever with many motivations.  That these two admins on working on the same computer and network in very different ways is just an example of really bad script development.

Note a few things:

• The AD protocol supports complex one-time passwords that meet AD complexity requirements.
• The password lifetime can be configured in the domain settings too. This setting is key as it is an attack window.
• This is the PC client pictured, in real life you would likely use a smart phone software token.

Next, we use this mimikatz command to grab the hashes of these two admins:

sekurlsa::logonpasswords

This is what we get:

And:

Note the NTLM hashes - that's what we will use. 

Now, we will use Mimikatz's pash-the-hash command to escalate our privilege to domain admin.  First, we try the admin that used the static password.

sekurlsa::pth /user:sysadmin /domain:wikidsystems.com /ntlm:0a53c1165654e555ed5992963d097495

This command gives us a dos prompt that shows my user hasn't changed:

  but in fact, the user has the administrator's ticket.  We can use psexec to prove this

psexec.exe \\192.168.56.129 cmd.exe

You can see that we are now sysadmin on the domain server.  The attack was successful! 

Now, let's try the same with the domain admin that used the WiKID password to login.

sekurlsa::pth /user:nowen_admin /domain:wikidsystems.com ntlm:f2ef29069c481dfaec8ce0590b4fa46d

 We get our DOS prompt with our username once again:

 Now, let's see if the hash will work.  We run the same command:

psexec.exe \\192.168.56.129 cmd.exe

 It fails!  Of course it does.  The password is changed after the expiration of the "one-time password" and the hash is no longer valid.  Note that it's not really a one-time password.  The WiKID server writes a random password to AD and sends it to the token as well.  Once the password expires, the WiKID server over-writes the password in AD with another random complex string that no one knows.  Thus, there is a window where an attacker can still use the hash - the lifetime of the password, which can be configured in the WiKID domain to whatever you want. It also means that you can setup an alert in your SIEM for both unsuccessful pass-the-hash attacks (a la "honey tokens") and multiple successful logins within the password expiration.

The WiKID server is free for up to 5 users.  So, even if you don't use two-factor authentication for remote access, a company with 5 or fewer domain admins could use this for free.  That's a lot of companies.

• ← Two-factor authentication for banking
• Evading Microsoft ATA > Another reason to use 2FA for Windows Admins →