Nguồn:

+/ https://docs.microsoft.com/en-us/windows-server/identity/software-restriction-policies/software-restriction-policies
+/ http://woshub.com/using-fsrm-on-windows-file-server-to-prevent-ransomware/
+/ http://woshub.com/how-to-block-viruses-and-ransomware-using-software-restriction-policies/?
fbclid=IwAR2yapm_VLCCeRUrxavK1o8clyJTueG6pxrNWlJ73wRzsYc6s22022Yrqk4

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 %UserProfile%Local Settings*.exe %LocalAppData%\*.exe
to run from
%LocalAppData%
Don’t allow executables %AppData%\*\*.exe %AppData%\*\*.exe
from %AppData%
subfolders
Don’t allow executables %UserProfile%\Local Settings\*\*.exe %LocalAppData%\*\*.exe
to run from
%LocalAppData%
subfolders
Block executables run %UserProfile%\Local %LocalAppData%\Temp\Rar*\*.exe
from archive Settings\Temp\Rar*\*.exe
attachments opened
with WinRAR
Block executables run %UserProfile%\Local %LocalAppData%\Temp\7z*\*.exe
from archive Settings\Temp\7z*\*.exe
attachments opened
with 7zip
Block executables run %UserProfile%\Local %LocalAppData%\Temp\wz*\*.exe
from archive Settings\Temp\wz*\*.exe
attachments opened
with WinZip
Block executables run %UserProfile%\Local %LocalAppData
from archive Settings\Temp\*.zip\*.exe %\Temp\*.zip\*.exe
attachments opened
using Windows built-in
Zip support
Don’t allow executables %Temp%\*.exe %Temp%\*.exe
to run from %temp%
Don’t allow executables %Temp%\*\*.exe %Temp%\*\*.exe
to run from %temp%
subfolders
Optional. Don’t allow %UserProfile%\*\*.exe UserProfile%\*\*.exe
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

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\root\AppData\Local\Temp\71EBBB1F-3073-436E-A3DB-D577172DA029\dismhost.exe
has been restricted by your Administrator by location with policy rule {31f4bdb9-d39b-4bf3-d628-
1b83892c6bd2} placed on path
C:\Users\admin\AppData\Local\Temp\*\*.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.

Using FSRM on Windows File Server to Prevent

Ransomware
In this article, we’ll consider the methods of using File Server Resource Manager (FSRM) features on
a file server running Windows Server 2012 R2 to detect and block ransomware. In particular, we’ll
tell how to install FSRM service on the file server, configure file screening, and in the case
ransomware detection block user access to the share.

Contents:
 How to Detect Ransomware Using FSRM
 How to Configure the SMTP Settings of FSRM to Send E-Mail Notifications
 How to Create a Group of File Extensions for the Ransomware
 File Screen Templates Configuration
 How to Apply File Screen Template to a Disk or Folder
 Automatic Block of the User Infected by Ransomware
 FSRM Protection Test

How to Detect Ransomware Using FSRM

If File Server Resource Manager (FSRM) feature is not installed on your file server, install it using
Server Manager graphic console or PowerShell command prompt:

Install-WindowsFeature FS-Resource-Manager -IncludeManagementTools

Make sure that the role has been installed:

Get-WindowsFeature -Name FS-Resource-Manager

After the feature has been installed, restart the server.

How to Configure the SMTP Settings of FSRM to Send E-Mail Notifications

The next step is the configuring of SMTP settings of FSRM to sending e-mail notifications to admins.
To do it, start fsrm.msc, right-click the root of File Server Resource Manager console and
select Configure Options.
Specify the SMTP server name or IP address, the administrator and sender e-mail addresses.
Tip. If you don’t have an internal mail server, you can configure sending mail using SMTP relay.

To make sure that the SMTP server is configured correctly, send a test e-mail using Send Test E-
mail button.
SMTP settings of FSRM can also be configured from PowerShell:

Set-FsrmSetting -AdminEmailAddress "[email protected]" –smtpserver

smtp.adatum.com –FromEmailAddress "[email protected]"
How to Create a Group of File Extensions for the Ransomware

The next step is to create a group of files containing known extensions and file names, created by
encryption malware during its work.

This list can be created in the FSRM console. To do it, expand File Screening Management ->
File Groups and select Create File Group.

You have to specify group name (for example, Crypto-files) and enter all known extensions to the
list using Files to include field.
The list of known file extensions created by ransomware is quite long, so it is easier to create it
using PowerShell.

In Windows Server 2012, you can create the file group using PowerShell as follows:

New-FsrmFileGroup -Name "Crypto-files" –IncludePattern

@("_Locky_recover_instructions.txt","DECRYPT_INSTRUCTIONS.TXT",
"DECRYPT_INSTRUCTION.TXT", "HELP_DECRYPT.TXT", "HELP_DECRYPT.HTML",
"DecryptAllFiles.txt", "enc_files.txt", "HowDecrypt.txt", "How_Decrypt.txt",
"How_Decrypt.html", "HELP_RESTORE_FILES.txt", , "restore_files*.txt",
"restore_files.txt", "RECOVERY_KEY.TXT", "how to decrypt aes files.lnk",
"HELP_DECRYPT.PNG", "HELP_DECRYPT.lnk", "DecryptAllFiles*.txt", "Decrypt.exe",
"AllFilesAreLocked*.bmp", "MESSAGE.txt","*.locky","*.ezz", "*.ecc", "*.exx",
"*.7z.encrypted", "*.ctbl", "*.encrypted", "*.aaa", "*.xtbl", "*.abc", "*.JUST",
"*.EnCiPhErEd", "*.cryptolocker","*.micro","*.vvv")

In Windows Server 2008 R2, you will have to use filescrn.exe:

filescrn.exe filegroup add /filegroup:"Crypto-files"

/members:"DECRYPT_INSTRUCTIONS.TXT|DECRYPT_INSTRUCTION.TXT| DecryptAllFiles.txt|
enc_files.txt|HowDecrypt.txt|How_Decrypt.txt| How_Decrypt.html|
HELP_TO_DECRYPT_YOUR_FILES.txt|HELP_RESTORE_FILES.txt| HELP_TO_SAVE_FILES.txt|
restore_files*.txt| restore_files.txt|RECOVERY_KEY.TXT|HELP_DECRYPT.PNG|
HELP_DECRYPT.lnk| DecryptAllFiles*.txt|Decrypt.exe|ATTENTION!!!.txt|
AllFilesAreLocked*.bmp| MESSAGE.txt|*.locky|*.ezz|*.ecc|*.exx|*.7z.encrypted|*.ctbl|
*.encrypted|*.aaa|*.xtbl|*.EnCiPhErEd|*.cryptolocker|*.micro|*.vvv| *.ecc|*.ezz|*.exx|
*.zzz|*.xyz|*.aaa|*.abc|*.ccc|*.vvv|*.xxx| *.ttt|*.micro|*.encrypted|*.locked|
*.crypto|*_crypt|*.crinf| *.r5a|*.XRNT|*.XTBL|*.crypt|*.R16M01D05|*.pzdc|*.good|
*.LOL!|*.OMG!|*.RDM|*.RRK|*.encryptedRSA|*.crjoker| *.LeChiffre|*.keybtc@inbox_com|
*.0x0|*.bleep|*.1999| *.vault|*.HA3|*.toxcrypt|*.magic|*.SUPERCRYPT|*.CTBL|*.CTB2|
*.locky"

Tip. You can make a list of known file extensions yourself or use ready regularly updated lists from
the following pages:
https://www.bleib-virenfrei.de/ransomware/
https://fsrm.experiant.ca/api/v1/combined
In the second case, you can download an up-to-date list of file extensions for FSRM directly from the
webserver using Invoke-WebRequest
new-FsrmFileGroup -name "Anti-Ransomware File Groups" -IncludePattern @((Invoke-
WebRequest -Uri "https://fsrm.experiant.ca/api/v1/combined").content | convertfrom-
json | % {$_.filters})

Or use a ready file crypto_extensions.txt. You can save this file to the disk and update the created
FSRM file group with it:
$ext_list = Get-Content .\ransomware_extensions.txt
Set-FsrmFileGroup -Name "Crypto-files" -IncludePattern ($ext_list)

File Screen Templates Configuration

Create a new File Screen Template to determine the actions FSRM has to perform if it detects these
files. To do it, in the FSRM console go to File Screen Management -> File Screen Templates.
Create a new template by selecting Create File Screen Template.
In the Settings tab, specify the template name “Block_crypto_files”, screening type Active
screening (do not allow to save these file types) and select Crypto-Files in the list of file groups.
In the E-mail Message tab, enable sending e-mail notifications and specify text of message subject
and body.
In the Event Log tab, check making an entry to the system log with the note to specify only the
name of the user: [Source Io Owner]
In the Command tab, you can select what to do if one of these file types is detected. We’ll discuss
it a bit later.
Save the changes. One more template will appear in the list.
How to Apply File Screen Template to a Disk or Folder

Now you only have to assign the created template to a disk or network share on your server. In the
FSRM console, create a new rule Create File Screen.

In File screen path field, specify the local disk or the path to the directory you want to protect from
the ransomware, and select the template Block_crypto_files created earlier in the list of templates.
Automatic Block of the User Infected by Ransomware

Now you have to configure the action FSRM will perform if files created by encryption malware are
detected. We’ll use a ready script: Protect your File Server against Ransomware by using
FSRM and Powershell (https://gallery.technet.microsoft.com/scriptcenter/Protect-your-File-
Server-f3722fce). What does this script do? At the attempt of writing a prohibited file type to the
network share, FSRM runs this script, which analyses the event log and prohibits a user to write files
to the shared folder. Thus, the access of the infected user to the network share will be blocked.
 Download this script and unpack it to the root of C:\ directory on your file server.
Copy SubInACL (a tool that allows to change permissions for the network share) in to the same
directory. The following files have to be located in the directory:
 RansomwareBlockSmb.ps1

 StartRansomwareBlockSmb.cmd

 subinacl.exe

Note. I had to change these strings in PS script:

$SubinaclCmd = "C:\subinacl /verbose=1 /share \\127.0.0.1\" + "$SharePart" + " /deny="
+ "$BadUser"

and

if ($Rule -match "Crypto-Files")

In the Command tab of “Block crypto files” template settings, specify that the command prompt
containing the argument StartRansomwareBlockSmb.cmd must be started:

Run this command or script: c:\windows\system32\cmd.exe

Command arguments: /c “c:\StartRansomwareBlockSmb.cmd”
The command has to be run as Local System.
FSRM Protection Test

Let’s test how the FSRM protection against ransomware. To do it, create a file with any extension in
the protected directory and try to change this extension to the prohibited one .locky.
 When trying to save the prohibited file, FSRM will make an entry in the log:

Event ID: 8215

Source: SRMSVC

Based on the data from the log, RansomwareBlockSmb.ps1 script will prohibit the current user from
accessing this directory, by changing share access permissions.

The protection works! In the log located in the root of the disk you can see the directory and the
user account the ransomware has been attempted to be run from.

If you need a higher protection level, you can switch from the black list of files to the white list, and
then you’ll be able to save only allowed file types.

So, we have considered how to automatically block network share access to the users whose
computers are infected by ransomware. Naturally, using FSRM in this way cannot fully protect files
on your servers from this kind of malware, but it is suitable as one of the protection levels. In the
next articles, we’ll consider another variant of protection against encryption ransomware:

 How to Recover User Files from VSS Snapshots After Getting Infected with the Ransomware
 Software Restriction Policies to Prevent Ransomware