Active Directory (AD) is Microsoft’s identity and access management software that controls which users have access to the systems and resources on a network. It’s a popular target for attackers because getting control of AD allows them to deploy malware, steal sensitive information or do other nasty things in a way that’s very difficult for defenders to detect or block. 

Making AD more secure involves fixing security flaws within the environment that allow attackers to get in - but first defenders need to identify what those flaws are. AD’s built-in tooling makes it very difficult to see which users have privileges to which systems and objects. So many security issues, even very dangerous ones, simply go unnoticed. 

Luckily for defenders, several common AD security issues are quite easy to fix once they’ve been identified. These “low-hanging fruit” issues allow defenders to reduce the risk exposure of their AD environment relatively easily. Here are three of the most common security issues across AD environments, their impacts, and how defenders can find and fix them. I’ll be explaining how to do this using BloodHound, a free and open-source tool (of which I am a co-creator) for mapping Microsoft Active Directory and Azure Active Directory, but you can follow the same steps using a different tool.

Kerberoastable Users With High Privilege

The Kerberoast attack was first identified by security researcher Tim Medin in 2014. It extracts service account credential hashes from Active Directory for offline cracking and can be carried out by any user without sending packets to the target. When highly-privileged users in a target environment are vulnerable to this attack, they give threat actors a short route to seizing control of Active Directory. My colleagues and I see this issue in virtually all of the real-world AD environments we examine.  

Having high-privileged users vulnerable to Kerberoasting creates a great deal of security risk, but identifying those vulnerable privileged users is extremely difficult using only AD’s built-in tools. This is because AD makes it impossible to empirically determine the privilege of any user. AD’s interface doesn’t allow users to “unroll” the members of a security group and groups can be nested inside other groups, which means tracking down every user with a certain level of privilege is a long, difficult exercise. It’s easy to make mistakes and accidentally overlook people. 

In FOSS BloodHound, the process is much simpler. Run this query in FOSS BloodHound using the "raw query" bar at the bottom to show the most high-risk kerberoastable users.

MATCH p = shortestPath((u:User {hasspn:true})-[*1..]->(g:Group))

​

WHERE g.objectid ENDS WITH '-512'

​

RETURN p

​

LIMIT 100

This returns a visual that illustrates the attack paths that these high-privilege kerberoastable users create. Here is an example. Each starting user node (the green icons along the left of the screen) in this example is a kerberoastable user:

The target group is the yellow icon on the far right. As you can see, an adversary targeting this group has many potential attack paths to choose from. 

To close off these attack paths, each of these vulnerable users needs to be protected from kerberoasting (and I’d suggest starting with the ones closest to Tier Zero assets). There are two ways to do this:

1. Make sure the user has a very strong password (64 random characters).

2. Remove the SPN from the user and configure the associated service to authenticate with a computer account instead.

Domain Controller Object Ownership

Domain Controller objects should only be owned by Domain Administrators. But in most real-life AD environments, they're not. This issue is extremely common (I see it in about 75% of the environments I audit) because it’s the result of a build process where the user that creates an object in AD has ownership of it. This is a very risky configuration, because users that own Domain Controller objects can create new Attack Paths to those objects and non-domain admin users accounts aren’t traditionally well-secured.

To find out if this is happening on a network, run this query in FOSS BloodHound using the "raw query" bar at the bottom: 

MATCH (g:Group)

​

WHERE g.objectid ENDS WITH '-516'

​

MATCH p = (n:Base)-[:Owns]->(c:Computer)-[:MemberOf*1..]->(g)

​

RETURN p

The result will be a graphic showing the various principals that own the Domain Controller computer objects in this AD environment. All of these random principals have Attack Paths leading to them, which means they end at the Domain Controllers.

To fix this, follow these steps:

1. Open Active Directory Users and Computers.

2. Enable advanced features.

3. Locate each Domain Controller object. 

4. Right click Properties, Security, Advanced, then Change.

1. Change the owner of each DC to the Domain Admins group.

That’s it! The whole process takes no more than an hour, and shouldn’t affect any other relationships or privileges in AD, so the chance of it breaking something else is very low.

Domain Users, Everyone and Authenticated Users Groups With Control of Other Objects

Instances where the Domain Users, Everyone, and Authenticated Users principals have any kind of privilege serves as a jumping-off point for an attack path. These groups don’t need this privilege - it only makes things easier for an attacker. But this happens in nearly all real-world environments for various reasons, often an admin trying to fix a specific issue by giving blanket privileges. This is another dangerous configuration that is easy to remedy. 

First, find all instances of the Domain Users group having control of another principal. FOSS BloodHound can show this in two ways.

Option one: Look up the group in the GUI and click "Outbound Object Control."

Option two: If you’re running multiple AD domains, you can use this command to bring up all instances:

MATCH p = (g:Group)-[{isacl:true}]->(m)

​

WHERE g.objectid ENDS WITH '-513'

​

RETURN p

Fixing this issue is similar to the previous one. Find the affected object in Active Directory Users and Computers, bring up its security descriptor, and remove the offending ACE where the "Domain Users" group is the identity reference.

Identifying and fixing these three problems is well within the capabilities of most AD or security teams, and they’ll make the AD environment more secure even without follow-up work. If the organization decides not to focus on AD security, admins can (and should) make a difference by tackling these three issues.