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

Learn more

PowerView Pen Testing

Pen Testing Active Directory Environments, PowerView, and how to go on the offensive with AD, take a look at our guide!
Michael Buckbee
4 min read
Published November 30, 2016
Last updated February 25, 2022

In my last post, I began discussing how valuable pen testing and risk assessments can be done by just gathering information from Active Directory. I also introduced PowerView, which is a relatively new tool for helping pen testers and “red teamers” explore offensive Active Directory techniques.

To get more background on how hackers have been using and abusing Active Directory over the years, I recommend taking a look at some of the slides and talks by Will Schroeder, who is the creator of PowerView.

Get the Free PowerShell and Active Directory Essentials Video Course

What Schroeder has done with PowerView is give those of us on the security side a completely self-contained PowerShell environment for seeing AD environments the way hackers do.

How to Use PowerView for Pen Testing

powerview pen testing goal

Last time I was crowing about crackmapexec, the Swiss-army knife pen testing tool, which among its many blades has a PowerView parameter. I also showed how you can input PowerView cmdlets directly.

However, the really interesting things you can do with PowerView involve chaining cmdlets together in a PowerShell pipeline. And—long sigh—I couldn’t figure out how to get crackmapexec to pipeline.

But this leads to a wondrous opportunity: download the PV library from GitHub and directly work with the cmdlets.

And that’s what I did.

I uploaded PowerView’s Recon directory and placed it under Documents\ WindowsPowerShell\Modules on one of the servers in my mythical Acme company environment. You then have to enter an Import-Module Recon cmdlet in PowerShell to load PowerView—see the instructions on the GitHiub page.

And then we’re off to the races.

Pen Testing Active Directory with PowerView

I already showed how it was possible to discover the machines on the Acme network, as well as who was currently logged in locally using a few crackmapexec parameters.

Let’s do the same thing with PowerView cmdlets.

For servers in the domain, the work is done by Get-NetComputer.

Use PowerView cmdlet Get-NetComputer to see all active computers

Notice how this is a little more useful than the nessus-like output of crackmapexec—we get the more nutritious AD server names and domain.

To find all the user sessions on my current machine, I’ll use the very powerful cmdlet Invoke-UserHunter. More power than I really need for this: it actually tells me all users currently logged in on all machines across the domain.

But this allows me then to introduce a PowerShell pipeline. Unlike in a Linux command shell, the output of a PowerShell cmdlet is an object, not a string, and that brings in all the machinery of the object-oriented model—attributes, classes, inheritance, etc. We’ll explore more of this idea below.

I present for your amusement the following pipeline below. It uses the Where-object cmdlet, aliased by the PowerShell symbol, and filters out only those user objects where the ComputerName AD attribute is equal to “Salsa”, which is my current server.

PowerView cmdlet Invoke-UserHunter shows logged in users from active directory

Note: the $_. is the way PowerShell lets you refer to a single object in a stream or collection of objects.

To see who’s on the Taco server, I did this instead:

PowerView cmdlet Invoke-UserHunter Administrator

Interesting! I found an Administrator.

One of the goals of pen testing is hunting down admins and other users with higher privileges. Invoke-UserHunter is the go-to cmdlet. Let’s store this thought away for the next post.

Another good source of useful information are the AD groups in the Acme environment. You can learn about organizational structure from looking at group names.

I used PowerView’s Get-NetGroup to query Active Directory for all the groups in the Acme domain. As the output sped by, I noticed, besides all the default groups, that there were a few group names that had Acme as prefix. It was probably set up and customized by the Acme system admin, which would be me in this case.

One group that caught my attention was the Acme-VIPs group.

It might be interesting to see this group’s user membership, and PV’s Get-NetGroupMember does this for me.

PowerView cmdlet Get-NetGroupMember

I now have a person of interest: Ted Bloatly, and obviously important guy at Acme.

Gathering Active Directory Information

At this point, I’ve not done anything disruptive or invasive. I’m just gathering information – under the hood PowerView, though is making low-level AD queries.

Suppose I want to find out more details about this Ted Bloatly person.

AD administrators are of course familiar with the Users and Computer interface through which they manage the directory (see below).

Active Directory Properties

 

It’s also a treasure trove of information for hackers.

Can I access this using PowerView?

Through another PV cmdlet, Get-NetUser, I can indeed see all these fields, which includes phone numbers, home address, emails, job title, and notes.

Putting on my red team hat, I could then leverage this personal data in a clever phishing or pretext attack — craft a forged email or perhaps make a phone call.

I then ran Get-NetUser with an account name parameter directly, and you can see some of the attributes and their values displayed below.

PowerView cmdlet Get-NetUser Active Directory Properties

However, as a cool pen tester I was only interested in a few of these attributes, so I came up with another script.

I’ll now use the PV cmdlet Foreach-Object, which has an alias of %.

The idea is to filter my user objects using the aforementioned Select-Object to only match on ted, and then use the Foreach-Object cmdlet to reference individual objects—in this case only ted—and its attributes. I’ll print the attributes using PowerShell’s Write-Output.

By the way, Get-NetUser displays a lot of the object’s AD attributes, but not all of them. Let’s say I couldn’t  find the attribute name for Ted’s email address.

So here’s where having a knowledge of Active Directory classes comes into play. The object I’m interested in is a member of the organizationalPerson class. If you look at the Microsoft AD documentation, you’ll find that this class has an email field, known by its LDAP name as “mail”.

With this last piece of the puzzle, I’m now able to get all of Ted’s contact information as well as some personal notes about him contained in the AD info attribute.

PowerView cmdlet Get-NetUser parameters

So I found Acme’s CEO and even know he’s a bowler. It doesn’t get much better than that for launching a social engineered attack.

As a hacker, I could now call it a day, and use this private information to later phish Ted directly, ultimately landing on the laptop of an Acme executive.

One can imagine hackers doing this on an enormous scale as they scoop up personal data on different key groups within companies: executives, attorneys, financial groups, production managers, etc.

I forgot to mention one thing: I was able to run these cmdlets using just ordinary user access rights.

Scary thought!

In my next post, we’ll instead to try to access Ted’s laptop more directly, and explore techniques of navigating around the Acme network.

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-vi:-the-final-case
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...
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...