Disabling PowerShell and Other Malware Nuisances, Part II

Whitelisting apps is nobody’s idea of fun. You need to start with a blank slate, and then carefully add back apps you know to be essential and non-threatening. That’s the the idea behind what we started to do with Software Restriction Policies (SRP) from last time.

As you’ll recall, we ‘cleared the board’ though the default disabling of app execution in the Property Rules. In the Additional Rules section, I then started adding Path rules for apps I though were essential.

Obviously, this can get a little tedious, so Microsoft helpfully provides two default rules: one to enable execution of apps in the Program folder and the other to enable executables in the Windows system directory.

But this is cheating and then you’d be force then to blacklist apps you don’t really need.

Anyway, when a user runs an unapproved app or a hacker tries to load some malware that’s not in the whitelist, SRP will prevent it.  Here’s what happened when I tried to launch PowerShell, which wasn’t in my whitelist, from the old-style cmd shell, which was in the list:

100% Pure Security

To be ideologically pure, you wouldn’t use the default Windows SRP rules. Instead, you need to start from scratch with bupkes and do the grunt work of finding out what apps are being used and that are truly needed.

To help you get over this hurdle, Microsoft suggests in a Technet article that you turn on a logging feature that writes out an entry whenever SRP evaluates an app.  You’ll need to enable the following registry entry and set a log file location:

"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers"

String Value: LogFileName, <path to a log file>

"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers"

String Value: LogFileName, <path to a log file>

Here’s a part of this log file from my AWS test environment.

So you have to review the log, question users, and talk it over with your fellow IT admins. Let’s say you work out a list of approved apps (excluding PowerShell), which you believe would make sense for a large part of your user community. You can then leverage the Group Policy Management console to publish the rules to the domain.

In theory, I should be able to drag-and-drop the rules I created in the Group Policy Editor for the machine I was working into the Management console. I wasn’t able to pull that off in my AWS environment.

I instead  had to recreate the rules directly in the Group Policy Management Policy Editor (below), and then let it do the work of distributing it across the domain — in my case, the Acme domain.

Magic!

You can read more about how to do this here.

A Look at AppLocker

Let’s get back to the issue of PowerShell. We can’t live without it, yet hackers have used it as tool for stealthy post-exploitation.

If I enable it in my whitelist, along with some of the built-in PowerShell protections I mentioned in the last post, there are still so many ways to get around these security precautions that it’s not worth the trouble.

It would be nice if SRP allows you to do the whitelisting selectively based on Active Directory user or group membership. In other words, effectively turn off PowerShell except if you’re, say, an IT admin that’s a member of the ‘Special PowerShell’ AD group.

That ain’t happening in SRP since it doesn’t support this level of granularity!

Starting in Windows 7 (and Windows Server 2008), Microsoft deprecated SPR and introduced the (arguably) more powerful AppLocker. It’s very similar to the what it replaces, but it does provide this user-group level filtering.

We’ll talk more about AppLocker and some of its benefits in the final post in this series. In any case, you can find this policy next to SRP in the Group Policy Editor under Application Control Policies.

For my Acme environment, I set up a rule that enables PowerShell for only users in the Acme-VIP group, Acme’s small group of power IT employees. You can see how I started setting this up as I follow the AppLocker wizard dialog:

PowerShell is an important and useful tool, so you’ll need to weigh the risks in selectively enabling it through AppLocker— dare I say it, perform a risk assessment.

Of course, you should have secondary controls, such as, ahem, User Behavior Analytics, that allows you to protect against PowerShell misuse should the credentials of the PowerShell-enabled group be compromised by hackers or insiders.

We’ll take up  other AppLocker capabilities and final thoughts on whitelisting in the next post.