Pre RSA Conference Demo - Win 8.1 attack machine vs 2012r2 DC w/ Win 8.1 client

The Story Thus Far...

So on the twitters today, Sam Bowne (@sambowne / http://samsclass.info) continued on a partial conversation started earlier in the week with @obscuresec / myself regarding an upcoming RSA talk.  The RSA talk is entitled "Pass-the-Hash: How Attackers Spread and How to Stop Them" by Mark Russinovich and Nathan Ide, both from Microsoft.  The slides can apparently be found here: http://www.rsaconference.com/writable/presentations/file_upload/hta-w03-pass-the-hash-how-attackers-spread-and-how-to-stop-them.pdf

I respect the work that the folks at Microsoft have put into trying to lessen the impact of PTH attacks on Microsoft products.  However, I feel obligated to point out that claims that something "stops PTH attacks" is at best an exaggeration and at worst a bold-faced lie of a delusional mind.

Repeat After Me :  PTH is By Design Functionality

This is the way NTLM works.  All authentication operations work on the password hash.  Internally the NTLM security provider only saves the username / hash for use during Single Sign On.  If it needed more, it would have saved more.  Just ask the Digest SSP, which saves the username / plaintext password.

PTH attacks cannot be stopped unless you disable NTLM.  Period.   End of story / paragraph / book / library.  They can only be mitigated or made more challenging.

The Demo Setup

I have a VMWare virtual network set up with 3 hosts.

1 domain controller (172.19.1.1) running Server 2012 R2 running in 2012r2 functional level

1 domain client machine (172.19.1.5) running Windows 8.1

1 attack machine (172.19.1.10) running Windows 8.1

All machines are fully patched as of today : 2/22/2014.

I have disabled Windows Defender and the Windows firewall on all machines.  I also re-enabled the local administrator accounts on both Windows 8.1 machines, as they are disabled by default.  In addition, on the attack machine only I disabled UAC.

Aside from the above changes, these are stock builds.  No registry settings have been changed.

In the domain I have created several users, but for the purposes of the demo I used the domain administrator.

For attack tools I am using the latest version of Mimikatz (@gentilkiwi / http://http://blog.gentilkiwi.com/mimikatz) and Mr. Russinovich's venerable psexec tool from Microsoft's Sysinternals.

All hashes will crack with a 4x4 character keyboard pattern if you're bored ;-)  I made separate passwords for each account in use to ensure nothing weird happened with accounts with the same PW.

The accounts:
172.19.1.1
administrator, Member of Domain Admins group, built-in 500 account
NT hash: 821C5CA39C55B70ADF80CADAFBFCD849

172.19.1.5 - 

Administrator - Member of the local 'administrators' group, built-in 500 account
NT hash: 0C1F997A0830BBFB8167F49B1ED59D15
Skip - Member of the local 'administrators' group
NT hash: 57C8A8C6D4FC8CCA2EAC7D4DC2C6576A

172.19.1.10 -
attackadmin - Member of the local 'administrators' group, built-in 500 account
nt hash: 8189A242FEAC3582A0A084D199EDCD2C

Let's Fire Some Binary Bullets!

Here's a screenshot of the attack machine.  Note that the attack machine has a reddish desktop for clarity:

Here's a screenshot of the Win 8.1 domain client machine.  Note it has a black background to differentiate it from the attack machine:

We are going to use the Mimikatz to create a new process with a specified hash on our attack machine.  Note that you must have enabled debug privileges in order for it to work properly.

The command prompt that opened up can now be used with psexec to connect to the Windows 8.1 client.  Note that since the attack machine is NOT domain joined, the only way to log in without specifying a username and password is via the process token that was created.

As you can see, we have logged into the Windows 8.1 domain client as "2012r2\administrator" or the domain administrator account.

Here we log into the 2012r2 domain controller in the same fashion:

So as of right now, neither Windows 8.1 or Windows 2012 R2 stock prevents a domain administrator account from using PTH to access these machines.  This is the expected behavior.

Where things get interesting is when we try to use a non-500 account local administrator to log into the Windows 8.1 client.

By default on Vista+ versions of Windows, members of the local admin groups via UAC are not allowed to access the computer via the network.  (Technically this is because of privileged token filtering, however this bit gets flipped on the back end when UAC is enabled.)

However, by default on Vista+, the local 500 account is not subject to UAC or the token filtering so that account can log right in.

Here's a screenshot of the Local Security Policy on the Windows 8.1 client:

And here's me using psexe to log in as the local 500 administrator:

In order to make it so the local administrator account that failed could log in, we need to modify the client's registry to disable the token filtering feature from working.  Alternatively, we could have just disabled UAC and that would have also worked.

After adding this registry setting, we can log in via psexec as the user 'skip'.

Some Closing Thoughts

It is worth noting that the default 500 administrator is disabled by default.  This is done for a reason since it has separate UAC permissions in the local security policy.

However, based on my personal experience as a pentester this environment is not terribly realistic for several reasons, all of them bad.

1)  I've never seen a 2012 domain in production, let alone a 2012 R2 domain.

2)  I've never seen any Windows 8 in production, let alone 8.1.

3)  Many places I've visited have the local 500 account enabled.

4)  Many places I've visited have disabled UAC.

I could go on and on....