Varonis announces strategic partnership with Microsoft to accelerate the secure adoption of Copilot.

Learn more

Pen Testing Active Directory Environments, Part VI: The Final Case

If you’ve come this far in the series, I think you’ll agree that security pros have to move beyond checking off lists. The mind of the hacker is all about making...
Michael Buckbee
5 min read
Published January 27, 2017
Last updated April 25, 2022

If you’ve come this far in the series, I think you’ll agree that security pros have to move beyond checking off lists. The mind of the hacker is all about making connections, planning several steps ahead, and then jumping around the victim’s network in creative ways.

Lateral movement through derivative admins is a good example of this approach. In this concluding post, I’ll finish up a few loose ends from last time and then talk about Active Directory, metadata, security, and what it all means.

Get the Free Pen Testing Active Directory Environments EBook

“This really opened my eyes to AD security in a way defensive work never did.”

Back to the Graph

Derivative admin is one of those very creative ways to view the IT landscape. As pen testers we’re looking for AD domain groups that have been assigned to the local administrator group and then discover those domain users that are shared.

The PowerView cmdlet Get-NetLocalGroup provides the raw information, which we then turn into a graph. I started talking about how this can be done. It’s a useful exercise, so let’s complete what we started.

Back in the Acme IT environment, I showed how it was possible to jump from the Salsa server to Avocado and then land in Enchilada. Never thought I’d get hungry writing a sentence about network topology!

With a little thought, you can envision a graph that lets your travel between server nodes and user nodes where edges are bi-directional. And if fact, the right approach is to use an undirected graph that can contain cycles, making it the inverse of the directed acyclic graph (DAG) that I discussed earlier in the series.

In plain English, this mean that if I put a user node on a server’s adjacency list, I then need to create a user adjacency list with that server. Here it is sketched out using arrows to represent adjacency for the Salsa to Enchilada scenario:  salsa-> cal    cal  -> salsa, avocado   avocado->cal,meg   meg->enchilada enchilada->meg

Since I already explained the amazing pipeline based on using Get-NetLocaGroup with –Recursive option, it’s fairly straightforward to write out the PowerShell (below). My undirected graph is contained in $Gda.

buildda

Unlike the DAG I already worked out where I can only go from root to leaf and not circle back to a node, there can be cycles in this graph. So I need to keep track of whether I previously visited a node. To account for this, I created a separate PS array called $visited. When I traverse this graph to find a path, I’ll use $visited to mark nodes I’ve processed.

I ran my script giving it parameters “salsa”, “enchilada”, and “avocado”, and it displays $Gda containing my newly created adjacency lists.

gda-results

Lost in the Graph

The last piece now is to develop a script to traverse the undirected graph and produce the “breadcrumb” trail.

Similar to the breadth-first-search (BFS) I wrote about to learn whether a user belongs to a domain group, depth-first-search (DFS) is a graph navigation algorithm with one helpful advantage.

DFS is actually the more intuitive node  traversal technique. It’s really closer to the way many people deal with finding a destination when they’re lost. As an experienced international traveler, I often used something close to DFS when my local maps prove less than informative.

Let’s say you get to where you think the destination is, realize you’re lost, and then backtrack to the last known point where map and reality are somewhat similar. You then try another path from that point. And then backtrack if you still can’t find that hidden gelato café.

If you’ve exhausted all the paths from that point, you backtrack yet again and try new paths further up the map. You’ll eventually come across the destination spot, or at least get a good tour of the older parts of town.

That’s essentially DFS! The appropriate data structure is a stack that keeps track of where you’ve been. If all the paths from the current top of the stack don’t lead anywhere, you pop the stack and work with the previous node in the path – the backtrack step.

To avoid getting into a loop because of the cycles in the undirected graph, you just mark every node you visit and avoid those that you’ve already visited.

Finally, whatever nodes are already on the stack is your breadcrumb trail — the path to get from your source to destination.

All these ideas are captured in the script below, and you see the results of my running it to find a path between Salsa and Enchilada.

findpath
Stacks: it’s what you need when you’re lost.
find-results
From Salsa to Enchilada via way of Cal and Meg!

Is this a complete and practical solution?

The answer is no and no. To really finish this, you’ll also need to scan the domain for users who are currently logged into the servers. If these ostensibly local admin users whose credentials you want steal are not online, their hashes are likely not available for passing. You would therefore have to account for this in working out possible paths.

As you might imagine, in most corporate networks, with potentially hundreds of computers and users, the graph can get gnarly very quickly. More importantly, just because you found a path, doesn’t necessarily mean it’s the shortest path. In other words, my code above may chug and find a completely impractical path that involve hopping between say, twenty or thirty computers. It’s possible but not practical.

Fortunately, Andy Robbins worked out far prettier PowerShell code that addresses the above weaknesses in my scripts. Robbins uses PowerView’s Get-NetSession to scan for online users. And he cleverly employs a beloved computer science 101 algorithm, Dijkstra’s Shortest Path, to find the optimal path between two nodes.

Pen Testers as Metadata Detectives and Final Thoughts

Once I stepped back from all this PowerShell and algorithms (and had a few appropriate beverages), the larger picture came into focus.

Thinking like hackers, pen testers know that to crack a network that they’ve land in, they need to work indirectly because there isn’t (or rarely) the equivalent of a neon sign pointing to the treasure.

And that’s where metadata helps.

Every piece of information I leveraged in this series of posts is essentially metadata: file ACLs, Active Directory groups and users, system and session information, and other AD information scooped up by PowerView.

The pen tester, unlike the perimeter-based security pro, is incredibly clever at using this metadata to find and exploit security gaps. They’re masters at thinking in terms of connections, moving around the network with the goal of collecting more metadata, and then with a little luck, they can get the goodies.

I was resisting, but you can think of pen testers as digital consulting detectives — Sherlock Holmes, the Benedict Cumberbatch variant that is, but with we hope better social skills.

Here are some final thoughts.

While pen testers offer valuable services, the examples in this series could be accomplished offline by regular folks — IT security admins and analysts.

In other words, the IT group could scoop up the AD information, do the algorithms, and then discover if there are possible paths for both the derivative admin case and the file ACL case from earlier in the series.

The goal for them is to juggle Active Directory users and groups into a configuration that greatly reduces the risk of hackers gaining user credentials.

And ultimately prevent valuable content from being taken, like your corporate IP or millions of your customers’ credit card numbers.

 

What you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.

Try Varonis free.

Get a detailed data risk report based on your company’s data.
Deploys in minutes.

Keep reading

Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.

pen-testing-active-directory-environments,-part-iv:-graph-fun
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...
binge-read-our-pen-testing-active-directory-series
Binge Read Our Pen Testing Active Directory Series
With winter storm Niko now on its extended road trip, it’s not too late, at least here in the East Coast, to make a few snow day plans. Sure you...
pen-testing-active-directory-environments,-part-iii: -chasing-power-users
Pen Testing Active Directory Environments, Part III:  Chasing Power Users
For those joining late, I’m currently pen testing the mythical Acme company, now made famous by a previous pen testing engagement (and immortalized in this free ebook). This time around...
pen-testing-active-directory-environments,-part-i:-introduction-to-crackmapexec-(and-powerview)
Pen Testing Active Directory Environments, Part I: Introduction to crackmapexec (and PowerView)
I was talking to a pen testing company recently at a data security conference to learn more about “day in the life” aspects of their trade. Their president told me...