In this article, we shall be leveraging Zero Trust to harden the Veeam Backup Server with Microsoft AppLocker. Zero Trust principles include explicit verification, minimal privilege access, and assuming breach. Please see how to Configure Multiple IP Addresses on a Single or Multiple NICs, and “Demystifying Zero Trust with Veeam: Design your Architecture“. AppLocker enables System Administrators control which applications can be run on their system by creating rules that specify which software is allowed or is not.

One of the main measures in hardening is removing all non-essential software programs and utilities from the deployed Veeam components. While these components may offer useful features to the administrator, if they provide additional access to the system they must be removed during the hardening process.

If you’re not familiar with how to configure it properly. It’s best to avoid configuring AppLocker. This is because, it can cause significant issues if misconfigured. Interestingly, with the release of Veeam Backup and Replication v12.2, you can leverage the RBAC Enhancement and get the desired results.

This approach focuses on identifying and authorizing users, limiting access to essential resources (least privilege) thereby minimising security breaches. Since the rise of Ransomware and high profile attacks, AppLocker can help in the prevention of malware infection. To help protect against these risks, the Defence in Depth approach must be employed.

Why Utilise a Third Party tool instead of AppLocker?

There are many tools in the market capable of implementing Zero Trust Architecture such as “ThreatLocker” and ‘PolicyPak” etc as they provide more granular control over application permissions and security policies compared to AppLocker. Regardless, we will utilize AppLocker and in a subsequent article, we will discuss how you can achieve same with WDAC.

Some of these tools can dynamically enforce policies based on real-time factors like device security posture, network environment, and user behavior. AppLocker, on the other hand, relies on static rules that may not adapt well to changing circumstances.

For instance, ThreatLocker offers “application ringfencing” where it restricts what actions allowed applications can take and which other resources they can access. This helps prevent lateral movement by attackers even if an application is compromised. AppLocker focuses on allowing or blocking applications but lacks this advanced control over what allowed apps can do.

Note: Microsoft AppLocker itself is not a Zero Trust principle, it can be part of a broader security strategy that aligns and achieve Zero Trust principles. AppLocker helps control which applications are allowed to run on Windows devices by defining rules based on file paths, digital signatures, and other criteria.

Lastly, these tools come with intuitive dashboards and advanced logging/monitoring capabilities that make it easier to track policy enforcement and application behavior. AppLocker’s monitoring is less robust and may require third-party tools to get comprehensive visibility into policy violations.

Also, see How to create a Windows firewall rule on Windows, “What are the differences between Lite-Touch and Zero-Touch installation?“, and how to “Prevent Local Administrators from managing BitLocker with the manage-bde command.

AppLocker as a “hardening process” for VBR

By using AppLocker, organisations can limit user access to only authorised applications, which aligns with the least privilege access principle of Zero Trust. Thereby helping to improve application control management.

Veeam has done a very good job by suggesting that we place Veeam Backup and Replication in a management Domain or Workgroup. This in itself complies with the principle least privilege.

Also, When a hacker fakes credentials to get on your VBR Server, they should not be able to install tools or perform lateral movement to other parts of the network. Because they do not have the proper access privileges and not part of the domain. Therefore making it easier to quarantine the problem.

In the context of Veeam Backup & Replication, placing it in a management domain or workgroup aligns with this principle.

Management Group Deployment

As recommended by Veeam when deploying Veeam Backup and Replication. We must keep in mind the principle that a data protection system should not be placed in the environment it is meant to protect in any way.

This is because when your production environment goes down along with its domain controllers. It will impact your ability to perform actual restores due to the backup server’s dependency on those domain controllers for backup console authentication, DNS for name resolution, etc. Below are some benefits;

Most secure is to add Veeam components to a separate Active Directory Forest’s management domain.
Secure Kerberos communication between different Veeam components, and isolates Veeam infrastructure from the environment it protects. Thereby, reducing reliance on production systems.
Employs group policies to control the domain and facilitate compliance more easily.

Here are some interesting article on how to architect your VBR server “Migrate Veeam Infrastructure from a Production Domain to a Backup Workgroup“, and “Migrate the Veeam Infrastructure from a Production Forest/Domain to a Backup Forest/Domain“.

Workgroup Deployment

In a very large institution with multiple Veeam servers and users, this can become challenging to implement. This is because, each system needs individual configuration with a local security policy, user settings, and permissions etc.

Also, NLTM is used instead of Kerberos in a Workgroup. Therefore, making it harder to defend against internal threats (e.g., disgruntled employees). Below are some advantages as well of using a workgroup instead of placing it with the same environment it is meant to protect.

Fast and easy to setup and not dependent on the environment it is meant to protect.
Does not require additional infrastructure such as Domain Controllers, NTP and DNS

Now that we have some some best practices on how to reduce the Attack surfaces for our VBR servers. It will interest you to know that this is not sufficient and the notion of Defense in Dept must be employed in order to correctly protect our backup system as it the last line of defense for our business.

Please see how to Install and configure Veeam Backup and Replication Community Edition, and how to uninstall Veeam Backup and Replication from your server.

How can we achieve Zero Trust (hardening) with AppLocker?

Hardening in this context refers to the process of securing a system by limiting potential attack surfaces. AppLocker is a feature in Windows operating systems that enables administrators to control which applications are allowed to run on a system.

Implementing AppLocker to protect Veeam Backup and Replication involves creating rules to control the execution of applications and scripts on the Veeam Backup and Replication Server.

Through policies enforced by AppLocker, administrators can specify rules that define which applications and scripts are permitted to execute. This reduces the risk of unauthorized or malicious software running on a system. This is a proactive security measure that strengthens the overall security posture of a system or network.

Note: Microsoft advises customers that want to implement application control to employ “WDAC” rather than AppLocker. This is because “WDAC” currently undergoes continual improvements, and added support from Microsoft management platforms. AppLocker continues to receive security fixes, but it isn’t getting new feature improvements.

With this approach, you can protect your devices, and networks against the exploitation of zero-day vulnerabilities as well.

Please see the fix to “An account with the same name exists in Active Directory: Re-using the account was blocked by a security policy“, and how to Achieve 3-2-1 rule with SOBR on Synology or OOTBI and Wasabi.

What to know about AppLocker!

AppLocker can be easily bypassed if a user is a member of the local administrators group. Therefore it is recommended to remove all standard users from the local administrators group. Also, non-admin (standard users) have read/write permission on some writable workspaces.

Therefore, Planning a roll out is probably the most important step in an AppLocker delivery. As mentioned previously, limiting access to only resources that is needed (least privilege) is one of the most important steps in the Defense in Depth strategy.

As System Administrator, we can define some set of rules to be applied against non-admins (standard desktop user) and this can be based on attributes from a file’s digital signature including the Publisher, Product or Version. You can also create rules from a hash of the file or a path to a set of files. Along with the Whitelist rules. Exceptions can be defined to prevent certain files from being executed from the initial larger rule set etc.

From Windows 10, Windows 11, and Windows Server 2016 or later, you can apply the AppLocker policy to non-user processes, including those that run as SYSTEM.

Understand Veeam Components

By implementing AppLocker with careful consideration of Veeam’s components. You can enhance the security of your backup infrastructure by controlling which applications and scripts are allowed to execute on the Veeam server.

This step involves identifying the executables, scripts, and components associated with Veeam Backup and Replication that need to be allowed to run. Here is how to Install Veeam Backup And Replication With Dedicated SQL Server.

Configure AppLocker

You can create AppLocker rules for a single device or for a group of devcies. For a single computer, you can create rules using the Local Security Policy Editor (secpol.msc). For a group of computers, you can create the rules in a GPO by using the Group Policy Management Console (GPMC).

Note: If you have your VBR setup in a management domain. Kindly employ this approach to role out the AppLocker configuration to multiple VBR in your environment. Launch he Group Policy Management console and drill down to.

Computer configuration\Policies\WindowsSettings\SecuritySettings\ApplicationControl Policies\AppLocker

Since this is a single VBR server. I will be using the Local Group Policy Editor to configure app Locker as shown. Search and Launch the Local Group Policy Editor

Then navigate though to AppLocker under “Application Control Policy”.

Alternatively, you could open the Local Security Policy on the Veeam server

Then navigate to path below “Security Settings -> Application Control Policies -> AppLocker“.

AppLocker is organized into four areas called rule collections. The four rule collections are executable files, scripts, Windows Installer files and Packaged app.

Please learn more on Fix WDAC vulnerabilities by updating PowerShell, and how to Force BitLocker Recovery: Perform BitLocker Recovery via the Self-Service Portal and Helpdesk.

Set AppLocker to Audit-Only

Note: Please be careful and set the AppLocker Rule to Audit-Only before proceeding. Else, you could make your PC/Server unusable. When you are sure of the rules, then you can enforce them.

You can leave them as default (not configured). But to identify potential issues without impacting operation in the production environment or in my case the test (Lab) environment. Please set them to “Audit Mode”. This will help prevent lockout, help fine tune rules thereby leading to non-disruptive testing.

When you set the enforcement mode to Audit only, the following behaviour occurs:

AppLocker rules are evaluated, but no enforcement actions are taken.
All events generated from the rule evaluation are written to the AppLocker event logs.

Note: AppLocker is not configured to Audit Mode or Enforced Mode by default. This is because AppLocker is designed to be a powerful security tool that requires deliberate configuration based on an organisation’s specific needs.

Therefore, I will set this to “Audit Only” for now for the rule collections you want to audit. To do this, right click on “AppLocker” and select “Properties”.

Note: Enabling Audit Mode by default could result in excessive logging in environments where AppLocker is not actively being used. Thereby complicating log management and analysis.

Under Enforcement, ensure the boxes are checked and rule set to “Audit Only”.

Note: Microsoft encourages a staged approach to deploying AppLocker. You as an administrator should first define specific rules, and then they have the option to enable Audit Mode to test those rules before enforcement.

Is Application Identity Service Running?

The Application Identity service is a crucial component for enabling and managing AppLocker on Windows systems. The Application Identity service is responsible for determining and verifying the identity of applications running on the system.

This service plays a key role in enforcing AppLocker policies by evaluating the identity of an application against the rules you have configured.

As you can see below, the service is not running. To fix this, please see how to fix unable to start the Application Identity Service. Thereaafter, you can open the Services console (services.msc). Locate Application Identity in the list of services and start it.

As you can see below, the serive is running and the service type is set to Manual (Trigered). We have to change this to automatic.

We have to Right-click on it, select Properties

Application identity properties — Starting with Windows 10, the Application Identity service is now a protected process. As a result, you can no longer manually set the service **Startup type** to **Automatic** by using the Services snap-in

Set the Startup type to Automatic

As you can see, this service has been set to automatic and it is running. To disable this service “Application Identity Service” in the future, you also have to use the GPO or Windows Registry Editor. Else, you will be prompted with the Access Denied wizard.

Application Identity set to automatic — If you make changes to your AppLocker policies, ensure the Application Identity service is running to apply those changes. If the service stops for any reason, AppLocker rules will not be enforced until it is restarted.

Scenario 1: Create “Default Rule” / “Automatically Generate Rules”

You can use the automatic AppLocker rule to create rules for all files and programs on your PC. This feature is useful when you want to quickly generate rules based on existing files on a reference device (Veeam Backup and Replication Server). Below is a list of rule extensions and associated file format.

Scripts: .ps1 .bat .cmd .vbs .js
Packaged Apps Packaged apps and packaged app installers: .appx
Windows Installer: .msi .msp .mst
Executable: .exe .com

When you enable a rule, it effectively creates an allowlist. You don’t need to create deny rules to block anything because only the applications specified in the allowlist will be permitted to run. Therefore, this might be sufficient for your need provided the Administrator Account is not compromised.

If all necessary applications are already installed on the PC. You can use automatic rules to quickly generate an allowlist. Below are some reasons to create automatic rules

AppLocker Automatic General Rules provide a baseline security setup by automatically allowing essential and trusted Windows system files and applications to run. This minimizes the risk of accidentally blocking critical system components.

By automatically generating rules for known safe applications and paths. You reduce the likelihood of configuration errors that could block necessary applications or processes. Thereby improving the stability and functionality of the system.

Create Executable Rules

In this section, I will show you how to “Create Default Rules”. Thereafter, demonstrate the steps on how to “Automatically Generate Rules”.

To do this, open the AppLocker console. Right-click the appropriate rule type “executable”. Subsequently, we will do this for all other rule types such as “Windows Installer, script and packaged app rules”. Select “Create Default Rules”.

Default rules - Executive Rule — These rule will serve the purpose for most people. But you can continue to refine your rules henceforth.

As you can see below, the Default Rules have been created. Note that if we had created the “Automatically Generate Rules”, the Default Rule would have been created on the fly as well.

Automatically generative executive rules — The Default Rule ensures essential system applications and processes are allowed to run. They provide a quick way to start with some level of application control. While the “Automatically Generate Rule (Custom Rules) are based on the applications that are already installed on the system. This feature scans directories and generates rules for all executable files, allowing you to quickly create a tailored allowlist for your environment.

For me, I have decided to apply this to everyone and will click next.

You should consider giving a Group the ability to run the application instead of ‘Everyone.’

As you can see below, the Rules are being generated. Click Next when complete

Rule Preference — Rule conditions are criteria that the AppLocker rule is based on. Primary conditions are required to create an AppLocker rule. The three primary rule conditions are: Publisher, Path, and File Hash

Please review the rules and click on “Create”.

We have successfully created the custom rules as shown below.

Executive Rules — These rules are considered trustworthy and implicitly denying anything other than the allowlist.

Windows Installer Rule

Also, for the Windows Installer Rules, I will proceed and create the Automatic Rules.

Review the rules and click on “Create”.

As you can see, AppLocker detected that the Default Rule were not in place. Click on Yes to have the default Rules created as well.

As you can see from the Default Rules above. They are easy to implement with minimal configuration effort. They are a quick way to get started but are not ideal for comprehensive application control. But the “Automatically Generate Rules” require more initial effort, as the system needs to be scanned and rules reviewed and create a more precise security posture tailored for VBR Server

Script Rule

We will do the same for the Script Rule. You can decide if you wish to create the Deafult Rules first or have it created automatically.

I will click on automatically generate rules for this PC in order to have custom rules for the device.

I will go with the defaults on Folder and Permissions and click Next

You can go for file path and here is why. When the file hash condition is chosen, the system computes a unique cryptographic hash of the identified file that is based on the SHA256 algorithm that Windows uses. The hash condition type is unique. Therefore, each time a publisher updates a file, you must create a new rule.

I have decided to chose the File Hash as this is just a PoC. Please review the rules and click on create.

We have successfully generated the Script rules as well.

Note: AppLocker uses its own path variables for directories in Windows. AppLocker does not enforce rules that specify paths with short names. If you were to create your own rules and not the Automate (Custom) rules, please always specify the full path to a file or folder when creating path rules so that the rule will be properly enforced

Package App Rule

We would do the same for the Package app Rule. So I will right on the working area or on “Package app Rule” and select “automatically Generate Rules”.

Here you can decide to restrict it to groups etc. But I will set this for “Everyone” and click on Next.

Click on Next on the Rule Preference

Please review the rules and click “create”

This will automatically generate the “Package app rule” for everyone.

Ensure that you have configured AppLocker properties to Enforced mode again and you can now continue testing.

Note: AppLocker extends the capabilities of Software Restriction Policies and offers more configuration options. However, including the built-in administrator in the default rule may defeat the purpose of securing your system. If the administrator account is compromised, it becomes overly permissive. While this might be acceptable for some, it’s generally not recommended for maintaining strong security.

As you can see above, AppLocker is incredibly flexible and customisable as rules can be created based on a wide range of criteria, including file names, digital signatures, publisher information, and even specific versions of software. This ensure only approved applications are permitted to run on my VBR server.

Scenario 2: Utilising the Deny Rule

An allowlist protects against future threats, while a blacklist focuses on past threats. A blacklist requires fewer rules but leaves vulnerabilities to yesterday’s threats. In contrast, an allowlist defends against emerging, unknown threats by only permitting known and trusted applications to run, though it requires more complex and detailed rules to implement effectively.

Assume you have got these users and wish to block “Moses” access to the VBR Server but on access VeeamONE only. Please take a look at this Microsoft article for more information.

Configure AppLocker Deny Rules

Firstly, create some “default rules” if you wish to use the DENY Option. Else, you will end up blocking (Denying) everyone else including the local Administrator. So, I will start with the executable rules as shown below. This will ensure important system files will be allowed to run.

We have our default rules in place. You should to do this for the other three rules conditions which are “Windows Installer Rule”, “Script Rile”, the “DLL Rules” if you have it enabled and the “Package App Rule”.

This ensures that the Standard users (non-admin) users are only permitted to run programs that are in the program file and Windows Directory. Every other thing will be blocked. For a VBR Server this is an ideal behaviour for me.

Now you can proceed to create a DENY Action as you wish. You can then start creating your DENY Action for certain users, groups, or everyone based on their use cases.

I have got some users that are also allowed access to the VBR server due to their job functions. So, I will be creating some rule to DENY some folders, applications, executables etc based on my use case.

Click next to proceed and ensure you deny access to the following path “”C:\Program Files\Veeam\Backup and Replication\Veeam.Backup.Manager.exe”

Deny Action selected — In AppLocker, **deny rules take precedence** over allow rules. Even if an application is included in an allow list, if a deny rule is also configured for that application or its location, the deny rule will override the allow rule, and the application will be blocked from running

Ensure that you have configured AppLocker properties to Enforced mode. When testing AppLocker, allow a few minutes for the enforcement to take effect. This delay occurs because AppLocker policies may take time to apply across the system, ensuring all rules are properly enforced before testing begins.

Note: AppLocker doesn’t replace your antivirus software; instead, it works alongside it to help prevent the execution of unauthorised applications.

While antivirus detects and removes malicious software, AppLocker strengthens your security by blocking unwanted or unapproved applications from running in the first place. Together, they provide a more comprehensive defense against threats.

Conclusion on AppLocker

There is a trade-off between convenience and security as you are probably used to. Before enforcing AppLocker, please test these policies in a controlled environment before implementing them in a production setting. Regularly update the allowed paths or rules based on the evolving needs of your environment and document your configurations for reference and auditing purposes.

One of the principles of Zero Trust is Monitoring and Auditing. Once AppLocker is configured and applied, it is vital to monitor the effectiveness of the rules. The Windows Event Logs provide great any AppLocker-related events. Events related to blocked applications can provide insights into missing rules. The Event Id’s used by AppLocker range from 8000-8027.

If you intend to apply the AppLocker rule to multiple VBR in a large organization, manually reviewing every single Event Log may be a daunting task. This is where the Windows Event Forwarding (WEF) may come in handy where the filtered result can be forwarded to a collector. You will find Splunk very handy in this case as well.

Keep the AppLocker rules up-to-date. Whenever there are updates or new versions of Veeam, review and update rules as needed.

Lastly, anyone with admin rights to their local device can subvert AppLocker Policies. As a result, you may expose your environment to malware despite your best efforts to lock down applications. Therefore, ensure standard users are not part of the local admin user group.

I hope you found this article useful on how to Harden your Veeam Backup Server with Microsoft AppLocker. Please feel free to leave a comment below.

5/5 - (1 vote)