There are two main password attacks leveraged by adversaries; one is called Password Spraying and the other is called Kerberoasting.

This post focuses on identifying accounts that may be targeted for Kerberoasting and how to harden the environment against Kerberoasting.

Password spraying involves the attacker using a list of passwords and for each password attempts to authenticate as each user using that one password. After working through all users with the first password, they move on to the next password in the list. Successful authentication is noted along the way as these are compromised accounts.
I wrote about detecting password spraying here: https://trustedsec.com/blog/detecting-password-spraying-with-a-honeypot-account

Kerberoasting is possible when an Active Directory account has a Kerberos Service Principal Name (SPN) associated with it. In order to enable Kerberos authentication for an application, the associated service account needs a SPN. Kerberoasting takes advantage of the fact that one can request a service ticket using the SPN associated with a target service account and take that Kerberos service ticket offline to attempt to crack it.

Attackers are most likely to attempt Kerberoasting on the accounts with passwords that are about 5 years and older since they are more likely to have poor passwords, though attackers may just attempt kerberoasting all AD accounts that have SPNs.

For more information on how Kerberoasting works as well as detecting Kerberoasting, read this article: https://adsecurity.org/?p=3458

I wrote a short PowerShell script that identifies all accounts with SPNs as well as Active Directory admin accounts with SPNs (leverages the Active Directory PowerShell module):
https://github.com/PyroTek3/Misc/blob/main/Get-ADUsersWithSPNs.ps1

TO DO LIST:

1. Remove SPNs from AD Admin accounts associated with people since they shouldn’t have any SPNs associated with them.
   
2. If the default domain administrator account is listed here, work to remove the SPN associated with it. This account should never have a SPN.
   
3. Remove SPNs from the other accounts associated with people since they shouldn’t have any SPNs associated with them.
   
4. Identify service accounts identified as AD Admin accounts (those that are members of Administrators, Domain Admins, or Enterprise Admins). Remove accounts that don’t belong and leave only those accounts that require these privileges (should be a minimal to 0 list of service accounts).
   
5. Identify the AD Admin accounts that have old passwords (> 5 years) and put together a plan to change those passwords, preferably with a password of >25 characters.
   
6. Identify the other accounts that have old passwords (> 5 years) and put together a plan to change those passwords, preferably with a password of >25 characters.

IMPORTANT NOTE: Ignore the krbtgt account with regard to these directions as this is required to be configured this way for AD Kerberos to work.

The KRBTGT account requires special attention: https://adsecurity.org/?p=4597

(Visited 27 times, 27 visits today)

Sean Metcalf

I improve security for enterprises around the world working for TrustedSec & I am @PyroTek3 on Twitter.
Read the About page (top left) for information about me. :)
https://adsecurity.org/?page_id=8