Often in penetration tests we discover password hashes. In this situation every penetration tester use the password cracking tool of his convenience ( like john the ripper) in order to crack the hashes offline and to escalate privileges. The sooner that the hash cracks the better for the results of the engagement as the penetration tester will have more time to search on the system for other important things while he has a valid password.

For that reason a script created that allows the penetration tester to crack hashes using free online services or even Google if the hash is common. The usage of the script is very simple and it can be seen below:

FindMyHash Script in action
FindMyHash Script in action

 

This is definitely something that every penetration tester should check before he starts the process of cracking a hash.

Author: https://twitter.com/laXmarcaellugar

Email: bloglaxmarcaellugar@gmail.com

Script: http://code.google.com/p/findmyhash/

9 Comments

  1. I’m not sure I agree with this – posting of hashes to a public site may not appropriate. Is the source IP attributable to the client – if so the owner of the site now knows password X is likely to belong to organisation Y?

    Does the client approve of you posting sensitive password hashes to a website which cannot easily be verified?

    Does the third-party website attempt to crack (and therefore compromise) unknown password hashes?

    Most testers I know would stay clear of such sites (on a penetration test at least) for the above reasons….

    1. I agree with apentester, because it is quite a bit risky to use this script. Because even the hashes could include company details.
      But on the other hand: It is good when you make sure that nobody can get to your IP. Even if this is not the company IP 😉 And if you have no other choice to crack that system.

      So I would say it depence on the case, if you use it or not. 🙂

  2. @apentester I slightly disagree with you even though your reasons are valid. I will share my thoughts on this script and why I think that it is useful.

    First of all you can avoid sending the hash from the network of the client (if the test is internal). So this problem is solved as it will be impossible for anybody to match this hash to your client.

    Secondly the majority of these websites are performing a check in their database to see if the hash is already cracked or not. In the above example the hash is well-known so in these scenarios it can save you time especially when it is impossible for them to associate the hash with your client. If the hash is already cracked by someone else and you discover it through this script then still you will mark the issue as weak password and you will report it. So in this situation the client still needs to change the password ( so the hash will change) so nobody will have nothing.

    For me the only problem that I can think with the usage of this script is when a password is the name of the company. So in this situation yes all these third-party websites can associate the hash with the company. But someone can argue and say that if you don’t check a system for default or weak credentials as a pen tester then definitely you are not doing something correctly.

    1. Key thing to remember, the hash is the clients data. You should be under NDA when conducting a pentest, the client must authorise the release of this data to a third party.

      Whether or not you believe the risk to minimal is irrelevant.

  3. what if hashes reveal the organisation names in different probabilities and combinations? Posting it to the public databases is highly risky in my opionion.

    A good alternative could be having nice wordlists with you on external drive or somethign and you can automate jtr/hash cat to come up with some passwords fast. Or add a rule to john to check different combinations of the client organisation name or frequently used string that you think is likely to be part of a password.

  4. You should not post hashes to third party sites when performing a penetration test for a client. scripts like this are bad and should be used only under your own lab or if you have explained to the client what the script does and who it talks too and get their consent. but even still they likely wont understand the risk to this. sorry but this is not a good recommendation. Pentesters be be weary!

  5. I have a confusion here. Never used this script before, wouldn’t it do the same thing as others? It would either connect to its online database and see if it has been cracked already? As shown in the example, the has of “admin” would be cracked by any website as it has been matched with the plain text millions of times before.

    What exactly is different about this tool?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s