How to make use of AppLocker during and post-installation using PowerShell and JumpCloud

How to make use of AppLocker during and post-installation using PowerShell and JumpCloud

Intro

Microsoft provides multiple approaches to manage Application Controls on Windows-based systems. One of them is AppLocker, besides Software Restriction Policies and Windows Defender Application Control.

AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers.

As referenced in the article, it's important to highlight that: If not managed via a MDM-solution, a Windows Enterprise License is required. As you can see in the screenshot below, I could only make it work after upgrading from Windows 10 Pro to Enterprise. In our case we're using PowerShell to enforce these settings.

No alt text provided for this image
No alt text provided for this image

In general, AppLocker can help you:

  • Define rules based on file attributes that persist across app updates, such as the publisher name (derived from the digital signature), product name, file name, and file version. You can also create rules based on the file path and hash.
  • Assign a rule to a security group or an individual user.
  • Create exceptions to rules. For example, you can create a rule that allows all users to run all Windows binaries, except the Registry Editor (regedit.exe).
  • Use audit-only mode to deploy the policy and understand its impact before enforcing it.
  • Create rules on a staging server, test them, then export them to your production environment and import them into a Group Policy Object.
  • Simplify creating and managing AppLocker rules by using Windows PowerShell.

Practical Approach and Solution

First you will need to create your Package App Rule (as an example) to come up with an XML-file containing the restrictions which we will apply later via a JumpCloud Commands using PowerShell and carrying the XML as an additional payload.

Generating the XML File

As this is well documented here, I won't repeat the whole content. You can follow the instructions in the article until "Creating the Policy". Stop there and in a next step you can simply cleanup the XML-file by removing unnecessary lines ("NotConfigured") which would lead to a failed application of the rules. In our example here, we will deny the execution of MS Teams (because I prefer Slack) and MS Paint.

No alt text provided for this image

After cleaning up, your XML-file will look like this:

No alt text provided for this image

Assembling the PowerShell Script and the JumpCloud Command

Now that you have a consumable payload, we can put together a few lines of code which will:

  • Configure the Application Identity Service on Windows (setting it to Automatic Startup Mode)
  • Start the Service
  • Import and apply the AppLocker Policy

# Bypass Execution-Policy

Set-ExecutionPolicy Bypass -Force




# Set Application Identity Service to Automatic

Stop-Service AppIDSvc

Set-Service AppIDSvc -StartupType Automatic?

Start-Service AppIDSvc




# Import and set the AppLocker Policy previously created with gpedit.msc

Set-AppLockerPolicy -XmlPolicy C:\Windows\Temp\DenyTeamsPaint.xml        

We're adding this to the JumpCloud Command and attaching the XML-file:

No alt text provided for this image
No alt text provided for this image

Now you can scope the Command on Devices/Device Groups already.

Note: Just like hardening your Windows devices, this requires extensive testing prior a wider rollout within your organization.

On Another note: during the execution of the Commands, I frequently received an Access Denied error while setting the service to Automatic, yet, the change was successful. I couldn't figure out the exact root cause yet.

Once applied - it takes a moment until it's effective actually - you will get the fairly basic notification that the execution of an application was prevented:

No alt text provided for this image

Baking it into the AutoPilot scenario

Just like in my previous article about Windows Hardening, you can apply this policy during the deployment before issuing the device to a user. It's the same approach: We will add a trigger to the JumpCloud Command and make it consumable within the PowerShell Module.

# Apply AppLocker via JumpCloud Command

# Add device to the Command

Add-JCCommandTarget -CommandID $AppLockerCommandID -SystemID $agentconf.systemKey

# Execute the Command to harden the device

Invoke-JCCommand -trigger 'AppLocker'?

# Wait for the hardening to finish
Sleep 240 

# Remove the hardened device from the Command itself

Remove-JCCommandTarget -CommandID $AppLockerCommandID -SystemID $agentconf.systemKey?d        

Conclusion

By doing this your device can be even more secure out-of-the-box:

  • Push-MFA enabled on the device-level for every managed user
  • Hardened by applying the Microsoft Security Baseline (or any other)
  • Applications locked down as needed (for security and/or operational reasons)
  • Policies applied including BitLocker DiskEncryption and Key Escrow
  • Software deployed by using Commands or Software Management Capabilities

Previous articles


要查看或添加评论,请登录

Juergen K.的更多文章

社区洞察

其他会员也浏览了