We live, whether you like it or not, in an age of “fileless malware.”  More and more malware nowadays is purposefully designed to interact only minimally (if at all) with the file system on its victim host.  Because most anti-malware software tools operate primarily by searching the filesystem for known malware signatures, an attacker’s ability to stay off the filesystem, therefore, provides a correspondingly minimal foothold for detection by those products.  And this strategy works: a study from Ponemon found that 77 percent of successful compromises employed fileless malware or fileless techniques and that fileless attacks are 10 times more likely to succeed relative to file-reliant counterparts[1].  

The reason why this is possible all is that facilities exist for malware to propagate, move laterally, and ultimately execute its payload without writing to disk.  Specifically, by using one of two facilities: PowerShell and/or Windows Management Instrumentation (WMI).  Because of this, many security practitioners ask the inevitable question about completely removing and/or disabling this functionality – particularly PowerShell (for example for systems in the internally managed ecosystem or remote virtual images in the cloud).

This is a legitimate question to ask, but it’s also a deceptive one.  It’s analogous to asking whether you should tear out the plumbing in your house to guard against flooding risk.  Could you do it?  Probably, given sufficient time and expense investment, but would you want to?  After all, while flooding is a risk, living without it at your primary residence would be as inconvenient as it is risk-generating in other respects (consider, fire prevention or making do without access to treated water).

By this, I mean that while PowerShell is absolutely both a helpful tool to an attacker for moving laterally and a part of what makes fileless malware operate, there are risk impacts in not having it available to you as a management facility.  Consider, for example, the impact from a user account management, system auditing, and hardening and configuration management perspective. 

Perhaps the better question then is how to harden PowerShell in such a way that you reap its benefits while at the same time minimize its utility to an attacker. While there are a number of steps you can take (and this isn’t intended to be an exhaustive list), there are two ways that you can get started moving toward this: through hardening and enhanced logging.

For more insight and knowledge on topics like this, be sure to make your calendars for April 1 as the InfoSec World Conference & Expo returns for its 25th year.

Hardening PowerShell

First off, there are some steps you can take to “harden” PowerShell usage and configuration in your environment.  Microsoft has already taken some steps to help do this without specific administrator intervention.  For example, the Antimalware Scanning Interface (AMSI) was implemented to assist in the detection and prevention of undesirable script activity.[2]  In a nutshell, AMSI de-obfuscates and “hands-off” scripts to an installed anti-malware provider to determine a script’s safety and ultimately block it if it’s unsafe.  The de-obfuscation component means that an attacker can’t simply tweak the script such that it will pass a simple validation check while the registration component means flexibility invalidation.  This isn’t a panacea of course: it’s only available in Windows 10 and it requires a recent version of PowerShell (PowerShell v2, for example, doesn’t employ it).  There are also a few notable strategies that the research community has highlighted that bypass it.  That said, it’s better than it used to be without it.  It’s also enabled by default, not requiring any specific administrator intervention (other than the obvious removal of PowerShell version 2).

There are active measures that you can employ beyond this, however. The first way is through constrained language mode.  Constrained Language mode limits what PowerShell can do: ideally by allowing administrators to perform their duties while disallowing features of PowerShell that are most beneficial to attackers (e.g. invoking COM objects, executing Win32 API’s, etc.[3]).  To enable this, you can enable Device Guard UMCI (User Mode Code Integrity); specifically, by creating and apply a Device Guard policy, only those scripts that are explicitly trusted will run in full language mode.  This means that others (such as malware or attacker activity) will not.  An alternative (though potentially more easily circumvented) strategy to enforce constrained language mode is via AppLocker.  Specifically, you can create policy that limits the execution of scripts in full language mode only to those in the Windows folder and/or the Programs Files folder. 

Enhance your logs

In addition to hardening usage of PowerShell, you can also increase your awareness of the actions taken by scripts.  First, you can enable logging when scripts are executed (module logging).  This is a useful first step, but it’s even more powerful when you enable logging of the script code itself through Script Block Logging.  Meaning, if the code gets run, it gets de-obfuscated and logged so you that you can review it after the fact.  As of PowerShell 5, it’ll even warn you if specific commands look suspicious.  You can enable this functionality through group policy (Administrative Templates -> Windows Components -> Windows PowerShell[4]).

Of course, it goes without saying that, just like any other logging exercise, the ability to centrally collect these logs greatly increases their utility to you.  Also, keep in mind that these logs can become fairly verbose, so the degree to which you normatively use PowerShell as a normal course of administration will increase the volume of the log information generated.  So, plan accordingly and potentially “slow roll” the enablement of this logging facility rather than trying to enable it everywhere at once (potentially bringing your collection tools low in the process).

At the end of the day, PowerShell is an enormously flexible, valuable, and helpful tool in any enterprise administrator’s toolbox, so “turning it off” isn’t really a viable option for most shops.  That said, there are security features that it does behoove security teams to know about – and, where viable, take active steps to enable – that help leave that power intact but that close off avenues of attack to both malware and human actors. 


 

Mimi Thian