.locked files & Virus software issue

[keith Drayton]

We are running Backup & replication 10, Installed a couple months back, Nothing has changed with the Veeam server or our McAfee policies as far as i am aware,
We do not have exclusions set for the Veeam directories in the McAfee polices and i now this would be the simple option but as it has not been needed until now i want to check what is happening.

Event viewer is filling with errors similar to this,

C:\Program Files\Veeam\backup and Replication\Console\veeam.backup.shell.exe which tried to access the file C:\ProgramData\Veeam\Backup\Console\localhost\Console_Veeam_Administrator.9.log_xxxxxxxx.locked violating the rule 'file creation of dot locked files' and was blocked

This is not just the console folder,
xxxxxxxx is a mix of numbers & letters,

Are these .locked files genuine?
i assume its the open version of the logs,
We are generating a lot of logs because of this which is filling the C drive,

As i say never been a problem until a couple days ago, now multiple errors per sec, eventually McAfee consumes so much server memory everything else runs into trouble and Veeam collapses.
If nothing has changed why has it started being a problem now?

Thanks

[PetrM]

Hi Keith,

An issue would not occur if there were no changes, apparently something was changed but we just don't know what exactly.
For instance, antivirus software updates could introduce some changes which might have side effects.

Let me please share some suggestions:
1) I would recommend to follow the instructions of this KB to configure antivirus exclusions and to double check if the issue reoccurs.
2) You may take a look at this KB on McAfee Knowledge Center, looks like it contains some similar examples.
However, I would recommend to clarify possible reasons of the error message from your event logs with McAfee support team.
3) You may contact our support team as well and ask them to identify a process which holds file lock (for example using Process Monitor tool).
4) You can control Veeam log files retention using registry values which are described in this KB.

Thanks!

[yavor.indzhev]

Hello,

We have big amount of alerts like:

domain\user ran D:\Veeam\Backup\Veeam.Backup.WmiServer.exe, which tried to access the file D:\Veeam_logs\WmiServer.BackupSrv.9.log_a0c341d7.locked, violating the rule "Ransom-Goga 1", and was blocked. For information about how to respond to this event, see KB85494.

The alerts are from 2-3 different veeam processes, and always related to their corresponding log files. Both path are the actual paths where veeam and veeam logs are kept.

I saw an old topic regarding the same:

vmware-vsphere-f24/locked-files-virus-s ... 66734.html

From the answer I can assume that .locked files are expected to be created by veeam, and the whole folders can be excluded as per article: https://www.veeam.com/kb1999

The problem is that I already have a ticket to veeam support and the agent insist that veeam doesn't generate .locked files at all, and we can assume this is a ransom attack. Because of this we stopped all veeam servers and our security team is investigating.

As you can see I have contradicting information so far, but the fastest path to re-activate all backups is somebody from veeam to confirm that veeam processes may actually create .locked files (if this is the case at all. this is more an assumption at this point).

In addition - we have the same problem in 2 completely separated environments. The only common thing between them is veeam.

Thank you

Y.

[wishr]

Hi Yavor,

I presume this is normal as one of the VBR services is writing data to the log file. In this particular example, it looks to be the WMI server process responsible for providing data for Veeam ONE and Veeam MP, our monitoring solutions (regardless of their presence in the environment).

Could you please share your support case ID? I'll check the details to confirm.

Also, I'm merging your post with the thread you linked since this is the same topic.

Thanks

[yavor.indzhev]

Hello,
The number is 04488731

The question basically is - when veeam is writing data to a log file does it create a (probably very temporary) .locked file in the process? Because the whole alert is because of the extension of the file - ".locked"

A clear answer of this question will allow us to turn on all veeam servers again and start our backups.

Thank you

[wishr]

Hi Yavor,

I can confirm that .locked files are created by VBR, as a part of the log removal optimization process, so it's safe to ignore the warnings you see in McAfee AV software because they are false-positives and you may configure exclusion rules as stated in the aforementioned KB article.

Honestly, I'm a little surprised they simply look into the file extension to detect the presence of ransomware, but from our point, we'll see if there is a way to change/improve the log removal logic in future versions.

Hope it helps. Thanks.

[yavor.indzhev]

Yes, I received the same.
Thanks for the help.

This is a custom rule added in our AV system, but is a recommendation from Mcafee regarding this specific ransomware Ransom-Goga 1. Chain of unfortunate events

Thanks again

BR

Yavor

[wishr]

Hi Yavor,

You are welcome.

Just to be sure, could you please let us know what is the detection logiс in the rule? Is it simply the file extension or something else?

Thanks

[yavor.indzhev]

File extension only.
Even if I try to make an empty file "test.locked" on the desktop, Mcafee will log it as suspicious and will not allow it.

[wishr]

Hi Yavor,

Thanks for confirming. This is definitely a wrong approach to ransomware detection . We'll try to reach McAfee on this topic.

[yavor.indzhev]

I think our security team followed the following KB:

https://kc.mcafee.com/resources/sites/M ... erGoga.pdf

This is a custom rule, suggested by McAfee, but not there by default.

BR

Yavor

[wishr]

Thanks for the info, Yavor. We are in touch with the support team as well and they passed me the same information.

[Dima P.]

Hello Yavor,

Thanks for bringing this topic up, talking with McAfee team. I'll update this thread with the news. Cheers!