What are the pros/cons of blocking a program from running in %appdata%, %temp%, etc.?

Question

While researching ways to prevent CryptoLocker, I saw a forum post that advised using Group Policy Objects (GPO) and/or antivirus software to block run access in the following locations:

1. %appdata%
2. %localappdata%
3. %temp%
4. %UserProfile%
5. Compressed archives

Obviously, anything written in a forum should be taken with caution. I do see advantages to do doing this, though, primarily because malware likes to execute out of these locations. Of course, this could impact legitimate programs as well.

What are the drawbacks to blocking run access to these locations?

What are the advantages?

Answer 1

The reason malware likes to execute from these locations is because legitimate software likes to execute from these locations. They're areas that the user's account should expect to have some level of access to.

Based on a quick grep of my own system and a random end-user account on our network:

%appdata%

Right now, I've got Dropbox, the installer for Adobe AIR and a few Microsoft Office odds and ends in this folder.

%localappdata%

join.me and SkyDrive appear to live here, or at least to have driven through recently.

%temp%

Lots of programs, legitimate or otherwise, will want to execute from this folder. Installers typically unpack themselves to a subfolder of this when you run setup.exe on a compressed installer archive.

%UserProfile%

It will typically be safe unless the user has particular requirements, though note that at least some of the above folders could be subsets of this on a network with roaming profiles.

Compressed archives

Don't run code directly, instead typically extract to %temp% and run from there.

As to whether or not you should block these areas, it depends what your users typically are doing. If all they need to do is edit Office documents, play Minesweeper during lunch, and maybe access a LOB app via a browser, etc. then you might not have too much trouble blocking executables in at least some of these folders.

Clearly the same approach won't work for people with less well-defined workloads.

Answer 2

Pros:

Malware attempting to execute from those locations will be unable to run.

Cons:

Legitimate programs attempting to execute from those locations will be unable to run.

---

As to what legitimate programs you have in your environment that need execution rights in those directories, only you can say, but I see RobM just posted an answer with a high-level overview. Blocking execution from these directories will cause you problems, so you need to do some testing first to determine what problems you'll have, and how you need to workaround them.

Answer 3

Those recommendations would work perfectly in my environment. NO users are allowed to install software, and NONE of the approved software executes from the mentioned locations. The workstations have the approved software pre-installed in the workstation image and updated by script.

Dropbox, Chrome, Skype, etc. can all be re-located during install to a more acceptable "Program Files" installation location.

As long as you have an allowance for Administrator or Domain Admins (and maybe a specific "Installer" account) to be able to run updates and add approved software, I'd agree with the recommendations.

Answer 4

I assume you want to deny the execute right not only to these folders but to the whole tree starting from them (otherwise, there is no point in doing what you want to do).

The - obvious - consequence will be that any executable located in these will fail to run.

Unfortunately, this will include a rather large number of legitimate applications.

%localappdata% and %appdata% are the most problematic ones: Dropbox, Chrome, SkyDrive, for instance, will fail to work. Most automatic uploaders and many installers will also fail to work.

%UserProfile% is even worse since it includes both %localappdata% and %appdata% as well as a number of other folders.

In short: if you prevent applications from running from these folders, your system might get pretty much unusable.

%temp% is different. While you might occasionally have legitimate programs running from there, it's quite infrequent and usually easy to work around. Unfortunately, %temp% expands to different folders depending on the user context you're expanding it from: it might end up in %localappdata%\temp (in the context of a user) or %SystemRoot%\temp (in the context of the system) so you will have to secure each location individually.

%temp% is also a good candidate because that's where most mail programs will save attachments before opening them: that will help in many cases of mail-based maleware.

One good trick is to change the premissions on the C:\Users\Default\AppData\Local\temp and C:\Users\DefaultAppPool\AppData\Local\Temp folders when you setup the system (and, of course, %SystemRoot%\temp). Windows will copy these folders when it creates new profiles and so new users will have a secured environment.

You might want to add %UserProfile%\Downloads to your list: this is where most browsers will same the user's downloaded files and denying execution from there will also increase security.

Answer 5

For the last three months I am running with a similar setup on my main workstation. My primary user has either execute permissions to a directory or write permissions but never both.

This means no new executables can be introduce by this account. That's the pro, I can execute programs already on the system or installed by other accounts, but I can not download any new program and run it, this means any malware that comes in through a browser or other means has a much harder time to run on my system, simple DLL injection also doesn't work.

As others have pointed out, the main problem is that some legitimate software uses the locations I blocked. In my case:

• Google Chrome - I installed the msi version
• any Portable Apps application - which I now run under a different user
• Process Explorer - I use the extracted 64bit version directly
• dism.exe - run as admin, which I have to do most of the time anyways.

So basically I'm using three accounts, one I'm logged in with, another normal user account to execute certain validated programs as and a admin account to install new software for the other two.

I like the fact that it forces me to test any newly downloaded software in a VM.

I start most of my programs via PowerShell and having three shells, one for each account is fine for me. Whether this works for you really depends on how much software you use that has to be treated differently.

On a developer machine this doesn't really work because I have to compile my code and then execute it. So I made an exception for my code directory on a data drive, malware could scan all drives and find this.

I'm using NTFS ACLs rather then policies to enforce this. This prevents any programs to run, but I can still create a PowerShell script and then run that and it can do enough damage.

So while it makes things harder it is not 100% secure but would still protect you from most current malware.

Answer 6

You can look in those folders, but most are data, exactly what the folder is named for. For example you will see chrome, but the actual executable is in the c:\programs folder.

I block all executable from running anywhere on the computer except the program folders. Only allowed temporarily when I need to install something, and I've never had any problems.

Answer 7

I'd recommend a quick search of the directories to see what you have in each of them currently. If nothing is executing from them now follow the guidance in the forum. Should you come across an issue in the future simply assess your options then. Most of these shouldn't have executables in them anyway.