Thursday, December 27, 2012


Since Microsoft did a number to confuse the issue of "Pass the hash" attacks in their whitepaper, I think it's time for a brief refresher on what exactly a "Pass the hash" attack is.

So, please bear with me whilst I go over a few definitions.  I'm going to gloss over some of the details and elaborate where I feel I must.  I include a link to wikipedia with tons more info...

Cryptographic Hash  Function (from Wikipedia)-  "... an algorithm that takes an arbitrary block of data and returns a fixed-size bit string, the (cryptographic) hash value, such that an (accidental or intentional) change to the data will (with very high probability) change the hash value"
In small words, this means that you take a block of text (for example, a password) and run it through some magic function, and if you made a small change to the password, you would end up with a completely different value.  Passwords are often stored using a hash function to make them more difficult to crack prevent the password from being stored in plain text.

NTLM (from wikipedia) - "... a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users".  For implementation details, read the page on NTLM from the Davenport Project.

NT hash - the 16 byte result of the Unicode password sent through the MD4 hash  function
LM hash - old (NT old) hash read about it on Wikipedia

Kerberos - Microsoft's default authentication mechanism  for Active Directory (originally from MIT). (Wikipedia)

Now that you have some background...

A "pass the hash" (PTH) attack can happen when just the password hash is sufficient to authenticate a user to a system.  NTLM is a good example.  For both NTLM version 1 and version 2, the password for the user requesting services is hashed and then that hash is used for the rest of the challenge-response based authentication process.   Note other platforms have suffered from a PTH attack (e.g. coldfusion) so Microsoft doesn't own the patent on this class of vulnerability.

What normal authentication looks like
Hash only authentication

So, what does this mean?  In essence, if an attacker has password hashes (multiple ways of obtaining hashes, more than likely another blog entry... ) and access to a service which allows NTLM to authenticate, the attacker can authenticate using a username and a hash with a modified client.  

What services can use NTLM to authenticate?  Well, IIS, Exchange (to include SMTP, POP3, IMAP), file and print services, MSSQL, and many other services related to gathering information from an Active Directory environment can use NTLM to authenticate.  There are even a couple of ways to obtain code execution using PTH with either winexe (psexec clone) or WMIC, depending on how you're feeling.  There are modified clients to do all of this from Linux and there are even ways to coax a Windows client to do it.  For more info, please see the rest of the blog entries, our Blackhat 2012 talk, or the demo vids ;-)

But, you may say, "We use Kerberos, your puny PTH won't work against us!". You would be incorrect. In order for Kerberos to work properly, several conditions need to be met.  Among the big ones 1) both ends of the connection need to be in the same Active Directory domain (or trusted) and 2) each end of the connection needs to refer to the other side by DNS name.  There are more conditions (read the NTLM wiki link above for all the conditions of when NTLM is used instead of Kerberos)

If Kerberos cannot be used, by default NTLM is used as the fail over.  Uh oh....

WAIT! I thought PTH meant....

The MS whitepaper confuses the meaning of PTH with a couple of different attacks than what I described earlier. 

One attack that MS calls "PTH" is using a local account hash from a computer to privilege escalate on that computer or move laterally to other machines.  So, let's decipher this a little bit.  

When a new Windows computer is stood up it is built with an account that has administrative privileges.  Then, at some point, the computer has to be added to the domain.  So what happens to the admin account on that machine after it gets added to the domain?

On older Windows systems (XP/2003) the local administrator account (also sometimes known as the 500 account) is created when the computer is stood up.  This account is used for administrative tasks, such as backups, patching, installing software, etc...  The hashes for this account are stored locally in the SAM database.  When the computer is added to a domain, this account remains and is still available for network logins.  Since admins are often lazy, many of these built-in admin accounts share the same password across multiple machines.  If one of these machines is compromised, and the local hashes are dumped out of the SAM, an attacker has now gained administrative access to potentially more machines on the network.  While  the attacker doesn't have privileged domain credentials, the local "system" account on these machines has access to the computer account for the domain.  This is sufficient to query the AD for more information, such as a list of users or groups.  This extra info leads to further attacks later.

Newer versions of Windows (2008/Vista / 7 ) by default disable the built-in administrator account  and instead creates an account that is in the "Administrators" group local to the machine.  This account can also be used to administer the workstation and its information is also stored in the SAM.  When the computer is added to the domain, by default (assuming UAC is enabled) these accounts are NOT accessible from the network.   So while the hashes provided could be cracked or recycled for other accounts, this information isn't as useful as it would be on older versions of Windows.  However, it is worth noting that this behavior can be overridden by registry settings or GPO settings, so beware.

The MS whitepaper calls using these accounts a PTH attack. Meh.  I sorta see what they are going for, but aside from hashes being involved, this isn't really a separate attack vector...   More like an availability of hashes sort of issue... 


In either case, if an attacker could get to a point where they can dump the local hashes, then more than likely they'd be more interested in whatever security tokens are available. Tokens will be addressed in a later blog post about Windows authentication, however the gist is that a token gets created when a user logs in.  The token also contains the user's login name, the user hashes (NT / LM) and  the domain (if applicable) the user is authenticated to.  To keep things interesting, tokens often persist in memory for a long time, even after a user has disconnected from the computer.  If that wasn't enough, in many cases the plain text password (mimikatz) can be recovered as well.  

If that doesn't give you nightmares nothing else will... of course if I have a plain text password is it really a PTH attack now?  

Not to be confused with...

Another form of attack which is often confused with PTH is called SMB relaying.  Although, this is even a bit of a misnomer.  This attack deals with hashes, but not with the NT or LM hashes used by the traditional PTH tool suite.  The hashes involved are the response hashes to the challenge issued by a server when attempting to authenticate using one of the versions of NTLM.  

Because of a poor design in the NTLM protocols, if I can get an authenticated person to attempt to use NTLM authentication against a computer I control (say, via a web page requesting NTLM authentication) I can act as a Man-in-the-Middle for any other service using NTLM, such as file shares.  If I initiate a connection to the file server, I can feed the challenge I get from the file server back to the web page as my challenge and use the results to authenticate against the file server.  Essentially I'm using an already authenticated connection to authenticate to a different service.  So, without knowledge of the password, I am able to access additional services by "passing the hash".

There has been a lot of semi-recent conversations about SMB Relaying.  A couple of links:

In Summary...

I've tried to lay out the foundation to understanding what a PTH attack is.  I've also tried to explain what MS is calling a PTH attack and what other folks are calling PTH attacks.  Next post will be all about Windows authentication....  Questions? Comments? Feel I need clarification?  Hit me up on twitter or post comments to the blog and I'll try to answer as best I can...

Sunday, December 16, 2012

And we're back...

Sorry folks for the delay in getting the blog updated.  I'd meant to get back to the blog sooner, but I was on the road for a month, then I was trying to finish stuff up at work, then $excuse[0] and then $excuse[1]  and then $excuse[$i++] ...

So, what shook me out of my stupor?

This article and the associated PDF from Microsoft talking about Pass-the-Hash.

 My initial response after reading the blog post and the associated 81 page PDF?


Chris (@obscuresec), my speaking partner at BHUSA 2012 and Derbycon 2.0, had a similar response...

Then Richard Bejtlich (@taosecurity) asked for comments on Twitter about the paper... that sorta opened up the floodgate for both me and Chris.  Long story short, I was asked to put some of my thoughts on the subject down, so here we go...

I've spent a couple days now re-reading the whitepaper.  I've read for detail and am trying to make sure I'm completely understanding what they are saying and where they're going.  I'm also trying (sometimes harder than others) to deliver a calm, rational response to the items in the whitepaper.

We'll see how that goes...

So, I'm going to have several blog entries about the whitepaper.  I'm not quite sure how it's all going to be split up at this point, but I am going to start with a few overall observations and then we will see.

I'm going to start with a quick aside, as I want to make sure we are all on the same sheet of music when it comes to terminology.  Please bear with me.

Definition :
  Mitigation - The action of reducing the severity, seriousness, or painfulness of something
Synonyms : cure, alleviate
So, I would expect a "PTH Mitigation" to lessen the impact of PTH attacks.  Makes sense, eh?

Ok, what's PTH (Pass-the-Hash)?

Short version: Microsoft treats the password hash as being equivalent to a password with NTLM.  This means that you don't need the plaintext password to log into a service.  With a modified client, you can simply substitute the hashed password and it will still work.

Longer version: For our BHUSA 2012 talk, Chris and I wrote a whitepaper.  You can read it here.

What PTH attacks are talked about in the MS whitepaper?

Microsoft in their whitepaper lists 2 specific examples of PTH attack:
1) Using password hashes to move laterally from computer to computer.  In this case the computers are of the same "value".  This means that an attacker is moving from workstation to workstation instead of workstation to server.

2) Using password hashes to "privilege escalate", or to move from a lower valued computer to a higher valued computer.  For example, moving from a workstation to a web server.

All of Microsoft's "mitigations" are meant to defend one or both of these "attacks"

Quick Observations
  • It's obvious (aside from 2 pages of writing credits) that this paper was written by many different hands.  This becomes even more obvious when parts of the whitepaper contradict itself.  I don't envy the job of the person who was supposed to cull everything together into some sort of semi-coherent beast.
  • The paper tries to do too much.  It tries to be all things to all people.  I realize that MS has been under pressure to deliver some sort of response to the 15 year old PTH problem, but releasing a long, confusing whitepaper really doesn't solve anything and could possibly compound the issue by being easy to misread or misunderstand. God help us when people implement the "mitigations" and are still attacked with PTH.  Microsoft better be ready for the pitchforks and torches...
  • This is a complex subject.  Windows authentication is a quagmire of backwards compatibility built on hacked solutions to hard problems (like SSO, single sign on).  You can't have a frank and complete conversation about Windows auth without talking about ALL of Windows auth, and the paper doesn't cover everything.
  • Pro Tip: You probably shouldn't have a "recommendation" for a mitigation that says "don't do this mitigation, instead do something else" (Read mitigation 2, p14.)
  • There are a lot of useful nuggets in the whitepaper.  However, they're either buried or poorly worded 
  • Many of the mitigations seem redundant and could be summarized as "Don't be stupid"
  • The tone of the whitepaper is a weird combination of spin control, defeatism, and over-generalizations.
And Finally....

If somebody is already in your network and has your hashes none of the mitigations in the whitepaper will have any positive effect.  None of the mitigations will give the attacker any pause, make life difficult, pester or bother them in any way.


I'm sorry, don't shoot the non-Microsoft messenger...


The only glimmer of hope is that some of these mitigations might make it more difficult for an attacker to obtain administrative hashes if they don't already have them.  However, it's usually just a matter of time.

So, moving forward I plan on several blog entries.  I think the first one is going to be an in-depth refresher on PTH.  I'm also going to have to do a post on Windows authentication mechanisms and talk about the stuff the whitepaper glossed over... I'm also going to do a post on hash collection methods... and also on the "mitigation" techniques and what MS was shooting for and what the actual effects would be if implemented...

and all I wanted for XMAS was a vacation.... :/