Responder, one of the tools that is part of every pen-testers toolkit (if you are a pen-tester and you don’t use it, shame on you), is by far one of the greatest tools ever made. We use it on every internal and sometimes external pen test that we do. For those that aren’t familiar, responder gives someone the ability to (potentially) capture password hashes (an encrypted version of your password). Yes, there are other tools that can be used but we prefer to use responder.

Once a hash is captured the next logical thing to do is to try and crack it (or you can try pth or relay, but these are for a different article). In most cases cracking attempts are commonly performed using tools like john or hashcat, and oftentimes it is done on the local machines being used to perform the test. While a chance exists to possibly crack a password using the resources that a laptop may have, the reality is it is either too slow, or it will never happen because your laptop will burn to the ground trying to crack a 12 character password. We don’t know about our fellow pen-testers, but we don’t have fancy GPUs in our laptops, but we do have “special boxes” we use for cracking those 12 character hashes.

Now that we need to use that “special box” (we call it “The Cracken”), we have to first copy the hash to that box, set up the hashcat switches and rules, and then let it run until the password is cracked. But after the password is cracked (hopefully it is), there is no immediate indication to us that it was successful, unless someone is staring at the screen.

While this is how most of us do it and so far we haven’t had any issues with it, we thought to ourselves, there must be a better way to handle this entire process. The thought of trying to come up with a better way to handle this happened when we were performing an external pen test.

When we ran our external pen test we had our machine set up with responder to listen for incoming hashes. We used some credential phishing techniques to try to get some hashes. Because we didn’t know when someone was likely to perform an action that allowed us to capture a hash, we left responder running over night. We came back the next morning to find that there was a hash that was captured but between the time the hash was captured and the successful cracking of the password, over 10 hours went by. This was enough time for the end user to be a little suspicious (because of the method we used), which most likely resulted in the changing of the password. Lo and behold, the password didn’t work even though we were able to crack it in under an hour.

On to the fun stuff: We wanted a way of being able to process the entire capturing of a password hash to cracking it, then being notified that something was cracked (or not) without having to babysit responder and hashcat. What we came up with was a solution (that was fully written in python) that allowed us to:

  • Kick off responder
  • Monitor for new captured hashes
  • Upload the hash to a proxy server
  • Move the hash to “The Cracken”
  • Run hashcat against the hash(es)
  • Get notified (if) and when the hash was cracked (with the password of course)

Below is a video (sorry we’re not specialists in video editing) illustrating the victim machine, our machine running responder, and the box that the cracked password ended up on.

If you don’t want to watch the full video, up to about .05 seconds is the capturing of the hash, fast forward to about 1:14 and you’ll see the hash get cracked.

There is still work to be done. Some of the next initiatives include having the cracking process run through different rule sets, etc. Once we have that down, we plan on integrating it with cme, mailsniper, and a few of the other tools. We’ll provide another write-up in the near future as progress is made.