Delegation–A Blessing or a Curse?

I’ve been wanting to sit down and write this blog post about AD information exposure for a couple of weeks now, and am finally finding the time to do so. For those of you who follow my blog, you know that I posted nearly a year ago after a visit to the BlackHat and BSides conferences in Las Vegas. At the time, I was introduced to a tool in one of the sessions, called Bloodhound, which utilized graph theory and some excellent work done by a number of security researchers that have built the excellent PowerShell Empire toolkit, to essentially speed the discovery of paths to increasing privilege in Active Directory environments. I think the most revelatory part for me at the time, was the use of the IT’s shop’s own infrastructure information against itself. By that, I mean that many AD and Group Policy shops don’t take the time to harden the information that is gladly given out to any and all authenticated users, about an organization’s security posture. As a result, these recent tools have begun to make it easy for an attacker to use this exposed information to move rapidly and laterally across a network to find high-valued users (e.g. domain admins) and targets where those users have access.

Frankly, this is not really a new problem. When AD was first introduced, I was a Windows guys at a large financial services company. As I evaluated AD, it’s delegation model frankly scared me. Compared to NT 4, AD’s security granularity was byzantine, and would require special attention to get it right. I even came up with the idea to create templates of permissions that could be applied to AD containers, that mapped to job functions within AD management. This idea eventually became a product from a company we were partnering with called Fastlane, and the product was called ActiveRoles. In fact Quest Software still has a product called “ActiveRoles Server” today–not quite the same product that I envisioned, but it contains some of those original permission template ideas from the early days. Suffice it to say, I doubt many shops really followed best practices or had a method to their delegation madness, and the result is what we see today.

Greater Attacker Sophistication Coming Soon…or Now

To that end, at least one intrepid researcher has taken advantage of these new red team tools by building the well-named “Death Star”–which uses BloodHound and PowerShell Empire in an automated way to speed the process of getting to Domain Admin–described here. Much of the capability of Death Star takes advantage of weak delegation habits within AD, as well as poor habits in GP management (e.g. not removing GPP Passwords, which have been shown to be highly “crackable”), but it underscores how vulnerable some shops are, that don’t pay attention to their AD delegations. But let’s be specific about where the issues lie. You can make the case that there are two main classes of “threats” with respect to AD and GP delegation:

1. Default ACLs (Access Control Lists) that grant over-permissive READ access on objects, allowing attackers to be more efficient at finding high-valued targets (e.g. privileged groups and their members). In the Group Policy world, this means security policy granting administrative access (e.g. using Restricted Groups (see Figure) or GP Preferences Local Users and Groups policy).

Viewing Restricted Groups granting privileged access in a GPO, with read permissions

If I, as an attacker (presumably one who already has a logon credential on AD), am able to see these policies, and know where those GPOs are linked, then I can deduce which groups, and by that, which user accounts, have admin access on which computers. And indeed this what the PowerShell Empire tools help do. This is precisely why I’ve advised that a best practice for GPOs that deliver security policy, is to remove Authenticated Users Read permissions and replace them with Domain Computers or a similar group.

On the AD front, the problem is similar. In the figure above, if I know the membership list of the cpandl\Marketing Admins group, then I can figure out fairly easily, what user accounts I need to compromise in order to become Marketing Admins equivalent. Since Authenticated Users is often granted Read access on all group properties (see Figure), it’s fairly easily for any user to find out a privileged group’s membership.

Viewing Authenticated Users permissions on an AD group.

2. The other ACL threat, is overly permissive ACLs that grant unnecessary access to AD objects. This is articulated well in an article describing Bloodhound 1.3 and the so-called “ACL Attack Path”. Namely, Bloodhound looks for a set of rights that have been granted to users on “interesting” AD objects, as a way of leapfrogging their way up to more and more elevated rights within AD. These rights that Bloodhound and related tooling look for, as articulated in the article I just quoted, include:

• Reset Password
• Change Group Membership
• Full Control
• Write All Properties
• Modify Owner
• Modify Permissions
• All Extended Rights

If your AD objects are loosely delegated, or, as is more often the case, multiple admins over the years have overlaid duplicate or conflicting delegations in attempt to perform a particular task at a particular moment, then you are likely vulnerable to this kind of permission exploitation.

As a simple example, it works like this: Let’s say I’m JoeSmith, the attacker. JoeSmith is a domain account with little privileges. But JoeSmith is a member of a group that has been granted Reset Password Permissions on the user SallyJones. SallyJones works on the help desk, and is a member of a group that has Change Group Membership permissions on a privileged domain group. JoeSmith uses his ResetPassword rights to reset SallyJones’ password, then logs in as SallyJones and add JoeSmith as a member of the privileged group. And, voila! JoeSmith is now privileged. The bad delegation has always been there, but tools like Bloodhound make it easy to find these weaknesses more quickly. As you can see, the possibilities are pretty staggering.

What To Do?

With these tools getting more sophisticated, it behooves you to think about how you’ve delegated read and write access to your AD infrastructure. Sadly, for most large shops, this is not an overnight process. The first thing you can do for your GPOs, is to adopt the guidance I’ve suggested in my previous blog post on the subject, particularly the section at the end on GPO permissioning. And if you don’t know which GPOs you need to be worried about, or where those GPOs are in your environment, you can use our GPO Reporting Pak product to get an inventory of where security policy like Restricted Groups or User Rights Assignment has been implemented across your GPOs.

From an AD perspective, it’s going to take a bit more work. You’re going to need to do a thorough assessment of how objects, and especially privileged objects, are delegated within your AD. One easy place to start, is with privileged security groups. By default, Authenticated Users can read all properties on all groups. There’s no reason for that. So the easiest thing you can do is remove that Access Control Entry (ACE). Well…not so fast! If you remove it, you could break a whole bunch AD-enabled apps that rely on service accounts to properly evaluate those AD group memberships that grant access to applications. So you will need to do some homework. But one easy approach here is the following. When you remove read access from Authenticated Users, grant read access to the group itself (see Figure below). This ensures all members of the group will continue to be able to read the properties on the group. You’ll also need to include read access for those service accounts that need to evaluate the group membership for some AD-enabled application. You can either make the service account a member of the group that gets granted that access (not ideal) or explicitly grant the service account read permissions on the group as needed. The goal here, again, is to have the fewest number of user accounts possible, having read access to the group. It should be granted on a “need to know” basis, rather than an “everyone gets to know” basis.

Granting a group called “PrivilegedGroup”, access to read itself.

It takes work to assess holes in your AD delegation strategy. I encourage you to start…NOW!  That’s why I think running tools like Bloodhound and “Death Star” in a defensive way are a great idea for assessing how bad your particular environment is. Use the attacker’s tools before they do–to ensure that if they do, you are not vulnerable. This is the whole point of “red teaming” after all.

Darren