Golden Ticket attack is part of Kerberos authentication protocol. Attackers should gain domain administrator privilege in Active Directory to create a golden ticket. This ticket leaves attackers to access any computers, files, folders, and most importantly Domain Controllers (DC). Successful creation of this ticket will give the attacker complete access to your entire domain with an access time of 10 hours or can be expanded up to several years to stay in your domain controller and move laterally to discover more machines and infect them.
What is Golden Ticket?
- Golden Ticket is part of Microsoft authentication protocol called Kerberos.
- Whenever the user tries to login with his/her username and password, NTLM hash ( NT LAN Manager is a suite of Microsoft security protocols intended to provide authentication, integrity, and confidentiality to users. ) will be created for the user’s password, TGT ( Ticket Granting Ticket ) will be sent to KDC Server ( Kerberos Key Distribution Center ) as authentication request ( AS-REQ )
Also Read : Defending and Preventing Against Active Directory Kerberos Attacks
- When users use their Kerberos tickets to authenticate to other systems, the PAC ( Privilege Attribute Certificate ) can be read and used to determine their level of privileges without reaching out to the domain controller to query for that information.
- An attacker with domain administrator privilege can create Golden tickets ( Ticket Granting Ticket ) with arbitrary account names.
- Since the attacker obtained the Domain admin privileges, He/she may configure group policy to set the TGT lifetime of a user account to a shorter or longer value for lateral movement.
Challenges in Detecting Golden Ticket Attacks
- Soc analysts have to validate the Large volume of logs generated and hunt the anomaly.
- Security operation center analyst sees this as legitimate domain administrator activities and marks the incident as false-positive.
- Detecting Golden Ticket attack is difficult as an analyst should be correlating all attributes one with others I.E Time& Date, Login Time Frequency, Logon type, etc.
Event ID’s to Correlate
Event ID | Description | What soc analyst to think |
4672 | Special Privilege Assigned | Analyst should apply filter logic on there enterprise / free SIEM and drill down to find the account name which is uses the special Privilege |
4674 | An operation was attempted on a privileged object | Check for specific commands or processors which is getting executed using the user account, check the computer name on your EDR as well. There is a high chance were attacker can send legitimate commands like ( Ipconfig , etc ) to show them as legitimate business operations. Never stop suspecting and don’t mark the incident as false-positive. |
4688 | A new process is created | Legitimate or suspicious programs ,commands are ran at the moment. |
4768 | A Kerberos authentication Ticket Requested ( TGT ) | Missing this event ID “4768” shows Golden Ticket is used. |
4769 | A Kerberos service Ticket | Check the ticket encryption type and description about the type will be provided in the event log. |
5140 | A network share Object was accessed | File sharing service is accessed |
Top Indicators of Compromise
- Event ID 4674 & 4688 will won’t have the details of origin IP addresses in log, But still this Event ID’s will provide you the account name in the event log for further investigation.
- IP addresses will be captured in Event ID 4769 before the Event ID 4674/4688 for each accounts.
- Special privilege assigned to specific account name or service account.
- Execution of windows CLI commands such as reg.exe , net.exe ,etc , Basically using internal commands to script and do malicious stufuess ,Review your EDR on such circumstance.
Also Read : Malware Hiding Techniques in Windows Operating System
- Shared drive access to keep malicious hacking tools.
- Attacker sent a Kerberos Service Ticket to domain controller prior to TGT request.
Preventive Measures
- Limit user access to only what they need and Install endpoint protection to block attackers from loading modules like mimikatz.
- Create a Terminal Server that can only talk to the DCs. Configure the DCs to only accept administrative connections from that Terminal Server
- Monitor file and user activity , Implement multi-factor authentication (MFA) on all external authentication points, including VPN and OWA/O365.
- Limit the amount of admin accounts to only those who absolutely need it and ensure admin access is not simply added to their day-to-day user account.
- Perform the reset of the krbtgt account (twice) in accordance with your password reset policies, or quarterly.