
This article is part of the series "Pen Testing Active Directory Environments". Check out the rest:
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 Pen Testing Active Directory Environments EBook
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.