February 6, 2020

Infosec Blocking and Tackling – Restricting Malicious Code – WST

Continuing our series on basic security controls, this week we will cover how to restrict malicious code.  As an industry, application whitelisting has been a buzzword for a while now.  In theory, the concept is great: Only allow programs you trust to execute, nothing else will be allowed to run.  No malware, no problem.  Unfortunately, implementing this in a real-world environment is much more complicated.  Oftentimes we see clients attempt this, only to either give up or basically wind up trusting most executables, which kind of defeats the purpose.

One thing that can be easy to implement, and highly effective however, is blocking execution of scripts.  Many attackers use the scripting languages supported by Windows to establish a foothold on your network.  Older script types such as HTA, JS, VBA, etc. are very capable and can execute with little or no warning.  Once run, many payloads then use Windows PowerShell to do just about anything on the system they want.

The good news is that restricting these types of payloads is easily doable with Active Directory Group Policy.  Not only is Group Policy already present and in use on just about any Windows-based network, it is flexible and can be applied by Organizational Unit (OU) so you can have different restrictions based on need, user role, etc.

A step by step write-up is beyond the scope of a Weekly Security Tip, however, here are a few ideas on how to stop some of the attacker’s favorite payloads:

  • Use Group Policy to associate common script file extensions with Windows Notepad. By using “User Configuration\Preferences\Control Panel Settings\Folder Options” you can add entries for various file extensions and associate them with “C:\Windows\System32\notepad.exe”.  Even if a user downloads and attempts to open one of these file types, they will open “safely” inside Notepad.  Extensions to consider adding here are: *.JS, *.VBS, *.WSF, *.WSH, and *.HTA.  The beauty of this is if administrators or power users need to run scripts, you can simply not apply this Group Policy Object (GPO) to their OU.
  • Restrict execution of PowerShell. This can be tricky, as PowerShell is an integrated part of Windows.  You can’t keep a determined user from running PowerShell, but you can make it harder so most automated scripts can’t do it.  Use “User Configuration\Policies\Windows Settings\Security Settings\Software Restriction Policies\Additional Rules” to create entries that disallow execution of the PowerShell.exe executables (generally found at %systemroot%\system32\WindowsPowerShell\v1.0\ and %systemroot%\syswow64\WindowsPowerShell\v1.0\.  This makes most automated methods of calling PowerShell code ineffective.
  • Restrict Microsoft Office Macros. This is probably the hardest of these recommendations to implement, but is still doable, and can make your environment much more secure against malicious attachments.  It involves importing custom ADMX files to give you the needed Group Policy settings.  The process for this is dependent on your version of Office and Windows Server, but a good place to start is: https://www.microsoft.com/en-us/download/details.aspx?id=49030.

Past Weekly Security Tips – WST