Malware detection, Ransomware Notice found

[GaborCs]

ok, so I can confirm that I don't get any malware reports after the backup jobs, which means that the fix works. Thanks a lot to all who have been involved!

same situation here, no more false positive reports
Thanks for the fix

[Stabz]

Hello guys, I m playing with the Malware detection feature and Yara rules. I would like to know before to give you my feedback, does this onion yara rule check inside the files too ?:

r

Code: Select all

ule OnionLinks
{
    meta:
        description = "Onion link"

    strings:
	$onion_linkv2 = /\b([a-z2-7]{16}\.onion)\b/i
        $onion_linkv3 = /\b([a-z2-7]{56}\.onion)\b/i

    condition:
	any of ($onion_linkv2,$onion_linkv3)
}

[Dima P.]

Hello Philippe,

Yes you can use this rule to search for the text inside the files. Thank you!

[Chrispyyy]

Requested private fix through support as we had a couple of VMs constantly reported onion link.
This resolved it for us, many thanks - and may it reach the official build in the next release.

[coolsport00]

Hey @Dima -
On a particular VM, its restore points are still getting 'flagged' as suspicious, although I'm not getting daily email notifications of a potential "malware event". What I think is happening is the scanning is "ok", but I have old restore points that weren't, and I left them that way (left them marked as 'malicious'). What I've been doing is marking each daily backup restore point as fine (clean). What I would like to see happen is Veeam not mark subsequent backups as 'suspicious', as long as what Veeam is finding is the same thing which was marked as "clean" by me. Make sense? Any way around this? I could exclude the VM I guess...but would rather not do that. Thoughts?
Thanks.

[Dima P.]

Hello Shane,

What type of malware event is that? Thank you!

[coolsport00]

That's just it Dima...I'm not getting an "event"..i.e. no email or anything in History. But, after each subsequent backup job this VM is in, the VM's restore points are marked by Veeam as 'suspicious'.

[Dima P.]

That's... new! Can you please raise a support case, share the case id and we will review the logs! Thank you Shane!

[coolsport00]

Yep...will do.

[coolsport00]

Hi @Dima -
Case is #02682898.

Thanks.

[coolsport00]

@Dima -
I think I know what was happening with this particular VM. First, the Guide was slightly confusing on how things work when marking Restore Points (RPs) as clean or not. For Veeam to not mark subsequent/future RPs as Suspicious after determining an 'event' was a false pos by via A/V and/or YARA scans, etc., you have do say this for a VM(s) in the Inventory node (rt-click VM > Mark as clean). The current RP Veeam detected to be Suspicious, and all future scans of the VM, will then be ok, UNLESS Veeam finds a different/new "suspicion".

What I was doing was marking RPs as clean in the HOME node: Backups > Disk section, rt-click Job > Properties, selecting the VM, then marked each RP as clean which Veeam was marking as Suspicious. The Guide doesn't say doing this manual task would not mark *future*/subsequent RP scans as Suspicious. As such, all subsequent backups/scans of this VM were being marked Suspicious; but oddly, I was getting no malware event notification...I guess because it wasn't "new". It was the same event as initially Veeam found 2wks ago. I think this manual marking area is for when one does an A/V and/or YARA scan of a VM against a range which includes various RPs. If the scan(s) come back fine, then you would want to mark those RPs as fine also (i.e. clean). This would mean just those RPs you mark are ok and would have no bearing on future scans. How to make future RPs be marked ok by Veeam is to do so in the Inventory node as I shared above.

So, I think we're squared away here. Again, just slight confusion on how I was interpreting the User Guide 'Managng Malware Status' section.
Thanks!

[Dima P.]

Hello Shane,

Thank you for the case ID and for the provided description. Yes, the behavior is expected as marking restore point as clean does not actually mark the machine clean. The inventory node is a way to go!

[Dima P.]

Hello guys,

For those who wanted to investigate the 'Encrypted Data' malware event and get the path of the questionable files we've prepared a tool and scripts that allows you to get all the needed information (Encrypted block and offsets from the original source disk from Veeam B&R database) and match those with file system from the backup file in the question during mount operation. While mount is performed we can gather the information about such files and paths and collect all that in a dedicated csv file.

One note to keep in mind: this tool / scrip works only for the Encrypted Data malware events created with the latest Veeam B&R patch 12.1.2.

Please take a look and let us know how it works for your envirioment How to Investigate 'Encrypted Data Event' from Malware Detection. Thank you!

[Stabz]

Hello

I m playing with the inline malware detection.
On a test server I created a file with only an onion link in it, my link "rnfdsgm6wb6j6su5txkekw4u4y47kp2eatvu7d6xhyn5cs41t4pdrqqd.onion"

At the end of the backup job I got un event Malware detection, detection source : Onion link
But when I used the YaraRule, my file is not detected... Any idea?

[coolsport00]

Hello guys,

For those who wanted to investigate the 'Encrypted Data' malware event and get the path of the questionable files we've prepared a tool and scripts that allows you to get all the needed information (Encrypted block and offsets from the original source disk from Veeam B&R database) and match those with file system from the backup file in the question during mount operation. While mount is performed we can gather the information about such files and paths and collect all that in a dedicated csv file.

One note to keep in mind: this tool / scrip works only for the Encrypted Data malware events created with the latest Veeam B&R patch 12.1.2.

Please take a look and let us know how it works for your envirioment How to Investigate 'Encrypted Data Event' from Malware Detection. Thank you!

Heck yeah! Thanks @Dima! Please pass along our appreciation to your Devs. I haven't had an 'encrypted data' event in a while...not sure I can run this script on past systems? But, anxious to see how this works nonetheless.

Best.

[coolsport00]

Hello

I m playing with the inline malware detection.
On a test server I created a file with only an onion link in it, my link "rnfdsgm6wb6j6su5txkekw4u4y47kp2eatvu7d6xhyn5cs41t4pdrqqd.onion"

At the end of the backup job I got un event Malware detection, detection source : Onion link
But when I used the YaraRule, my file is not detected... Any idea?

@Stabz - was the Yara scan from within Veeam, or a manually ran scan directly on the VM?

[Stabz]

the Yarascan hab been lauch from Veeam. I didn't test from a manual scan I dont have the tools on my server.

[coolsport00]

@Stabz - ok...was curious if it was manual or from Veeam.

[coolsport00]

@Dima and PM team -
Just FYI...I haven't had a Malware event since I implemented the changes to the Inline scan engine (updated Proxy files fix). It's been so "quiet" that I wonder if Malware detection is even working now (btw..I'm sure it's working fine)

[Dima P.]

Hello Shane,

Thank you for the update and glad to hear that our false-positive fix for onion links works as expected!

[coolsport00]

@Dima -
I know we talked a bit in Berlin about Inline Entropy Malware engine. Overall, the above change you guys added with the 12.2 release (I got the fix beforehand) works way better than initial release. But, I've been getting false positives on Linux VMs..standard Ubuntu OS and Linux appliances, when software/package updates are done on those VMs. I get an 'Encryped Data' alert from Veeam. Anyway this can be addressed?
Thanks.

[Dima P.]

Hello Shane,

We've got similar issues couple a times, but to understand it better can I ask you to raise a support case? We might need to collect some metrics from logs to understand why false-positive is created. Thank you!

[coolsport00]

Yep...assumed that would be the case, but wanted to 'ping you' first. Will keep you posted.

[coolsport00]

Case submitted Dima (support site was down for quite a while). Case# 07524714
Thanks.

[stewsie]

Hello guys,

For those who wanted to investigate the 'Encrypted Data' malware event and get the path of the questionable files we've prepared a tool and scripts that allows you to get all the needed information (Encrypted block and offsets from the original source disk from Veeam B&R database) and match those with file system from the backup file in the question during mount operation. While mount is performed we can gather the information about such files and paths and collect all that in a dedicated csv file.

One note to keep in mind: this tool / scrip works only for the Encrypted Data malware events created with the latest Veeam B&R patch 12.1.2.

Please take a look and let us know how it works for your envirioment How to Investigate 'Encrypted Data Event' from Malware Detection. Thank you!

Downloaded this.

Be aware that this needs to be run by an accounbt that doesn't use MFA and if you have changed the installation location for Veeam B&R you need to edit the script

class CatalogFsLib
{
static [String] $LibPath =

And input the file path where Veeam was installed

[coolsport00]

@Dima -
I opened a case but am getting the runaround from the Support Engineer. Maybe I misunderstood here. I opened the case so your Dev team (?) can do further investigation on the cause of the events after software upgrades on the Linux VMs. At least, that's what I thought was going to happen. Instead, the Support Engineer is going through a troubleshooting process, which I don't need to do....as I obv understand how Malware works. The Engineer said he can't escalate the case, as I had already requested. Thoughts on how to proceed?
Thanks.

[Dima P.]

I saw that you've asked support team to put it on hold and notified them that the case has been opened because I've requested it, thank you! Let us review those logs now, I'll let you know if anything else is needed!

[coolsport00]

Ok, thanks Dima. I'm not meaning to be difficult ...I just want to make sure your and my time is best utilized for this issue is all, and see if it can even be resolved.

[Dima P.]

No problem, thank you for the report Shane! QA team is aware and looking at the logs. I'll update this thread with the investigation results.

[coolsport00]

Hi @Dima -
I received word back from Michael at Support and he shared with me what the QA team found out. Kind of interesting the logic involved in determining an 'Encryption' event with Inline Entropy. I'm not sure what can be done to make this better for VMs (for me, it's Linux-based VMs) with small OS disk sizes...