by Roy Tobin, Webroot Threat Researcher.
In this tutorial we are going to explore some additional steps to help secure your environment. First thing to mention is that the following guide is only a rough guide and will need to be catered for each environment.
This guide comes with a health warning, this may cause certain programs to not install/function
Some tips before we start:
What we are going to do is to create some Windows Policies to block certain paths and file extensions from running.
Having Windows running with the latest updates is something that should be given, a number of infections are blocked by Windows if you have the latest updates. Having those disabled is not a good idea.
Java generally gets the most coverage when it comes to exploited software but it applies to nearly all commonly used plugins. Generally speaking if you do not intend on using certain plugins it’s better to not even have them installed (less exploits).
If you do use them make sure they are up to date, i.e. do not disable the run keys for the Java updaters etc.
Example of a Java updater service:
Having users running as local admins is generally not a good idea, it can’t always be avoided but a limiter user cant install a rootkit or access most of the registry. If possible set users to be limited users. Limited the users access to network shares and other PC’s is also a good idea
In this document we are going to talk a lot about paths and file types so a brief introduction is useful. Malware generally speaking drops in a few common paths, once there it is free to move around about the PC (and network paths)
Common paths for malware to drop:
To go to the paths with the % in them just type the full phrase into a run window or windows start search i.e. %temp% will go directly to C:\Users\admin\AppData\Local\Temp
Once the infection is on the PC and is actively running (important distinction to make). It can move itself to make itself more difficult to find or to move to location that can help it spread. Common paths encountered. More sophisticated malware can spread to network paths. It can use a registry entry to autostart or another method (scheduled task, service etc)
Malware will often use well-known names or Windows system names to try to throw off the user. For example Winlogon.exe is a core component of Windows and is located at:
c:\windows\system32\winlogon.exe and is around 450 kb in size
If we see a WinLogon.exe file in the user’s temp folder that is twice the size it should be a red flag and the file should be looked at! Don’t worry that’s Webroot job!
This is all taken care by Webroot but I hope the above gives an idea of what we are trying to do with this document. In the following sections we are going to use some policies to restrict access to certain file types and paths. The more restrictive we are the better however it can lead to certain programs not functioning.
It’s advisable to have a second browser installed for a number of reasons:
There are dozens of browsers available to us but Chrome and Firefox and the two most popular browsers on the market at the moment. Another very useful ability of Chrome and Firefox is the use of plugins. Some of these can be quite helpful and can stop issues entirely.
Useful plugin types:
The ad-blocker is one that is often asked about, while many websites need advertisements to stay online we have seen recently more and more very popular websites (i.e millions of visitors a year) infecting customers due to 3rd party hosted adverts on their websites. The FBI infections are still commonly using adverts to either scare users or get them to download an infection.These plugins can be installed and left without any user input, very useful for less technical users.
Script blockers stop Java scripts running on websites unless you specifically ask for. These require a bit more technical knowledge on the user’s behalf and thus aren’t recommended for the less technical user. Many websites will use Flash, Java plugins and if a user isn’t able to figure this out it can lead to support tickets/calls.
Web filters are very commonly installed by AV products and can act as a first line defence against threats. They can scan websites before the user gets a chance to see them, thus stopping threats from getting a chance to be executed.
Below is the Webroot Filtering Extension installed in Chrome. This checks website reputations and will alert the user if they are visiting a site that is unsafe:
While Autorun is a useful feature it can be used by malware to spread around a corporate environment. With the growth of USB sticks there has malware is increasingly using Autoruns as a method to automatically run (and spread). Commonly used by VBS malware and worms to spread its best to disable it as a policy. We can disable Autorun easily enough by using the Local Group Policy Editor:
Note that this doesn’t affect the functionality of USB drives
Policies are a powerful tool that you can use for a multitude of reasons. They are commonly used to stop users from opening or installing certain software however you can get quite creative with them.
In the cases below I am using local policies but the same principle applies to network group polices.This guide is only a brief introduction but if you want more information I would advise looking at the link from Microsoft show below:
Policies can be setup in groups so you can have more/less strict policies for certain groups. This can be useful if you have a group of users that need more access or are more tech savvy. When creating new policies it is vital that they are tested on a non-mission critical PC’s.
Examples of useful policies:
Realistically the following files types shouldn’t be run in the following directories:
A policy on the above would be a reasonably safe. Crypto ransomware are currently using the .SCR file format at the moment. The .SCR file format is a portable executable which is sometimes forgotten.
You could go another step and create a policy blocking PE file formats from common paths where droppers are located
You can open the Local Group Policy Editor by running the following process.
Please note that we advise that you test any policies on a test PC that is not mission critical!
To open the Local Group Policy Editor from the command line
To open the Local Group Policy Editor as an MMC snap-in
Testing out a policy:
To create a policy you need to expand out the tree to get to the following:
Computer Configuration -> Windows Settings -> Security Settings -> Software Restriction Policies
First thing is to modify a setting in the Enforcement. Change it from “All software files except libraries” to “All Software Files”
Creating a Policy:
To create a policy right click on the right hand side of the Policy window and select “New Path Rule”
Then we get a small window in which we can use to create our rules. In this window we can browser to specific folders or we can use common Windows wildcard paths. In the case below I have created a policy that will block an executable files running from the following path:
This is the Windows temp folder and it is used by a number of programs and installers and thus will probably cause some issues but it’s useful to demonstrate what we can do. We can get quite creative with the paths and in the screenshot below.
Note that in the case above the user can’t run anything from their desktop!
Please note that a number of legitimate programs (and updaters) run from the user’s appdata.
In the case below I have created a few policies to block executables from running from the following paths:
In the case below I have attempted to run an executable that is located on the local admins desktop. As you can see Windows pop-ups an alert and the program doesn’t run. If I move the file to another path that doesn’t have a restricted policy (in this case c:\) the program will open without any issues.
As mentioned earlier a number of programs will stop working if you apply policies to the local user’s appdata and temp folder. For example in the case below the popular browser Chrome will no longer run on the PC.
This is due to the policy of blocking all executables from the users profile folder. This is quite a strong policy but is quite broad reaching! In this case after some testing I have disabled that policy and started creating small more focused path + file polices
Mozilla Firefox will still open as its installs to the C:\Program Files\Mozilla\ location. Internet Explorer will also still run as it’s located in the program files path.
We can create an individual path+file policy rule as shown below.
On Windows XP and above Windows will create local copies of files using the VSS copy service. It is located in the following path:
In the earlier versions of CryptoLocker it was noticed that it didn’t stop and remove the VSS copies and thus data could be recovered. One of the most popular tools for this is Shadow Explorer although you can use the Windows function to roll the data back. It’s worth noting that VSS copies are only for the local drive (normally C:\).
The VSS service is realistically only useful in Vista and above and it’s a last ditch option for encrypted files.
Please note the VSS is not a substitute for backup!
We can lock access to the service and thus stop Cryptolocker from trying to erase file backups. We just create a policy like have earlier but point to the VSSAdmin executable. Any attempt to access/stop the service will result in a block.
If a program tries to access the VSSadmin service it will either be blocked or it won’t open.
VBS scripts are used by malware authors either to cause disruption in an environment or to run a process that will download more advanced malware. The ILOVEYOU VBS malware caused a huge amount of damage back in the early 2000’s. Nowadays most VBS scripts causing more irritation like hiding folders, moving files etc.
We can disable them completely by disabling the Windows Script Host engine which is what .VBS files use to run.
Warning if your company uses any login scripts they won’t be able to run
Note you can also use a policy to also disable the use of VBS files (see the MS link posted earlier)
The following two registry entries are the two entries that are used to block the Windows Script Hosting Engine Executable from running (Wcscript.exe)
HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings\Enabled
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\Enabled
When a VBS file attempts to run with the above registry key enabled any VBS script that attempts to run will see the following error message:
This is a simple method to block these, the following two registry keys are located below if you wish to use them. You can use the policy editor to create more custom versions if you do need to run scripts: