Services that support Kerberos authentication require to have a Service Principal Name (SPN) associated to point users to the appropriate resource for connection. Discovery of SPNs inside an internal network is performed via LDAP queries and can assist red teams to identify hosts that are running important services such as Terminal, Exchange, Microsoft SQL etc. and being stealthy at the same time. Furthermore identification of SPNs is the first step to the kerberoasting attack.
Tim Medin explained SPN really well in his talk Attacking Kerberos: Kicking the Guard Dog of Hades with practical examples. Sean Metcalf also provided some good resources regarding SPN including an extensive list of Active Directory Service Principal Names which can be found at the end of the article.
SetSPN is a native windows binary which can be used to retrieve the mapping between user accounts and services. This utility can add, delete or view SPN registrations.
setspn -T pentestlab -Q */*
Services that are bind to a domain user account and not a computer account are more likely configured with a weak password since the user has selected the password. Therefore services which they have their Canonical-Name to Users should be targeted for Kerberoasting. From the list of SPNs below the service PENTESTLAB_001 is associated with a user account.
Tim Medin developed a PowerShell script which is part of kerberoast toolkit and can query the active directory to discover only services that are associated with a user account as a more focused approached compared to SetSPN.
There is also a VBS script which is part of the same tookit and can provide the same information. The script can be executed from the windows command prompt by using the native Windows binary cscript.
PowerShell AD Recon
Similarly to what Tim Medin developed Sean Metcalf wrote various PowerShell scripts to perform recon against Kerberos. These scripts are part of PowerShell AD Recon repository and can query the Active Directory for interesting services such as Exchange, Microsoft SQL, Terminal etc. Sean bind each script to a specific service depending on what SPN the red teamer would like to discover. The following script will identify all the Microsoft SQL instances on the network.
powershell_import /root/Discover-PSMSSQLServers.ps1 powershell_execute Discover-PSMSSQLServers
Microsoft Exchange servers can be also discovered with the PSMSExchangeServers script.
powershell_import /root/Discover-PSMSExchangeServers.ps1 powershell_execute Discover-PSMSExchangeServers
Enumeration of service accounts is important as these accounts might be configured with a weak password. The attributes PasswordLastSet and LastLogon can provide an indication of services which have a higher possibility to have a weak password set.
powershell_import /root/Find-PSServiceAccounts.ps1 powershell_execute Find-PSServiceAccounts
PowerShell Empire has also a module which can display Service Principal Names (SPN) for domain accounts. This module is part of the Situational Awareness category and it should be used as stealth network recon in a red team engagement.
The services will be presenting in the following format.
Scott Sutherland before implementing the Get-SPN module to Empire had created several Powershell scripts as part of PowerShellery which can gather SPNs for various services. Some of these require PowerShell v2.0 and some other PowerShell v3.0.
Get-SPN -type service -search "*"
Results can be also formatted as a table for easier mapping of accounts and services.
Get-SPN -type service -search "*" -List yes | Format-Table
There is also an additional script which can obtain the UserSID, the service and the actual User.
Import-Module .\Get-DomainSpn.psm1 Get-DomainSpn
Service Principal Names can be also discovered from non-joined domain systems with the python version of GetUserSPNs which is part of impacket. However valid domain credentials are required for communication with the Active Directory as token based authentication cannot be used.
./GetUserSPNs.py -dc-ip 10.0.0.1 pentestlab.local/test
Sorry, part of my last comment was a stupid question. Google shows that dsquery CAN do arbitrary ldap queries, but that point is moot, as it’s not included except in server versions of Windows. I do think all of the listed functionality could be performed using arbitrary LDAP queries, but I don’t see anything built into Windows that lets you perform one. Oh well…
Can’t all of this be done with simple LDAP queries? Though I suppose you’d have to download openldap… Can you do somehow using dsquery as well?