Quest Active Directory Security Assessments Reveal Top 4 Issues: #1 Service Accounts (Part 1 of 3)

It is not often that a systems administrator gets the chance to build and maintain a corporate Active Directory environment from its inception. Instead, you have probably inherited the AD Forest or Forests and the original creators left years ago. We find that most Active Directory Forests average about 14 years old. 

So, what happened before you arrived? What policies were in place at that time? Were the policies automated or was it mostly “Tribal Knowledge” that ran the network?  Is this “Tribal Knowledge” still around or did it walk out the door before you arrived?  Trying to discover and understand the artifacts lingering in your Active Directory is difficult and time consuming. These legacy artifacts also increase the vulnerability and integrity of your infrastructure. 

In this blog series, we are going to look at some of the most common Active Directory security holes in organizations as discovered in the Quest Security Assessment, as well as how to resolve or mitigate these vulnerabilities. In Part 1 of this series, we will focus on Service Accounts and the top vulnerabilities we have discovered. 

About the Quest Security Assessment

The issues identified in this blog series are taken from a review of anonymized Active Directory security assessments performed in 2019 for large organizations. These security assessments are requested by enterprises to evaluate their AD security posture. Using Quest Active Directory solutions, a Quest architect will provide an analysis of a comprehensive set of data relating to AD including:

• Domain groups and members
• Domain users
• Domain servers
• Active Directory permissions

Service Accounts, 9 out of 10 Organizations are at risk

Many applications that we run in the enterprise require a service account. These accounts are prime targets for attackers as they are generally ignored after the application is running.  To make things worse, their passwords are rarely changed, they tend to have more rights than needed and are frequently configured with legacy setting that make them vulnerable to attack.  In our research, we have found the following issues in more than 90% of enterprises.

Old Passwords

Service accounts that have not had their passwords changed in years. Yes, YEARS! This is an issue for a few reasons. 

1. Most administrators managing the network will have access to the service accounts’ passwords to performs updates, configuration and maintenance. Ask yourself, “Have any of the admins that had access to these passwords left the company?” If your answer is “Yes”, then there are one or more service accounts walking around in the wild.
2. Password policies have changed over the years. What was the password at the time the password was set? I remember back in 2010 we would recommend a minimum length of 8 characters. With the ability to use powerful GPUs to brute force a password, we can crack weak passwords fast. Let’s consider the following passwords and the time it would take to crack them. In the example below, all passwords contain upper and lower-case letters, numbers and symbols. For the 10-character passwords, you can see the difference using only upper and lower-case letters as well as the effect of adding numbers and symbols.

Source: https://howsecureismypassword.net/

Mitigation

There are a few ways to deal with this issue depending on the application. If the application can use a Group Managed Service Account (gMSA), password management is taken care of automatically. Standalone Managed Service Accounts (sMSA) were introduced in Windows Server 2008 R2 and gMSAs in Windows Server 2012.  The gMSA behaves like both a user and computer account. It can be used to run services, like a user account, as well as automatically change its password every 30 days, like a computer account. However, not all application support using gMSA.

If your application cannot take advantage of gMSA you have a couple options. 1) Change the password manually or with a PowerShell script. 2) Use a product like Quest One Identity Safeguard. One of the many features that Safeguard possesses is the ability to automatically rotate passwords on service accounts. This will free-up valuable IT resources from doing this work manually and add a layer of security to your Active Directory.

Over Permissioned Service Accounts

Take a moment and look at your Domain Admins (DA) and Enterprise Admins (EA) groups. Do they contain any service accounts? Do these service accounts need this type of access? Far too often we find that DA and EA, as well as other privileged groups, contain service accounts. There are times when these accounts need this type of access. However, most of the time they do not. Often it is easier for a software vendor to require Domain Admin rights instead of doing the hard work and explicitly listing the permissions needed for the service account. In addition, Active Directory administrators will often give a service account DA rights to simplify their immediate need to get things working. If one of these service accounts become compromised an attacker could create additional accounts and add them to privilege groups to persist on the network as well as install backdoors on servers for future attacks.

Mitigation

First thing we need to do is discover all the services that are using a service account other than Local System or Network Service. This can be accomplished with PowerShell or an enterprise reporting tool like Quest Enterprise Reporter. Once we get this list, we need to focus on the service accounts that are in DA, EA or some other privileged group. We then must research the services\applications that use these service accounts. Look at the vendors’ documentation which describes the minimum set of permissions needed to run the service. If that is not available, ask the vendor of the application.

Sometimes the application will need a service account with DA rights. If this is the case, we should make sure to rotate the password on a regular basis. Specifically, when admins and people with access to the service account password leave the company. Use long, complex passwords. And my favorite, Audit! Audit what the service account does in real time. For example, if a service account was used for a CRM application it should not be creating users or modifying groups in Active Directory. If the service account does perform one of these tasks you need to be alerted immediately. Quest Change Auditor is a solution to this problem as it can provide real time alerts for these types of events. Understanding the scope of what a service account should and should not do will allow us to setup alerting to notify us if they are performing activities that are out of scope of their intended use.

Unconstrained Delegation

Servers and service accounts configured for Unconstrained Delegation can impersonate other users and computers. Sounds scary?  It is. This legacy artifact is found far too often in older environments. For some applications, the server or service account needs the ability to impersonate other users to function properly.  Microsoft provided the option to allow for Unconstrained Delegation in Windows Server 2000. Servers or service accounts configured with this setting could connect to any other server while impersonating any user.  Before Windows Server 2003 it was all or none. However, in Windows Server 2003, Microsoft allowed for Constrained Delegation. In this case, the server or service account could impersonate any user but only to a specific server and port. There are a plethora of articles diving deeper into this topic and how to exploit objects configured with Unconstrained Delegation. Check out The Experts Conference 2019 and 2020 keynote speaker and Microsoft Certified Master Sean Metcalf’s blog “Active Directory Security Risk #101: Kerberos Unconstrained Delegation (or How Compromise of a Single Server Can Compromise the Domain)” .

Mitigation

There are a few ways to mitigate the risk of application server or service accounts configured with Unconstrained Delegation. First, determine if the app really needs Unconstrained Delegation. If possible, change the delegation model to none or Constrained Delegation depending on the requirements. Second, make sure that critical accounts --your admin account, built-in Administrators, etc. -- are in the Protected Users group. Being part of this group will prevent the account from being impersonated. You can learn more about the “Protected Users Security Group” here. Third, you can configure your critical accounts individually to disallow delegation by going to the account’s Account Settings and check the box “Account is sensitive and cannot be delegated”.

Summary

Take the time to discover old and new service accounts that may not have been configured properly or had different requirements at the time they were created.  Doing this will improve your AD security posture and shrink the attack surface. While this seems like an overwhelming task, it can be accomplished efficiently with proper tools and visualizations. With a combination of Quest Enterprise Reporter and Power BI you can bring these threats into focus and proactively address these issues.
In Part 2 and Part 3 of this blog series we will look at a few more common issues that plague Active Directory.

References:

Group Managed Service Accounts Overview - https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview

Quest One Identity Safeguard - https://www.oneidentity.com/one-identity-safeguard/

Quest Enterprise Reporter - https://www.quest.com/products/enterprise-reporter/

Active Directory Security Risk #101: Kerberos Unconstrained Delegation (or How Compromise of a Single Server Can Compromise the Domain) - https://adsecurity.org/?p=1667

Protected Users Security Group - https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group