So there you are, performing your internal penetration test, using Responder to potentially grab hashed credentials and thinking "Responder is awesome… but manually cracking credentials isn’t fun." Well, welcome Gladius! Gladius happily listens for Responder hashes (and.. spoiler alert.. secretsdump.py and hashdump) and automatically passes them to hashcat.
At its core, Gladius listens in target directories for file events and then performs computations based on the event. Let’s walk through the Responder workflow with Gladius:
At this point, we have a hashcat process furiously cracking credentials. Meanwhile, Gladius is watching the output directory from the hashcat process, waiting to parse the results for human consumption.
The found credentials from Responder are then displayed to the user in an ascii gladius.
(For those of you who don’t like beautiful works of art, then —no-art is an option to disable the ascii gladius)
The usefulness of Gladius is that any sort of file driven event can be captured and triggered. By default, Gladius comes prepackaged with three types of events:
What this means, is that once Gladius is started, all one has to do is perform a smart_hashdump in metasploit or pipe the output from secretsdump.py into /usr/share/responder, and the resulting hashes are automatically passed to hashcat to begin cracking.
One other feature that is useful to clients is the ability to tell them how many credentials were cracked in what span of time. Given a hashdump, Gladius happily displays the following information:
Quick example of this:
Here we see that this credential was cracked in 1.5 seconds, was the 40/41 credential cracked, and that currently 97.56% of all credentials have been cracked.
Lastly, we can also quickly tell if multiple users are using the same password: