Defending Windows with Application Whitelisting

The SANS Internet Storm Center recently featured a post about the increasingly stubborn fake anti-malware "scareware" that has been remarkably successful at infecting machines and convincing people to purchase the fake software. Among the comments on that post, others who have encountered this kind of malware questioned what protection measures might be effective. Of course, the common ideas of fingerprinting the malware by filename or checksum came up, as did potential ideas for hardening the operating system in small ways. Unfortunately, this malware has already proven that those measures are not enough. This malware changes too fast for fingerprinting, heuristics are unreliable, and improvements in privilege separation in Windows have been ineffective at blocking this malware. Removal of this malware can be a tedious and time-consuming task. I have used Fedora Live media or host systems to perform manual cleaning, then spent hours repairing the damage. If a system is infected, I recommend wiping and reloading the system (as I recommend with any infection on any operating system), but it is much easier to prevent infection in the first place. So, if traditional methods are ineffective, what do you do? An alternative approach that does work against this and most other malware is application whitelisting. In this post, I will run through a quick-start guide to configuring the application whitelisting that is already available in Windows XP and newer releases. There are also more powerful third-party options, and similar capabilities are available for other operating systems. Application whitelisting is not for everyone, but if you manage a large number of computers that need to be defended, it is definitely worth considering.

Application Whitelisting

Application whitelisting allows an administrator to restrict what programs may run on a computer to a trusted list, instead of a normal configuration where all programs are allowed unless explicitly blocked. This is a highly effective way to block malware and unwanted programs from being installed or used on the system. The configuration outlined below is ideal for office setups where most users run as restricted users and only a few people may have administrative access. When set up on a domain, this can dramatically reduce the threat of malware, but it does take a lot of freedom of choice away from the users and increases the administrative burden. Running as an administrator bypasses the protection of this configuration. Windows XP and later have built-in support for application whitelisting. This support is not as robust as that provided by third-party application whitelisting products, but can still be used effectively. Prior to Windows 7, this feature is available as "Software Restriction Policies". In Windows 7 and later, it is available as "AppLocker".

Software Restriction Policies

Software Restriction Policies is a system policy feature that can be configured through local system policies or through Group Policy. To configure Software Restriction Policies as part of Group Policy:

  1. Launch gpedit.msc (on servers, use the Group Policy management tools; to edit local policy instead, use secpol.msc)
  2. Select "Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies"
  3. In the "Actions" menu, choose "New Software Restriction Policies"
  4. With "Software Restriction Policies" selected, double-click "Enforcement" in the right pane
  5. Enforce the policy for "All software files" and "All users except local administrators" and hit "OK"
  6. Double-click on "Designated File Types"
  7. Select the "LNK" extension and hit "Delete" - this allows the Start Menu and Desktop shortcuts to work normally
  8. Hit "OK"
  9. Under "Additional Rules", you can edit the whitelist with paths, hashes, certificates and Internet zones
    By default, the Windows installation and system folders will be unrestricted, as will "Program Files"
  10. Select "Security Levels"
  11. Right-click on "Disallowed" and select "Set as default", then click "Yes" when prompted to confirm the change

With these settings, administrators will continue to be unrestricted, while regular users will only be able to run programs that have been installed under the Windows installation folder (typically "C:\WINDOWS") or under "Program Files". They will be able to launch those programs using shortcuts. Administrators must handle program installation on behalf of the system's users.

Network Shares and Mapped Drives

When adding rules for network shares and mapped drives, you must use the UNC path in the rule. Using the mapped drive letter will not work.

More Information

More information on Software Restriction Policies is available from Microsoft TechNet at:


Over the years, as a dedicated hobbyist in malware removal, none of the malware I have run into has turned into the nightmare as the "fake alert" strains. I try to soak up as much info from every corner and carefully gleen what I can from writings such as yours, which I followed from SANS.
I am curious about one my past has always been essential to turn off System Restore...even when running a linux flavor with an AV or AM program. Since it respawns from segments stored within the hive, would it not be wise to disable System Restore first?

I appreciate the information you shared in your piece on this website.

Oldphart in Kansas

It is definitely a good idea to remove System Restore backups that may be infected. I usually like to move the “System Volume Information” folder from the root of the drive using my Fedora live media and keep it as a backup, since I may want to access the old registry hives as part of the repair procedure. Once the cleanup and repair are completed, I will destroy that backup and create a new restore point.

Thanks! I've always been curious about this, and not for any sort of business reason.

In the near future, I might be a father, and teachingsafe computer practices are important to me. Website and program whitelists with an "Ask dad for permission" setup is what I want, as well as a time limit for computer activities.

Do you have any additional advice for a simple home network?

Unfortunately, Windows does not have full-featured parental control features built in, but there are third-party applications that will give you granular control over children's activities. I know that CyberPatrol will allow granular control, and it enables time limits. It is also a good idea to combine parental control applications with network controls, such as OpenDNS.

Windows Vista has all of these features -- web whitelisting, program whitelisting, parental controls, time controls. This is one of the reasons I chose it for my son's laptop. He doesn't go anywhere that isn't on his lists of OK places.

I understand the viewpoint of those who say "nay" to Vista. But this one use makes it acceptable to me.

BTW, nice article!

FYI, if you implement this in a domain you need to make sure your logon scripts are also whitelisted otherwise they will silently fail. I added %LOGONSERVER%\netlogon to the whitelist and everything worked as expected afterwords.