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 🎙