After doing some more digging, I think I have found the answer. When the TGT is returned to the client, it has 2 main parts as shown below:
![enter image description here](../../images/3851291831.webp)
The key point to note is that the whole entire TGT is encrypted with the client's (Alice's) private key (Alice's password) but within this TGT is a sealed ticket and that ticket is encrypted with the Ticket Granting Service (TGS, the service which created the TGT).
Once this entire TGT arrives at the client, the client decrypts it and the result is
- A Sealed Ticket (TFS Encrypted and it will stay encrypted).
- A session key
After now, whenever the client needs a ticket for a service (not a TGT but just a ticket), the client has to send the sealed ticket part of the (TGT) within all requests and the request has to be encrypted with the Session Key as shown below:
![enter image description here](../../images/3824290962.webp)
Thus if a man-in-the-middle gets a hold of the original TGT as shown again below:
![enter image description here](../../images/3851291831.webp)
, they cannot decrypt it to it's individual parts. If they were to send it for a ticket, it will NOT only contain the Sealed Ticket but the entire thing and the request will NOT be encrypted with the Session Key. Thus when the server decrypts it, it will NOT be only the Sealed Ticket, and it will not be encrypted with the session key (How could it be? The attacker could not decrypt to get the session key) and thus it will reject it.
Even another precaution is that the original client's IP is within the ticket so only requests from that same IP will be able to use the ticket; this, however, is just another precaution.
See here for more info.