How to Block Viruses and Ransomware Using Software Restriction Policies
We go on with the series of articles on counterstrategies to the viruses and encryption malware (Ransomware, CryptoLocker , etc.) in the corporate environment. Earlier we considered how to configure Windows file server protection using FSRM and restoring encrypted files from VSS snapshots after infection. Today we’ll talk about how to block ransomware executables (including common viruses and trojans) from running on user PCs.
Besides antivirus software, another barrier to prevent malware from running on user computers . In Windows environment can be Software Restriction Policies (SRP) or AppLocker. We’ll consider the example of using Software Restriction Policies to block viruses and malware.
Software Restriction Policies (SRP) provides the ability to allow or prohibit the launch of executable files using a local or domain Group Policy. The methods of protection against viruses or ransomware using SRP suggests to prohibit running files from specific directories in the user environment, to which malware files or archives usually get. In most cases, files containing a virus are obtained from the Internet or e-mail and saved to %APPDATA% directory in the user profile (%Temp% and Temporary Internet Files folders are also located here). Temporary copies of unpacked archives are also stored in this directory, when a user without much thought unpacks an archive received by e-mail or downloaded from the Internet.
When you configure SRP two strategies can be used
- Allow running executables only from certain folders (as a rule, these are %Windir% and Program Files / Program Files x86) — this is the most reliable method, but it requires a long debug time to detect the software that doesn’t work in this configuration
- Prevent executables in user directories from running — basically, these directories shouldn’t have any executables. However, these are the folders where virus files usually locate on a computer. Moreover, a user without the administrator privileges simply have no rights to write to system directories other than its own. So, a virus won’t be able to place its body anywhere other than the directory in the user profile
We’ll consider creating SRP using the second strategy as quite reliable and less time-consuming while implementing it. So let’s create a policy that blocks running files from specific locations. On a local computer, you can do it using gpedit.msc console, and if the policy will be used in a domain, create a new policy in Group Policy Management (gpmc.msc) and link it to the OU containing user computers.
Note. We strongly recommend to test SRP policies in a group of test computers prior to implementing them. If some legitimate programs don’t start due to SRP you will have to add some permissive rules.
In the GPO Editor, go to Computer Configuration -> Windows Settings -> Security Settings. Right-click Software Restriction Policies and select New Software Restriction Policies.
Select Additional Rules and create a new rule using New Path Rule.
Create a rule that prevents *.exe executables in %AppData% folder from running. Specify the following rule parameters:
- Path: %AppData%*.exe
- Security Level: Disallowed
- Description: Don’t allow executables to run from %AppData%
In the same way you have to create the deny rules for the paths listed in the table below. Since environment variables and paths in Windows 2003/XP and Windows Vistaor higher differ, the table provides values for the corresponding OS versions. If you still have Windows 2003/XP in your domain, you’d better create a separate policy for them and assign it to the OU containing these computers using GPO WMI filter by the type of the OS.
| Description | Windows XP and 2003 | Windows Vista/7/8/10, Windows Server 2008/2012 |
| Don’t allow executables to run from %LocalAppData% | %UserProfile%Local Settings*.exe | %LocalAppData%*.exe |
| Don’t allow executables from %AppData% subfolders | %AppData%**.exe | %AppData%**.exe |
| Don’t allow executables to run from %LocalAppData% subfolders | %UserProfile%Local Settings**.exe | %LocalAppData%**.exe |
| Block executables run from archive attachments opened with WinRAR | %UserProfile%Local SettingsTempRar**.exe | %LocalAppData%TempRar**.exe |
| Block executables run from archive attachments opened with 7zip | %UserProfile%Local SettingsTemp7z**.exe | %LocalAppData%Temp7z**.exe |
| Block executables run from archive attachments opened with WinZip | %UserProfile%Local SettingsTempwz**.exe | %LocalAppData%Tempwz**.exe |
| Block executables run from archive attachments opened using Windows built-in Zip support | %UserProfile%Local SettingsTemp*.zip*.exe | %LocalAppData%Temp*.zip*.exe |
| Don’t allow executables to run from %temp% | %Temp%*.exe | %Temp%*.exe |
| Don’t allow executables to run from %temp% subfolders | %Temp%**.exe | %Temp%**.exe |
| Optional. Don’t allow executables to run from any directories in the user profile.
Important. Be careful with this rule since some software, like browser plugins, installers, store their executables in the user profile. Create SRP exception rules for these applications
| %UserProfile%**.exe | UserProfile%**.exe |
You can also add your own directories. In our case, we have got the following list of preventive SRP rules.
As a rule, you should prevent other potentially dangerous files (*.bat,*.vbs, *.js, *.wsh, etc.) from running, since not only *.exe files can contain malicious code. To do it, change the paths in the SRP rules by deleting *.exe occurrences. Thus, you’ll prevent all executables and scenario files in these directories from running. The list of “dangerous” file extensions is specified in the SRP policy parameters in Designated File Types section. As you can see, there is a preset list of executable and script extensions. You can add or delete specific extensions.
You only have to make sure if the Software Restriction Policies work on a client computer. To do it, update the policies using gpupdate /force command and try to run an *.exe executable from any of the specified folders. The following error message should appear:
Your system administrator has blocked this program. For more info, contact your system administrator.
The attempts of running executables from the protected folders blocked by SRP policies can be tracked using Windows Event Log. The events can be found in the Application section with Event ID 866 and SoftwareRestrictionPolicies as the source, the text is similar to the following:
Access to C:Users ootAppDataLocalTemp71EBBB1F-3073-436E-A3DB-D577172DA029dismhost.exe has been restricted by your Administrator by location with policy rule {31f4bdb9-d39b-4bf3-d628-1b83892c6bd2} placed on path C:UsersadminAppDataLocalTemp**.exe.
Tip. If the policy prevents a trusted application from running, you can add this file to the policy exceptions (and create a new rule specifying this *.exe file with the value Unrestricted).
So we have shown a general example of software restriction policy technique (SRP or Applocker) to block viruses, encryption malware or trojans on user computers. The described technique allows to significantly increase the level of system protection from running malicious code by common users.