Pen Testing Active Directory Environments, Part IV: Graph Fun

If we haven’t already learned from playing six degrees of Kevin Bacon, then certainly Facebook and Linkedin have taught us we’re all connected. Many of the same ideas of connectedness also play out in Active Directory environments. In this post, we’ll start out where we left off last time in thinking about the big picture of Active Directory users and groups.

Or more accurately pondering the big graph of Active Directory. And the game we’re playing is closer to four degrees of Ted, your overworked IT admin or other privileged user.

Graphically Speaking

Why do we need to think about graphs in AD environments?

These structures form naturally from AD group membership. At the Acme company, I already set up groups for Acme-Clevels, Acme-VIPs and Acme-Serfs. These AD groups can contain either users or other groups. IT often establishes AD environments with group hierarchies so they can control permissions at finer levels with each hop down the hierarchy.

Since the last post, for example, I added a group for Acme-Legal under Acme-VIPs. In Acme Legal, there are legal subgroups for Acme-Patents and Acme-Compliance. As Acme’s beloved IT admin, I can set permissions that allow only members of Acme-Patents to view and update certain directories or include all of Acme-Legal or even all of Acme-VIPs.

The computer science-y word for the hierarchies I’m describing is known as directed acyclic graphs or DAGs. For anyone who’s ever taken a basic CS class such as “Data Structures for Poets and Aspiring Sous Chefs”, this core graph type always comes up.

Pen testers who work in AD environment are also very fond of these graphs. They allow them to quickly hunt down users who’ll have the credentials they need. A gentle intro to the subject can be found in this Def Con presentation. I’ll add the usual qualifier: the whole area of graph theory is a rich one, and we’ll only be sipping its foamy crema in this post.

One use of these ideas is known as “derived admin”, which involves hopping around the network while gaining local admin privileges. We’ll do something a little different: finding users who have permissions to a file we’re interested but can’t access.

Practicing Law Without the Right Permissions

Let’s say I’ve landed on Acme’s Salsa server with Bob’s plain credentials — Bob is in the Acme-Serfs’ group. Bob has enough file permissions to help me move around the server, but not enough to allow access to interesting content.

I come across a tempting directory named “Top Secret”. Unfortunately, I can’t navigate into it. I now use PowerView’s Get-PathACL to get a little more insight.

Wouldn’t you know it, but “Top Secret” gives access to those only in Acme-Legal (and Administrators). As an Acme-Serfs member, I’ve been excluded.

Here’s the problem. I’d like to discover all the users under the Acme-Legal umbrella since any user in the Acme-Legal hierarchy would give me the right privileges.

The goal is to find all those users – in graph-speak, the leaves — under Acme-Legal.  And then hope that one of these users are on the Salsa server so I can steal their credentials through pass-the-hash.

If you do this on an ad-hoc, manual basis this can get complicated very quickly for even small companies. For example, I can try running Get-NetGroupMember, write down all the groups and users that are spit out and then repeat until exhaustion sets in.

Paul Revere Rides Again

The better way to do this, of course, is to automate the task using PowerShell.

We need to build what’s known in the trade as adjacency lists — it’s a array structure for representing the DAG. For each Acme group, I can quickly access the immediate members under it.

I’m not much of a PowerShell scripter, but in an afternoon or two I was able to generated these lists using PS’s associative arrays and arraylist data types, along with using PowerView’s Get-NetGroupMember.

You can see the partial results below, with the variable $GroupAdj containing it all.

Yeah, it’s a great homework assignment to work this out for yourself.

Do some of these ideas seem familiar in a kind of Paul Revere-metadata way?  Of course, sociologist Kieran Healy’s great Using Metadata to Find Paul Revere should come to mind! Healy’s post was a first introduction to metadata and graphs for many of us.

His problem was finding all the Tea Partiers — the original version 1.0 — that Paul Revere was connected to. By the way, his post shows you how to create what’s known by the graph-erati as the “transitive closure” for each node.  I’ll take that up next time for our Acme graph.

This time we’ll solve a far simpler puzzle: given a specific Acme user and a group, is there are connection between the two? Essentially, I want to see if there’s a path from an AD group to the user by navigating my adjacency lists.

If you’ve the taken the computer course for poets that I mentioned earlier, you know about breadth-first search (BFS) and depth-first search (DFS) algorithms. As a cool pen tester, I wrote a couple of lines of code that implements  BFS and kept in a file call depthsearch:

Let’s say I’m watching to see who’s logging into Salsa using crackmapexec with --lusers option. I discover that someone named Cal is now on the server. He’s seems like an IT guy based on running the Get-NetUser cmdlet.

So I now run my depthsearch script with parameters Acme-Legal and cal.

Eureka! Next I just need to dump his hash using crackmapexec and then I can pop a shell with Empire – remember from last time?

And the Lesson Is  … Role Based Access Controls

In my role as Acme admin, I created a special group known as Acme-SnowFlakes, where I put Cal the IT guy. The Acme-Snowflakes group is itself buried down in the hierarchy under the Acme-Patents group. In this make believe scenario, once upon a time we needed to give Cal access to legal folders and then we promptly forgot to remove these special Snowflakes.

As a pen tester, I can now report to management about a small hole in the Acme permission structure.

We covered a lot of ground this time, but there is an important lesson. Once the hackers get in and then leverage Active Directory metadata, they have – let’s face it – awesome power. The goal is to make it harder for them.

And one of the ways to do that is through role-based access control policies that always forces you to restrict who has access to sensitive files. An IT group that’s on its game would have been questioning why Cal had give access to the “Top Secret” directory used by the legal department.

Enough preaching!

We’ll go over some of these same ideas again next time, and then explore derivative admins, which is a variation of the concepts we’ve covered in this post.