Identity has always been married to security, even if the relationship has not always been publicly celebrated. Times are changing, however, and there is a growing recognition that identity management and security are intrinsically linked.
At the center of this, even after more than 20 years of existence, is Active Directory (AD). While companies might look to other options to support their cloud environment, AD remains the primary directory service used by countless companies worldwide. That status has also made it a primary target for attackers.
Recently, I presented a webinar for IDSA in which we examined the top five vulnerabilities affecting AD. What might surprise some is that unlike with other software, in this case, the word vulnerabilities does not refer to security flaws in the code. Instead, it relates to configuration issues that open the door for attacks.
Vulnerability #1: Users with rights to add computers to a domain
On the surface, number one on this list might not seem like a big deal. After all, computers do need to be added to domains. Once a user has the “Add workstations to domain” security setting enabled, they are allowed by default to add ten computers to the domain. The problem here arises from the fact that if an attacker gets their hands on an account with this capability, they could use it to circumvent your endpoint security controls. When someone adds a machine account, they become the owner of that machine object from an ACL (Access Control List) perspective. They have administrative rights on that machine and can use it to launch targeted attacks on AD. Due to these risks, keep the number of users with this security setting to a minimum.
Vulnerability #2: Accounts with unconstrained delegation
AD is 20 years old, and in the time since its introduction, we’ve learned that unconstrained delegation is a risky configuration. Unconstrained delegation enables attackers to impersonate a user to any service in the same domain. It also allows a service to act on behalf of a user, and it can mask malicious activity by mimicking a legitimate user. For example, creating a DC is normal activity. But cyberattackers can use Mimikatz—the Swiss army knife of hacking tools—with unconstrained delegation to build a DC and then replicate it to grab data. With unconstrained delegation, a computer that stores tickets for numerous users becomes an obvious target for attackers, who can use those tickets to act with the identity and privileges of those users. Ticket-granting tickets (TGTs) stored in memory provide a means for attackers to impersonate users and potentially leverage Domain Admins access privileges (if a Domain Admin logged into that system) to launch Golden Ticket and other attacks.
Don’t use unconstrained delegation. Monitor delegation carefully and use the Protected Users security group—after thorough testing to ensure that depreciated authentication methodologies are not in use in your environment. In addition, you should set the “Account is sensitive and cannot be delegated” configuration option on the accounts of high-privileged users to prevent the account credentials from being forwarded to other computers or services.
Vulnerability #3: High number of users in privileged groups
The principle of least privilege should not be an afterthought but a driving force of your identity management policies. The reality is often quite different. It is easy to grant access to get everything working. We are all guilty of it. But we need to pull back on that mindset. Having a large number of users in privileged groups increases the risk of domain compromise. These accounts are granted broad access and are attractive targets for attackers. To protect them, organizations should consider adopting a just-in-time privileged access approach, where access is granted for a limited period so that a particular task can be performed.
A little bit of obscurity can help as well. Every domain in AD has a default administrator account established when the domain is created. This account is, by default, a member of the Domain Admins and Administrators groups in the domain. If the domain is the forest root domain, the account is also a member of the Enterprise Admins group. Because this account is created by default, its existence is no secret to attackers. In addition to following the best practices recommended by Microsoft, it is a good idea to rename this account to hide it from threat actors. Just make sure you update the description field so you can identify it.
Vulnerability #4: Service accounts with elevated privileges
Service accounts are designed with specific permissions intended to allow them to run particular services or applications without giving them full admin rights. Sounds good. The problem is when these accounts have elevated permissions. Given that they often have weak passwords that are set never to expire, service accounts can represent a significant hole in the security of your AD infrastructure. We all know how this happens. Someone comes to the operations team or whoever is in charge of AD and says they are installing a new product and need domain admin rights. But these requests should be denied. The fact is that service accounts may have access to business-critical systems, web services, databases, and APIs. If an attacker gets control of a service account, they can use it to compromise these resources and persist in your environment for a long time—totally undetected.
Vulnerability #5: Passwords
Ah, yes, passwords. Even as other authentication methods, such as biometrics, grow in popularity, passwords remain the frontline of defense for enterprise identities. Having to enforce password complexity stinks, but credential theft and password cracking stink more. So does all the work involved in restoring AD after an attack. Still, it is not uncommon to see situations where passwords are set to never expire. This setting should never be enabled.
Another common mistake is storing credentials in SYSVOL folders. SYSVOL contains a domain’s public files that need to be shared for common access and replication throughout the domain. Sometimes administrators choose to store credentials in SYSVOL folders. However, because any domain user can access the SYSVOL shares, those credentials could be swiped by someone in control of a compromised account.
There is no space here for compromise. Passwords need to be up to snuff. Failing to enforce password complexity makes it easier for attackers to crack or guess passwords and lowers the barrier of entry for them to breach your environment and maintain persistence.
Close security holes
The threat landscape is constantly shifting, and staying ahead of those changes requires monitoring AD for signs of trouble and eliminating low-hanging fruit. From risky configurations to unauthorized modifications, attackers will leverage any opening they can find to get a foothold in your organization. Now is time to be proactive and close common security holes in AD.
For best practices on protecting Active Directory, read this blog from my colleague Gil Kirkpatrick.
