Rubeus - Now With More Kekeo
Kerberoasting is where a service ticket is used to brute force a service password. This password can then be used to either move laterally or (if the service runs with elevated privileges) to elevate your privileges.
Note that not every account is kerberoastable, though it’s not 100% obvious from this walk-through why that is. The Kali Linux tool bloodhound
can be used to identify potentially kerberoastable accounts.
The Invoke-Kerberoast
PowerShell module can be used to create a dump of service tickets that can then be attacked offline using Hashcat of John the Ripper. (Note that calling Out-File
with the -Width 8000
option is important in the below example, as otherwise the ticket can be truncated!)
Invoke-Kerberoast -OutputFormat Hashcat |
Select-Object Hash |
Out-File -filepath "$FILE_PATH" -Width 8000
The main defenses against kerberoasting are (1) strong passwords and (2) making sure you’re not running any services as domain admin (which you shouldn’t need to do in this day and age anyway).
AES-REP roasting is basically kerberoasting for regular user accounts. The only requirement to roast a user account is that Kerberos pre-authentication is disable.
(When pre-authentication is disabled, the authentication server will supply a ticket granting ticket and a session key automatically when requested, without first verifying the user. This data is then stored offline by the Windows machine for later decryption when the user with pre-authentication disabled logs in. But this means that all we need to do is to break the user’s NT hash!)
Basically the only mitigation for this attack is to keep pre-authentication enabled, though strong password policies can help.
The only real way to defend against this attack is to only allow domain admins to log into domain controllers, not lower privileged machines!
The idea with gold and silver tickets is that, since the KDC and service long term secret keys are just the NT hashes of the corresponding service account’s passwords, then if you can dump the password (or even its hash), you can forge a kerberos ticket without ever needing to contact the KDC.
Silver tickets are forged using a service account’s NT hash, and can be used to grant any user access to that service. This works because Kerberos implicitly assumes that only the KDC and the service account know the service account’s long term secret key.
Golden tickets take things a step further - if you can get the krbtgt
user’s NT hash, then you can forge a ticket granting ticket for any user, and then use that to get the KDC to provide a valid service ticket for any service that user has access to. This works because Kerberos trusts the encrypted ticket granting ticket blob and doesn’t reauthenticate the user before granting further access.
Golden tickets are powerful (since you can be anyone, it’s trivial to gain control of the domain), but also noisier - because you’re running through the KDC infrastructure, golden ticket still generate (almost) all of the normal logging, while silver tickets allow you to bypass the KDC completely and only generate logs on the service server (if that).