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 I’m using two very powerful tools, PowerView and crackmapexec, in my post-exploitation journey into Acme’s IT.

Before we get into more of the details of hunting down privileged users, I wanted to take up one point regarding Active Directory mitigations that I touched on last time.

Protecting the VIPs

As we saw, PowerView cmdlets give pen testers and hackers incredibly valuable information about the user population. It does this by pulling attributes out of Active Directory, some of which can then be used to launch a phishing-whaling attack.

So you’re wondering whether or not we can put restrictions on who gets to see the data? Or what data is made available in the first place?

Yes and yes.

For the purposes of this post, I’m proposing a quick fix. We’ll simply prevent some key AD attributes from being displayed in PowerView’s Get-NetUser cmdlet.

We really don’t want to make it easy for hackers to access phone numbers, mail addresses, and other personal information of the C-suite.

These folks may not have customer accounts and credit card numbers in their files, but they surely have access to key corporate IP – contracts, plans, pending deals, etc.

The answer can be found in the Active Directory Computer and User interface.

Our first priority should be to secure Ted Bloatly, Chief Honcho (CEO) of Acme.

If we click on his Security tab, we can view a list of broad AD attribute permissions — personal, phone and email — that we can allow or deny access to.

For Mr. Bloatly, I’ll simply deny access to his contact information (see below) for anyone in the Acme domain.

I really don’t want hackers and even employees to get this kind of sensitive data.  If you want to know anything about Mr. Bloatly, you’ll have to find out the old-fashioned way, by contacting his loyal personal assistant, Smithers.

Sure we can be more granular about who gets to see this information. Clicking on “Advanced” lets you enable certain groups to view Bloatly’s contact information: for example, I could allow access for just the Acme-VIPs group, the C-levels of the company.

In any case, if we go back to the Salsa server that we landed on, and run Get-NetUser, we’ll see that his postal address and the personal info about his bowling habits no longer shows up.

We’ll delve into other ways to restrict access to AD attributes later on in this series.

The Credential Hunt

Building on the scenario from last time, I’m back on Salsa with Lele’s credential. Lele, like her friend Bob, is in the Acme-Serfs group.

Let’s rerun Get-NetComputer.

You’re probably thinking, as I did when I set this up, that Enchilada is where the important people hang out. “Big Enchiladas”, right?

Let’s see if Lele’s credentials will allow me access to it. One quick way to do this is to use crackmapexec and point it at the server you’re trying to access—it will let you know whether can log in (below).

My pen testing senses are tingling. I’m denied access to Enchilada, but allowed access to Taco and Salsa.

It’s like the equivalent of a sign that says “Private Property: Keep Out!”. You know there has to be something valuable on the Enchilada server.

We’re now at the point where you have to find the users who’ll get you what you want – access to Enchilada.

Like last time, we can run Get-GroupMembers Acme-VIPs. I’ve found two power users now– Ted Bloatly and Lara Crasus. (fyi: I added VIP Lara since the previous post.)

What you can hope for is that one of these VIPs will let you log on to the Salsa machine. Then we can grab the hashes, and use them with crackmapexec to get into Enchilada.

By the way, this brings up an important point about risk assessments regarding user accounts: you have to be very careful about assigning user account access rights.

One common technique is to assign multiple accounts to the same user with each account having its own privileges. This avoids the problem of an over-privileged account logging into a less-privileged account’s machine, thereby leaving it open to credential theft and pass-the-hash.

So let’s say Acme hasn’t learned this lesson, and Ted Bloatly occasionally uses his one AD account to log into the Salsa server used by the plebians.

We can set an alarm.

Enter something like Invoke-UserHunter –GroupName Acme-VIPs on the command line, then check the output and repeat. Obviously, we can do a better job of fine-tuning and automating. I’ll leave that as a homework assignment.

Once we find an Acme-VIPs member, we dump the hash using the --lsa option for crackmapexec and the pass-the-hash using the –H option to log into the Enchilada server.

PowerShell Empire and Reverse Shells

One aspect of hopping around a domain that’s worth talking about is the topic of getting shell connections. So far I’ve been cheating a little bit in showing screen output from the actual server.

In real life, hackers and pen testers are using reverse-shells — remember those? — to see what’s going on from a remote terminal.

In my last pen testing series, getting a reverse shell from a PowerShell environment was a bit rocky. In fact, I didn’t really have a good way of doing this,

And the I discovered PowerShell Empire.

It describes itself as having the ability “to run PowerShell agents without needing powershell.exe, rapidly deployable post-exploitation modules ranging from key loggers to Mimikatz… all wrapped up in a usability-focused framework”

Amen, and it lives up to its billing. This is powerful stuff and I attained beautiful remote PowerShell access to the Acme environment.

If you want to play around with Empire for yourself, you can download it from GitHub here. With a little bit of struggle (and two aspirins later), I installed it on an Ubuntu Linux server in my AWS environment.

In terms of its remote PowerShell powers, it allows you to create a Listener, which lives at one end of the connection. And then you grab some shell code to run on the victim’s machine. Ultimately, it launches an Agent, which is what you interact with in Empire.

Effectively, we’re implementing the PowerShell version of the reverse shell that I previously accomplished with ncat.

You can have many agents running at a time and interact concurrently with each PowerShell session on the target machines.

This is very powerful, and I’m only scratching the surface.

Let’s take a breath.

In my next post, we’ll go into more detail for this Empire-based reverse PowerShell technique, and demonstrate how you can use it to hop around the Acme domain using crackmapexec to inject the shellcode for the next hop.

Yes, we’ll get back into exploiting the information in Active Directory groups and in particular use the relationships in it to guide which users to chase down. It’s referred to as derived or derivative  admins.

I’ll leave you with this interesting observation made by (I believe) Will Graebner: pen testers think in graphs, IT people think in terms of lists.

Meditate on that thought till next time.