Block User Folder Executables

One suggestion for blocking the Cryptolocker ransomware virus is to prevent execution of *.exe files in the %AppData% folder and its subfolders. I wanted to make the restriction a little more generic (to cover mutations of this virus and others) and discovered these issues under Windows 7:

• If roaming profiles are in use, the %AppData% environment variable refers only to C:\Users\<User>\AppData\Roaming (or its equivalent in the server’s roaming profile folder). It does not cover AppData\Local or AppData\LocalLow.
• The virus takes advantage of the ability of users to create files and execute programs in AppData. However, this capability extends to the user’s entire profile, including My Documents etc. So really we should block executables from C:\Users\<User> and all subfolders.
• The suggested workaround blocks .exe files, but executables can also be created as .cmd, .vbs, etc. A more generic approach would block execution of any program from the user’s profile.

The threat is serious enough that I’m willing to try blocking execution of all programs in the users’ profiles. Time will tell how much that gets in the way of normal system operation and updates (see “Drawbacks” below).

Block Execution

We want to add a Group Policy Software Restriction Policy that blocks execution of any file (not just .exe’s) in %UserProfile%.  According to KB310791, “Path rules apply to all programs that run from the specified local or network path, or from subfolders that are in the path,” so we only need one policy to cover the whole folder tree. [Update November 19, 2021 KB310791 is no longer available on Microsoft’s site. You might be able to find it on archive.org.]

Create a new Group Policy object and set up a Path Rule like this with the Path name %UserProfile% and Security level of Disallowed.

Make sure you link the GPO to an OU or to your domain. On the workstation, apply it with gpupdate and check it at the with gpresult /r. Then test it on the workstation by copying a “known good” executable to various paths in the user profile and trying to run it. (I tested with a CutePDF installation file.) You should see messages like this:

Note that the message pops up after the Open File – Security Warning dialog(“Do you want to run this file?”) but before any UAC prompts. And there should be a corresponding message in your Application event log:

Log Name:      Application
Source:        Microsoft-Windows-SoftwareRestrictionPolicies
Event ID:      866
Task Category: None
Level:         Warning
Keywords:
Description:
Access to C:\Users\<User>\Documents\CuteWriter.2.8.exe has been restricted by your Administrator by location with policy rule {3807c85d-bb33-41fb-92f0-8973e61eb3bf} placed on path C:\Users\<User>\*\*.*.

Drawbacks

Several legitimate programs use subfolders of %UserProfile% for temporary storage of installers and executables.

• On one computer, for example, under AppData, I see a LogMeIn installer, an Adobe Air installer, and a Dell system detection program.
• The user’s desktop is also in the %UserProfile% folder, so executables on the desktop will be blocked.
• If you run an installer across the network, it may try to create a local copy in the user’s Temp folder, which would also be blocked (not tested).

You’ll need to adapt procedures to put installers somewhere outside the user profile, or create exceptions to the Software Restriction Policy.

Update October 16, 2013:  Exceptions Needed

Well it didn’t take long to discover that the policy above is too broad. Here are some examples of things I could no longer do, and how I’m working around them.

Hint Review the SoftwareRestrictionPolicies events in the Application event log to see exactly what path is being blocked, then create corresponding exceptions.

Program Links

I could not start programs from program icons I had pinned to the taskbar or the Start menu. For example, it blocked:

• C:\Users\<User>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Quicken 2010.lnk
• C:\Users\<User>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\StartMenu\Windows Command Processor.lnk

Adding a New Path Rule to allow Basic User access to %UserProfile%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\*\*.lnk takes care of that. Note the “*” wildcard to cover both the Taskbar and StartMenu folders.

I found I also need to add an exception on %UserProfile%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\*.lnk to cover the classic Quick Launch icons. Update October 22, 2013:  Apparently this one needs Unrestricted access if the shortcut uses a known program to open a file, e.g. the shortcut is to a text file and you expect it to open in Notepad.

Firefox Plugin

Use the Firefox LogMeIn plugin—it blocked C:\Users\<User>\AppData\Roaming\Mozilla\Firefox\Profiles\m4k1ojhr.default\extensions\[email protected]\plugins\x86\LMIGuardian.exe.

An exception on %UserProfile%\AppData\Roaming\Mozilla\Firefox\Profiles\*\extensions\[email protected]\plugins\x86\LMIGuardian.exe seems to take care of that—note the asterisk (*) in the middle of that string to “wildcard” the Firefox profile name.

Software Installation

Install Malware Bytes. Even with the installer stored in a special folder (C:\InstallTemp), it blocked access to C:\Users\<User>\AppData\Local\Temp\is-63KFJ.tmp\mbam-setup-1.75.0.1300.tmp.

This one doesn’t make sense to me, unless the .tmp file is somehow executable. I was able to get around it by allowign Unrestricted access to %UserProfile%\AppData\Local\Temp\*\*.tmp.

Conclusion

This is turning into a whitelisting approach to user programs stored in the user profile, where everything is blocked unless explicitly allowed. That’s not a bad principle in general, but it’s a lot to try to develop piecemeal like this. I’ll see how far we get in the next few days, but I may have to abandon this approach.