Tag Archives: powershell empire

Disabling PowerShell and Other Malware Nuisances, Part I

Disabling PowerShell and Other Malware Nuisances, Part I

This article is part of the series "Disabling PowerShell and Other Malware Nuisances". Check out the rest:

Back in more innocent times, circa 2015, we began to hear about hackers going malware-free and “living off the land.” They used whatever garden-variety IT tools were lying around on the target site. It’s the ideal way to do post-exploitation without tripping any alarms.

This approach has taken off and gone mainstream, primarily because of off-the-shelf post-exploitation environments like PowerShell Empire.

I’ve already written about how PowerShell, when supplemented with PowerView, becomes a potent purveyor of information for hackers. (In fact, all this PowerShell pen-testing wisdom is available in an incredible ebook that you should read as soon as possible.)

Any tool can be used for good or bad, so I’m not implying PowerShell was put on this earth to make the life of hackers easier.

But just as you wouldn’t leave a 28” heavy-duty cable cutter next to a padlock, you probably don’t want to allow, or at least make it much more difficult for, hackers get their hands on PowerShell.

This brings up a large topic in the cybersecurity world: restricting application access, which is known more commonly as whitelisting or blacklisting. The overall idea is for the operating system to strictly control what apps can be launched by users.

For example, as a member of homo blogus, I generally need some basic tools and apps (along with a warm place to sleep at night), and can live without PowerShell, netcat, psexec, and some other cross-over IT tools I’ve discussed in previous posts. The same applies to most employees in an organization, and so a smart IT person should be able come up with a list of apps that are safe to use.

In the Windows world, you can enforce rules on application execution using Software Restriction Policies and more recently AppLocker.

However, before we get into these more advanced ideas, let’s try two really simple solutions and then see what’s wrong with them.

ACLs and Other Simplicities

We often think of Windows ACLs as being used to control access to readable content. But they can also be applied to executables — that is, .exe, .vbs, .ps1, and the rest.

I went back into Amazon Web Services where the Windows domain for the mythical and now legendary Acme company resides and then did some ACL restriction work.

The PowerShell .exe, as any sys admin can tell you, lives in C:\Windows\System32\WindowsPowerShell\v1.0. I navigated to the folder, clicked on properties, and effectively limited execution of PowerShell to a few essential groups: Domain Admins and Acme-SnowFlakes, which is the group of Acme employee power users.

I logged backed into the server as Bob, my go to Acme employee, and tried to bring up PowerShell. You see the results below.

In practice, you could probably come up with a script — why not use PowerShell? — to automate this ACL setting for all the laptops and servers in a small- to mid-size site.

It’s not a bad solution.

If you don’t like the idea of setting ACLs in executable files, PowerShell offers its own execution restriction controls. As a user with admin privileges, you can use, what else but a PowerShell cmdlet called Set-ExecutionPolicy.

It’s not nearly as blunt a force as the ACLs, but you can restrict PowerShell to work only in interactive mode –  with the Restricted parameter — so that it won’t execute scripts that contain the hackers’ malware. PowerShell would still be available in a limited way, but it wouldn’t be capable of running the scripts containing hacker PS malware.

However, this would PowerShell scripts from being run by your IT staff.  To allow IT-approved scripts, but disable evil hacker scripts, you use the RemoteSigned parameter in Set-ExecutionPolicy. Now PowerShell will only launch signed scripts. The IT staff, of course, would need to create their own scripts and sign them using an approved credential.

I won’t go into the details how to do this, mostly because it’s so easy to get around these controls. Someone even has a listicle blog post in which 15 PowerShell  security workarounds are described.

The easiest one is using the Bypass parameter in PowerShell itself. Duh! (below).

Seems like a security hole, no?

So PowerShell has some basic security flaws. It’s somewhat understandable since it is, after all, just a shell program.

But even the ACL restriction approach has a fundamental problem.

If hackers loosen up the “live off the land” philosophy, they can simply download — say, using a remote access trojan (RAT) — their own copy of PowerShell .exe. And then run it directly, avoiding the permission restrictions with the resident PowerShell.

Software Restriction Policies

These basic security holes (and many others) are always an issue with a consumer-grade operating systems. This has led OS researchers to come up with secure secure operating systems that have direct power to control what can be run.

In the Windows world, these powers are known as Software Restriction Policies (SRP) — for a good overview, see this — that are managed through the Group Policy Editor.

With SRP you can control which apps can be run, based on file extension, path names, and whether the app has been digitally signed.

The most effective, though most painful approach, is to disallow everything and then add back application that you really, really need. This is known as whitelisting.

We’ll go into more details in the next post.

Anyway, you’ll need to launch the policy editor, gpedit, and navigate to Local Computer Policy>Windows Settings>Security Settings>Software Restriction Polices>Security Levels. If you click on “Disallowed”, you can then make this the default security policy — to not run any executables!

The whitelist: disallow as default, and then add app policies in “Additional Rules”.

This is more like a scorched earth policy. In practice, you’ll need to enter “Additional Rules” to add back the approved apps (with their path names). If you leave out PowerShell, then you’ve effectively disabled this tool on the site.

Unfortunately, you can’t fine-tune the SRP rules based on AD groups or users. Drat!

And that we’ll bring us to Microsoft’s latest and greatest security enforcer, known as AppLocker, which does provide some nuance to application access. We’ll take that up next time as well.

Continue reading the next post in "Disabling PowerShell and Other Malware Nuisances"

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 also play out in Active Directory environments. In this post, we’ll start out where we left off last time in thinking about the big picture of Active Directory users and groups.

Or more accurately pondering the big graph of Active Directory. And the game we’re playing is closer to four degrees of Ted, your overworked IT admin or other privileged user.

Graphically Speaking

Why do we need to think about graphs in AD environments?

These structures form naturally from AD group membership. At the Acme company, I already set up groups for Acme-Clevels, Acme-VIPs and Acme-Serfs. These AD groups can contain either users or other groups. IT often establishes AD environments with group hierarchies so they can control permissions at finer levels with each hop down the hierarchy.

Since the last post, for example, I added a group for Acme-Legal under Acme-VIPs. In Acme Legal, there are legal subgroups for Acme-Patents and Acme-Compliance. As Acme’s beloved IT admin, I can set permissions that allow only members of Acme-Patents to view and update certain directories or include all of Acme-Legal or even all of Acme-VIPs.


Part of the Acme AD hierarchy.

The computer science-y word for the hierarchies I’m describing is known as directed acyclic graphs or DAGs. For anyone who’s ever taken a basic CS class such as “Data Structures for Poets and Aspiring Sous Chefs”, this core graph type always comes up.

Pen testers who work in AD environment are also very fond of these graphs. They allow them to quickly hunt down users who’ll have the credentials they need. A gentle intro to the subject can be found in this Def Con presentation. I’ll add the usual qualifier: the whole area of graph theory is a rich one, and we’ll only be sipping its foamy crema in this post.

One use of these ideas is known as “derived admin”, which involves hopping around the network while gaining local admin privileges. We’ll do something a little different: finding users who have permissions to a file we’re interested but can’t access.

Practicing Law Without the Right Permissions

Let’s say I’ve landed on Acme’s Salsa server with Bob’s plain credentials — Bob is in the Acme-Serfs’ group. Bob has enough file permissions to help me move around the server, but not enough to allow access to interesting content.

I come across a tempting directory named “Top Secret”. Unfortunately, I can’t navigate into it. I now use PowerView’s Get-PathACL to get a little more insight.


Wouldn’t you know it, but “Top Secret” gives access to those only in Acme-Legal (and Administrators). As an Acme-Serfs member, I’ve been excluded.

Here’s the problem. I’d like to discover all the users under the Acme-Legal umbrella since any user in the Acme-Legal hierarchy would give me the right privileges.

The goal is to find all those users – in graph-speak, the leaves — under Acme-Legal.  And then hope that one of these users are on the Salsa server so I can steal their credentials through pass-the-hash.

If you do this on an ad-hoc, manual basis this can get complicated very quickly for even small companies. For example, I can try running Get-NetGroupMember, write down all the groups and users that are spit out and then repeat until exhaustion sets in.

Paul Revere Rides Again

The better way to do this, of course, is to automate the task using PowerShell.

We need to build what’s known in the trade as adjacency lists — it’s a array structure for representing the DAG. For each Acme group, I can quickly access the immediate members under it.

I’m not much of a PowerShell scripter, but in an afternoon or two I was able to generated these lists using PS’s associative arrays and arraylist data types, along with using PowerView’s Get-NetGroupMember.

You can see the partial results below, with the variable $GroupAdj containing it all.


Yeah, it’s a great homework assignment to work this out for yourself.

Do some of these ideas seem familiar in a kind of Paul Revere-metadata way?  Of course, sociologist Kieran Healy’s great Using Metadata to Find Paul Revere should come to mind! Healy’s post was a first introduction to metadata and graphs for many of us.

His problem was finding all the Tea Partiers — the original version 1.0 — that Paul Revere was connected to. By the way, his post shows you how to create what’s known by the graph-erati as the “transitive closure” for each node.  I’ll take that up next time for our Acme graph.

This time we’ll solve a far simpler puzzle: given a specific Acme user and a group, is there are connection between the two? Essentially, I want to see if there’s a path from an AD group to the user by navigating my adjacency lists.

If you’ve the taken the computer course for poets that I mentioned earlier, you know about breadth-first search (BFS) and depth-first search (DFS) algorithms. As a cool pen tester, I wrote a couple of lines of code that implements  BFS and kept in a file call depthsearch:


Classic depth-first-search in PowerShell. By the way ArrayLists are the way to implement simple queues!

Let’s say I’m watching to see who’s logging into Salsa using crackmapexec with --lusers option. I discover that someone named Cal is now on the server. He’s seems like an IT guy based on running the Get-NetUser cmdlet.

So I now run my depthsearch script with parameters Acme-Legal and cal.


Eureka! Next I just need to dump his hash using crackmapexec and then I can pop a shell with Empire – remember from last time?

And the Lesson Is  … Role Based Access Controls

In my role as Acme admin, I created a special group known as Acme-SnowFlakes, where I put Cal the IT guy. The Acme-Snowflakes group is itself buried down in the hierarchy under the Acme-Patents group. In this make believe scenario, once upon a time we needed to give Cal access to legal folders and then we promptly forgot to remove these special Snowflakes.

As a pen tester, I can now report to management about a small hole in the Acme permission structure.

We covered a lot of ground this time, but there is an important lesson. Once the hackers get in and then leverage Active Directory metadata, they have – let’s face it – awesome power. The goal is to make it harder for them.

And one of the ways to do that is through role-based access control policies that always forces you to restrict who has access to sensitive files. An IT group that’s on its game would have been questioning why Cal had give access to the “Top Secret” directory used by the legal department.

Enough preaching!

We’ll go over some of these same ideas again next time, and then explore derivative admins, which is a variation of the concepts we’ve covered in this post.

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

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



PowerShell Empire: multiple agents each with its own shell connection.  Shellcode runs on the target computer. Awesome power.

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.


PowerShell connection back to Salsa!

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.

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