QuickPost – restricting system applications using AppLocker

I have been asked about this a few times in the past, so thought I would quickly document it while it is fresh in my memory.

AppLocker is Microsoft’s GPO-based technology that deals with application execution restriction. It superseded the old Software Restriction Policies and is itself slated to be replaced by Microsoft Defender Application Control, but as of today, it is still the recommended application management solution, particularly within multi-user environments. Rather than discuss the ins and outs of each of these technology stacks (or even third-party tools that can extend these capabilities, such as Ivanti Application Control or Citrix WEM), I will simply link you to this article for further reading (which was actually written by me, despite what the author details may have you think!)

A common requirement for any application management tool is to restrict system applications. Think anything in the Windows system folders – the command prompt, Registry editor, FTP, subst, etc., etc. etc. There are GPOs that can control some of these, but if AppLocker is your approach then it makes sense to leverage that. The commonest use case I see is that people want administrators to be able to run anything, but wish to restrict the use of certain system executables to “whitelist” groups. Let’s take an example and use FTP – the FTP executable is only to be used by Administrators, and any users added to an “FTP Allow” Active Directory group. Everyone else is blocked by default.

Obviously it goes without saying that you’d need to turn on AppLocker (by enabling the App Identity service and configuring it for “Enforced” – both of which are covered in the article linked above) and create your required AD group ahead of time.

The requirement sounds easy enough, but AppLocker can be a little bit tricky to get right with these parameters. Let’s give you some examples of incorrect ways that people attack it.

Default Deny

Unseasoned AppLocker users often go for this approach, which can burn quite badly. If you’re aware that AppLocker supports exceptions, you may have this thought. “Well, why don’t I just block everything in the Windows folder for Everyone, and then put an exception in for my ‘Allow’ group?”

First of all, though, the AppLocker concept of an exception might not be what you think it is. You can’t set up an exception for a specific user or group, you simply set up an exception that isn’t caught as part of the rule. So the only thing you can do is set up an exception for the target executable – it can’t be associated with a user or group.

Secondly, Deny trumps all. So even if you’re allowing administrators to run everything with a wildcard, the Deny for Everyone will still override it.

If you set it up (which I wouldn’t advise), the GPO you configured would probably look something like this

The exception configured would simply be a path or hash rule that specifies the FTP executable, as shown below

If you do set this up and also link it to an OU, I hope you have a snapshot. Because this will actually stop everyone from being able to run anything from the %WINDIR% folder apart from the FTP executable. And if you think you can just disable the policy and run a Group Policy update, think again…

…because even gpupdate will be blocked. if you haven’t taken a snapshot – get rebuilding.

Group blacklisting

Now of course, when confronted with this, a lot of users circle back and end up taking the “group blacklist” approach. That is, you allow the Windows folder executables to run but simply stop them from running for certain users or groups, as shown below.

This works, and has the added bonus of not breaking your machine so badly it needs to be restored from a snapshot. But this doesn’t really fulfil our requirements. Why not? Well, it relies on each user who is being restricted from running the target executable being added to a specific AD group, so it isn’t the desired state, which is that users are only allowed to run the sensitive app if they’re specifically configured to. Using the “blacklist” approach means that all users who aren’t in the group can run the app, so any user that slips through the net or isn’t provisioned properly escapes the rule.

The solution

There is a way to do this, but it feels a bit back-to-front. The trick is, configure an Allow rule for the Windows folder for Everyone, but put an exception in for your target executable (so in this case, c:\windows\system32\ftp.exe). Because AppLocker blocks everything except that which is specifically allowed, the exception actually creates a targeted block. You can then create an Allow rule for your AD group, which doesn’t interfere with the exception – because an exception isn’t an explicit Deny rule. Obviously, you also need the Default Rule as well that allows everything for Administrators.

In case you’re confused, here’s the GPO with the required settings added

The exception is exactly the same as it was previously, except applied to an Allow rule rather than a Deny

This works perfectly – any user not in the group can’t run the target executable, and any user who is added to the group can run it without issue, along with Administrators who can run anything.

Summary

AppLocker is a somewhat convoluted beast, but it has a lot of good features to help enhance your security posture. Until MDAC becomes fit for multi-user systems, it’s really the only choice you have for app management unless you are adopting third-party tools. This guide should help you with dealing with what looks like a straightforward use case but which becomes slightly complicated if you’re unfamiliar with the tech.

A few helpful notes when dealing with AppLocker. Firstly, familiarize yourself with the event log under Applications and Services | Microsoft | Windows | AppLocker. Secondly, if you see any inconsistency and weirdness when applying rules, a reboot will normally sort it out. Finally, if your Windows Start Menu stops functioning after applying AppLocker rules, you may need to configure the “Default Rules” for Packaged Apps – even if you haven’t configured Packaged Apps to “Enforced”! This looks like a bug.

More content due later this week – please keep coming back and supporting this site!