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.

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

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.

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.

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:

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.

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).

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.

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.

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.

Continue reading the next post in "Pen Testing Active Directory Environments"

Part III:  Chasing Power Users