Chris Underwood, Senior Consultant, SecureITsource, Inc.
Last year I wrote a short article about group managed service accounts, a great mitigation against LSASS dumps and Kerberoasting. Mitigating these two attacks are still entirely possible without use of GMSAs when service account best practices are applied. It’s time to update your security policy and ensure these minimum requirements are being met.
Service Account Password Length: At least 20 characters
There are a few different methods to find out what services are running under service accounts within the domain. Tim Medin and Sean Metcalf have published powershell scripts that will provide user SPNs (services running under AD users). Script Links: Tim Medin GetUserSPNs and Sean Metcalf Find-PSServiceAccounts
With the reconnaissance phase complete, any user can move on to using basic Kerberos functionality to request a TGS ticket to authenticate against domain services. Kerberos will respond with TGS tickets that are partially encrypted with the SPN service account’s hash which can then be attacked offline. This attack vector is incredibly lucrative given the rotation policies surrounding service accounts and privilege assigned to them.
- Standard users can quietly obtain TGS tickets encrypted by a service account’s hash for offline cracking.
- If an account is set to never expire and has not been integrated into a PAM solution, an attacker will have months or even years to crack it offline
- Requesting TGS tickets is routine and a smart attacker can stealthily gather tickets over a long period of time without setting off any alarms
- Service Account Honeypot monitoring is a great way to detect Kerberoasting activity
Routine rotation via a PAM solution: Never set to “Do not expire”
Regular rotation is a natural complement to enhancing password length. Most service account credentials out there are rarely being changed. Those of us who make a living maintaining critical services share a profound anxiety associated with touching revenue generating servers. We bury a landmine every time we have an account that is so critical to our success that we are averse to their regular rotation.
A timely response is critical to recovery once an account compromise is realized. If a service account password has not been changed in years, a sudden change will also send a message to the attacker of your awareness of their presence. An APT is much less likely to panic or escalate their attack if their loss of access is routine. Regular password rotations will not only give an attacker less time to use the credential, it will reduce the risk of correcting a compromise.
Products like CyberArk Application Identity Manager integrate into source code, data stores and even configuration files to ensure that credential changes do not negatively effect the applications utilizing those service accounts.
Apply Least privilege: No more domain admin
Tim Medin mentioned during his kerberoasting presentation that targeting a MSSQL service account is advantageous due to the privileges typically associated with its SPN. He reminds us that instructions to register the SPN for MSSQL manually can be ignored when the service account is a domain admin. In fact, registration of the SPN for Kerberos authentication becomes automatic.
This is the same issue we encounter when implementing new products or applications. Excessive privileges are often granted as a means of troubleshooting and rarely walked back. Even though it is a post-exploitation attack, dumping LSASS credentials to find the plain text passwords of your service accounts grants the opportunity to potentially obtain domain admin credentials.
Proof of concepts are especially dangerous. Getting an application to work in time is hard enough without pushing back against the vendor or developers to find out exactly what permissions are needed. If the proof of concept is bought off on, how confident are you that the POC will not just become the prod environment?
Taking the time to apply least privilege to your applications is time well spent. And let your implementation engineers know, it is okay to question why an account needs so much privilege.
References (Follow these folks!)
My recommendations come from aggregating a ton of content from the fine folks listed below. They have all provided extensive insight into how attacks mentioned in this article work and how to mitigate them.
Tim Medin: https://twitter.com/timmedin