How to Avoid AppLocker’s Lockdown Limitations

Windows AppLocker is a feature of Microsoft Windows 7 and Windows Server 2008 R2 that lets administrators control what types of programs are allowed to run on users’ PCs. AppLocker can be centrally managed by configuring Group Policy and has several benefits, including preventing users from installing unauthorized applications and preventing certain kinds of malware from installing in an environment. AppLocker also can help organizations ensure compliance with government and other security requirements.

A lot of IT shops still have some confusion about what AppLocker can and can’t do. The following points briefly explore the limits of AppLocker by describing five things that AppLocker can’t do.

AppLocker Can’t: Deal with 16-Bit Apps

Some agencies are still relying on legacy 16-bit applications. While it’s best to migrate business functions away from 16-bit programs as soon as possible, cost considerations and an “if it ain’t broke, don’t try to fix it” attitude can cause organizations to try and get one more mile out of these legacy programs. 

If you’re using the 32-bit version of Windows 7, then AppLocker can’t be used to prevent installation of specific 16-bit programs. However, because 16-bit programs are actually loaded by ntvdm.exe, AppLocker can be used to block execution of these programs by locking down ntvdm.exe. But then keep in mind that 16-bit programs won’t be able to run on the system, including those needed to run your district. If using the 64-bit version of Windows 7, then obviously this isn’t an issue because 16-bit programs can’t run on this platform.

AppLocker Can’t: Hold the WSF Scripts

AppLocker can be used to prevent certain kinds of scripts from running on users’ PCs. Specifically, it can control the execution of:

• VBScript (.vbs)
• JavaScript (.js)
• Windows PowerShell (.ps1)
• batch scripts (.bat)
• Windows command line scripts (.cmd)

But what about Windows Script File (.wsf)? Unfortunately AppLocker rules can’t be used to control .wsf scripts. It also can’t be used to lock down macros and other Active content embedded within Word documents or Excel spreadsheets.

AppLocker Can’t: Control Arbitrary File Extensions

AppLocker also can’t lock down arbitrary file extensions such as .pl, for Perl scripts. Therefore, an AppLocker rule cannot be created to block execution of Perl scripts, but it can be used to block installation or execution of a specific Perl script interpreter, if needed.

The reason .pl scripts can’t be blocked is because of how AppLocker works. It’s the responsibility of the script interpreter to call in to AppLocker before running a script to make sure any AppLocker policies are enforced. For example, if you create an AppLocker policy to block execution of .vbs scripts, it’s the responsibility of the VBScript interpreter (vbscript.dll) to call in to AppLocker before running a .vbs file to ensure the policy is enforced.  

Similarly, Windows batch files (.bat) run within the context of the Windows Command Host (cmd.exe), and it’s the responsibility of this Command Host to call in to AppLocker before running a batch file to make sure AppLocker rules are enforced. Third-party Perl script interpreters, however, generally aren’t designed to use AppLocker application programming interfaces, so that’s why an AppLocker rule can’t be created to block .pl scripts from running on computers.

AppLocker Can’t: Handcuff Local Admins

AppLocker can’t lock down PCs if the users of those PCs have local administrator privileges on those machines. As Figure 1 illustrates, the Local Group Policy Editor on a Windows 7 machine can be used to configure AppLocker rules at the Local Group Policy Object level. If the computer is domain-joined and Group Policy is applied, the domain-based AppLocker policy and local AppLocker policy are both applied in an additive fashion.

Figure 1: AppLocker also can be configured at the local security policy level on each Windows 7 computer.

The bottom line is, local admins rule their systems, and they can circumvent any security controls instituted at the domain level. Fortunately, with User Account Control, users of Windows 7 computers no longer need to be local admins on their machines in order to perform work-related tasks. So if you haven’t upgraded your PCs from Windows XP to Windows 7, consider making users standard users instead of local admins in the upgraded environment.

AppLocker Can’t: Keep a Handle on All Virtual Machines

Think of Windows 7 as a kind of matryoshka doll — those wooden Russian nesting dolls that open to reveal smaller dolls inside. The allusion here is to Windows Virtual PC, which allows a separate virtual Windows environment to run, such as Windows XP Mode, as a guest on your host machine (a Windows 7 PC). 

But what if AppLocker policies are being applied to a host computer? Will those policies automatically be applied to a guest such as Windows XP Mode, which is running within a host environment? 

The answer is no, they won’t. AppLocker policies applied to a host machine won’t automatically be applied to any virtual machines running on the host. However, if the guest operating system is joined to the same Active Directory domain, then Group Policy, and therefore AppLocker policies, also can be applied to the guest (but may not, depending on how the administrator has configured it).

To learn more about AppLocker, go to the Windows Server TechCenter Library on Microsoft TechNet.