How to extract Kerberos ticket from Wireshark?

Question

I'm running a pentest and I've managed to get man-in-the-middle access between a machine and a domain controller. A process on the machine will log into the DC, as a domain admin, to get a Kerberos ticket. I can see the AS-REQ/AS-REP & TGS-REQ/TGS-REP packets in Wireshark.

I want to take either the TGT or TGS that the DC returns to the machine and inject it into my local machine, using mimikatz or the like, so that I can impersonate the ticket. How do I get the ticket from Wireshark into a form that can be used in a pass-the-ticket attack?

In other words, how do I take the data from Wireshark, where I see the separate fields of the ticket and the encrypted part, and convert it into a kirbi file, or some other format, that I can then inject and impersonate? (If not, is there a packet capturer that will do this other than Wireshark?)

Answer 1

The ticket itself is sent in plaintext in the REP.

KDC-REP         ::= SEQUENCE {
        pvno            [0] INTEGER (5),
        msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
        padata          [2] SEQUENCE OF PA-DATA OPTIONAL
                                -- NOTE: not empty --,
        crealm          [3] Realm,
        cname           [4] PrincipalName,
        ticket          [5] Ticket, <-- plaintext
        enc-part        [6] EncryptedData
                                -- EncASRepPart or EncTGSRepPart,
                                -- as appropriate
}

Or more accurately, it's an opaque blob to the client. Only the KDC and target server can decrypt that ticket. The security of Kerberos relies on this because the ticket itself is useless without knowledge of the session key.

The session key is in the REP.enc-part portion encrypted to the user's long-term key for AS (password or a DH session key for smart cards), or to the TGT's session key for TGS.

The way a client works is it sends the REQ, and in response gets the REP, then decrypts the enc-part using whatever key is required. Then the client wants to use the ticket to authenticate to a server, which is called the AP-REQ.

The AP-REQ is formed by generating what's called an Authenticator. The authenticator contains values copied from the decrypted enc-part, which mirror values stored in the encrypted ticket, and then finally encrypted to the session key originally found in the enc-part, and also mirrored in the ticket.

The server receives the AP-REQ and decrypts the ticket using its own long-term key (service account passsword), and then using the key found in the ticket, decrypt the authenticator, verifying the contents of the authenticator match whatever is sent in the ticket.

The purpose of this authenticator is to prove that the sender of the AP-REQ is the rightful owner of the ticket, by virtue of knowing the session key.

So, what this means is stealing the ticket itself is meaningless. You also need to steal the enc-part and then decrypt it. If you had the key to decrypt, it then you don't need to steal it, and could just authenticate as that user because it's just their password in the AS case.

As such, you must bruteforce it. This is often described as kerberoasting, though kerberoasing often only refers to attacking the AS-REQ PA-DATA, but fundamentally it's the idea that you bruteforce your way through guessing the session key or password based on the message on the wire. In the AS case you get their password, and away you go. In the TGS case this'll just be impossible because the session key is long and cryptographically random and heat death of the universe yadda yadda yadda. If the password is sufficiently long, you won't be able to crack it. If the password is medium length, and encryption type is sufficiently strong, you won't be able to crack it.

Tools like hashcat and John the Ripper support this.