Your LiveGrid system needs tweaking

[McMcbrad 2]

Hi,

I am a malware hunter and I've come across an interesting ransomware sample, which I've also uploaded to you. 

 

What I am curious to know is how a brand new and unknown, unsigned executable with low number of users gets half-way good reputation? Not only all of your technologies failed to stop the encryption on my test, but also your reputation system seems a bit... funny to say it in a polite way.

I am expecting a response from STAFF and not anyone else. 

Edited October 26, 2020 by McMcbrad

[Marcos 5,074]

Given the relatively high number of users the sample cannot be brand new. Brand new samples are unknown to LiveGrid. Please provide SHA1 of the file since it's truncated in the screen shot.

It's also not clear if the sample is detected and if it's actually subject to detection without checking it.

[McMcbrad 2]

https://www.virustotal.com/gui/file/9be3b8dff2d24146e732fa8f81b1a56860b579622e31c991ceaf847ade9717ae/detection

 

You can see the hash in the VT report. I believe I have already mentioned that my system got encrypted on my test with all layers of protection turned on and machine learning setup this way:

The detection engine number is 22213

Edited October 26, 2020 by McMcbrad

[Marcos 5,074]

Since the file was new to LiveGrid, it got medium reputation. Now that it's been blacklisted, it shows risky reputation:

[McMcbrad 2]

So your system assigns medium reputation to brand new samples by default? This is not totally wrong, as when you don't know anything about a file, it's 50/50 whether it's malicious or good. However, from protection point of view, it's not great.

[Marcos 5,074]

Reputation has no effect on protection and showing for instance Windows or other popular applications as red after an update would not be good.

[McMcbrad 2]

Then in that case other protection technologies need to be improved, as I will repeat it again. The sample was missed with quite aggressive machine learning settings in place and my system got encrypted, meaning HIPS, as well as DBI have all failed. Whilst this is a test system and controlled environment, a standard user might come across this sample. Do you believe that user will be protected?

Edited October 26, 2020 by McMcbrad

[McMcbrad 2]

I believe it would be great if you introduce either protected folders - folders where untrusted executables can't perform modifications, or a journaling system that makes backup copies and restores them in case a program has exhibited ransomware-like behaviour. Or maybe even both.

[Marcos 5,074]

2 minutes ago, McMcbrad said:

I believe it would be great if you introduce either protected folders - folders where untrusted executables can't perform modifications,

This can be accomplished using HIPS rules; you can create a rule allowing only specific processes to write into such folders. However, it could be circumvented by malware injecting into trusted processes.

[McMcbrad 2]

This is a very unfriendly way of doing it. Majority of users think trojan horse is one virus and not a whole family. 

Also if you add rule in HIPS, this will either allow/block the action or it will ask the user whether or not they allow modifications. None of these ways stops only UNTRUSTED executables from making modifications. 

And it still doesn't give the option for journaling these important files. 

[Marcos 5,074]

What is the definition of untrusted? We see dozens of thousands of legitimate untrusted files on a daily basis so blocking them could cause a lot of issues. Untrusted would be also a freshly updated Microsoft file if not signed. Also as I have mentioned, malware could inject into trusted processes so such protection could be circumvented relatively easily.

If you are a business user, we strongly recommend trying out ESET Dynamic Threat Defense for instant analysis of files possibly carrying malware in ESET's cloud sandbox.

[McMcbrad 2]

The fact that malware could inject into trusted process can be mitigated in other ways. Creating a HIPS rule that allow only certain apps to access certain folders is madness. Can you list all apps that I have to add to this list? This is a paid product and securing people is your job. It's not their own job to add HIPS rules. That's why we are paying you. If I wanna write HIPS rules I will come join your team.

[McMcbrad 2]

This is wrong.

Also, when someone comes to your forum to provide feedback, the right way you react is to say "Thank you for your feedback, we'll pass it on to the relevant team" instead of falling into explanations what could and could not be done. 

Did you know that you company actually pays testing organisations for this type of feedback? If you didn't then now you do.

[itman 1,659]

I'm curious about a couple things in this ransomware test.

Assuming you're running Win 10 and have SmartSceen set to default settings, did you get a SmartScreen alert when when tried to run this .exe? You should have if the sample was directly downloaded from the web.

As far as TrendMicro's RansomBuster, it along with a whole lot of other security solutions were bypassed here: https://safebreach.com/Post/EFS-Ransomware

Edited October 26, 2020 by itman

[McMcbrad 2]

I am not here to talk about TrendMicro or Windows Defender Smart Screen and neither are you, as this is the Eset's forum. I am here to provide a finding and feedback on how Eset's products could be improved. I can accept any sort of product failure, as this is technology. Important thing is to learn from it and avoid it in the future, which clearly Eset refuses to do.

[itman 1,659]

As far as how Eset Livegrid works, that is clearly explained here: https://help.eset.com/glossary/en-US/technology_livegrid.html .

Of note is the following excerpt from the above:

Quote

Additionally, it implements a reputation system that helps to improve the overall efficiency of our anti-malware solutions. When an executable file or archive is being inspected on a user’s system, its hash tag is first compared against a database of white- and blacklisted items. If it is found on the whitelist, the inspected file is considered clean and also flagged to be excluded from future scans. If it is on the blacklist, appropriate actions are taken based on the nature of the threat. If no match is found, the file is scanned thoroughly. Based on the results of this scan, files are categorized as threats or non-threats.

Elaborating, LiveGrid is a "whitelist - blacklist" mechanism. If the process is neither, then Eset hueristic scanning is employed upon file creation. If not detected at that point, then additional mitigations are employed at file execution time.

[McMcbrad 2]

I am new to ESET's engine and categorisation system, I am used to deny-by-default systems where every executable outside of the whitelist or deviating from a training set with trusted executables is considered malicious. ESET has implemented an allow-by-default system where every executable is considered trusted, unless afterwards proven to be malicious. 

I was not aware that reputation makes little difference in ESET's classification process, hence I have named the thread this way. Furthermore, my question was not how LiveGrid data was utilised in the product, because I already know that. This is not something unique for ESET, others have been doing it for ages too. My question was why a brand new piece of malware has MEDIUM reputation, which was then answered by staff.

However, now that we've learned that reputation plays no vital role in protection, shall we move on saying that ESET's ransomware protection can be improved in other ways? 

Let me repeat these ways again:

1. List of "protected" folders, where only executables with HIGH reputation or digital signature from a trusted vendor can perform changes.

2. Journaling system that works for these folders, copying files and then restoring them in case 1 has failed and ransomware behaviour has been exhibited by any process, be it a highly trusted one.

Edited October 26, 2020 by McMcbrad

[itman 1,659]

6 minutes ago, McMcbrad said:

Let me repeat these ways again:

1. List of "protected" folders, where only executables with HIGH reputation or digital signature from a trusted vendor can perform changes.

2. Journaling system that works for these folders, copying files and then restoring them in case 1 has failed and ransomware behaviour has been exhibited by any process, be it a highly trusted one.

Your points are valid. However, they have been previously requested multiple times by other forum posters.

Eset does not subscribe to the protected folders concept as @Marcos has previously stated.

Edited October 26, 2020 by itman

[McMcbrad 2]

So how will Eset protect against ransomware? 

[Marcos 5,074]

The Protected folders feature is not  not a magic thing that will protect all documents, multimedia files, etc. from 100% of ransomware. We will investigate this particular ransomware to find out if there's a way to improve Ransomware shield to cover it proactively without update.

[McMcbrad 2]

Protected folders is definitely not a magical thing with many potential bypasses, but it's still something worth implementing and it doesn't require any complex engineering from ESET's side, as it can step on the foundation of HIPS. 

File journaling is a much more effective method of keeping user data safe. I don't know how your endpoint products work, this is the first time I am trying ESET, but if they lack journaling too... don't envy corporations relying on you. 

Your reaction time to the threat was ~3 hours, whilst this is lower than others, it's enough to cause harm.

The fact that you will provide proactive protection against this particular piece of ransomware is not too calming, more generic approaches are needed.

[peteyt 393]

1 hour ago, Marcos said:

The Protected folders feature is not  not a magic thing that will protect all documents, multimedia files, etc. from 100% of ransomware. We will investigate this particular ransomware to find out if there's a way to improve Ransomware shield to cover it proactively without update.

While I completely agree with your statement, nothing can be 100 percent, but does that mean we shouldn't put in things to try and stop it? By that logic couldn't we argue that why bother with protection if some kind of malware could theoretically be designed to bypass or disable an AV (yes I know my comparison is slightly different to the issue we are talking about and AVs have tech to stop these).

I do think we will see a lot more people requesting a folder system for ransomware protection. As mentioned before I'd love to see a better system for advanced users for warning them about files with no to low reputation. I get that eset doesn't want to cause issues and confusion for average users but surely that shouldn't mean the more advanced users should go without. Just make it harder to find and enable these things and make it clear when enabling the risks.

[McMcbrad 2]

1 hour ago, peteyt said:

While I completely agree with your statement, nothing can be 100 percent, but does that mean we shouldn't put in things to try and stop it? By that logic couldn't we argue that why bother with protection if some kind of malware could theoretically be designed to bypass or disable an AV (yes I know my comparison is slightly different to the issue we are talking about and AVs have tech to stop these).

I do think we will see a lot more people requesting a folder system for ransomware protection. As mentioned before I'd love to see a better system for advanced users for warning them about files with no to low reputation. I get that eset doesn't want to cause issues and confusion for average users but surely that shouldn't mean the more advanced users should go without. Just make it harder to find and enable these things and make it clear when enabling the risks.

Warning them about files with no to low reputation is great, but that works on products like Norton, McAfee, Kaspersky...Every new executable has low reputation by default, unless it "proves" itself trusted. ESET by default gives these files a chance. This is not a bad strategy but it should be paired with effective BB (or as you call it here DBI), sandbox and more. You can't just rely that static machine learning and dynamic emulation will be good enough to stop everything.

Edited October 26, 2020 by McMcbrad