[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 28 Sep 2015 11:50:56 +0200
From: "Michael Kramer" <michael.kramer@...-konstanz.de>
To: john-dev@...ts.openwall.com
Subject: Kerberoast for John
Hello John Community,
I'm a Information Engineering Student from Germany and I've worked on a John the Ripper format plugin while I was working at SySS GmbH.
I wanted to share my work with the John Community. The work is based on the Kerberoast Python script from Tim Medin and I've ported it from there to C and then into John.
I had to cheat a little since the cracking algorithm of those Kerberos Tickets is not like the usual cracking John does. The first 16 bytes of the file will be used as a checksum, while the rest of the ticket will be hashed a few times with the cleartext password we are trying and then compared to the checksum itself. If this matches, our guessed password was the one the Ticket was encrypted with. Therefore I saved the first 16 bytes inside the salt variable John uses.
I've included the fmt_plug file for John, a testfile with 3 testhashes the module is able to crack, and also part of the python script from Tim Medin to parse kirbi files into the format my John module uses.
I've created the tickets I've tested my module with inside a VM and everything works with them.
Since I'm fairly new to John developement I haven't optimized my code yet.
But I've encountered a strange bug and thought maybe one of you could help me.
If I try to crack my test tickets with the ./john acrackfile call without any arguments (except the file of course) the performance is okay. It's not great, but it has the same performance over a long peroid of time.
But if I try to crack a larger file (let's say 300 tickets/hashes), John behaves strange. The performance starts very good (150000p/s) but then gets worse pretty fast. After 17 hours I had a performance of 500p/s.
Could anyone help me with this behaviour? Or at lest hint me what could cause it? I've already tried to check if there are any memory-leaks, but neither Valgrim nor a check of the used memory has shown anything.
Greetings,
Michael Kramer
View attachment "kirbi_export.py" of type "text/x-python" (1323 bytes)
View attachment "krb5_tgs_fmt_plug.c" of type "text/x-csrc" (10593 bytes)
Download attachment "acrackfile" of type "application/octet-stream" (6303 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
