AppLocker: Security, Rules, and Bypass Techniques

Understanding AppLocker

AppLocker is a vital security feature in Windows that empowers administrators to control which applications and files users can execute on their devices. This powerful tool serves as a formidable defense against malware and helps enforce organizational policies. Whether managed through Group Policy or the Local Security Policy editor in Windows, AppLocker puts you in control.

AppLocker Rules and Restrictions

AppLocker leverages rules to restrict access to applications and files based on several key attributes:

• File Name and Path: Specify which files or file types users can access based on their names and locations.
• File Publisher: Allow or deny access to files based on their digital signatures from specific publishers or certificates.
• File Hash: Control access to files by their unique cryptographic hash values.
• Windows Installer: Regulate access to files through Windows Installer rules.
• Scripts: Manage access to Windows Script Host (WSH) scripts, including VBScript and JavaScript files.

By harnessing these restrictions, administrators wield a powerful tool to thwart malware and unauthorized software, ensuring compliance with organizational directives.

For more advanced techniques and in-depth insights into AppLocker, including bypass techniques and security considerations, We invite you to explore our follow-up article, “Mastering AppLocker Evasion Techniques.” This article delves into advanced strategies for both defending against and circumventing AppLocker’s restrictions, providing valuable knowledge for security practitioners and enthusiasts.

Week Points Of AppLocker

AppLocker has several potential weak points, including:

• Bypass techniques: Some attackers may be able to bypass AppLocker restrictions by renaming files, modifying file properties, or using other techniques to evade detection.
• Unsigned files: AppLocker rules are based on file signing, and if files are not signed, they cannot be restricted.
• Lack of control over third-party software: AppLocker only controls access to files that are executed by Windows, so it cannot control access to third-party applications.
• Limited script control: AppLocker’s script control is limited and may not be able to detect or block all malicious scripts.
• Limited to Windows: AppLocker is a Windows-only feature and does not protect other operating systems.
• Complexity of management: AppLocker rules can be complex to manage, especially in large environments with many users and applications.
• False positives and negatives: AppLocker rules can be too strict and block legitimate files or too loose and allow malicious files to run.

Identify If AppLocker Is Running On The System

There are several ways to identify if AppLocker is running on a system:

• Group Policy: AppLocker is managed through Group Policy, so you can check the local Group Policy settings on the computer to see if AppLocker is enabled.
• Event Viewer: AppLocker generates events in the Event Viewer when it is used to block or allow files. Check the Application and Services Logs > Microsoft > Windows > AppLocker for events.
• Local Security Policy: AppLocker can also be managed through the Local Security Policy editor in Windows. Open the Local Security Policy editor, and navigate to Security Settings > Application Control Policies > AppLocker.
• Command line: You can use the command line tool sfc /scannow to check if AppLocker is running on the system.
• Third-party tools: There are also third-party tools available that can be used to check if AppLocker is running on a system, such as Sysinternals Process Monitor and Process Explorer.

To identify if AppLocker is running on the machine, we can attempt to execute a binary that is typically blocked by AppLocker. In our case, we’ll use PsExec.exe. Picture 1 shows an attempt to execute a binary file, PsExec.exe, which is typically blocked by AppLocker. The goal here is to identify if AppLocker is running on the machine by observing the response to the execution attempt.

Bypassing AppLocker

An In-Depth Guide

Here is an example of a technique attackers might use to bypass AppLocker.

First, we need to find and retrieve the AppLocker Policy. We can locate the policy at the following path:

C:\Windows\System32\AppLocker\MDM\

Picture 2 demonstrates the process of finding and retrieving the AppLocker Policy. This policy file holds information about allowed and disallowed applications.

After obtaining the AppLocker Policy, we can review it to find potential paths where weak folder permissions might exist. Let’s focus on the path "%OSDRIVE%\Users\Public\*", where we will search for weak folders after the Public folder. In Picture 3, the AppLocker Policy has been opened for review. The focus is on identifying potential paths that contain folders with weak permissions.

To check folder permissions, we can use the Get-Acl command in PowerShell. However, checking each folder individually can be time-consuming. To speed up the process, we’ll use a PowerShell Script that provides the output in a user-friendly GridView format and allows for filtering.

The PowerShell script to check folder permissions is as follows: We will simply modify the path to C:\Users\.

$FolderPath = Get-ChildItem -Directory -Path "C:\Users\" -Recurse -Force
$Output = @()
ForEach ($Folder in $FolderPath) {
    $Acl = Get-Acl -Path $Folder.FullName
    ForEach ($Access in $Acl.Access) {
$Properties = [ordered]@{'Folder Name'=$Folder.FullName;'Group/User'=$Access.IdentityReference;'Permissions'=$Access.FileSystemRights;'Inherited'=$Access.IsInherited}
$Output += New-Object -TypeName PSObject -Property $Properties            
}
}
$Output | Out-GridView

To run the script, follow these steps:

• Open PowerShell and copy the script to the clipboard.
• Paste the script inside PowerShell and hit Enter.

Picture 4 presents a PowerShell script used to check folder permissions efficiently. The script uses the Get-Acl command to retrieve permissions, and it loops through folders in the specified path. The output is displayed in a user-friendly GridView format, allowing for easy inspection and filtering.

Once the script is executed, it will prompt the output in GridView. We can now examine the permissions and apply filters to facilitate our search. After running the PowerShell script, Picture 5 displays the output in the GridView format. The script has extracted permissions for folders, and users can now analyze and filter the results for their investigation.

To filter the output, click on “Add criteria,” select “Group/User,” click “Add,” and enter the “Group/User” we are interested in filtering. In Picture 6, the user is shown how to add criteria for filtering the output in the GridView. Now, the user can filter the results to focus on specific entities.

By applying filters, we successfully find two potential folders where we can attempt to bypass AppLocker. Let’s test them by copying our malicious EXE file into the identified folders and try to execute the binary.

In our case, we’ll use the PsExec.exe binary:

PS C:\Users\Dev\Desktop> cp PsExec.exe "C:\Users\Public\Pictures"

Picture 7 demonstrates the process of copying the PsExec.exe binary into the first identified potential folder (C:\Users\Public\Pictures). This folder has weak permissions, and the goal is to test whether we can execute the binary successfully.

Executing the binary file in the identified folder, we successfully bypass AppLocker. Picture 8 shows that the binary (PsExec.exe) was successfully executed in the first identified folder (C:\Users\Public\Pictures). This indicates that AppLocker has been bypassed for this folder due to weak permissions.

Testing the second identified folder, we again manage to bypass AppLocker successfully:

PS C:\Users\Dev\Desktop> cp PsExec.exe "C:\Users\Public\Videos\"

Picture 9 demonstrates the process of copying the PsExec.exe binary into the second identified potential folder (C:\Users\Public\Videos). Similar to the first folder, this folder is also suspected to have weak permissions that could bypass AppLocker.

Picture 10 shows the successful execution of the binary (PsExec.exe) in the second identified folder (C:\Users\Public\Videos). This confirms that AppLocker has been bypassed for this folder due to weak permissions.

Another way to filter is to search for permissions such as Write, ReadAndExecute, or FullControl for Everyone. Multiple criteria can be added to search for multiple permissions. Picture 11 demonstrates how to apply multiple criteria to filter the output. Users can search for specific permissions to identify folders with potentially weak security settings.

Additionally, we can see the folder permissions directly from PowerShell using the following commands and piping the results to ft to get a full view of the folder permissions:

PS C:\Users\Dev\Desktop> (get-acl C:\Users\Public\Pictures\).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags -auto

PS C:\Users\Dev\Desktop> (get-acl C:\Users\Public\Videos\).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags -auto

Picture 12 provides an alternative way to view folder permissions directly from PowerShell. By using the Get-Acl command and piping the output to ft, users can see the full permissions for a folder, including the identity, permissions, access control type, inheritance, and flags.

Wrapping Up

In conclusion, “A Comprehensive Guide to AppLocker: Security, Rules, and Bypass Techniques” has provided valuable insights into the significance of AppLocker as a security measure and the potential bypass techniques that could pose risks to its effectiveness. We have seen how regular policy reviews and cybersecurity awareness are essential to maintain a robust defense against potential threats. As responsible practitioners, it is vital to use this knowledge ethically, focusing solely on enhancing security measures and defending against attacks. By remaining vigilant and promoting collaboration and information sharing within the cybersecurity community, we can adapt and evolve our defenses to stay ahead of ever-changing challenges.

The article was written by M4rt1n3zz