Use Software Restriction Policies to block viruses and malware

You got a virusscanner and maybe also some other mitigation tools to protect your or company computers, but still viruses and malware can get thru into the system. Here is a method to create an extra layer of defense for your systems. We’ll be using Software Restriction Policies that can be found in the Local Security Policy for standalone PC’s or in the Group Policy Management for domain joined systems. We will be gonna use this for blocking executables from %APPDATA% and %USERPROFILE% directories, but also from compressed archives that can be mailed with an executable as attachment, for example the Cryptovirus (TorrentLocker) or Ransomware you get nowadays from DHL and PostNL e-mails (more info on Fox-IT). For this blogpost the screenshots and examples are made with Windows Server 2012 and Group Policy Management, but are also usable and tested by me in enviroments with Windows Server 2003/Windows XP and newer operation systems.

I like the idea behind this method to protect the system this way is just like you should do with linux servers to mount in example /tmp with noexec,nosuid in /etc/fstab. A lot of webhosters who don’t use this simple trick have mostly running some Eggdrop IRC bots on their servers, but for now we concetrate on Windows systems.

First fire up Group Policy Management from the Tools menu in your Server Manager and make a new Group Policy Object or use an existing one.

102214_1251_UseSoftware1

Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Software Restriction Policies and right click it to open a menu where you choose New Software Restriction Policies.

102214_1251_UseSoftware2

Open Additional Rules and right click it to create a New Path Rule.

102214_1251_UseSoftware3

Import the rules that are listed below.

Block executable in %AppData%:

  • Path:
    %AppData%*.exe
  • Security Level:
    Disallowed
  • Description:
    Don’t allow executables to run from %AppData%.

Block executable in %LocalAppData%:

  • Path if using Windows XP:
    %UserProfile%Local Settings*.exe
  • Path if using Windows Vista/7/8:
    %LocalAppData%*.exe
  • Security Level:
    Disallowed
  • Description:
    Don’t allow executables to run from %AppData%.

Block executable in %AppData% subfolders:

  • Path:
    %AppData%**.exe
  • Security Level:
    Disallowed
  • Description:
    Don’t allow executables to run from immediate subfolders of %AppData%.

Block executable in %LocalAppData% subfolders:

  • Path if using Windows XP:
    %UserProfile%Local Settings**.exe
  • Path if using Windows Vista/7/8:
    %LocalAppData%**.exe
  • Security Level:
    Disallowed
  • Description:
    Don’t allow executables to run from immediate subfolders of %AppData%.

Block executables run from archive attachments opened with WinRAR:

  • Path if using Windows XP:
    %UserProfile%Local SettingsTempRar**.exe
  • Path if using Windows Vista/7/8:
    %LocalAppData%TempRar**.exe
  • Security Level:
    Disallowed
  • Description:
    Block executables run from archive attachments opened with WinRAR.

Block executables run from archive attachments opened with 7zip:

  • Path if using Windows XP:
    %UserProfile%Local SettingsTemp7z**.exe
  • Path if using Windows Vista/7/8:
    %LocalAppData%Temp7z**.exe
  • Security Level:
    Disallowed
  • Description:
    Block executables run from archive attachments opened with 7zip.

Block executables run from archive attachments opened with WinZip:

  • Path if using Windows XP:
    %UserProfile%Local SettingsTempwz**.exe
  • Path if using Windows Vista/7/8: %LocalAppData%Tempwz**.exe
  • Security Level:
    Disallowed
  • Description:
    Block executables run from archive attachments opened with WinZip.

Block executables run from archive attachments opened using Windows built-in Zip support:

  • Path if using Windows XP:
    %UserProfile%Local SettingsTemp*.zip*.exe
  • Path if using Windows Vista/7/8:
    %LocalAppData%Temp*.zip*.exe
  • Security Level:
    Disallowed
  • Description:
    Block executables run from archive attachments opened using Windows built-in Zip support.

After everything is imported you get a list like this:

102214_1251_UseSoftware4

Now testing the Software Restriction Policies on a client computer (note: if the user is already logged on, you need to relog, a GPUPDATE /force doesn’t work).

102214_1251_UseSoftware5

Voila, but the user cannot start Teamviewer with those ruleswhat if you want an exception for this or other legitimate software. For this you can make other rules:

102214_1251_UseSoftware6

Make a New Path Rule but on the security level, choose ‘unrestricted‘.

Hooray it worked J As last I want to add, if you’re using some kind of monitoring software in your enviroment, you can check if users are trying to lauch executables. This can be done in the Event Viewer:

102214_1251_UseSoftware7

  • This doesn’t work when run directly from Internet Explorer. You would think the executable would be “cached” in a Temp-directory, but still the executable will be run without intervention of the SRP.

    • BVucinec

      Hi Christian,

      The above paths indeed doesn’t block executables running direct from Internet Explorer, you will need to add the following path to block executables from Internet Explorer in Windows Vista/7/8: “%LocalAppData%Temp**.exe” to the SRP.

      That is because the executables will run from a separate subfolder in the %LocalAppData%Temp folder.

    • Shaun
  • Eddy Current

    If you enable SRP then do it right!
    1. remember that blacklisting just some single files doesnt work, and dont use *.exe, but block all executables in directories like %USERPROFILE% and all their subdirectories.
    2. also remember that SRPs are evaluated in the user processes, and that users can change environment variables like %TEMP%, %LocalAppData%, %AppData%, %USERPROFILE% as they like.
    See http://mechbgon.com/srp or http://home.arcor.de/skanthak/SAFER.html for a correct setup of SRPs

    • BVucinec

      Thanks for the addition.

  • Mohammed Shawqi

    How about non executables? macro format such as word and excel macro spreadsheets?