McMcbrad

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.

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.

So how will Eset protect against ransomware?

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.

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.

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.

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.

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.

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.

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?

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.

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

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.