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

Learn more

Disabling PowerShell and Other Malware Nuisances, Part III

One of the advantages of AppLocker over Software Restriction Policies is that it can selectively enable PowerShell for Active Directory groups. I showed how this can be done in the...
Michael Buckbee
2 min read
Published June 8, 2017
Last updated June 30, 2022

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

One of the advantages of AppLocker over Software Restriction Policies is that it can selectively enable PowerShell for Active Directory groups. I showed how this can be done in the previous post. The goal is to limit as much as possible the ability of hackers to launch PowerShell malware, but still give legitimate users access.

It’s a balancing act of course. And as I suggested, you can accomplish the same thing by using a combination of Software Restriction Policies (SRP) and ACLs, but AppLocker does this more efficiently in one swoop.

Want to learn ransomware basics and earn a CPE credit? Try our free course.

“In just one hour, I’ll teach you the fundamentals of Ransomware and what you can do to protect and prepare for it.”

Let’s Get Real About Whitelisting

As a practical matter, whitelisting is just plain hard to do, and I’m guessing most IT security staff won’t go down this route. However, AppLocker does provide an ‘audit mode’ that makes whitelisting slightly less painful than SRP.

AppLocker can be configured to log events that show up directly in the Windows Event Viewer. For whatever reason, I couldn’t get this to work in my AWS environment. But this would be a little less of a headache than setting up a Registry entry and dealing with a raw file — the SPR approach.

In any case, I think most of you will try what I did. I took the default rules provided by AppLocker to enable the standard Windows system and program folders, added an exception for PowerShell, and then created a special rule to allow only member of a select AD group — Acme-VIPs in my case — to access PowerShell.

AppLocker: Accept the default path rules, and then selectively enable PowerShell.

Effectively, I whitelisted all-the-usual Windows suspects, and then partially blacklisted PowerShell.

PowerShell for Lara, who’s in the Acme-VIPs group, but no PowerShell for Bob!

And Acme Was Hacked

No, the hacking of my Acme domain on AWS is not going to make any headlines. But I thought as a side note it’s worth mentioning.

I confess: I was a little lax with my Amazon firewall port setting, and some malware slipped in.

After some investigation, I discovered a suspicious executable in  the \Windows\Prefetch directory. It was run as a service that looked legit, and it opened a zillion UDP ports.

It took me an afternoon or two to figure all this out. My tip offs were when my server became somewhat sluggish, and then receiving an Amazon email politely suggesting that my EC2 instance may have been turned into a bot used for a DDoS attack.

This does relate to SRP and AppLocker!

Sure, had I activated these protection services earlier, Windows would have been prevented from launch the malware, which was living in in a non-standard location.

Lesson learned.

And I hold my head in shame if I caused some DDos disturbance for someone, somewhere.

Final Thoughts

Both SRP and AppLocker also have rules that take into account file hashes and digital certificates. Either will provide an additional level of security that the executable are really what they claim to be, and not the work of evil hackers.

AppLocker is more granular than SRP when it comes to certificates, and it allows you to filter on a specific app from a publisher and a version number as well. You can learn more about this here.

Bottom line: whitelisting is not an achievable goal for the average IT mortal. For the matter at hand, disabling PowerShell, my approach of using default paths provided by either SRP or AppLocker, and then selectively allowing PowerShell for certain groups — easier with AppLocker — would be far more realistic.

Next Steps

It may seem odd if you’ve just gone through all three parts of this series about disabling PowerShell to find us suggesting a course on writing more PowerShell. It’s not hypocritical. It’s using the right tool for the right job at the right time.

To that end, if you’re interested in learning more practical, security focused PowerShell, you can unlock the full 3 hour video course on PowerShell and Active Directory Essentials with the code cmdlet.

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.

practical-powershell-for-it-security,-part-i:-file-event-monitoring
Practical PowerShell for IT Security, Part I: File Event Monitoring
Back when I was writing the ultimate penetration testing series to help humankind deal with hackers, I came across some interesting PowerShell cmdlets and techniques. I made the remarkable discovery...
adventures-in-fileless-malware,-part-ii:-sneaky-vba-scripts
Adventures in Fileless Malware, Part II: Sneaky VBA Scripts
I’m a fan of the Hybrid Analysis site. It’s kind of a malware zoo where you can safely observe dangerous specimens captured in the wild without getting mauled. The HA...
the-difference-between-bash-and-powershell
The Difference Between Bash and Powershell
You don’t normally talk philosophy and IT when considering Bash and Powershell, but if it’s one thing I’ve learned over the past 20 years of sysadmin work it’s that whether...
working-with-windows-local-administrator-accounts,-part-iii
Working With Windows Local Administrator Accounts, Part III
One point to keep in mind in this series is that we’re trying to limit the powers that are inherent in Administrator accounts. In short: use the Force sparingly. In...