When we configure our Servers (hosting a service) to use Kerberos authentication for the clients to access that service, there are a couple of prerequisites that must be met. First, the clients and servers must be joined to a domain. If the server is from other domain, then a trust must be setup between the two domains. Secondly an SPN must be successfully registered for the Server hosting the service so that it can be identified on the network.
The last bit is what will be attacked in a kerberoasting attack. The goal of the attack is to acquire the password for a service account. An attacker can do this by requesting a TGS ticket for the service (as an authenticated user in the domain), and then attempting to decrypt the TGS ticket by trying NTLM hashes of various passwords. When the correct NTLM hash is used to decrypt the ticket, a valid kerberos ticket will be decrypted and the attacker will know the password of the service account. Password cracking tools such as Hashcat and John the Ripper support cracking kerberos TGS tickets.
Kerberoasting — From setup to cracking
During this post I will be using Covenant C2, which I described how to setup in a previous post. This attack is not unique to Covenant, and can be performed over your preferred C2 framework or directly from a box you have RDP or hands-on-keyboard access to.
In Kerberoasting, threat actors abuse valid Kerberos ticket granting tickets to make a request for a ticket granting service from any valid service principal name (SPN) within your Microsoft Active Directory domain. Such ticket granting services can be vulnerable to offline password cracking which can allow a threat actor to recover the plaintext password of the associated service account mapped by the SPN.
This differs from NTLMv1-SSP in which the server challenge is changed at the client-sideNTLMv1 and NTLMv1-SSP are treated differently during cracking or even downgrading, this will be discussed at the NTLM attacks part.
For user accounts, passwords can be obtained the typical way, by Kerberoasting, cracking NTLMv1/NTLMv2 authentication, simply guessing weak passwords or dumping them from memory on compromised hosts. Computer accounts are harder to obtain since they do by default have very strong randomly generated passwords and their password/keys only reside on the host the account belongs to (or on the DC). When we have Administrator rights on the associated host, it becomes relatively easy since the computer account password is stored in the registry and thus can be obtained via the network with secretsdump.py, or by dumping the secrets with mimikatz lsadump::secrets. Both also support dumping secrets from offline registry hives.
Google Workspace admins may setup 2-step verification (2SV) to add an extra layer of security to user accounts by asking users to verify their identity when they use login credentials. Admins have the ability to enforce 2SV from the admin console as well as the methods acceptable for verification and enrollment period. 2SV requires enablement on admin accounts prior to it being enabled for users within organization units. Adversaries may disable 2SV to lower the security requirements to access a valid account.
2ff7e9595c
Comments