Threat Detection

Threat Detection is about identifying malicious activity - malware, ransomware, unauthorized access attempts - as early in the attack lifecycle as possible, ideally before it reaches or spreads through backup data. Being able to detect an attack before it takes place, or while it is taking place, considerably mitigates its impact.

For backup infrastructure, detection has a distinct urgency compared to detection elsewhere in the environment. If malware makes it into a backup chain undetected, the organization can end up “recovering” straight back into an infected state - turning what should be the recovery from an incident into a second occurrence of it.

In this page we will focus on the detection capabilities built into Veeam Data Platform and how to apply them across the backup and recovery lifecycle.

Why Detection Has to Happen at the Backup Layer Too

Relying solely on production-side detection (endpoint protection, network monitoring) leaves a gap:

  • Malware can lie dormant in a system for some time before activating, meaning it can be faithfully backed up long before anyone notices it in production.
  • A ransomware attack that encrypts production data can also reach the backup infrastructure, especially if detection is only watching production.
  • Without detection built into the backup and recovery process itself, a “successful” backup or a “successful” restore is not the same thing as a clean one.

Best Practices

Detect at Every Point in the Data Lifecycle

Malware detection is a fundamental part of a Cyber Resilience strategy and belongs in every data protection operation - not as a bolt-on feature, but at every stage where data moves or is stored. Veeam Backup & Replication provides detection methods for each of those stages, and they should be used as complementary methods, rather than alternatives (one or the other):

Stage Method Description
As data is backed up Inline Scan Scans blocks in the data stream using inline entropy analysis, catching signs of encryption-in-progress - a strong ransomware indicator - at the moment the data is being written to the backup.
As data is backed up Guest Indexing Data Scan Analyzes file system activity captured through guest indexing to spot suspicious file behavior, such as mass renames or the appearance of known ransom-note patterns. The same data is also checked for Indicators of Compromise (IoC): tools and utilities commonly used by attackers during reconnaissance, credential theft, or lateral movement, which often appear before encryption begins.

NOTE. Please consider that the scans mentioned above will have an impact on the backup operations performance, specifically on Proxy Servers or Workers, so please size the backup infrastructure accordingly. Check the Veeam Backup & Replication Best Practice Guide for more information about sizing.

Stage Method Description
While data is at rest Scan Backup Scans existing restore points using Veeam Threat Hunter, YARA rules, or third-party antivirus engines, so detection isn’t limited to the moment of backup creation. This matters because a backup that was clean when it was written can later be found to contain dormant malware once new signatures or YARA rules become available.
As data is restored Secure Restore Checks a restore point for malware before it is brought back into production, so a recovery doesn’t just reintroduce the same infection that caused the incident in the first place. It uses the same detection methods as Scan Backup.

For configuration details, see the Malware Detection section of the Help Center documentation.

NOTE. Detection during recovery should be part of the Disaster Recovery Plan, whether that plan is run manually or fully automated with a solution such as Veeam Recovery Orchestrator. VRO enables the use of multiple malware detection methods during an orchestrated recovery, so you always recover from a clean copy of your data.

Investigate Findings, Don’t Just Collect Them

A detection event is only the start: someone has to work out what was found, how serious it is, and which restore point is safe to recover from. VBR Malware Deep Analysis, a specialized agent in Veeam Intelligence (Advanced mode), runs deep malware analysis on backup data, reports threat insights and anomaly details, and can trigger signature-based scans to guide recovery. It requires Veeam ONE 13.0.1 or later.

See Working with Veeam Intelligence for how to access and use the agent.

Accept Detection Findings From Outside the Backup Platform

External cybersecurity and analytics tools (XDR/NDR/MDR/EDR) often identify an infection at an earlier attack stage, and the Veeam Incident API (available since V12.1) lets them notify the Veeam Backup Server so that the affected restore points are marked as infected.

More information about the Incident API, and how backup detection connects with the rest of the security tooling, is covered in External Security Tool Integration.

Use Deception to Surface Reconnaissance Early

Attackers typically probe an environment before acting, and deception gives that probing somewhere to land where it produces a signal instead of a breach:

  • Deploy honeypot servers with obvious, easy-to-guess names (e.g., “vbrsrv01”, “vbrrepo”). These should be deliberately visible, with DNS entries that make them look like easy targets.
  • A well-built honeypot can include a fake repository whose backup file changes act as the trip-wire.
  • Deploy honeypot users the same way (e.g., “VBRAdmin”, “BackupAdmin”), and make sure they are genuinely useless - no real permissions, no real access - so that their compromise carries no risk while their use is a near-certain sign of an attacker probing credentials.
  • Conversely, avoid giving real admin accounts a common giveaway pattern like an adm_ prefix - reserve that kind of naming for honeypots only, since it’s exactly what helps an attacker identify which accounts are worth targeting.

A honeypot is only a detection tool if something is watching it; the monitoring and alerting side is covered under Continuous Activity Monitoring.

Test Detection, Don’t Just Enable It

Detection capability that has never been tested is detection capability nobody can actually rely on:

  • Periodically test backups for malware rather than assuming a backup that was clean once stays that way indefinitely. This is how you can be confident you hold a clean copy of your data when a disaster occurs.
  • Treat a “successful” backup and a “clean” backup as two different things that both need to be verified.
  • Recovery itself is where this matters most: validating a restore point for malware before it reaches production deserves its own discipline, covered in detail on the Clean Room Recovery page.

Common Pitfalls

  • Enabling only one detection method (e.g., inline scanning) and assuming that’s sufficient coverage across the whole backup and recovery lifecycle.
  • Treating a successful backup or restore job as proof of a clean copy of data, without ever actually scanning for malware.
  • Scanning backups once at creation and never rescanning, so malware that was undetectable at the time stays undetected even after signatures and YARA rules improve.
  • Building honeypot accounts or systems that hold real permissions or real data, turning a would-be detection tool into genuine exposure.
  • Leaving malware detection out of the disaster recovery plan, so recovery happens without validating that the restored data is actually clean.
  • Assuming external security tools (EDR/XDR) will independently catch everything, without connecting their findings back to the backup infrastructure that might already hold infected restore points.

References

Table of contents

Back to top

Copyright © 2019 - 2026 Solutions Architects, Veeam Software.
Please note that information provided in this guide is not produced or verified by Veeam R&D but is a result of community effort based on the field observations.