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.
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.
Open Additional Rules and right click it to create a New Path Rule.
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 Settings\Temp\Rar*\*.exe - Path if using Windows Vista/7/8:
%LocalAppData%\Temp\Rar*\*.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 Settings\Temp\7z*\*.exe - Path if using Windows Vista/7/8:
%LocalAppData%\Temp\7z*\*.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 Settings\Temp\wz*\*.exe - Path if using Windows Vista/7/8:
%LocalAppData%\Temp\wz*\*.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 Settings\Temp\*.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:
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).
Voila, but the user cannot start Teamviewer with those rules what if you want an exception for this or other legitimate software. For this you can make other rules:
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:
Comments