Hi everyone, we’ve discussed basics of Active Directory and different servers in AD in previous blog posts of this series. If you’ve not yet read that, please find that here in [Part 1] and [Part 2]. We’ve also understood trust relationships in AD environment which can be checked in the blogpost [here]. Finally, we also did Active Directory enumeration which was discussed in part 4 of this series [here].
Let’s have a look at the current post in which we’ll discuss how to enumerate an active directory domain for the service accounts and perform Kerberoasting attack.
Kerberos:
To understand Kerberos based attacks, let’s first understand what Kerberos is, and how it works in Microsoft Active Directory Environments. Kerberos is used as the default authentication protocol used by Microsoft Windows. Kerberos authentication protocol was named after Cerberus (a big 3 headed dog) who guards the Gates to the Underworld according to myth. MIT used this name and similar kind of logo for the authentication protocol. In Windows 2000, Microsoft introduced their version of Kerberos and became the standard for SSO for other applications as well. Using the strong cryptography and third-party ticket authorization, it is surely an effective authentication protocol, but there are few flaws in its design which we will discuss so that we can understand the different attacks based on abusing Kerberos authentication flow.
In case of Kerberos, there is a Key Distribution Centre that includes below components:
- Authentication server (AS) – Performs the initial authentication and ticket for Ticket Granting Service
- Database – Used by authentication server to verify access rights of users
- Ticket Granting Server (TGS) – Issues the ticket for the Servers
For Kerberos authentication, both the client and the server are required to be verified. Let us suppose that a client wants to connect to a target server and access a particular service on it. The client will first verify itself to the KDC (Key Distribution Centre).
Below are the overall steps to get verified successfully to the KDC:
- The client first connects with the Authentication Server
- The client then presents its User ID to the Authentication Server
- And the client requests a ticket to the targeted server
Let’s understand it in detail. Now the request is partially encrypted with the requesting user’s password’s secret key. This is done so that the cleartext password isn’t sent over the insecure network. The Authentication Server verifies the user by using the password to decrypt the request.
Once the client is verified, the Authentication Server sends a TGT (Ticket Granting Ticket) to the client which is encrypted with a different secret key. Now the client has the TGT and if the user wants to access a particular service running on the target server, the client requests the TGS by sending its TGT with the request to access the target server.
Once the TGS receives the TGT, it decrypts it with the secret key that he shares with the Authentication Server and issues a token for the client, that it encrypts with another key. This third key is shared between the TGS and the targeted server.
Finally, the client sends the service ticket (token) to the targeted server which will decrypt the token with the TGS shared key. And now the client can use the targeted server.
Keys that are used in Kerberos authentication process
Three different secret keys are used in the Kerberos authentication process.
-
- The first key between the client and the AS is based on the client’s password.
- The AS and the TGS share another secret key.
- The TGS and the targeted server.
Introduction to Kerberoasting
In Kerberoasting attack, an attacker steals the service ticket, that is encrypted with RC4 and bruteforces its hash offline to extract its password. Kerberoasting attack takes advantage of legacy Active Directory support for older Windows clients and the type of encryption used and the key material used to encrypt and sign Kerberos tickets.
In the Figure 1, (Kerberos authentication process), Kerberoasting attack is focussed on the step 3 where user gets the service ticket for the target service. And it does not connect to the target server and instead retrieves the service ticket for the target service and performs brute force attack on it to crack the password for the service account running the service on the target server.
When a domain account is configured to run a service in the environment, such as in case of Microsoft SQL, a SPN (Service Principal Name) is used in the domain to associate the service with a login account. When a user needs to use the specific resource in the domain, they receive a Kerberos ticket signed with NTLM hash of the account that is running the service.
Note that any valid Active Directory domain user can make a request for SPN for any registered service (mostly we have seen MS SQL and IIS) and once the Kerberos ticket is received, it can be cracked offline. This is significant because in most of the cases, a service account is at least an administrator on the target server.
SPN (Service Principal Name)
In windows environments, a service principal name (SPN) is referred to be 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. Below is the reference for more details on service principal names-
The first step in the Kerberoasting attack is to find out all the Service Principal Names in the environment. This can be done either by using raw LDAP queries or by using utilities such as setspn which is builtin utility or by using third party/open-source scripts which we’ll discuss in next section.
Discovering SPN Ticket
A very simple way to discover all the present SPN tickets on a Windows Active Directory environment is by using the setspn utility by entering the below command:
setspn -t domainname -q */*
Note-: 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.
SPN Discovery using LDAP query:
SPN can also be queried by utilizing the LDAP queries. The query to enumerate SPNs is as follows:
(&(objectClass=user)(objectcategory=user)(servicePrincipalName=*))
Note: SPN can also be queried by using dsquery utility by using below command:
dsquery * "ou=domain controllers,dc=yourdomain,dc=com" -filter "(&(objectcategory=computer)(servicePrincipalName=*))" -attr distinguishedName servicePrincipalName > list_of_spns.txt
SPN Discovery using inbuilt SetSPN utility:
Below is how the output looks like from SetSPN utility.
As you can see in the screenshot above, it shows the SPN is for SQL Server account which is running with account SVC_SQL_Service.
Additionally, few other tools can also be used to do the SPN discovery such as:
Rubues (https://github.com/GhostPack/Rubeus)
GetUserSPNs from Impacket
PowerShell AD Recon
Empire
PowerShellery(https://github.com/nullbind/Powershellery) etc.
Once the enumeration of service accounts and SPNs is done, the attacker then requests Kerberos ticket-granting service tickets for the services, extracts the hashes from memory, and saves them for later offline brute force.
Performing Kerberoasting Attack
The service account SVC_SQL_Service@scriptdotsh.local is of a domain user with domain admin privileges to run the SQL Server service. Let us perform the kerberoasting attack to request the ticket for it. To perform Kerberoasting attack, we can use the tools such as Rubues (https://github.com/GhostPack/Rubeus) that can fully automate this process.
PS> .\Rubeus.exe kerberoast /simple /outfile:myhash.txt [*] Action: Kerberoasting [*] NOTICE: AES hashes will be returned for AES-enabled accounts. [*] Use /ticket:X or /tgtdeleg to force RC4_HMAC for these accounts. [*] Searching the current domain for Kerberoastable users [*] Total kerberoastable users : 2 [*] Hash written to C:\Rubues\myhash.txt [*] Roasted hashes written to : C:\Rubues\myhash.txt
For demonstration, we have hosted the Kerberoast.ps1 script on a remote system and ran the Powershell to run that to get the ticket in hashcat format.
In the output, we have ticket in hashcat format that we can crack in hashcat.
Cracking the ticket offline:
Once the kerberoasting is done, the ticket can be saved in a file for example myhash.txt. Any Kerberos tickets gathered by the GetUserSPNs script is directly crackable with Hashcat without any additional conversion. Let’s open hashcat and type command.
hashcat -m 13100 -a 0 myhash.txt rockyou.txt -o pass.txt
Command:
hashcat -m 13100 -a 0 myhash.txt rockyou.txt -o pass.txt
For those that have never used hashcat, essentially the command above is:
- hashcat: Running executable file on linux
- -m 13100: Specifying the hash type, this is called a mask. In this case we’re instructing it to use Kerberos 5, etype 23, TGS-REP.
- myhash.txt: This is where the hash file is, this could be called anything. We’ve named the file myhash.txt as shown in the screen capture above.
- rockyou.txt: This is a wordlist we’re going to try the hash against to try and extract the cleartext password.
Cleartext password:
Once hashcat is able to crack the password, we’ll see the status as cracked and in the output file, we can see highlighted the password.
As the password is cracked, the attacker can use these credentials of account SVC_SQL_Service to authenticate to any resources this service account has access to, allowing them to compromise data or to do privilege escalation and to perform lateral movement in the Active Directory environment. In this demonstration, the service account is domain administrator, it can be used to perform dcsync and dump credentials of all domain users and, also create golden ticket for persistence. We’ll discuss these attacks in upcoming posts.
Best practices for Service Accounts:
- It is always recommended to restrict the domain admin accounts from being used as service accounts.
- Since the service account hash is attempted to be cracked, it is recommended to use complex passwords and other credentials best practices that make the brute-forcing process significantly more time-consuming against the standard wordlist.
- Also ensure the passwords for service accounts are changed on a regular basis.
- Make sure to restrict the usage of insecure algorithms like RC4 in Kerberos and especially for service accounts. Instead, configure service accounts to negotiate using AES-128 and AES-256 encryption algorithms only.
Detection of Kerberoasting Attacks
Audit Service Ticket Operations.
To detect Kerberoasting attacks, we need to enable Kerberos service ticket request logging and need to monitor all the activity such as the domain user accounts requesting large numbers of service tickets (Windows Event ID 4769).
Using AD Decoy Accounts
Similar to how we do with our Active Defense using the LMNTRIX XDR Deceive element, blue teams can set the traps within the organization Active Directory environment by using the Active Directory decoy accounts and enable audit logging on them. These decoy accounts can act as a normal service account and generate an alert when an interaction is done. The concept is similar to the Server Decoys which immobilizes attackers doing reconnaissance through Active Directory with legitimate service names.
Next Steps
As enterprises grow and evolve, their Active Directory can get very complex and difficult to maintain. The constantly evolving security enhancements and configuration options results in enterprises failing to correctly maintain their Active Directory environments.
Our Active Directory Security Assessment assists enterprises enhance their processes, configurations, as well as security and monitoring controls necessary to effectively secure an Active Directory environment. It was developed based on extensive red teaming and Active Defense experience from our cyber defense centre defending clients around the globe.
For more information contact us.