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.
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.
Effectively, I whitelisted all-the-usual Windows suspects, and then partially blacklisted PowerShell.
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.
