How to Block Executables in Windows XP Using SRP

Software Restriction Policies (SRP) were introduced in Windows XP and Windows Server 2003 as a built-in Group Policy feature designed to regulate software execution. By allowing system administrators to identify and restrict unauthorized programs, SRP provided a native, policy-driven security layer to block malicious executables, prevent unauthorized software installations, and enforce strict execution environments across standalone machines and Active Directory domains.

Core Architecture and Default Security Levels

Administrators configured SRP via the Local Security Policy console (secpol.msc) or domain-wide Group Policy (gpedit.msc) under Computer Configuration (or User Configuration) > Windows Settings > Security Settings > Software Restriction Policies.

SRP operated on two foundational security levels:

  • Unrestricted: Allowed all software to run by default unless an explicit rule blocked it (a blacklist approach).
  • Disallowed: Blocked all software from running by default unless an explicit rule permitted it (a whitelist approach).

For strict environments, administrators set the default security level to Disallowed, preventing all executables from launching unless specifically permitted. For lighter environments, they kept the default as Unrestricted and created targeted rules to block specific executables.

The Four Rule Types for Blocking Files

To target executables, administrators created four specific rule types within the Additional Rules node of SRP:

  1. Hash Rules: An administrator could generate a cryptographic fingerprint (MD5 or SHA-1) of an executable. If the binary matched the hash, Windows XP blocked it. This rule remained effective even if a user renamed or moved the file, though updating the executable required generating a new hash rule.
  2. Path Rules: Administrators specified a file system path, folder, or wildcard pattern to block. For example, blocking C:\Users\*\Downloads\*.exe or specific program paths like C:\Games\game.exe prevented files matching those locations from running. Path rules also supported registry paths and environment variables, such as %temp%\*.exe, to curb malware executing from temporary folders.
  3. Certificate Rules: By utilizing digital signatures, administrators could block or allow executables signed with specific software publisher certificates. If an executable bore a revoked or untrusted commercial certificate, SRP prevented its execution.
  4. Internet Zone Rules: Windows XP allowed policies based on the Internet Explorer security zone from which a file was downloaded (such as the Restricted Sites or Internet zones), though this applied primarily to packages like Windows Installer (.msi) files.

Enforcement and Designated File Types

To ensure rules functioned effectively without breaking the operating system, administrators adjusted enforcement settings:

  • Enforcement Options: Administrators could choose whether SRP applied to all software files or excluded dynamic-link libraries (DLLs) to reduce system performance overhead. They could also exclude local administrators, ensuring administrative tasks were not impeded by the restrictions.
  • Designated File Types: SRP maintained a centralized list of file extensions considered executable. While standard binaries like .exe and .com were included by default, administrators could add or remove script extensions, such as .bat, .cmd, .vbs, .js, and .scr, ensuring users could not bypass executable blocks using secondary scripting engines.

When a user attempted to launch an executable restricted by any of these mechanisms, the Windows XP operating system intercepted the execution request, halted the process creation, and displayed an access-denied error indicating that the application was blocked by group policy.