Kerberoasting attacks: How to keep your Active Directory safe

A domain administrator account is the holy grail of privileged accounts in a Microsoft Active Directory environment. If an attacker can get their hands on a Domain Administrator account in the domain, they’ll have access to basically everything. Kerberoasting is one technique attackers may use to escalate privileges within Active Directory.

We’ll walk through what kerberoasting is, what makes Active Directory vulnerable, and how it can be prevented.

What is Kerberos?

To understand kerberoasting we must first understand Kerberos itself. Kerberos is the authentication protocol used in Microsoft’s Active Directory. It’s used to verify the identity of a user or computer requesting access to resources. Clients receive a special token called a ticket using Active Directory’s Kerberos Key Distribution Center (KDC).

Active Directory’s Ticket Granting Ticket (TGT) is the mechanism that grants permissions to request a Ticket Granting Service (TGS) ticket. The TGS Ticket is then used to access resources on the domain, such as file servers.

What is kerberoasting?

Kerberoasting is a privilege escalation attack that exploits the Kerberos authentication protocol in Microsoft Active Directory and the ticket-granting mechanism described above. An attacker can use a standard Windows user account to gain access to the password hash of a privileged user.

Known as a post-exploitation attack technique, the goal of kerberoasting is to obtain a password hash for an Active Directory account that has a Service Principle Name (SPN). An SPN ties a Kerberos service to a user account within Active Directory. The attacker requests a Kerberos ticket for an SPN, and the retrieved ticket is encrypted with the hash of the target accounts password associated with the SPN. The attacker then works offline to try and crack the password hash and ultimately take over the account plus its associated access.

These attacks can be difficult to detect as they don’t rely on malware, meaning they won’t be detected by antivirus or other traditional solutions. Kerberoasting is difficult to detect for any cybersecurity solution that doesn’t analyze the behavior of approved users.

What is an Active Directory service account?

Most organizations use a service account to run Windows services on servers in an Active Directory domain environment. Typically, these accounts are not used by regular users. Instead, administrators will create an Active Directory user account, set the password not to expire, and set the password for the user.

As you can see below, you will see the service account assigned to the Windows service in the Services console.

If you double-click a service, you’ll see the details of the associated service account.

Service accounts can be dangerous since they typically have high-level permissions on a server or even domain administrator access. They are often poorly monitored and may be configured with weak and easily compromised passwords that can quickly be cracked using the tools mentioned earlier.

How does kerberoasting work?

To carry out a kerberoasting attack, the attacker must be on the enterprise network where Active Directory resides to have ‘line of sight’ access and communication with a domain controller. First, an attacker can exploit any weak user credentials to gain access to a standard user account and then use the kerberoasting technique to compromise the legitimate Active Directory Kerberos service ticket.

For this attack to work, the attacker already has access to a standard Windows user account. Attackers can use any domain account for a kerberoasting attack, as any account can request tickets from the TGS.

How do attackers gain access to a valid standard Windows account in the environment? They can use several methods to reveal a valid user account. These include:

• Phishing attacks
• Malware
• Initial access brokers
• Social engineering

Once an attacker is inside the network, they can request a Kerberos service ticket from the ticket-granting service (TGS) in Active Directory. There are many free and open-source tools available that make this process easy. Examples include GhostPack’s Rubeus or SecureAuth Corporation’s GetUserSPNs.py. Many of these tools are available as part of Kali Linux, a special-purpose Debian distribution aimed at cybersecurity penetration testing.

Running these scripts against Active Directory will look for all user accounts associated with SPNs on the domain AND request their valid ticket from the domain controller. The returned ticket from the domain controller is encrypted with an NTLM hash.

The attacker will then capture the returned value of the Kerberos ticket and take it offline to use a password tool like Hashcat or John the Ripper, using a rainbow table or bruteforce to crack the password for the user account associated with the Kerberos ticket.

Bypassing antivirus and network traffic monitoring

One of the reasons that kerberoasting is a favorite among attackers is it allows them to carry out the attack offline. This is because it does not use malware that antivirus programs may block, and since they take the hash offline for cracking, it does not involve any unusual network traffic or account logins. So, after the initial activities to obtain the Kerberos ticket hash, the attacker can work entirely offline until they have cracked the password hash for the service account.

How can organizations protect against kerberoasting attacks?

Kerberoasting can be challenging to protect against since it uses legitimate Kerberos functionality and the ticket-granting service to carry out the attack. However, there are certainly best practices organizations can follow to bolster their account passwords and service account security. Note the following:

• Follow the principle of least privilege and grant administrator permissions sparingly. Service accounts are often granted administrative permissions. However, admin rights are often given when not needed to circumvent any challenges or obstacles.
• Audit all domain account passwords regularly, including service accounts. Be sure to audit Active Directory domain account passwords, including service accounts. If there are weak passwords assigned to service accounts configured in the domain, administrators need visibility of these.
• Use third-party tools. Carrying out effective Active Directory password auditing requires third-party tools. It isn’t easy to manually audit Active Directory passwords using homegrown scripts and other tools that administrators must maintain.

How can Specops Password Auditor help?

Specops Password Auditor offers a free automatedtool to proactively scan and find weak, reused, and breached passwords in your Active Directory environment. It makes this process extremely easy by providing an automated auditing tool that checks passwords of Active Directory user accounts against a list of vulnerable passwords obtained from multiple data breach sources.

It also provides valuable insights, such as a full view of the administrator accounts in an organization’s domain, including stale/inactive admin and user accounts. These capabilities help administrators audit service accounts in the domain for password security and help give visibility to service accounts with administrator permissions. Specops Password Auditor gives you a full view of stale accounts in your organizations, which are often a starting point for kerberoasting attacks. You can also view all delegable admin accounts and choose to mark them as ‘sensitive and cannot be delegated’ within your environment.

It also generates comparison reports of the password settings in your organization against industry-standard compliance regulations, such as NIST, PCI, HiTrust, and much more.