NT hashes in krb5

[Zaid Arafeh]

Thanks Benjamin,
I agree that krbtgt key is a random key, but I set it to a certain password for the purpose of this experiment.
What I am trying to get to, is to have the krbtgt key, so I can create custom tgt's and inject them directly into the cash. I do have the krbtgt key now, which will be used to sign the tgt, but I ran into a new roadblock which is the ticket format. I downloaded a tool that generates custom ticket for Windows, but apparently MIT Kerberos does it different than the RFC. I also need to ramp up on ASN.1..

> Date: Tue, 20 Jan 2015 00:02:38 -0500
> From: kaduk at MIT.EDU
> To: zarafeh at live.com
> CC: ghudson at MIT.EDU; kerberos at MIT.EDU
> Subject: RE: NT hashes in krb5
> 
> On Mon, 19 Jan 2015, Zaid Arafeh wrote:
> 
> > If I have the K/M key (which is in the database) and I have the password
> > for the master key, would that make extracting hashes from the database
> > easier? I looked at the keytab file (thnx) , unfortunately keytab files
> > usually don't store the krbtgt key (which is what I am looking for )
> 
> The K/M *key* is not in the database; it is only in the stash file (if
> extant) and derivable from the password for the master key.  You could in
> principle perform the string2key operation on the master key password and
> decrypt the relevant database entries, but that's quite a lot of work.
> 
> Greg was suggesting using kadmin.local on the KDC itself to create a
> keytab for the purpose of your experiment -- it need not be (and probably
> should not be) a keytab used for anything else.  If you are intersted in
> the krbtgt key, you could do something like "kadmin.local -q 'ktadd
> -norandkey -k /tmp/keytab krbtgt/REALM'" to extract a keytab containing
> that key.
> 
> That said, the krbtgt key should be a random key, not a password-derived
> one, so I don't understand how an NT hash would be involved with it.
> 
> -Ben Kaduk