AppLocker Setup and Rules
There are three primary AppLocker rule categories,
which can be combined as needed.
The first and most simple rule is based on file paths.
This rule can be used to whitelist a single file based
on its filename and path
or recursively include the contents of a directory.
The second rule type is based on a file hash which may allow a
single file to execute regardless of the location.
To avoid collisions, AppLocker uses a SHA256 Authenticode hash.
The third rule type is based on a digital signature,
which Microsoft refers to as a publisher.
This rule could whitelist all files from an individual
publisher with a single signature,
which simplifies whitelisting across version updates.
To get started with a simple case study, we’ll set up
some basic AppLocker whitelisting rules.
In order to simplify our testing we’ll login to the Windows 10
victim as “student” since administrators will be
exempt from the rules we’ll create.
Let’s open an administrative command prompt,
enter the “offsec” user credentials,
and launch gpedit.msc, the GPO configuration manager.
In the Local Group Policy Editor, we’ll navigate to
Local Computer Policy -> Computer Configuration ->
Windows Settings -> Security Settings
Application Control Policies
and select the AppLocker item.
The rule creation and configuration process
consists of several steps.
First, we’ll click Configure rule enforcement
to open the properties for AppLocker.
In the Properties menu,
we can enable AppLocker rules for Executables,
Windows Installer files,
scripts,
and packaged apps.
This will set four rule properties
which enable enforcement for four separate file types.
The first property relates specifically to executables
with the .exe file extension
and the second relates to Windows Installer files
which use the “.msi” file extension.
The third property relates to PowerShell scripts,
Jscript scripts, VB scripts and older file formats
using the .cmd and .bat file extensions.
This property does not include any third-party scripting
engines like Python nor compiled languages like Java.
The fourth property relates to Packaged Apps, also known as
Universal Windows Platform (UWP) Apps which include applications
that can be installed from the Microsoft App store.
For each of these four categories, we will select
"Configured”.
In addition, we can choose to “Enforce rules” to enable the
rule and enforce whitelisting or “Audit only” which will allow
execution and write an entry to the Windows event log.
We’ll configure AppLocker to enforce rules for all
four categories,
click Apply
and OK to close the window.
Next we must configure rules for each of these four categories.
We’ll do this from the options in the lower part of the main
window titled “Overview”.
We’ll first click Executable Rules to open a new window where
we can enter the whitelisting rules related to
each specific property.
Right-clicking the pane presents two options for rule creation.
The first is “Create New Rule...” which will let us define a
custom rule based on any of the three rule types.
The second, “Create Default Rules”,
will automatically apply the default AppLocker rules.
We’ll begin with the default rules,
which will be easier to work with.
As we progress through the module, we’ll add additional
rules to further harden the box.
Once we’ve chosen to apply the default rules,
they will be added to the pane.
This should block all applications
except those explicitly allowed.
Specifically, the two first rules will allow all users to
run executables in C:\Program Files, C:\Program Files (x86),
and C:\Windows recursively,
including executables in all subfolders.
This allows basic operating system functionality but
prevents non-administrative users from writing in these
folders due to default access rights.
The third rule allows members of the administrative group
to run any executables they desire.
The other three categories have similar default rules.
We’ll enable them to configure basic application whitelisting
protection on our Windows 10 victim VM.
Once we have created all the default rules, we must
close the Local Group Policy Editor,
and run gpupdate /force from the admin command prompt
to refresh the active group policies.
Now that AppLocker is configured and enabled,
non-admin users should not be able to execute any executable
or script outside allowed directories.
To test this, we’ll start a command prompt as “student”
in a non-admin context.
We’ll copy the native calc.exe executable from the
Windows System32 directory into the current directory,
and attempt to execute it.
The error was generated by AppLocker,
which blocked execution.
AppLocker logs each violation in the Windows event log.
To view this message, we’ll open “Event Viewer”,
press the windows key + r
enter “eventvwr”,
navigate to Applications and Services Logs ->
Microsoft ->
Windows
AppLocker
and select EXE and DLL.
The error reveals that execution of calc2.exe has been blocked.