Varonis announces strategic partnership with Microsoft to accelerate the secure adoption of Copilot.

Learn more

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...
Michael Buckbee
3 min read
Published June 2, 2017
Last updated February 11, 2022

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

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.

Get the Free PowerShell and Active Directory Essentials Video Course

I'd recommend this for both new and advanced PowerShell users. Building an AD tool is a great learning experience.
The only apps you’ll ever need!

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:

Damn you Software Restriction Policies!

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:

  1. "HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers"
  2. 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.

Log file produced by SRP.

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.

What you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.

Try Varonis free.

Get a detailed data risk report based on your company’s data.
Deploys in minutes.

Keep reading

Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.

how-varonis'-approach-to-sspm-helps-your-company
How Varonis' approach to SSPM helps your company
Adopt a data-first approach with Varonis' SSPM, securing SaaS apps & reducing risk. Learn how you can get better visibility, automation, and protection.
threat-update-54-–-sso-imposter:-intrusion
Threat Update 54 – SSO Imposter: Intrusion
Virtually every organization leveraging more than a few cloud offerings has a single sign-on solution to simplify the management of their various cloud apps. With a little careful planning, attackers…
securityrwd-–-github-secret-scanning-could-create-false-sense-of-security
SecurityRWD – GitHub Secret-Scanning Could Create False Sense of Security
Microsoft recently announced they would be adding another layer of security to their popular code repository, GitHub, by scanning for "secrets" (API tokens, access keys, etc. inadvertently saved in the platform). However, as Kilian Englert and Ryan O'Boyle from the Varonis Cloud Architecture team discuss, this positive first step shouldn't lull developers into a false sense of security. Listen in to hear why it's so important not to let your guard down when securing critical cloud apps and data.
threat-update-61---when-work-and-home-saas-use-blurs,-expect-the-unexpected
Threat Update 61 - When Work and Home SaaS Use Blurs, Expect the Unexpected
Businesses can face unexpected risk as the lines between corporate and personal SaaS apps begin to blur - especially as users introduce sensitive or regulated content into a corporate SaaS app.