Talk:Pass the hash

Errors in the current article

• 1. Pass-the-hash != credentials forwarding attack. You are confusing smbrelay with pass-the-hash. These are two different techniques, for this reason also a reference to smbrelay is also not correct in this entry. smbrelay performs credential forwarding/reflection. smbrelay refers to this http://technet.microsoft.com/en-us/security/bulletin/ms08-068. You trick a user into connecting to your own SMB server, and you forward/reflect the users credentials to another machine. You never use a hash, you never see a hash because you are doing MiTM with the NTLM challenge-response mechanism and the hashes are not transmitted; so, this is not pass-the-hash. In first paragraph, "or credentials forwarding attack" should be removed.

*2. The first paragraph of the Mitigations section is not accurate I believe. It talks about how to prevent any computer from being compromised, I don't think this has to do with pass-the-hash. The section is confusing pass-the-hash with dumping hashes from memory, these are two different techniques. There's no mitigation for pass-the-hash, there's only things you can do prevent users from dumping hashes from already compromised machines. I had added this to the article, but my additions were removed, rephrased, and added to the previous incorrect mitigations text which now makes it 'less incorrect' because of my clarifications, but it is still not accurate in my opinion.

• 3.Mention, Links and references to WCE should be added; this is currently the only tool that does what the PTh did on newer OSes, PtH does no longer work and it is obsolete, I'm the author of both tools.
• 4. Links to WCE written by other people other than the author (Socrates2008 asked me for this):

• • http://rebootuser.net/2011/05/08/windows-credentials-editor-v1-2-pass-the-hash/
  • http://www.pentester.es/2010/10/wce-windows-credential-editor.html
  • http://www.slideshare.net/rootedcon/hernan-ochoa-wce-internals-rootedcon-2011
  • http://blog.infobytesec.com/2011/09/another-way-to-bypassing-mcafee.html
  • http://blog.vidasconcurrentes.com/seguridad/post-exploitation-con-wce-y-flu/
  • http://www.c-intrud3rs.com/comunidad/hacking-en-general/windows-credential-editor-herramienta-para-hacer-pass-the-hash/
  • http://cpradier.blogspot.com/2011/08/review-windows-credentials-editor-wce.html
  • etc.

The following presentations I have written myself should also be included, since they have tons of information on how the tool works, how to implement the new techniques I authored, and how to use the tools in a penetration testing scenario:

• WCE Internals (description on Windows Internals and how dumping hashes and changing them works): http://www.ampliasecurity.com/research/WCE_Internals_RootedCon2011_ampliasecurity.pdf
• Post-Exploitation with WCE: Pass-the-hash, pass-the-ticket & more (describes how pass-the-hash works, why it is possible, attack scenarios, what you should do to protect yourself against the attack,etc). http://www.ampliasecurity.com/research/wce12_uba_ampliasecurity_eng.pdf

Please read the presentations to understand the information presented is relevant. It's basically the source of some of the scenarios described in this entry. Also, I know many of the authors of the references and papers included in this entry because they have contacted me with questions when they were writing them. So if you can trust them, I guess you should trust me..

• 5. The link to http://www.securityfocus.com/bid/42435 referring to 'pass-the-ticket' is actually a vulnerability, is not a technique. WCE, again, is the only tools that allows you to do the real pass-the-ticket technique equivalent to pass-the-hash. Again, this information is incorrect. Yes, again, I'm the author of WCE and PTh.

Ho8a (talk) 11:20, 20 October 2011 (UTC)

Actually I think the problems run deeper than that - pass-the-hash isn't limited at all to the SMB protocol. I've seen a million and one web applications that implement "secure" login by MD5ing the user's password before they post over plain HTTP, which is effectively a PTH. Not sure why this page only talks about passing LM hashes. Dan Fuhry (talk) 16:32, 11 April 2012 (UTC)

...only if there's no salt added (e.g see this example). Or do you have any specific information to the contrary? Thanks Socrates2008 (Talk) 11:24, 12 April 2012 (UTC)

Salting doesn't solve the problem because a salt value is supposed to be static and stored with the record. A challenge-response system does solves the issue but it makes it much more complex not to store the password in a reversible fashion server-side. That being said, I agree with Dan Fuhry: pass-the-hash attacks are definitely not limited to SMB Fulgan (talk) 12:42, 23 July 2014 (UTC)

Salt

This needs some context, otherwise it should be removed. (PtH works regardless if the hash salted or not, right?) Socrates2008 (Talk) 12:14, 20 October 2011 (UTC)

LM & NTLM hashes are not salted, so I second the removal. Also, PtH does not work nowadays :), WCE works and it is the replacement for PtH http://www.ampliasecurity.com/research/wcefaq.html#betterthanpsh. Ho8a (talk) 12:35, 20 October 2011 (UTC)

Not only NTLM/LM hashes

The article claims pass-the-hash attacks only work with NTLM/LM hashes which is wrong since pass-the-hash is a generic concept not relying on specific hash types or software. Every software is potentially vulnerable to this problem. The article seems to need a re-write. — Preceding unsigned comment added by 134.96.7.93 (talk) 10:39, 15 June 2015 (UTC)

The above statement is very wrong. Many widespread client authentication schemes are immune to this attack, including all of the following:

• Any scheme where the password itself is verified (like the many "crypt" algorithms), e.g. when combined with HTTP(S) Basic Authentication or password entry forms. This easily covers the majority of web servers with a public IP.
• TLS Client Certificates
• TOTP (used e.g. in Google's two factor authentication)

Now, obviously, using HTTP Basic Authentication (i.e. without TLS and a valid server certificate) is a bad idea, especially when using wireless networks. But that's a different problem from pass the hash (and also violates web best practices). Even with TLS, sending the password to the server comes with some security risks, which again are, however, different from pass the hash.

There are actually challenge-response authentication schemes, without ("true") asymmetric crypto, that are immune to pass the hash, notably SCRAM. Unfortunately, it's not seeing widespread use (yet?).

For the sake of completeness, I'll name one other scheme that I know is vulnerable: Digest access authentication. Aragorn2 (talk) 09:15, 22 July 2019 (UTC)

Yahoo attack claim

The claim that the Yahoo breach involved pass the hash is poorly referenced - the BBC article has no direct quotes on the subject, and does not seem verifiable - neither Yahoo press release [1][2] makes any mention of this technique, other than that hashed passwords were stolen, and forged cookies (which could easily be any number of different exploits, unrelated to hashes.) All other articles published seem to circularly reference each other, or this BBC article...can anyone find a more authoritative source? --Strangerpete (talk) 07:20, 29 January 2017 (UTC)