SBS CyberSecurity’s network security team performs hundreds of internal penetration tests each year. Over time, our clientele has consistently improved their security posture. However, some old tried and true attacks never seem to go away.
SPN Account’s User Hashes Can be Read by Any Domain User
Active Directory is the centralized management for the majority of on-premises domains. The directory service allows administrators to manage the domain’s users, computers, group policies, and many other common administrative tasks.
By default, Active Directory uses an authentication protocol known as Kerberos. The details of the authentication process for Kerberos are far beyond the scope of this article. For an in-depth look at the authentication protocol, please review the Kerberos Authentication Overview article from Microsoft.
The main security issue surrounding the use of Service Principle Name (SPN) accounts is the fact that any valid user on the domain can abuse the Kerberos authentication protocol to begin the authentication process and receive a hash of any SPN accounts in use. This action can be performed by any user on the domain and does not require any elevated privileges. Most often, the accounts set up with a Service Principle Name (SPN) are service accounts or other accounts with elevated privileges on the domain.
Once an SPN account’s user hash has been captured, it can be taken offline and potentially cracked by the attacker. If the password cracking process is a success, then the attacker has the ability to log in as that SPN account and will have all privileges of that user.
Low Tech Attack With a High Success Rate
To successfully perform this attack, the attacker would only need the following:
- Any user account on the domain. This can be achieved through social engineering, network poisoning attacks, or various exploits.
- A tool capable of querying the SPN user accounts and their hash. There are many tools that can be downloaded to perform this type of attack. Some of the more popular are Rubeus, Impacket Toolkit, and the Invoke-Kerberoast PowerShell module. Each of these tools is freely available online and has many guides written about performing this particular attack.
- The last requirement is for the attacker to have the ability to crack the SPN’s password hash. The success of this step will depend on the strength of the password in use and the capabilities of the attacker.
How to Minimize or Eliminate This Risk
According to the MITRE ATT&CK Framework, the following steps should be performed to mitigate this type of attack:
- Enable AES Kerberos encryption (or another more robust encryption algorithm), rather than RC4, where possible.
- Ensure strong password length (ideally 25+ characters) and complexity for service accounts and set these passwords periodically expire. Also, consider using Group Managed Service Accounts or another third-party product such as password vaulting.
- Limit service accounts to minimal required privileges, including membership in privileged groups such as Domain Administrators.
Detection
Enable Audit Kerberos Service Ticket Operations to log Kerberos TGS service ticket requests. Particularly investigate irregular activity patterns (ex: accounts making numerous requests, Event ID 4769, within a small time frame, especially if they also request RC4 encryption [Type 0x17]).
Know Your Active Directory Environment
Features such as SPN accounts are not always monitored and reviewed regularly. The reason why this attack continues to be successful is that an SPN account may have been set up several years ago, with a weak password compared to current standards, and then was largely forgotten.
