You may have heard about golden tickets before and that they are very scary. They are scary because it allows a bad guy or gal to gain 'keys to the kingdom' so to speak, and there really isn't too much that you can do to protect against this.
Before we move forward, here's an alphabet soup legend -
DC - Domain Controller
KDC - Key Distribution Center
AS - Authentication Server
TGS - Ticket Granting Server
KRBTGT - Kerberos Service Account
ITSITHTM - I'm Totally Screwed If This Happens To Me
It is highly recommended that you either have a background in Kerberos, or read my Kerberos 101 article before proceeding so that you are more familiar with all of the concepts and other crap to follow. In short, a Golden Ticket is a forged TGT that contains (or purposefully excludes) information about a user, including permissions and restrictions of that user, such as allowed logon hours, smart card requirement, group membership, etc. Normally, TGTs contain real information...but with Golden Tickets, they contain (or lack) information that is advantageous to an adversary. Golden tickets exploit Kerberos, which is used for authentication on your network. Kerberos uses a series of tickets and Ticket Granting Tickets, also known as TGTs (thus the term 'golden ticket') to authenticate various types of accounts and and permissions. The part of the magic Kerberos system that hands out these tickets is called the KDC, the Key Distribution Center. All machines in the domain implicitly trust any ticket issued by the KDC. Each principal (either a user, computer, or service) communicates with the KDC only with keys that exist between itself and the KDC. If these principals communicate with each other, they use session keys that have been generated by the KDC. How does a system know that a ticket is issued by the KDC and that the ticket can be trusted? Good question! First, let's get into some important security implications of the Kerberos authentication process -
The first important note about Kerberos is that it is stateless. This means that it has no memory of anything that it does. This also means that, although Kerberos authentication follows a series of steps to get tickets, if you forge or steal a ticket midway through these steps, there is nothing built into the Kerberos system that says "hey wait, I don't remember issuing this ticket to you! You can't use it!" As long as the ticket and TGT is valid, the receiving server will accept it. This makes the Kerberos service account that issues/encrypts these tickets and TGTs very valuable to an adversary, since it is the central account the that TGS trusts. Another security implication is that a service (HTTP server, FTP server, etc) never talks directly to the AS; it instead trusts that the AS did its job at capturing the user access rights and restrictions and includes those attributes in the TGT that it issued to the user. Kerberos also uses symmetric key cryptography, meaning that the same key used to encrypt is used to decrypt data. The key is typically a password that is salted (random data added to it before being hashed), hashed, and then used as input to an encryption algorithm (AES in this case) to encrypt the sensitive data. One last, and possibly most important, aspect of Microsoft's implementation of Kerberos is that it DOES NOT SALT LONG-TERM KEYS!!.
Moving on, TGTs are encrypted with the TGS secret key by the enterprise God account (not actually called this), known as the KRBTGT service account (Kerberos Ticket Granting Ticket service account). This is the service that issues and encrypts all of the TGTs in the domain. As a refresher, TGTs are issued by the AS and ultimately get to the TGS, which decrypts it and issues tickets based on the information inside of the TGT. The tickets are encrypted with the service secret key (FTP, HTTP, etc), which are used by a user to access a service. Here is where some other magic stuff happens. If an adversary compromises an account that is either a Domain Administrator on your enterprise, or is a local admin on the Domain Controller which hosts the Kerberos service, they can do what's called a DCSync. DCs store and replicate enterprise account data to each other for reasons. If an adversary has compromised a domain admin acct or a local admin acct on the DC, they can pretend to be a DC themselves and request account data be replicated to them (including password hashes for any account, including the KRBTGT account) using the GetNCChanges function. It goes without saying that it is very bad for your enterprise if the KRBGT account becomes compromised.
It is important to note again that the KRBTGT account password is not salted. This means that the hash captured during the DCsync step above can be used directly as input to the AES function used by Kerberos to encrypt data. The data encrypted by the hash will be successfully decrypted by the TGS, implying that the information in the TGT is accurate, since theoretically, nobody but the AS should be able to encrypt data with the TGS secret key. Once the KRBTGT hash data is acquired, an adversary can use the password hash to create fake TGTs. "Fake" meaning that they aren't legitimate, but they are real in the sense where they are encrypted by the legitimate KRBTGT account, and can be used anywhere within the domain without question.
This enables an attacker to make a ticket that lasts for many years, grants them access to anything on your network, and can't be revoked; all of the privilege and access requirements checking take place on the Authentication Server before issuing the TGT to the user. This means that if a user has a TGT encrypted with the TGS secret key (KRBTGT hash), it is implied that the user has passed these checks. In a Golden Ticket scenario, these checks are never performed, as the ticket is created locally. Even if a user is set to require a smart card authentication, this information is normally included in the TGT. SO, since the TGT is being forged/created locally, this information can be left out. That is the beauty of a golden ticket - you can make it do whatever you want to within the domain. This will work even if the user that the forged ticket is valid for is disabled in AD; it doesn't matter - the ticket is "valid", so the requests will be accepted. The only (sort of) way to fix this is to change the KRBTGT account password twice, which will invalidate the hash that the forged ticket was encrypted with. This needs to be done twice due to password history being retained on the DC, meaning that tickets signed within 1 password change of the service account will still be validated. Changing the password twice for the KRBTGT account will technically invalidate all TGTs signed by the account, but doing this is ill-advised, as this can possibly have bad effects on your computers, and if the adversary had access to the DC in the first place, you're still screwed as they can make another golden ticket with the new KRBTGT passwords. You will probably want to destroy your domain and rebuild from scratch if this happens.