Service Accounts – Weakest Link in the Chain?
At DerbyCon 2014, Tim Medin introduced a novel technique to elevate privileges by exploiting service accounts in Windows networks leveraging Active Directory and Kerberos. This method requires the service to be executed in the security context of a user account and support Kerberos authentication. It allows an attacker to request a Kerberos ticket for the vulnerable service instance (SPN) and potentially crack the ticket offline to recover the service’s secret key. Using that key, an attacker could forge an arbitrary ticket (Silver Tickets) and deceive the service to believe that the authenticating account is another user or has different group memberships.
Inspired by Medin’s work, CyberArk Labs developed RiskySPNs, an open-source tool presented at BSidesSF, which identifies vulnerable services and service accounts. The tool enables blue teams to mitigate this threat and red teams to detect and abuse the services and service accounts. Unlike other projects such as Kerberoast, RiskySPNs facilitates the identification of which accounts are most vulnerable and valuable by gathering a variety of information about the vulnerable services and the service account that runs them. This also increases the cracking efficiency and avoids unnecessary abnormal traffic and event logs on the Domain Controller.
Services in Windows networks are usually ‘kerberized’ (i.e. support Kerberos authentication) and are registered under a security principal (user or computer account) as a Service Principal Name (SPN) on the Active Directory. This enables Kerberos clients to uniquely identify the instance of the service and request a Kerberos service ticket (also called ticket granting service or TGS) to it. This ticket will be encrypted using the service’s long-term secret key derived from the security principal’s password.
Using Microsoft’s built-in tool, it is possible to query the Active Directory and retrieve all available SPNs in the user’s domain/forest.
Because Kerberos only deals with authentication and each service is responsible for authorizing clients, any domain user can request a Kerberos service ticket (TGS) from a Domain Controller to any service even if he doesn’t actually have permissions or have the intention to access the service. In fact, the service (or server) doesn’t have to be available to retrieve a valid ticket. Using the Get-TGSCipher function from RiskySPNs module, it is easy to obtain a service ticket for a service instance by its SPN.
The security principal (Target) that represent this service instance is retrieved by querying the Active Directory and identifying SPN registered SPN. The encryption type and the encrypted server’s portion of the ticket (EncTicketPart) are extracted from the ticket request stream. Typically it will require multiple tools like Mimikatz to export the ticket (kirbi file) from the client’s memory and extract the encrypted server portion from the ticket. This portion is encrypted with the secret key derived (hashed) from the password of the security principal associated with the SPN.
Detecting vulnerable SPNs
SPNs associated with computer accounts are not feasible to crack because they use rotated, complex random-generated passwords by default. However, user accounts are likely to contain guessable (non-random, relatively short) passwords. Regardless of the domain function level or the host’s Windows NT version, SPNs that are registered under a user account will use the old RC4-HMAC encryption suite instead of the newer AES cryptography which is used by default since Windows Server 2008/Vista. The key used for encryption and decryption of the RC4-HMAC (23) encryption type is just an unsalted NTLM hash version of the account’s password. This is probably because of backward capabilities concerns and interoperability.
Service accounts are often privileged and the passwords are set to never expire. Web and Database services often integrate with Kerberos to enable SSO and are running in the security context of a privileged user account. The Find-PotentiallyCrackableAccounts is another script in the RiskySPNs module that queries the Active Directory and reveals juicy information about user accounts associated with SPNs. The function checks the group memberships of the user and determines if he is a member of a sensitive group (such as Domain Admins). It also highlights the user’s encryption, and if there is a cracking window, the user will be forced to reset his password.
Additionally the Export-PotentiallyCrackableAccounts script can be used to export even more data about risky user accounts and their associated SPNs to a CSV file for further analysis (useful for blue teams).
Cracking the ticket
With the encrypted portion in hand and when encryption type is known, it possible to crack the ticket offline. When the service is running under an account created by a human, it will probably have a password which could be cracked. Because the ticket is encrypted using a symmetric encryption, it possible to make a dictionary or brute-force attack by deriving (hashing) keys from a list of passwords and trying to decrypt the ticket with them. The key that successfully decrypt the ticket (the output contains a valid ticket structure) is certainly derived from the service account clear-text password. Both Hashcat and John the Ripper, two well-known password crackers tools, support Kerberos service ticket (TGS_REP/AP_REQ) cracking modes.
Cracking the ticket could allow an attacker to efficiently escalate privileges by creating Silver Tickets (will be described in another blog post) or simply impersonate the service account by logging in with the appropriate credentials.
Because queries to the Active Directory and Kerberos service tickets requests are both legitimate actions which occur all the time, such reconnaissance should not trigger any suspicion (unless you request a lot of tickets). From an attacker perspective, identifying SPNs associated with user accounts that are a member of a sensitive group, configured to use RC4-HMAC encryption and have a cracking window would be a potential gold (or actually a silver) mine. These service accounts are often predictable, discoverable and accessible from anywhere in the network increasing the probability of an attacker to choose them over other attack vectors.