Hello Community!
Synopsis
I couldn’t wait to get this out to you all. If you’ve been following along my Veeam Malware Detection journey, specifically with Inline Entropy scans, you know I’ve shared it has some shortcomings; although, it’s still a great tool to implement in your environment in my opinion.
The post today coincides with my most recent Malware Forensics post on how to work through events you may receive from Veeam. Click below to read it if you like:
Since my Forensics post a few weeks ago, Veeam has provided a few updates to its Malware Detection engine.
Updates
The first update came with the latest Veeam Backup release, v12.1.2. Much of the Malware updates in this release came mostly from Community feedback on the Forums and pertained mostly to the File System Analysis (FSA) engine. I don’t use that engine in my environment, so not sure how well the update has worked with regard to FSA detection, false positives, and exclusions.
The 2nd update is specifically for the Inline Entropy Scan engine. It’s a manually-applied fix to help with Onion Link detections. Since the v12.1.2 release the end of May/early June, Veeam Mawlare scans were detecting a lot more onion links, which, after further investigation (via A/V and YARA scans) ended up being false positives. The types of onions Veeam found were browser (Chrome, Edge) cache files. I’m not sure why Google & Microsoft feel the need to use onion files in their browser cache (I haven’t researched on that), but those files are “safe”. If you’re experiencing an increase in Inline Entropy Onion events and feel they have been these kinds of false positives, just reach out to Veeam support and ask for the fix. The fix is simply a .zip file containing to 2 binary files which need to be placed on any Proxies you use in your Veeam environment → one for Linux (libRansomwareStats.so) and one for Windows (RansomwareStats.dll). Since applying the fix in my environment, I have yet to have an Onion event, so job well done Veeam! 
The 3rd update was just shared on another Forums post by Veeam Product Manager Dmitry Popov. And this one is a much anticipated fix. Veeam Developers created a script tool you can use to help find the actual file associated with Inline Entropy Encryption events! This is amazing! The process is this:
- Get the ID of the Encryption Malware event, using Powershell
- Use this event GUID within Veeam’s “find-encrypted-data.ps1” script
a. Veeam then compares the ransomware index (ridx file on the Proxy) of the Restore Point associated with the current Encryption event ID with the previous Restore Point’s ridx file to determine which disk offsets should be investigated - Veeam then mounts the Restore Point for investigation and checks the files associated with the offsets identified
- Each file associated with the suspect offset is checked to determine how much encryption is present in the file's first megabyte
- Then, the file path, its offset, and the percentage of encryption in the first 1MB are then output to a results CSV file which you can review to determine potential file infection
To download this new update script and read/learn more about the process, including Considerations and Limitations for its use, you can go to the following Veeam KB:
https://www.veeam.com/kb4632
Additional Info
I also wanted to clarify one last piece of information with regards to Managing Malware Status events as shared in the User Guide. If you determine a Malware event is a false positive, you need to mark the VM as “clean” in the Inventory node. In the Malware Events section, rt-click the VM, and select to Mark as clean. Do not mark individual VM Restore Points as clean within the Home node (Backups > Disks section). Marking a VM clean in the Inventory node will enable Veeam to not mark subsequent/future Restore Points as Suspicious for the same file/detection event type. Future Restore Points will be marked as Suspicious only if there is a new detection.
If you mark individual VM Restore Points as clean in the Home node, future scans/Restore Points are not affected and Veeam will still mark future Points as Suspicious. So keep that in mind. The Home node area should be used only for past Restore Point cleanliness. For example, if you run an A/V and/or YARA scan against a range of Restore Points for a given VM and determine all those Restore Points are clean, you would use this Home node area to mark those past Restore Points as clean, then also go into the Inventory node to mark the VM clean so future scans won’t show “Suspicion” for the same detected event. I hope that makes sense. Let me know if not.
And there you have it...a few things which should hopefully make your Malware scans a bit…..”cleaner” 
Let me know if you have any questions.
