Jump to content

ESET failed to protect against ZeroCrypt ransomware


Recommended Posts

  • Administrators

Unfortunately, the detection created by an automated system was removed during a purge of simple automated detections in 2018 after 2 years of no detection of the malware from 2016. We've created a smart generic detection for it and the file is already blocked.

Link to post
Share on other sites
1 hour ago, Marcos said:

Unfortunately, the detection created by an automated system was removed during a purge of simple automated detections in 2018 after 2 years of no detection of the malware from 2016. We've created a smart generic detection for it and the file is already blocked.

I see. But shouldn't the Ransomware shield and other modules be still able to detect the behavior of this ransomware and tell the user about it? In this case it didn't.

Link to post
Share on other sites
3 hours ago, SeriousHoax said:

But shouldn't the Ransomware shield and other modules be still able to detect the behavior of this ransomware and tell the user about it?

Next time you test malware, put in some effort to duplicate how malware is actually run. It is not run from the desktop via user manual startup.

Setup the malware to run from directory or registry startup location simulating boot execution of the malware. Or run it from a script via one of the script processes simulating on demand execution.

As far as machine learned detection, this is an old ransomware sample and as noted, was deleted from the Eset malware repository some time ago. As such, its behavior would not have been included during Augur's training period. Again, Eset does not detect per se en-mass encryption activities against files in the user directories. If you want that kind of protection, you will have to employ one of the third party anti-ransomware solutions. And there are published POC's where those solutions have been bypassed by 0-day ransomware.

Link to post
Share on other sites
  • Administrators

Massive encryption activities themselves are not enough for recognition of ransomware since encryption per se is not a bad thing and is often used for legit reasons. An example could be moving files to a password encrypted archive. Although it's not very common, the action itself is not malicious if carried out with the knowledge of the user.

Anyways, we'll check what conditions were not fulfilled in order for RS to trigger detection.

Link to post
Share on other sites
3 hours ago, itman said:

Next time you test malware, put in some effort to duplicate how malware is actually run. It is not run from the desktop via user manual startup.

Setup the malware to run from directory or registry startup location simulating boot execution of the malware. Or run it from a script via one of the script processes simulating on demand execution.

As far as machine learned detection, this is an old ransomware sample and as noted, was deleted from the Eset malware repository some time ago. As such, its behavior would not have been included during Augur's training period. Again, Eset does not detect per se en-mass encryption activities against files in the user directories. If you want that kind of protection, you will have to employ one of the third party anti-ransomware solutions. And there are published POC's where those solutions have been bypassed by 0-day ransomware.

I don't think it matters and it's not a good way to defend ESET here. Imagine an user downloading a cracked version of a program or lets say a pirated game. Pirated games doesn't often comes with malwares unlike pirated softwares. But if the crack file was replaced by the uploader with this ransomware exe then the user's data would've been compromised and ESET would be blamed for not being able to detect that by their signatures or other modules. For this ZeroCrypt ransomware, it's good to know that ESET has added signature again.

2 hours ago, Marcos said:

Massive encryption activities themselves are not enough for recognition of ransomware since encryption per se is not a bad thing and is often used for legit reasons. An example could be moving files to a password encrypted archive. Although it's not very common, the action itself is not malicious if carried out with the knowledge of the user.

Anyways, we'll check what conditions were not fulfilled in order for RS to trigger detection.

Now this is a nice response. It would be nice to know what conditions were not fullfilled. I like it ESET and only want it to get better so that's why I posted this.

Edited by SeriousHoax
Link to post
Share on other sites
  • Most Valued Members
4 hours ago, Marcos said:

Massive encryption activities themselves are not enough for recognition of ransomware since encryption per se is not a bad thing and is often used for legit reasons. An example could be moving files to a password encrypted archive. Although it's not very common, the action itself is not malicious if carried out with the knowledge of the user.

Anyways, we'll check what conditions were not fulfilled in order for RS to trigger detection.

Could eset not have an option to detect any encryption and warn the user. As you stated average users probably wouldn't use encryption so if there was an option that warned everyone these users would then probably know it was dangerous as they aren't encrypting something.

Does windows itself encrypt files without a user telling it to - as that is the only issue if windows was doing encryption and it was getting flagged.

1 hour ago, SeriousHoax said:

I don't think it matters and it's not a good way to defend ESET here. Imagine an user downloading a cracked version of a program or lets say a pirated game. Pirated games doesn't often comes with malwares unlike pirated softwares. But if the crack file was replaced by the uploader with this ransomware exe then the user's data would've been compromised and ESET would be blamed for not being able to detect that by their signatures or other modules. For this ZeroCrypt ransomware, it's good to know that ESET has added signature again.

Now this is a nice response. It would be nice to know what conditions were not fullfilled. I like it ESET and only want it to get better so that's why I posted this.

The video is better than most videos as most I have seen disable key things and then run the virus and then claim eset is bad trying to ignore the fact they made eset bad by disabling the stuff that would have detected it.

However - like a lot of these videos it doesn't show everything. Would eset have blocked the virus from downloading in the first place - that is the key thing. Eset might not have picked it up when it was run but that doesn't mean it didn't detect it being downloaded and the uploader may have had to disable eset to download the virus - which means eset was protecting the user they just chose to ignore it.

Link to post
Share on other sites
  • Most Valued Members
1 hour ago, itman said:

There's a detailed analysis of ZeroCrypt ransomware here: https://www.hybrid-analysis.com/sample/08f194844dafe43972c507da7f75f98cd0e7bddae9011b482da60d80b281967b?environmentId=100 .

Aside from the forked ADS stream, there isn't a lot of obvious fromt-end malicious behavior to it.

Maybe you can answer this question - I have windows 10 pro - I do not encrypt anything - I have played around in the past with securedata for testing purposes but that is it. Does windows do any encrypting itself without a user enabling it.

Basically if windows does not encrypt anything without a user enabling it and average users do not encrypt stuff could an AV not use this to implement an allowow/deny kind of process e.g. we have detected something attempting to encrypt files if you have not initiated this it might be ransomware and the user can allow it e.g. if they were the ones running it or block it.

Now I know ransomware will hide the fact it is ransomware but would an AV be able to detect the encryption itself before it did any damage? Maybe even have an option to block encryption which could be enabled/disabled in the settings that would automatically block any kind of encryption of files.

Link to post
Share on other sites
22 minutes ago, peteyt said:

Does windows do any encrypting itself without a user enabling it.

https://docs.microsoft.com/en-us/windows/win32/seccrypto/cryptoapi-system-architecture

Additionally, applications use the Win crypto API to protect their own sensitive data.

Using Process Explorer, display some app .dlls. One that you will find used extensively is crypt32.dll.

Edited by itman
Link to post
Share on other sites

Now this is strange. When I link to VT per the above Hybrid-Analysis posted link, it show Esets detects per this definition, Win32/Filecoder.ZeroCrypt.A. However when I search the VirusRadar database for it, nothing is found?

Link to post
Share on other sites
  • Most Valued Members
2 hours ago, itman said:

https://docs.microsoft.com/en-us/windows/win32/seccrypto/cryptoapi-system-architecture

Additionally, applications use the Win crypto API to protect their own sensitive data.

Using Process Explorer, display some app .dlls. One that you will find used extensively is crypt32.dll.

I did wonder but it's something I have been curious about for a while so thanks for the link. I persume ransomware could also abuse/hijack this so adding microsoft ones into a whitelist and warning about others would not be a reliable option? 

Link to post
Share on other sites
7 hours ago, itman said:

Now this is strange. When I link to VT per the above Hybrid-Analysis posted link, it show Esets detects per this definition, Win32/Filecoder.ZeroCrypt.A. However when I search the VirusRadar database for it, nothing is found?

The signature is recently added. When I checked virustotal last night the file was last scanned 11 hours ago and wasn't detected by ESET. Then I rescanned and this time ESET was detecting it.

Link to post
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...