https://www.thehacker.recipes/ad/movement/kerberos/forged-tickets#golden-ticket
https://adsecurity.org/?p=1515
first lets see how kerberos works:
1. First authentication request which is TGT, is send to the authenticator which is KDC in the form of AS REQ. When user put his/her username and password, the password is converted in NTLM hash and timestamp of that user (in order to prevent replay attack) is encrypted with the hash and send to KDC.
2. The domain controller KDC service checks users information like users logon restrictions, group membership permission etc. it basically checks what things users are allowed to do on their system; then create a TGT for the user. send the TGT in reply with AS REQ which is AS REP.
3. this TGT is encrypted with AD krbtgt account password hash. only the kerberos service in the domain can open and read TGT data. no other one can because they dont have krbtgt accounts password hash to decrypt.
4. the user needs to present this TGT when requesting for TGS in the form of TGS REQ. then the KDC opens the TGT and validate the PAC checksum. PAC stands for privilege attribute certificate which is a extension to kerberos tickets. this contains useful users privilege informations. when a user authenticates itself within the AD domain then domain controller add this information to the kerberos ticket. anyway if the PAC checksum check out/results as correct then the data in the TGT is effectively copied to the TGS ticket.
5. this TGS is encrypted with the ntlm password hash of the target service account and given the user in TGS REP return message.
6. the user connects to the server who is hosting the service on the appropriate port. user presents the TGS (AP REQ) to the server. server open the TGS ticket using its service account ntlm password hash.
7. Unless PAC validation is required (rare) the service accepts all the TGS data from the TGS ticket with no communication to the DC.
* golden ticket required krbtgt account ntlm password hash. if this password hash is compromised then you need to change the password of this account twice. because it remembers the current and previous password.
* silver ticket required service account password hash (the service account could be either computer account or user account).
golden ticket is called the authentication ticket. in this attack there is no AS REQ and AS REP. because as the TGT is forged meaning manually making, so attacker starts the process directly from sending TGT to KDC in order to get TGS.
TGT is only used to prove to KDC that the user is authenticated by another domain controller. as TGT is signed by krbtgt account so any KDC service in the domain can decrypt this. its literally telling the KDC that, hey KDC just decrypt the TGT using your krbtgt password hash and dont validate the user found inside the TGT. if decryption is successful then issue TGS please using service account ntlm password hash.
Golden ticket making requirements:
--krbtgt account password hash
--domain name
--domain sid
--userid (rid) or username for impersonation
The domain controller KDC service does not validate the user account present in TGT unless the TGT age is 20 minutes old. which means the attacker can use disabled/deleted/or even fictional account that does not exist in AD to create the TGT.
so it is best idea to create TGT using real AD account because KDC service checks the accounts validity after TGT is 20 minutes old. duing TGT creation kerberos policy says that TGT is valid for 10 hours. if the fake TGT says that the ticket validity is 10 years, KDC also accepts such because it also does not check the validation time. it assume may be 10 years is stated in my kerberos policy.
as the krbtgt account password is not changed by the domain admin often, so attacker can create TGT any times they want unless the krbtgt account password is changed twice. As the TGT is created to impersonate user persists so it does not matter if the user change its password. the ticket will be still valid. because it is not dependent on users password, KDC put more emphasis on krbtgt account password hash.
the golden ticket can be generated from any machine and can be used on any machine, even from domain not joined machine.
Detection:
Monitor for kerberos tickets issued with values for maximum lifetime for user ticket and maximum life time for user ticket renewal values. if the values are above than the specified in domain policy then suspicous things you have on your domain. but if the attacker create the ticket setting the value following your domain policy then you can not detect that.
Mitigation:
1. Limit domain admins from logging on to any other computers other than domain controllers and a handful of admin servers. also dont let other admins to log on these servers.
review membership of privileged domain groups i.e. domain admins, enterprise admins, server operators. these groups provide rights to access domain controllers. because if attacker capture the hashes of priviledged domain group member, then he can play pass the hash attack to get access on AD then can steal the ntds.dit file. then after grabbing krbtgt password hash from ntds.dit file, the attacker can make golden ticket.
another thing is, review the following AD permissions applied at the domain level:
--Replicating directory changes
--Replicating directory changes all
these rights provides attackers the ability to obtain the krbtgt hash using dcsync technique. remove any unnecessary permissions.
2. Delegate all other rights to custom admin groups. This greatly reduces the ability of an attacker to gain access to a domain controller's AD database. If the attacker cannot access the AD database ntds.dit file they cannot get the krbtgt account password hash data. use ADSelfService as two factor authentication.
3. the krbtgt account is disabled and stores the current and previous one password. this krbtgt account password hash is used to sign the PAC in kerberos tickets as well as encrypt the TGT (authentication ticket). if a ticket is signed/encrypted with a different key/password than DC (KDC) is expecting, then it checks krbtgt previous password to see if that is successful. this is the reason why both passwords are kept. that is why you need to change the krbtgt account password twice if you suspect the account is compromised.
4. It is advisable to regularly change the krbtgt account password after all this is an admin account too. Changing it once then letting AD replicate and changing it a second time about 12 to 24 hours later will update both of the krbtgt passwords (current and previous) in a manner that doesnot invalidate every existing kerberos ticket. this process should have no negative impact on the environment (but as always, test first). This process should be the standard method for ensuring the krbtgt password changes at least once a year (and when an AD admin leaves the organization, loss of control of AD backup media, etc).
once an attacker has gained access to krbtgt account password hash then can create golden ticket at will. invalidate any existing golden tickets (and all active kerberos tickets) by changing the krbtgt password rapidly aka double-tap. this invalidates all kerberos tickets and removes the attacker ability to create valid golden tickets with their krbtgt (assuming they dont have the ability to pull the updated krbtgt pw hash by dcsync). this krbtgt account double-tap is required when breach scenario is occured and there is an active attacker roaming on the network.
one thing to remember:
for golden and silver tickets please remember by default ticketer and mimikatz tool forged tickets containing PAC's that say the user belongs to some well-known administrators groups (i.e. 513, 512, 520, 518, 519). but there are scenarios where these groups are not enough because there could have some special machines where even domain admins dont have local admin rights.
in these situations, testers can either look for the domain groups that have local administrator privileges on target machines, or specify all groups id's when creating the ticket.
when forging tickets only user id and group id are useful. the username supplied is mostly useless.
In order to craft a golden ticket, testers need to find the krbtgt's RC4 key (i.e. NT hash) or AES key (128 or 256 bits). In most cases, this can only be achieved with domain admin privileges through a dcsync attack. because of this golden tickets only allow lateral movement and not privilege escalation.
Microsoft now uses AES 256 bits by default. Using this encryption algorithm (instead of giving the NThash) will be stealthier.
windows mimikatz:
with an NT hash:
kerberos::golden /domain:$DOMAIN /sid:$DomainSID /rc4:$krbtgt_NThash /user:randomuser /ptt
with an AES 128 key:
kerberos::golden /domain:$DOMAIN /sid:$DomainSID /aes128:$krbtgt_aes128_key /user:randomuser /ptt
with an AES 256 key:
kerberos::golden /domain:$DOMAIN /sid:$DomainSID /aes256:$krbtgt_aes256_key /user:randomuser /ptt
for both mimikatz and rubeus, /ptt flag is used to automatically inject the ticket.
linux impacket:
there are impacket scripts for each step of a golden ticket creation : retrieving the krbtgt, retrieving the domain SID, creating the golden ticket.
# Find the domain SID
lookupsid.py -hashes 'LMhash:NThash' 'DOMAIN/DomainUser@DomainController' 0
# Create the golden ticket (with an RC4 key, i.e. NT hash)
ticketer.py -nthash $krbtgtNThash -domain-sid $domainSID -domain $DOMAIN randomuser
# Create the golden ticket (with an AES 128/256bits key)
ticketer.py -aesKey $krbtgtAESkey -domain-sid $domainSID -domain $DOMAIN randomuser
# Create the golden ticket (with an RC4 key, i.e. NT hash) with custom user/groups ids
ticketer.py -nthash $krbtgtNThash -domain-sid $domainSID -domain $DOMAIN -user-id $USERID -groups $GROUPID1,$GROUPID2,... randomuser
Another command:
kerberos::golden /admin:ADMIINACCOUNTNAME /domain:DOMAINFQDN /id:ACCOUNTRID /sid:DOMAINSID /krbtgt:KRBTGTPASSWORDHASH /ptt
Avi
Comments
Post a Comment