Loading...

Latest news

All (183) General (51) Releases (72) Guides (38) Articles (22)
 Back
Articles

Inside the development of ransomware detection in Bacularis

28 Sep 2026, 08:04
<p>We are working on a new Restore Verification checker designed to identify suspicious changes in restored backup data that may indicate ransomware activity. In this development update, we take a closer look at how the feature works and the technical challenges behind it.</p>

We are working on a new Restore Verification checker designed to identify suspicious changes in restored backup data that may indicate ransomware activity. In this development update, we take a closer look at how the feature works and the technical challenges behind it.

Why do we need this feature?

In a ransomware attack, user data may become encrypted. Responding quickly to such an incident is very important.

From a backup perspective, it is important to detect as early as possible that encrypted or otherwise suspiciously modified data has started appearing in subsequent backups. The new Bacularis feature is intended to help identify anomalies in backup data that may indicate unwanted changes or activity potentially related to ransomware.

How will it work?

One of the most important aspects of this feature is that Bacularis works with the actual restored backup data.

It does not try to assess backup jobs only on the basis of Bacula metadata. Instead, it analyzes backup data directly after it has been automatically restored into a test environment. This makes it possible to inspect what is actually present in the backup and detect anomalies in the restored data.

The feature is being developed as an extension of the recently introduced Restore Verification functionality. It works as a modular checker plugin that can run on its own or together with other Restore Verification checkers.

A scoring-based approach

The restored data will be analyzed on several levels using different tests. Individual findings contribute points to an overall score according to their type and severity.

The analysis takes into account factors such as:

  • entropy analysis,
  • file type/header consistency,
  • extension mismatch,
  • historical anomaly,
  • modification time,
  • ransomware note detection.

After the points are calculated, the result is written to the job log together with the reasons why individual points were assigned.

This means that a single unusual signal does not automatically have to indicate a problem. Several independent indicators may need to appear before the score becomes high enough for the checker to report a warning or a verification failure.

Entropy analysis is also not based on a simple rule such as "if entropy X is greater than Y, report an error." The result is evaluated together with other signals and, where possible, compared with previous results for the same data. We describe some of these mechanisms in a little more detail below.

What were the biggest challenges?

Interestingly, the biggest challenge was not directly related to ransomware detection itself. It was providing the checker with access to the history of its previous runs.

With this mechanism, the checker does not have to evaluate every test in isolation. It can learn the typical values seen in earlier tests, compare them with the current result, and detect deviations from the previous behavior of the data.

We implemented this as a general mechanism for the whole Restore Verification checker system rather than as something specific to the ransomware checker. This means that result history can also be used by other checkers, including custom checkers created by the Bacularis community for their own needs.

The second challenge was entropy analysis.

We implemented native entropy calculation in Bacularis, which removes the need to depend on any external tool for this part of the analysis. This also allowed us to introduce sampling instead of analyzing entire files.

For example, the checker can be configured to analyze five samples taken from different parts of each restored file. The sample size can also be adjusted depending on the environment and requirements.

The final major challenge was introducing configuration support for checkers.

Until now, simple checkers such as FileSizeCheck or FileExistsCheck did not require any configuration. We have now added mechanisms that allow checkers to define and use their own settings.

We needed this for entropy sampling and for other ransomware checker options, but once again, the implementation is generic and can also be used by other Restore Verification plugins in the future.

Where are we now?

The most important infrastructure required for this checker is already in place.

We are currently developing additional methods for analyzing restored data, testing their behavior, and refining how the results are presented.

We plan to make the Ransomware Detection checker available with Bacularis 6.6.0.

See you in the next updates. We hope you found this development overview useful, and we will continue sharing what is new in Bacularis.