AppLocker can be used on Windows machines to control the execution of executables, dlls, scripts, and more. Here, we very often speak about whitelisting rules (specifically defining what can be executed) and blacklisting rules (preventing only specific known executions). AppLocker itself provides Allow and Deny rules, which fit perfectly with the previously described whitelisting and blacklisting rules.

To now force the whitelisting of our scripts, the following possibilities are available:

We create a simple script rule, configured in Allow-Mode, and are provided with three choices:

• Publisher: Sign all your scripts with a certificate from a trusted publisher to allow the execution of signed scripts
• Path: Use specific paths for whitelisting
• File hash: Pick dedicated scripts that are allowed to run

As a recommendation, you can start off very simple with path rules. Always use the GUI to create the paths to not make any mistakes. An initial approach could result in having a folder called c:Scripts, where all your scripts are stored. You could eventually add Action Control Lists (ACLs) on top of this path to prevent users from copying their own scripts into it. This approach can be implemented very quickly, but also gives attackers possible ways to attack it. A better approach to handling your scripts is to sign all of them and specify the trusted publisher who is being whitelisted. You have already learned about the signing process itself. The biggest challenge is to find all of your scripts and centralize them. We will dive into these kinds of topics in upcoming chapters. Once you have accomplished this preliminary task, it is very easy to maintain, and keep all of your scripts controlled and signed.

AppLocker comes together with the possibility of logging, as you can specify all of your rules either to Enforce rules or Audit only:

By default, you would start off by auditing and centralizing your audit information. This can easily be accomplished with PowerShell itself, as AppLocker will write its Audit logs to the EventLog, which can be easily gathered and filtered via code. If no whitelisting approach is defined in your company, the following process is recommended:

• Gather admin scripts, for example coming from/with System Center Configuration Manager.
• Centralize all your scripts.
• Sign your scripts with one of the following:
  • By the developer
  • Via Release Pipeline (explained in following chapters)
  • Via bulk-signing jobs
• Assert your current knowledge by defining AppLocker rules as audit rules.
• Validate the audit logs and search for new and unknown scripts.
• Repeat the last steps for as long you have too much noise in the logs.
• Enforce AppLocker.
• Handle the blocked files via Support Desk (with a defined process where not everything is allowed to run).

This will actually work similar to enforcing the ExecutionPolicy with the policy set to AllSigned. If you have already gone through this working steps for Execution Policy, you will save a lot of time for the whitelisting approach. 

After AppLocker is enforced, every interactive session is started in Constrained Language Mode, and this is for good reason. An attacker could otherwise easily execute their PowerShell cmdlets in an interactive session and bypass this approach. Unfortunately, you will not be able to debug any scripts anymore, because the execution of unsigned scripts is being cached from the AppLocker. Also, developing new scripts will become a very tough challenge.