Protect Your Service Account Passwords

Jim Shaver
| 2/1/2017
Password Strength Matters 1

Easy Target

Organizations typically maintain service accounts that have elevated privileges within the organization and are used to perform automated actions that are critical to business function. These accounts may not have had their passwords changed in years – so the passwords may have been set during a time of less stringent password requirements. Password requirements might also be dictated by vendors. Due to the elevated access provided by these accounts as well as the near zero foothold required to gain access to the accounts, they are often targeted during penetration testing engagements to escalate access privileges within a Microsoft® Active Directory® (AD) environment.

What if every user in an organization has access to encrypted passwords for these types of service accounts in an organization’s Active Directory environment? The passwords and accounts could be vulnerable to an attack. Unfortunately, that is sometimes the case.

Weakness in Active Directory Authentication

To understand this kind of attack, we first need to discuss how authentication works in an Active Directory environment. One of the most complex and secure methods of authenticating within Active Directory is Kerberos, a network authentication protocol originally developed by the Massachusetts Institute of Technology (MIT). Microsoft adapted MIT’s implementation of Kerberos and used the NTLM hash of the service account as the shared secret used to encrypt and decrypt Kerberos ticket granting server (TGS) tickets. In Microsoft’s implementation, knowing the NTLM hash or password for an account is the only validation needed to authenticate the service account requesting the TGS ticket. The TGS can be decrypted and used only when the credentials are known.

This is a clever use of what is known, in cryptography circles, as a plaintext attack. By requesting a TGS ticket for the various service accounts registered in Active Directory, the penetration testing team can perform offline password cracking to obtain the password that is used to encrypt the TGS ticket. Once the ticket is successfully decrypted, the team has access to the service account’s password.

How to Take Advantage of This Vulnerability

Here is how a penetration testing team might exploit this vulnerability:

Once the team has gained “domain user,” or normal user, privilege on the network, it can either use built-in Microsoft Windows® functions to generate and extract the TGS ticket or use open-source tools like Impacket to generate those encrypted Kerberos TGS tickets. In this example, we will use Impacket’s GetUserSPNs. With this command, the team can specify “–request” to request a TGS for each user that is associated with a service principal name (SPN). Active Directory uses SPNs to register accounts in Kerberos. The team can specify “–hashes” if it has NTLM hashes, or AD will prompt for the password of the unprivileged user whose account the team is using to authenticate to AD. The team also specifies that user in the format of domain/user at the end.

Impacket’s GetUserSPNs

Encrypted TGS tickets

The contents of the option “-outputfile” will contain the encrypted TGS tickets in John the Ripper and Hashcat formatted hashes ready to be cracked.

Encrypted TGS tickets

Impacket’s GetUserSPNs

Several open-source tools and projects exist. One of the largest projects, Cracklord, is a management interface for shared resources and tools like the password cracker Hashcat. A penetration testing team can take the text from the “outputfile,” load the hashes into Cracklord, and when a password is weak, it can crack it. What makes this attack truly unique is that it is all accomplished with minimal foothold and traffic on the network. It may be difficult or impossible to detect.

Defense Strategies

Protecting your systems against this vulnerability should be a fundamental practice of any cybersecurity program. First, assume that all service account encrypted passwords are accessible to all user accounts on the network. The only thing stopping a hacker from gaining access to one of these user accounts is the time required to crack the encrypted password, and that ultimately depends on the length and complexity of the password value.

Organizations should ensure that all service account passwords are set to a random, complex value with a minimum length of 16 characters. The estimated average time to crack a password of 16 random characters using advanced password cracking infrastructure is 40 billion years as opposed to the minutes or hours estimated to crack an eight-character password. Setting passwords to a long, complex, and random value will help protect service account credentials from compromise. Additionally, service account passwords should be changed annually or whenever key personnel who know the passwords depart the organization.

Other defense strategies include a strong security awareness program that will ensure users are skeptical of attempts by attackers to use social engineering to gain enough access to the network to conduct attacks like this one. Strong physical and technical controls can also limit attackers’ access to the internal network.

Microsoft, Active Directory, and Windows are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.