Active Directory Security Fundamentals (Part 2)- SPN, Kerberoasting

Service Principal Name (SPN)

A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name.

Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account object that the service instance uses to log on. A given SPN can be registered on only one account.

When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and presents the SPN for the service to authenticate.

SPN (servicePrincipalName) uniquely identifies a service account and it looks like below :

Why it is important to set up SPN❗

The most important reason for setting up an SPN is that it allows to identify your target Server hosting a particular service on the network.

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.

There are a few ways that we can check if the SPN has been registered successfully. If the server hosting the service is running under a domain account (which is recommended) we can run the following command to see the services that are registered.

How to set up SPN ❓

A Service Principal Name (SPN) is a name in Active Directory that a client uses to uniquely identify an instance of a service. An SPN combines a service name with a computer and user account to form a type of service ID. For Kerberos authentication (a protocol that authenticates client and server entities on a network) to function, an SPN must be registered for each service account in the Active Directory.

Demo

For this demonstration, let’s setup a SPN for SQLServiceAccount.

We have a domain account SQLServiceAccount that we’ll be using as a service account. And we’ll register it with a computer pretenting to be SQL server SQLServer Let’s register a SPN using below command:

1

setspn -s MSSQLSvc/sqlserver.rootdse.lab ROOTDSE\SQLServiceAccount

Let’s verify the attribute from the Active Directory Users and Computers as well to see if it is set up correctly.

Now, if we search for SPNs across the domain, we should be able to see it:

Or we can simply enumerate the Service Principal Name (SPNs) of service accounts through a LDAP queries with the help of adsisearcher:

PS C:\> ([adsisearcher]'(servicePrincipalName=*)').FindAll()
Path                                                       Properties
----                                                       ----------
LDAP://CN=RDSEDC01,OU=Domain Controllers,DC=rootdse,DC=lab {ridsetreferences, logoncount, codepage, objectcategory...}
LDAP://CN=krbtgt,CN=Users,DC=rootdse,DC=lab                {logoncount, codepage, objectcategory, description...}
LDAP://CN=SQLServiceAccount,CN=Users,DC=rootdse,DC=lab     {givenname, codepage, objectcategory, dscorepropagationdata...}

Now that we can do see that the SPN is configured properly, let’s see how to do kerberoasting.

Kerberoasting

Before starting Kerberoasting, let’s dicuss a bit about how this attack actually works. Kerberoasting is one of the popular AD Kerberos attacks which was persented in the talk of Tim Medin (Kerberoast Guy) at Derbycon 2014. In this attack, a service account’s credential hash is extracted from Active Directory and cracked offline. We need to identify what accounts are kerberoastable and then as any authenticated user, we can the request service tickets (TGS) for the target service accounts without sending any traffic to the target server on which the service is running.

As you can see in the below diagram, kerberoasting is focussed on requesting TGS from KDC. Only the highlighted steps 3 and 4 are involved in this attack.

Below are the steps for performing Kerberoasting:

1. Enumerate the AD for accounts that have SPN values set
2. Request service ticket (TGS) from AD using the SPN values for target service account
3. Extract service ticket and download it to crack offline
4. Perform a Brute force attack on it to crack the password for target service account

This reason this attack is so effective is :

• No speacial privileges are required to do kerberoasting. Any authenticated user can do it
• Admins create weak passwords for service accounts just like normal user accounts
• Service account passwords are changed very less frequently in an organization environment.
• In most of the cases, service accounts have domain admin privileges (or atleast local admin privileges on the target server)

Because of the above reasons, it is considered as a low hanging fruit since it is easily executed and if service account is successfully compromised, high chances of escalating privileges in domain.

For service ticket extraction, we can use tools like:

• Mimikatz
• PowerView
• SharpView
• Rubeus

Below is a demonstration of doing kerberoasting using Rubeus:

Once we get the ticket, we can begin cracking the passwords. Cracking service accounts is a particularly successful approach because their passwords very rarely change. Also, cracking the tickets offline will not cause any domain traffic or account lockouts, so it is undetectable.

Conclusion

Kerberoasting is an efficient technique for attackers who have limited rights within a domain. It totally depends on how strong the passwords are, and then once cracked, access to multiple accounts is gained and can be used to launch further attacks. Setting up strong passwords can make this attack more difficult, hence the service accounts should be treated much like the other privileged accounts. Best practice is to create a list of service accounts, regularly check when the password was last changed, and implement a process for rotating passwords on a regular basis. Few ways can be created to detect this kind of attack by implementing deception in the environment.

I have written another blogpost on detecting possible kerberoasting attempts in the environment using AD Decoys. Here is the link: Detecting LDAP enumeration and Bloodhound‘s Sharphound collector using AD Decoys