Stop mal(icious soft)ware with Software Restriction Policies Valid HTML 4.01 Transitional Valid CSS

Me, myself & I

Stop malware with Software Restriction Policies

[Screenshot from Windows Vista of dialog box for blocked program] [Screenshot from Windows Vista of message from 'Command Prompt' for blocked program]


The scripts NT6_SAFER.INF (for Windows Vista and later) and XP_SAFER.INF (for Windows XP and Windows Server 2003) configure Software Restriction Policies alias SAFER with a proven and well-tested ruleset on all (including Embedded, Home and Starter) editions of Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2 and Windows 10.

The SAFER ruleset implements for Windows' NTFS file system the equivalent of DEP alias W^X for virtual memory: execution is denied in all directories where unprivileged users are allowed to write (i.e. create, modify or replace) files, and allowed only in directories where unprivileged users are denied to write (i.e. create, modify or replace) files.
More precise: for users without administrative privileges execution is allowed only in the directory %SystemRoot%\ (typically C:\Windows\) and its subdirectories, in the directory "%ProgramFiles%\" (typically "C:\Program Files\") and its subdirectories, on systems with AMD64 alias x64 processor architecture also in the directory "%ProgramFiles(x86)%\" (typically "C:\Program Files (x86)\") and its subdirectories; execution in all other directories and their subdirectories is denied.

The exemption of privileged users from Software Restriction Policies leaves no loophole: privileged users can write (i.e. create, modify or replace) files in the directories where execution is allowed, can disable or remove Software Restriction Policies and can thus execute any file.
If you want to restrict Administrators too use the scripts NT6_SUPER.INF (for all editions of Windows Vista and later) and XP_SUPER.INF (for all editions of Windows XP and Windows Server 2003).


Users who are subject to Software Restriction Policies

Note: user accounts created during Windows setup are but privileged user accounts and therefore exempt from Software Restriction Policies configured with the scripts NT6_SAFER.INF and XP_SAFER.INF.
Change their account type to Standard User (since Windows Vista) resp. Limited User (Windows XP and Windows Server 2003) if you use them for your routine work!

Change a user's account type:

When you set up Windows, you were required to create a user account. This account is an administrator account that allows you to set up your computer and install any programs that you'd like to use. Once you finish setting up your computer, we recommend that you create a standard account and use it for your everyday computing. If you create new user accounts, you should also make them standard accounts. Using standard accounts will help keep your computer more secure.

Caveat: the dumb User Accounts control panel applet denies to demote the last or only privileged user account even if the builtin (real) Administrator account has been activated!
Use the real User Accounts control panel applet instead: run the command line
%SystemRoot%\System32\Control.Exe UserPasswords2 alias
%SystemRoot%\System32\RunDll32.Exe %SystemRoot%\System32\NetPlWiz.Dll,UsersRunDll to start it.

Note: the (predefined) privileged user accounts NT AUTHORITY\SYSTEM, NT AUTHORITY\LocalService and NT AUTHORITY\NetworkService are always exempt from Software Restriction Policies!

Reliability and safety

Unlike unreliable and unsafe antivirus programs which almost always fail to detect new or unknown malware (trojan horses, viruses, worms, …), known as false negative, or misdetect legitimate clean software as malware, known as false positive, this SAFER ruleset stops all kinds of known as well as new or unknown malware and all other unwanted or unauthorized software that uses executable files to infest Windows® installations while allowing all legitimate software to run!

[Screenshot of antivirus program outsmarted by malware via SAFER rules] The screenshot of a message box on the right shows an antivirus program that has been disabled by malware (ab)using Software Restriction Policies, i.e. this antivirus program was even unable to protect itself!

Trend Micro: Antivirus industry lied for 20 years:

In the antivirus business, we have been lying to customers for 20 years. People thought that virus protection protected them, but we can never block all viruses. Antivirus refresh used to be every 24 hours. People would usually get infected in that time and the industry would clean them up with a new pattern file.
In the last 20 years, we have been misrepresenting ourselves. No-one is able to detect five and a half million viruses. Nowadays there are no mass virus outbreaks; [malware] is targeted. But, if there are no virus samples submitted, there's no way to detect them.
Securing That XP Desktop, Part 1:
The best kind of desktop is a secure desktop. As you all know, hackers are a tricky bunch. You have to go beyond Symantec Antivirus and actually lock Windows down if you want to make sure your computing environment is actually secure.
Cyber Resilience And Spear Phishing:
For example, application whitelisting on end-user devices stops advanced and zero day attacks from infecting the system by preventing unauthorized code execution, protecting memory, and blocking attempts to exploit a whitelisted app before it gains a foothold and impacts the business. Application whitelisting is listed as a Quick Win in the SANS Critical Security Controls list and the Australian Government Top 4 Mitigating Controls cybersecurity guidance. According to Australian Signals Directorate Deputy Director Steve Day, attackers have not stolen any sensitive data from government networks because of their adoption of the Top 4 mitigating controls.

Vulnerability and availability

Also unlike antivirus programs which often are vulnerable themself Software Restriction Policies introduce no additional code which allows to leverage successful attacks in the first place!

Analysis and Exploitation of an ESET Vulnerability:

Do we understand the risk vs. benefit trade-offs of security software?
Tavis Ormandy, June 2015
Attackers can cause I/O via Web Browsers, Email, IM, file sharing, network storage, USB, or hundreds of other vectors. Whenever a message, file, image or other data is received, it's likely some untrusted data passes through the disk. Because it's so easy for attackers to trigger emulation of untrusted code, it's critically important that the emulator is robust and isolated.

Unfortunately, analysis of ESET emulation reveals that is not the case and it can be trivially compromised.

Kaspersky: Mo Unpackers, Mo Problems:
Because antivirus products typically intercept filesystem and network traffic, simply visiting a website or receiving an email is sufficient for exploitation. It is not necessary to open or read the email, as the filesystem I/O from receiving the email is sufficient to trigger the exploitable condition.
Product Design Flaws

I've also reported some major design flaws in various other components of Kaspersky Antivirus and Kaspersky Internet Security. The patches for the remote network attacks I had planned to discuss here were delayed, and so I'll talk about them in a second post on this topic once the fixes are live.

Security Software Considered Harmful?

We have strong evidence that an active black market trade in antivirus exploits exists. Research shows that it's an easily accessible attack surface that dramatically increases exposure to targeted attacks.

Some, but not all (now fixed) vulnerabilities in Microsoft's anti-malware products for consumers are documented in the MSKB articles 932135, 952044, 2823482, 2847927, and 3074162, the Security Advisories 2491888, 2846338, 2974294 and 3074162, plus the Security Bulletins MS07-010, MS08-029, MS13-058 and MS13-034.

The additional updates to harden the anti-malware products for consumers are documented in the MSKB articles 2781197, 2856373, 2883200, 2894853, 2939153, 2976536 and 3025417.


Although Software Restriction Policies work together with UAC it's safer to Windows is only safe when you use a Standard User account:
One of the common misconceptions about UAC and about Same-desktop Elevation in particular is that it prevents malware from being installed or from gaining administrative rights. First, malware can be written not to require administrative rights, and malware can be written to write just to areas in the user's profile. More important, Same-desktop Elevation in UAC is not a security boundary and can be hijacked by unprivileged software that runs on the same desktop. Same-desktop Elevation should be considered a convenience feature, and from a security perspective, "Protected Administrator" should be considered the equivalent of "Administrator." By contrast, using Fast User Switching to log on to a different session by using an administrator account involves a security boundary between the administrator account and the standard user session.
Update on UAC:
One important thing to know is that UAC is not a security boundary. UAC helps people be more secure, […]
The most effective way to secure a system against malware is to run with standard user privileges.
Inside Windows 7 User Account Control:
[…] the primary purpose of elevation is not security, though, it's convenience: […]
The Long-Term Impact of User Account Control:
[…] this is also where we run into some of the limitations of UAC. Remember, there is no effective isolation; there is no security boundary that isolates processes on the same desktop.
Inside Windows Vista User Account Control:
It's important to be aware that UAC elevations are conveniences and not security boundaries. A security boundary requires that security policy dictates what can pass through the boundary. User accounts are an example of a security boundary in Windows because one user can't access the data belonging to another user without having that user's permission.

[Screenshot of default 'User Account Control Settings' from Windows 7] Note: with default settings UAC performs since Windows 7 silent (automatic) elevation for programs that

These programs can but trivially be (ab)used by protected administrators to write arbitrary files to write-protected and therefore "unrestricted" locations like %SystemRoot%\ and its subdirectories and thus bypass NTFS ACLs and Software Restriction Policies!

To prevent this bypass either set UAC to its highest level "Always notify" or (better and safer) use a Standard User account!

Google's Project Zero reported several bugs which allow to bypass UAC that Microsoft wont fix: Issue 156 and Issue 220.

Also note that Windows Explorer in combination with UAC shows surprising behaviour (documented in the MSKB article 950934) which generally impairs security and safety!
To detect directories with additional NTFS ACL entries created by Windows Explorer as well as writable files eventually created in these directories from your user account start a Command Prompt, run the following command lines and inspect their output, then remove the additional NTFS ACL entries:

            "%SystemRoot%\System32\ICACLs.Exe" "%SystemRoot%\*" /FindSID "%USERNAME%" /C /T
            "%SystemRoot%\System32\ICACLs.Exe" "%ProgramFiles%\*" /FindSID "%USERNAME%" /C /T
            "%SystemRoot%\System32\ICACLs.Exe" "%ProgramFiles(x86)%\*" /FindSID "%USERNAME%" /C /T
            "%SystemRoot%\System32\ICACLs.Exe" "%ProgramData%\*" /FindSID "%USERNAME%" /C /T

Limitations and dependencies


[Screenshot of 'Designated File Types Properties' from Windows Vista] Subject to Software Restriction Policies are files that match the definition of "executable": Except on Home and Starter editions of Windows the list of file extensions can be viewed and modified via the Local Security Policy snapin of the Microsoft Management Console.

[Screenshot of 'Local Security Policy' snapin from Windows Vista] The Local Security Policy snapin reads the additional SAFER rules only from the file "%SystemRoot%\System32\GroupPolicy\Machine\Registry.Pol", not from the registry: additional SAFER rules written directly resp. only to the registry therefore don't show in the Local Security Policy snapin!

If this file exists modifications of the SAFER settings or rules written directly resp. only to the registry will (periodically) be overwritten with the SAFER settings and rules from the file!

If this file contains neither SAFER settings nor rules (or does not exist) the Local Security Policy snapin (creates it and) writes the default SAFER settings and rules to the file and to the registry, thereby overwriting existing SAFER settings and rules in the registry!
To avoid this either run the program SRP2LGPO.EXE (available upon request) once to export all SAFER settings and rules from the registry to the file %SystemRoot%\System32\GroupPolicy\Machine\Registry.Pol or download the ("empty") REGISTRY.POL that contains the (missing) setting

which enables all SAFER levels and save it as "%SystemRoot%\System32\GroupPolicy\Machine\Registry.Pol".


On Windows 7 and Windows Server 2008 R2 the optional update 2532445 must be installed to prevent circumvention of Software Restriction Policies!

On Windows Vista and Windows Server 2008 the optional update 969972 or one of the optional updates 2257986, 2414106 resp. 2812950 which contain a newer version of the file replaced by 969972 should be installed!

On Windows Server 2003 the optional update 973825 should be installed!

On systems with AMD64 alias x64 processor architecture running Windows XP or Windows Server 2003 the optional update 942589 must be installed to enable the special directory pathname %SystemRoot%\SysNative!

Background information

More than 20 years ago Microsoft introduced User Profiles and the NTFS file system supporting fine-grained ACLs to separate user data (with emphasis on "data") from each other as well as from the operating system and to control access to file system objects.

More than 13 years ago Microsoft introduced Software Restriction Policies alias SAFER and published the MSDN articles
Using Software Restriction Policies to Protect Against Unauthorized Software,
How Software Restriction Policies Work and
Using Software Restriction Policies to Protect Against Unauthorized Software.

JFTR: ! ? 1 From ...:

At least 85% of the targeted cyber intrusions that the Australian Signals Directorate (ASD) responds to could be prevented by following the Top 4 mitigation strategies listed in our Strategies to Mitigate Targeted Cyber Intrusions:
#1 use application whitelisting to help prevent malicious software and unapproved programs from running

More than 10 years ago Microsoft introduced DEP alias W^X and enabled it by default.


But even today all (data) files created in the user profiles, the %PUBLIC%\, %ProgramData%\ and almost all other "data" directories too are still "executable": although not needed the (inheritable) NTFS ACLs of all these directories include "Execution" permission!
And Software Restriction Policies are still not enabled by default!

The immediate benefit of an NTFS ACL without "Execution" permission or the default SAFER ruleset is: no (unintended) execution of files like invoice.pdf.exe etc. stored in "data" directories, so spreading malware to Windows systems becomes utterly useless.

If you want to try "DEP in the NTFS filesystem" for yourself:

Cf. m for instructions, or use the scripts XP_SAFER.INF for Windows XP (including embedded editions) and Windows Server 2003 resp. NT6_SAFER.INF for Windows Vista, Windows 7 and Windows 8 as well as Windows Server 2008 and Windows Server 2008 R2 Then open the SPAM folder of your mail client, get one of the many invoice.pdf.exe your anti-virus fails to detect and "Open" it.

Implementation and build details

The SAFER ruleset installed with the scripts NT6_SAFER.INF and XP_SAFER.INF uses a belt & suspenders approach: although the Default rule denies execution additional Deny rules are defined for almost all paths and directories except %SystemRoot%\, "%ProgramFiles%\" and "%ProgramFiles(x86)%\", i.e. all local drives, all network paths, "%ProgramData%\", "%PUBLIC%\", "%ALLUSERSPROFILE%\", "%USERPROFILE%\", "%TEMP%\" etc.

SRP2LGPO.EXE, the program to export SAFER settings and rules from the registry to the file %SystemRoot%\System32\GroupPolicy\Machine\Registry.Pol, is a pure Win32 binary, written in ANSI C without the use of the MSVCRT libraries, built with the platform SDK for Windows Server 2003 R2 for use on Windows 2000 and newer versions of Windows.

SRP2LGPO.EXE is available for the I386 alias x86, AMD64 alias x64 and IA64 processor architectures of Microsoft Windows NT.

Code authenticity and integrity

SAFER.CAB and SRP2LGPO.EXE are digitally signed using an X.509 certificate issued by WEB.DE.
Download and install the root and CA certificates of WEB.DE to validate the digital signature.


The installation scripts NT6_SAFER.INF and XP_SAFER.INF are packaged in the digitally signed (compressed) cabinet file SAFER.CAB.


On systems with AMD64 alias x64 processor architecture the installation must be run in the native execution environment!
The installation requires administrative privileges.

Automatic online installation

If this web page is visited with Internet Explorer it will prompt to install (the contents of) the package using Internet Component Download.
On systems with AMD64 alias x64 processor architecture Internet Explorer (x64) must be used!

Manual offline installation

Download the package SAFER.CAB and verify its digital signature, then extract its contents, right-click the extracted installation script NT6_SAFER.INF … resp. XP_SAFER.INF to display its context menu and click "Install" to run the installation.

License terms

• Copyright © 1995-2015 • Stefan Kanthak • <­skanthak­@­arcor­.­de­>