Rubeus.exe golden /aes256:<krbtgt_aes256_key> /sid:<domain_sid> /ldap /user:Administrator /printcmd
Mitigation
The following security control should be implemented to mitigate a Golden Ticket:
Change the KRBTGT password every 12 months, or when the domain has been compromised or suspected to have been compromised. Changing the KRBTGT password will invalidate any existing Golden Tickets that are being used.
To effectively change the KRBTGT user object’s password hash, and invalidate any Golden Tickets, the KRBTGT password must be reset twice. This is because both the new and old KRBTGT passwords are stored by Domain Controllers such that authentication in the domain is not disrupted during a KRBTGT password change. When resetting the KRBTGT password, it is important to ensure that sufficient time is allowed between password resets to ensure the new password has had time to replicate to all Domain Controllers. For more information, see Microsoft’s guidance and PowerShell script to assist with resetting the KRBTGT password.
Whereas golden tickets are forged TGTs, silver tickets are forged service tickets (TGS) - Encrypted and signed by the hash of the service account (golden ticket is signed by the hash of krbtgt)
The following security controls should be implemented to mitigate a Silver Ticket:
Create User objects with SPNs as group Managed Service Accounts (gMSAs). gMSAs have automatic password rotation, a 120-character password and simplified SPN management. These security features protect the password from being cracked, reducing the likelihood of a successful Silver Ticket. However, if creating user objects with SPNs as gMSAs is not feasible, set a minimum 30-character password that is unique, unpredictable and managed is set.
Change all computer object (including Domain Controller) passwords every 30 days. Malicious actors can establish persistence in Active Directory using a computer object’s password; ensuring all computer object passwords (including Domain Controller passwords) are changed every 30 days can mitigate this persistence technique.
Ensure computer objects are not members of privileged security groups, such as the Domain Admins security group. If malicious actors obtain a computer object’s password hash, then they gain any privileges the computer object has in the domain.
Ensure the Domain Computers security group does not have write or modify permissions to any objects in Active Directory. All computer objects are members of the Domain Computers security group. If this security group has rights over other objects, then malicious actors can use these rights to compromise other objects and potentially escalate their privileges and perform lateral movement.
The following security controls should be implemented to mitigate Skeleton Key:
Limit access to Domain Controllers to only privileged users that require access. This reduces the number of opportunities for malicious actors to gain access to Domain Controllers.
Restrict privileged access pathways to Domain Controllers to jump servers and secure admin workstations using only the ports and services that are required for administration. Domain Controllers are classified as ‘Tier 0’ assets within Microsoft’s ‘Enterprise Access Model’.
Run the LSASS process in protected mode. This makes it more difficult to override the LSASS process, which is required for Skeleton Key to succeed.
Implement Microsoft’svulnerable driver blocklist. Restricting known malicious or vulnerable drivers on Domain Controllers makes it more difficult for malicious actors to bypass LSASS protection.
Restrict driver execution to an approved set. Restricting the drivers that can be loaded on Domain Controllers to an approved set hardens it against attempts to bypass LSASS protection. This can be achieved through application control solutions, including Microsoft’s Windows Defender Application Control.
Only use Domain Controllers for AD DS and do not install any non-security-related services or applications. This reduces the attack surface of Domain Controllers as there are fewer services, ports and applications that may be vulnerable and used to compromise a Domain Controller.
Centrally log and analyse Domain Controller logs in a timely manner to identify malicious activity. Domain Controller logs provide a rich source of information that is important for investigating potentially malicious activity on Domain Controllers and in the domain.
Disable the Print Spooler service on Domain Controllers. For example, malicious actors have targeted the Print Spooler service on Domain Controllers as a technique to authenticate to a system they control to collect the Domain Controllers computer object password hash or TGT. Malicious actors can then use this to authenticate to the Domain Controller they coerced and gain administrative access.
There is a local admin "Administrator" on every DC whose password is DSRM. DSRM password is required when a server is promoted to DC and it is rarely changed
Dump DSRM password - DA privileges needed
Invoke-Mimikatz -Command '"token::elevate" "lsadump::sam"' -Computername dc
Compare the Administrator hash with the Administrator hash of below command
Invoke-Mimikatz -Command '"lsadump::lsa /patch"' -Computername dc
Logon Behavior for the DSM account needs to be changed before passing the hash
Security Descriptor Propagator (SDPROP) runs every hour and compares the ACL of protected groups and members with the ACL of AdminSDHolder and any differences are overwritten on the object ACL
