You need Blocky to stops ransomware attacks.  Add Blocky to your Veeam® for maximum protection of your backup data against malware and ransomware attacks. Blocky runs on the Windows VBS and hardens the Veeam® Backup Repository (VBR) without adding Linux or additional servers. 

Blocky is specifically designed to work with Veeam® to protect backup data by creating an immutable, zero-trust backup environment.  Blocky automatically creates an application fingerprint for each trusted Veeam process, ensuring that only Veeam® has full access to the critical backup data, making it a secure and reliable solution against ransomware.

Blocky protects the Veeam backup data volumes. Veeam users should protect their backup volumes with Blocky for Veeam to ensure cyber resiliency. In the event of an encryption attack, the backup will remain intact and enable the infected servers and data to be restored quickly.

The files from other backups such as Veeam Backup Copy Jobs and Veeam Scale-Out Repositories can also be protected with Blocky for Veeam.

Blocky supports Windows Server 2012, 2016, 2019, and 2022.

Please note that only Windows Server operating systems are supported and, for example, the protection function does not work under Windows 10.

Blocky for Veeam also securely protects the Windows volumes of the Veeam v12 repositories from encryption.

When upgrading Veeam from a previous version, e.g. v9, v10 and v11, please carry out the following steps for Blocky:

• Temporarily deactivate Blocky Volume Protection before the Veeam update
• Activate the Blocky Protection again after the Veeam update
• Update the “Trusted Applications”:
  • Update of the fingerprints of the existing whitelist entries (right mouse button – update)
  • Add the application C: \ Windows \ Veeam \ Backup \ VeeamDeploymentSvc.exe to the Trusted Applications (add automatically or manually via “Whitelisting”)

Blocky protects Windows NTFS or ReFS volumes that appear with a drive letter in the Windows Device Manager.

Network-attached storage (NAS devices) have their own security environment and unfortunately cannot be protected via Blocky.

Yes, these volumes must not be used by other applications, for example, as a cache or dump or similar. This use is theoretically possible, but the function of the other applications cannot be guaranteed, since the blocky whitelisting may not identify all DLLs belonging to the application and provide them with a fingerprint.

The Blocky-Suite is a generic protection software, which, if necessary, can also protect other application scenarios. Blocky4Backup has been specially tested for Veeam environments and is maintained and developed accordingly.

Antivirus software should of course be used in parallel with Blocky on the Veeam Repository Server.

In order to avoid unnecessary antivirus notifications, BlockyAccessCntrlSvc.exe in the folder C: \ Program Files \ GrauData \ Blocky should be excluded from the real-time scan and behavior monitoring in the antivirus software.

There are various events that lead to notification of the administrator. These notifications are configurable. The most important thing is that the event “unauthorized access” is notified. Event notification can be made by email, by making an entry in the Blocky Log (“Logging” in the Monitoring Area) and in the Windows Application Event Log.

Blocky follows a standard Windows application installation but must be installed and started as the system administrator.

Blocky for Veeam is password protected. The password is required to install, uninstall and activate / deactivate the protection function.

Yes, Blocky for Veeam provides a command line interface. All commands relevant to protection require the entry of the password. For details, see the admin guide.

The applications are normally identified using “Automatic Whitelisting”. Unwanted applications are removed manually if necessary, and others are added. With Veeam V11, the list usually looks like the illustration below, whereby the CatalogDataService often only starts weekly and should therefore be added manually to the automatically generated list. Your reseller partner will advise you on the individual setup of your Veeam Repository Server.

Every application that is allowed to access the protected volume must be identified and authorized. For this purpose, a SHA1 hash value is stored and checked for each application, the associated components and the ongoing processes. If the value does not match, there has been an intentional or unintentional change in the application. Unintentionally, it then indicates possible malware activities. An intentional change would For example, a Veeam software update will cause the fingerprint to become invalid.

The executables of the programs listed in the whitelisting may change. This makes the so-called “fingerprint” of the application invalid and must be updated. The programs with fingerprints that are no longer up-to-date are highlighted in color in the trusted application list and must be updated: Right mouse button – “Update”. The fingerprint is then recreated and the program can be executed again.

Notification of invalid fingerprints via email to the administrator is easy to set up: Add an entry at the end of the list of notifications (right mouse button – insert) and enter the event “Whitlelist Entry Invalid” as an email notification.

Blocky uses its own filter technology to monitor access to the protected volumes. Even if the Blocky GUI is closed, the protection runs as set up.

However, if the associated service is changed or closed, the filter driver switches to full protection, no longer allows changes to the volume and notifies the administrator.

Blocky is sold as a subscription license model and offered with one, three and five-year licenses. These should be ordered and installed within the free 14-day trial period.

Exactly one “entry” license is required for individual volumes up to 25TB or 50TB.

For several Repository Server volumes to be protected, the “Enterprise” license model offers licensing packages up to 100TB, up to 250TB, up to 500TB, up to 1PB and> 1PB.

For each volume to be protected, a license file is provided and assigned accordingly in the Blocky for Veeam GUI. Blocky stores the license file in a protected manner on the volume.

The customer receives a “Cap-ID” for each Windows volume to be protected. With the Cap-ID under “License Management” a volume license can be requested from [email protected] (“Register License”). The license key can be generated online or accessed by email and then sent within a few days. In the GUI, the license is then assigned to a specific volume drive letter under “License Management” – “Install”.

The protection can then be activated with a right click on the drive letter. The protected volume is assigned to the “Access-Controlled Volumes” in the directory tree. The protection can be deactivated temporarily (for volume maintenance) or completely at any time.

The customer receives a notification in good time (configurable) that the license is expiring. A purchased license can be registered at any time and then installed. “If you do not want to extend the license for Blocky for Veeam and instead uninstall it, start the Uninstall program (e.g. via” Add or Remove Programs “using the Blocky password.) For security reasons, when a license expires on a protected volume Blocky moves to full protection, i.e. all change requests rejected.

Blocky can send alert notifications to the Windows application event log, to email recipients and to the Status Area of ??the Blocky4Backup GUI depending on certain rules.

Event types

• unauthorized access
• authorized access
• no license valid
• license will expire soon
• invalid whitelist entry
• internal error

Notification of invalid fingerprints via email to the administrator is easy to set up: Add an entry at the end of the list of notifications (right mouse button – insert) and enter the event “Whitlelist Entry Invalid” as email notification.

Further information: Please read the Admin Guide (part of the program download zip file)

Recurring processes – invalid license, invalid whitelist

The count indicates how often a certain event must have occurred for a notification to occur. The 0 was intended to ensure that the event must have occurred at least once and then be regularly notified at the “Threshold Time Interval”. In other words, an event that exists permanently, such as an invalid license or an invalid whitelist entry, should be able to be notified periodically. However, this is currently not working properly, which means that the event is not notified after x minutes, but only when the service rechecks the occurrence of the event. In the case of licenses or whitelist entries, this is either when restarting or after 24 hours at the latest. In other words, the notification would then be triggered again.

If the count is 1 or greater, the event must first occur often according to the specified value (and within the time specified with the interval) in order to once trigger the notification. In the case of events such as “unauthorized access”, the event may then occur several times and will then be notified again and again when the count and interval conditions apply.

Our recommendation is therefore (with the current software version) in case of events that represent a state to set the count to 0 and the interval to 1. In a case such as an invalid license, invalid whitelist, etc. Notification will take place at the next cyclical test (approx. 24 hours or following a restart).

For events that occur selectively, such as “unauthorized access”, a count value of 1 or greater should be set, combined with a corresponding interval, depending on how quickly you want the notification. With a count of 1, the interval would then be irrelevant because every event is notified anyway, but with a count greater than 1, the specified number of events must occur in the specified interval for the event to be notified.

Further details can be found in the Admin Guide in Section 4.6, although the special case with Count = 0 and Interval = x is unfortunately not described correctly. The handling of the notifications is currently being revised so that the software in one of the next versions (> 2.5) will works as described in the documentation.

Yes, as long as the USB disk is used as a kind of fixed disk.

No, the executable program and its external tools such as the license generator are implemented in C++ and are therefore not affected by the vulnerability.

Updating the whitelist is necessary as soon as any component included in the fingerprint has changed. That could be the main executable itself or one of the included DLL’s on a Veeam Update. 

Blocky’s Centralize Management makes it simple to update the whitelist for all remote Blocky systems from the central UI, either updating each instance individually, or to update all of them at once if they have identical whitelist entries.