Veeam Oxford Style Debate – Episode 4 -Who Should Detect Malware?

I am challenging ​@eblack 

I’ll have to give this one full thought before I answer! :)

I’m taking against on this one.

Most of my view comes from the recovery work we do at Recovery Point. EDR is important and I’d never argue otherwise. It gives you visibility into what’s happening on the endpoint and in the live environment, which is where it belongs. But once you’re recovering from a cyber event, the problem changes shape. You’re not just trying to figure out what happened anymore. You’re also trying to figure out what you can trust enough to put back into prod.

That’s where Veeam’s malware detection has value for us. We use the entropy analysis and YARA capabilities, and we’ve built out our own custom YARA rules around it. Those have been excellent because they let us look for things that matter in the kind of recovery work we’re doing instead of relying only on a generic detection set.

We also use Predatar alongside Veeam for scanning and validation, so we’re not looking at recovery through just one tool or one detection method.

I think that’s where the “distraction from EDR” argument stops for me personally. Nobody on our side is trying to make Veeam into an EDR platform. What we’re trying to avoid is getting into a serious ransomware recovery and then depending on one layer to tell us whether the data we’re about to restore is good.

As we all know, a successful backup job doesn’t mean you have a clean recovery point. Those are two different things, and anyone who’s spent enough time in DR has seen why that distinction matters during a ransomware recovery.

So from my side, I want EDR doing its job in production. I also want Veeam looking at what’s happening in the backup data, our own YARA rules available when we need to dig into something, and Predatar giving us another way to scan and validate before something goes back into service.

I challenge ​@kciolek

AGAINST

I disagree with the statement that using Veeam for malware detection is a distraction from dedicated EDR tools.

EDR solutions are designed to detect, investigate, and respond to threats in real time. They monitor processes, memory, user activity, network connections, and other behavioral indicators to stop attacks as they happen. Their primary objective is prevention and containment.

Veeam’s malware detection capabilities, including Inline Entropy Analysis and YARA Scanning, address a different challenge: understanding the integrity of backup data and identifying potentially compromised restore points. They do not replace EDR, but they provide valuable visibility into an area that traditional security tools often overlook, the backup repository itself.

“How did the attack happen?”

“What is our last known clean recovery point?”

This is where Veeam adds significant value. Inline Entropy Analysis can detect unusual changes in data patterns that may indicate encryption activity, while YARA scanning can help identify known malware signatures within backup data.

Together, these capabilities help organizations make faster and more informed recovery decisions.

Now, I'll pass the microphone to ​@Dynamic 🎙

AGAINST

Thanks DJ ​@Jean.peres.bkp, I take it from here. Jean and ​@eblack covered the recovery side already very good. I want to add the attacker side and one story from a customer.

Ransomware groups try to kill or blind the EDR first, or they go for systems without any agent, like hypervisors, appliances or old servers. And there is one more gap people forget: the backups itself.

One of my customers switched to CrowdStrike Falcon at some point. But servers they decommissioned before were still in the backups. A restore of one of these systems would have brought a machine online without Falcon. On exactly these systems we found malware infected data with YARA rules, and also data a crypto trojan had already encrypted. The EDR could not warn anybody there, because nobody ever installed the agent on these machines.

The second point is time. When new IOCs or YARA rules come out, I can scan weeks of restore points afterwards. Then you know how long it was already in, where it started and which restore point is clean.

To be fair, there are limits:

• Inline entropy can give false positives, e.g. on encrypted databases or compressed archives. Without tuning you get alert fatigue.
• YARA finds only what your rules describe. Custom rules make the difference, like ​@eblack said.
• Scanning costs proxy resources and backup window.
• It doesn’t stop an attack!

So yes, it can become a distraction if nobody owns the alerts. Define who handles a Veeam malware event (backup team or SOC) and put it in the Incident Response runbook. For me EDR stays the tool for production. Before I click on restore, I also want Veeam to check what I bring back.

I guess we will not find many people for the FOR side in this round 😄 Maybe somebody wants to try?
Let me know your thoughts ​@jos.maliepaard 🎙

anyone else? 😀 ​@CMF ​@lukas.k 

Easy one! Thanks for mentioning ​@Dynamic!

I’m clearly against. That’s a short answer though - let me compare this to our good old Windows Firewall.

Many customers are telling me that they disabled it to not cause issues. Another reason is that they don’t trust that “tool” at all and have a “mature” EDV / AV / FW solution. Although I get the point, why not have that additional layer of security, even if that means only catching 5-10%? Why not take this with them and use it in addition to what’s already there (“mature tools”)?

Let me nominate ​@MarvinMichalski

Same goes for this scanning of backups. Two main reasons.

One: You might use different tools and rulesets / technologies to scan production environments, so maybe they catch something that has been missed earlier. Why not take this an add it as an overall layer of reliability?

Two: You scan on a different layer - the “inactive” layer, which is backup data. You can run more detailed and longer scans without affecting production environments and you may detect something even before it affects the production, including some timelining.

Cheers!

Lukas

And we are still waiting on ​@kciolek and ​@jos.maliepaard 😁😋

My apologies, I missed this one. I will get a response out today

I’m AGAINST 

I disagree that Veeam's malware detection capabilities are a distraction from dedicated EDR tools. As a backup engineer with over 25 years in data protection, I see them as another layer of protection, not a replacement for EDR.

Working in the lab, I've explored Veeam's Inline Entropy Analysis, malware detection, and recovery workflows. One thing I've learned is that a successful backup doesn't necessarily mean a clean backup. Even immutability can't guarantee the data was clean when backed up.

Inline Entropy Analysis identifies suspicious patterns that could indicate ransomware encryption, while YARA scanning checks supported backup content for known malicious patterns. Both provide valuable visibility, but neither is perfect. Entropy analysis can produce false positives, and YARA scanning depends on rule quality and coverage.

I don't see Veeam competing with CrowdStrike, Microsoft Defender, or other EDR solutions. EDR detects and contains threats in production, while Veeam helps investigate potentially compromised recovery points.

Think about an attacker who goes undetected for weeks while backups continue running. Even if EDR eventually detects the threat, how confident are we that those backups are clean? That's why security and backup teams need to work together to investigate threats and validate recovery.

I believe our responsibility as backup engineers goes beyond successful backup jobs. We need to help ensure organizations can recover safely after an attack.

Would I rely solely on Inline Entropy Analysis or YARA scanning? Absolutely not. But would I want those capabilities available during ransomware recovery? Absolutely.

My bottom line - EDR helps protect production. Veeam helps protect our ability to recover. That's not a distraction; that's defense in depth and cyber resilience.

​@lucasmagnum I can see you liked this comment so I thought I would challenge you too 😁

hi, I was offline last week and missed this one. i see everyone is against, let me think about the FOR motivation, unless there is no time anymore.

​@jos.maliepaard we need a FOR in here ;)  

Also I am challenging ​@leaha and ​@morgan.munck 

AGAINST.

I agree with the points about recovery and historical analysis, but I would add an operational question: How long does it take us to decide which restore point we can trust enough to recover?

During an incident, having multiple backups available does not eliminate the difficult decision of choosing a reliable recovery point. If the investigation only starts after an outage, analysis time competes with the recovery process itself, including application validation. That's why I see value in incorporating backup analysis into recovery preparedness, with defined priorities and resources.

I would also challenge the idea of adding "another layer" without considering its operational purpose. Who investigates the alerts? How are they correlated with EDR findings? Who approves the recovery point? Without a defined workflow, concerns about alert fatigue and operational overhead are valid.

The SOC can provide threat intelligence and help validate YARA rules, while the backup team can apply them to supported restore points and provide evidence for the investigation. Both teams contribute to the same recovery decision.

One important distinction: "No detection" describes the result of a particular analysis, using specific rules and coverage. Entropy analysis can identify encryption activity and suspicious artifacts, while YARA identifies patterns defined by its rules. Neither guarantees a clean recovery point. Security checks and application validation are still necessary before returning workloads to production.

I would measure the value through metrics such as time to identify a candidate restore point and total time to recover the service.

These capabilities can reduce the uncertainty that delays recovery — and that is directly connected to the mission of backup.

If we cannot confidently justify which restore point to recover, that uncertainty needs to be part of our RTO planning.

I am challenging ​@lucasmagnum !!

​@Madi.Cristil challenge accepted 😊

AGAINST

I believe we are looking at this discussion from a rather limited perspective when comparing Veeam's capabilities with dedicated EDR solutions.

In my view, we need to distinguish between two responsibilities: identifying a threat in the production environment and ensuring that we are not bringing that same threat back into the environment during a recovery process.

EDR plays a fundamental role in identifying and responding to suspicious behavior. However, the backup process has an important characteristic: it preserves historical data, including data from periods when a threat had not yet been identified.

I have personally experienced a situation with a customer where the environment remained compromised for several days before the incident was identified. During that period, backups continued running normally. In this case, having restore points available did not necessarily mean we had safe recovery points to use.

This is exactly where I see value in Entropy Analysis and YARA. They add a different perspective to the investigation, allowing us to analyze protected data and look for indicators of compromise that might have gone unnoticed during normal operations.

There is another point I consider important: responsibility for safe recovery should not end when a backup job reports success.

We need to evolve the way we think about backup. A data protection strategy should not be evaluated solely by its ability to store information, but also by its ability to provide reliable recovery conditions.

Another important aspect is performing restore tests in customer environments. This practice has become part of my daily routine as a backup analyst, and I believe it should be adopted as a best practice in any data protection strategy. After all, having backups is not enough; we need to periodically validate our ability to recover.

I don't see Veeam trying to take over the role of an EDR solution. Instead, I see these technologies working together as different layers of the same security strategy.

Ultimately, protecting data is important, but ensuring that we can recover it safely is what truly demonstrates the resilience of a backup strategy. 🚀🚀🚀🚀🚀🚀

Challenge accepted, my friend!! 🤓🤓

I’m FOR because everyone else is against:

it’s a though one so let’s give it a try:

Veeam only finds malware when it scans a backup or during restore. The machine has already been infected, often for days or weeks. A good EDR tool blocks / isolates at execution time.

EDR sees process tree, memory, network connections, lateral movement, command-and-control. Veeam just sees static files in a backup image. It can't tell you how it got in, what ran, or what was exfiltrated.

Backup scans flag cracked tools, AV signatures in old files, or dormant samples in downloads folders. That creates noise and distracts the SOC from real active threats that EDR prioritizes.

EDR can kill process, and isolate networks. Veeam can only say "this restore point is infected" It doesn't stop the current outbreak.

Modern ransomware runs in memory, registry and legitimate “LOLBins”. Those often don't leave a simple file signature for a backup scanner to catch, but EDR behavior analytics will.

Scanning full backups for malware is resource-heavy and delays backup\restore SLAs. Running that continuously to compensate for weak EDR is the wrong tradeoff.

Creates a false sense of security. Teams think "we'll just restore a clean VM" but if you don't have EDR telemetry, you'll restore into the same unpatched, still-compromised environment with all the risks.