Jump to content

rapid ransomware detection?


Recommended Posts

I've encountered a rapid ransomware sample around 15 hours ago. At that time, ESET's scanner couldn't detect it (while other major vendors already detected it on VT). The ransomware shield can stop it before it encrypting more of my images. The cloud also detect it as malicious at that time. However the scan engine/cloud blacklisting is still not updated to detect such sample as of now. Wondering if this is expected or not.. the sample is uploaded with the name 713995310B25497E94432F22D262B84EF196AEA3.zip

BTW the scan engine takes a while to scan this 4MB file, which is a bit unusual.

 

https://www.virustotal.com/#/file/487313b869a4d73c9f7288786e70a1660893a9c7243b81ccd49ccc051caf0fa9/detection

Edited by 0xDEADBEEF
Link to comment
Share on other sites

  • Administrators

It is detected now. At the time we received it for the first time the sample didn't reach sufficient confidence level in order to be detected (there was a collision with a legitimate uninstaller), otherwise automatic detection would have been added instantly. Soon Augur will be made more aggressive to block samples like this on download automatically, however, we need to improve performance on the internal anti-FP mechanisms first.

Link to comment
Share on other sites

Is the same story with ESET, over and over again: being the last one to detect a ransomware. Even MSE (free) detected it, alongside with most major AV's.

Link to comment
Share on other sites

  • Administrators
9 minutes ago, novice said:

Is the same story with ESET, over and over again: being the last one to detect a ransomware. Even MSE (free) detected it, alongside with most major AV's. 

I would suggest weighing words. This is a fresh Filecoder.ED:

ESET Win32/GenKryptik.CHZG
Symantec     clean
AVG          Win32/Herz.B
Avast        clean
Avira        clean
Microsoft    clean
DrWeb        clean
Bitdefender  clean
Kaspersky    clean

We do not live in a perfect world where security solutions could detect 100% of malware without false positives. The detection was added within a couple of hours, however, it takes even days for many other vendors to add detection for malware that ESET detects among the first.

Link to comment
Share on other sites

Well, see here:

Detected by Avast!, AVG, Avira, BitDefender, F-Secure, Kaspersky, Microsoft, Sophos, Symantec

Not detected by:  ESET, Malwarebytes, Trend Micro, Webroot

 

ransomware.jpg

Edited by novice
Link to comment
Share on other sites

  • Administrators

I gave you another example where most of the AVs you mentioned failed to detect a new Filecoder.ED that is detected and blocked by ESET.

Link to comment
Share on other sites

  • Administrators

Moreover, one should take VT results with a grain of salt. While it's still showing the malware as not detected by ESET, it actually is:

C:\!test\713995310b25497e94432f22d262b84ef196aea3 - Win32/Filecoder.Rapid.A trojan

 

Link to comment
Share on other sites

1 hour ago, Marcos said:

It is detected now. At the time we received it for the first time the sample didn't reach sufficient confidence level in order to be detected (there was a collision with a legitimate uninstaller), otherwise automatic detection would have been added instantly. Soon Augur will be made more aggressive to block samples like this on download automatically, however, we need to improve performance on the internal anti-FP mechanisms first.

Thanks for the explanation. Looking forward to seeing Augur's improvements

Link to comment
Share on other sites

2 hours ago, Marcos said:

It is detected now. At the time we received it for the first time the sample didn't reach sufficient confidence level in order to be detected (there was a collision with a legitimate uninstaller), otherwise automatic detection would have been added instantly. Soon Augur will be made more aggressive to block samples like this on download automatically, however, we need to improve performance on the internal anti-FP mechanisms first.

This is one area that I still have an issue with Eset detection.

I would still like an option included that would throw a "suspicious" alert in these instances for non-system file detections. I am a very strong believer in the "it is better to err on the side of caution than to pay the price for not doing so" philosophy.

Link to comment
Share on other sites

9 hours ago, 0xDEADBEEF said:

The ransomware shield can stop it before it encrypting more of my images. The cloud also detect it as malicious at that time.

I am confused here.

If Eset's ransomware detection was triggered, was the process terminated and quarantined? Or, was an alert thrown requiring user interaction?

You state the cloud detected it as malicious. Do you mean LiveGrid detected it as malicious? If so, why was the process allowed to run? Or was the LiveGrid lookup processing triggered by the ransomware shield detection? If so, was the file then quarantined?

Edited by itman
Link to comment
Share on other sites

15 minutes ago, itman said:

I am confused here.

If Eset's ransomware detection was triggered, was the process terminated and quarantined? Or, was an alert thrown requiring user interaction?

You state the cloud detected it as malicious. Do you mean LiveGrid detected it as malicious? If so, why was the process allowed to run? Or was the LiveGrid lookup processing triggered by the ransomware shield detection?

the ransomware detection was triggered, the process is terminated and the original binary is quarantined (yes there is a threat prompt). However, some images are encrypted already, and the malware has successfully achieved persistence. So in the next boot the ransomware shield is triggered again, and more files are unfortunately encrypted. The major threat is cleaned only after the second ransomware shield quarantine event.

By saying the cloud detected it as malicious, I was referring to EDTD's detection. The file is marked as malicious by EDTD upon the first encounter already, so I expect it to be blacklisted as suspicious object soon, but apparently as Marcos explained, this doesn't happen due to some FP concerns at that time.

Link to comment
Share on other sites

4 hours ago, 0xDEADBEEF said:

However, some images are encrypted already, and the malware has successfully achieved persistence. So in the next boot the ransomware shield is triggered again, and more files are unfortunately encrypted. The major threat is cleaned only after the second ransomware shield quarantine event.

Thanks for the very informative reply!

Hopefully, this will silence those that believe Eset does not employ behavioral analysis in its ransomware  detection methods.

The downside to behavioral analysis is what you have described. Since encryption per se is also legit activity for a number of processes, malicious encryption activities to a limited degree can occur prior to detection. Some third party anti-ransomware products have tried to use "bait" files in known user directories targeted by ransomware. Effectiveness of the technique has been "so-so." Ransomware creators will randomize their file encryption activities within and across directories to avoid detection. As such, placement of bait files becomes a somewhat "hit and miss" thing.

Which takes me back to whitelisting and anti-exec blocking as the only really 100% effective method. Appears PC Matic has finally gotten their FP scores down to at least tolerable levels in the last AV-Test comparative although they still remain high in comparison to other vendor scores.

Link to comment
Share on other sites

2 hours ago, itman said:

...Eset does not employ behavioral analysis in its ransomware  detection methods.

ok, from where did you get the idea that ESET does employ behavioral analysis in its ransomware detection methods?

Could be only HIPS involved in the process.

Link to comment
Share on other sites

11 minutes ago, novice said:

ok, from where did you get the idea that ESET does employ behavioral analysis in its ransomware detection methods?

Could be only HIPS involved in the process.

Yes, the HIPS employs YARA like behavioral sigs. if you weren't aware of that. For example if the process reputation is unknown, start monitoring it for encryption API usage. If that usage exceeds a predetermined threshold in predefined directories, shut it down.

Link to comment
Share on other sites

This is a bit off topic but relevant.

My "fallback protection" of using Win 10 native SmartScreen to block unknown process execution just got "blown out of the water." Now I knew previously there were ways to "strip" the-mark-of-the-web identifier from downloads. One of my favorite "red teamers" has taken this to a new level in this recent POC: https://www.wilderssecurity.com/threads/av-comparatives-real-world-protection-test-february-june-2018.406045/page-4#post-2774785

Link to comment
Share on other sites

2 hours ago, itman said:

Ransomware creators will randomize their file encryption activities within and across directories to avoid detection

You just said that "Ransomware creators will randomize their file encryption activities within and across directories to avoid detection" so how "If that usage exceeds a predetermined threshold in predefined directories, shut it down" is going to work???

 

11 minutes ago, itman said:

If that usage exceeds a predetermined threshold in predefined directories, shut it down.

 

Link to comment
Share on other sites

1 minute ago, novice said:

You just said that "Ransomware creators will randomize their file encryption activities within and across directories to avoid detection" so how "If that usage exceeds a predetermined threshold in predefined directories, shut it down" is going to work???

The predefined directories would be the ones that ransomware commonly attacks; e.g. user Documents, Pictures, etc.. Note that the "predefined directories" comment was speculation on my part. Eset could be monitoring encryption API usage in other ways also. As far as ransomware randomization techniques, it again would be usually in areas where users store their data files. It doesn't matter if the malware is encrypting in a "zig zag" fashion in these directories since any multiple encryption of files in these areas is suspect.  

Link to comment
Share on other sites

3 hours ago, itman said:

this will silence those that believe Eset does not employ behavioral analysis in its ransomware  detection methods

ESET indeed has behavioral analysis against ransomware from my own testing (and the Beh.XXX family which is used to flag potential ransomware behavior now has more members), it is rare to see it being effective though because most samples are already detected by the scan engine already (some slip through the defense though) ? Actually this is also the first time I encounter a real-world fresh sample being caught by the ransomware shield.

Ransomware shield is the last defense layer in such case with the cost of some files being encrypted. Of course ESET can further implement the roll-back as some other vendors do. But the performance implication and the protection robustness remain a problem.

Still, there is no perfect auto-blocking solution against ransomware so far, while ESET is so insistent on protection with minimal user interaction. I've evaluated several other vendors so-called "ransom shield" designs using white samples or realworld malicious samples. Most of them are effective against typical malicious ransom behaviors, but are also way too sensitive to white programs (some even mark legitimate archive program as suspicious without the help of a sufficiently large whitelist).

Generally not knowing the true intention of a file modification behavior makes recognizing ransomware a particularly hard problem, and one can't expect computer program to fully understand this because sometimes even human can't without careful analysis :( 

Edited by 0xDEADBEEF
Link to comment
Share on other sites

21 minutes ago, 0xDEADBEEF said:

I've evaluated several other vendors so-called "ransom shield"

Have you tried RanSim on ESET? Nothing is being detected , with the explanation: we know that is a simulator, but in real life ESET will behave differently.

Here is the real life: this rapid ransomware sample , where you end up having several files encrypted.

Link to comment
Share on other sites

30 minutes ago, novice said:

Have you tried RanSim on ESET? Nothing is being detected , with the explanation: we know that is a simulator, but in real life ESET will behave differently.

Read my analysis on RanSim here: https://forum.eset.com/topic/10792-ransomware-simulators-a-detailed-analysis/

Link to comment
Share on other sites

57 minutes ago, 0xDEADBEEF said:

Ransomware shield is the last defense layer in such case with the cost of some files being encrypted.

Excellent point.

Additionally, such is the case in a number of the third party anti-ransomware solutions although such facts seldom make it to the mainstream ransomware protection discussions. And as you pointed out, many of these solutions introduce their own set of system and other resident security solution conflicts. 

Link to comment
Share on other sites

25 minutes ago, novice said:

Have you tried RanSim on ESET? Nothing is being detected , with the explanation: we know that is a simulator, but in real life ESET will behave differently.

Here is the real life: this rapid ransomware sample , where you end up having several files encrypted.

RanSim from my view is not a correct way to test ransomware protection. Since itman has more info on that, I will skip those details.

The art of detecting the malware automatically is to precisely locate the difference between it and benign programs. This can be very subtle in some cases because antivirus has limited view on program’s intention. Take winrar as an example, if a bad guy use it to silently batch encrypt all your docs and delete the original files without telling you, this legitimate program is a “ransomware”. In that sense how does an antivirus know if these behaviors should be allowed or not? The answer perhaps is: user prompt. But the truth of such fall back method is essentially offloading the decision back to human, while human ( I mean ordinary users) can be easily fooled to click allow in such case with some social engineering tricks. On the other hand, if the user clicks deny in such case, it is actually the user instead of the AV itself that manage to recognize the ransomware.

So different vendors have different ways to deal with this pain point. Some use whitelist to only allow common program to modify files in key folders. RanSim might be blocked in such case but as soon as one use a legitimate program outside a whitelist, things become troublesome (they might even auto quarantine the legitimate program!) Some simply rely on user decision, but humans are always the weakest part in such attack. Some use heuristic rules to guess if a program is ransomware or not, and this is how ESET and some other vendors deal with this. You have a balance between FPs and detection ratio, and of course malware can play by such rules as AVs can hardly be smart enough.

I feel like with so many different security product, each with a different design philosophy on the market, one have abundant choice to pick a security solution that best fit him/herself. If one wants more control on such events, enabling custom HIPS rules in ESET or change to other security product with more aggressive blocking (and hence FPs) might be a better choice. 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...