Jump to content

Eset Effectiveness In Recent Worldwide Ransomware Incident


itman
 Share

Recommended Posts

Thanks for always giving me good information. :)

Edited by NOD
Link to comment
Share on other sites

On ‎6‎/‎29‎/‎2017 at 9:36 AM, itman said:

Eset was the only vendor to completely block the EternalRomance exploit attack vector in this incident:

https://www.mrg-effitas.com/eternalromance-vs-internet-security-suites-and-nextgen-protections/

But after analyzing the disclosed exploits, Microsoft security team says most of the windows vulnerabilities exploited by these hacking tools, including EternalBlue, EternalChampion, EternalSynergy, EternalRomance and others, are already patched in the last month's Patch Tuesday update.

hxxp://thehackernews.com/2017/04/window-zero-day-patch.html

 

Link to comment
Share on other sites

9 hours ago, MSE said:

But after analyzing the disclosed exploits, Microsoft security team says most of the windows vulnerabilities exploited by these hacking tools, including EternalBlue, EternalChampion, EternalSynergy, EternalRomance and others, are already patched in the last month's Patch Tuesday update.

Yikes! The test was done on an unpatched OS to test each security solution's effectiveness in that scenario.

Link to comment
Share on other sites

One more thing, though! ESET is the only one which has a "name" for the blocking, see the picture attached. That means is signature based and not heuristic/behavior, etc.

All the other vendors have generic detection on the exploit, most likely employed by other mechanisms than signature.

 

Untitled.png

Link to comment
Share on other sites

The MRG test was done using both Win 7 and Firefox. As such, browser based SmartScreen detection would be N/A. Whether SmartScreen would detect the exploit activities if IE11 or Edge was used remains to be determined. This is doubtful since the exploit activities were perform internally in the network to spread the ransomware from device to device. The only thing #NotPetya originally downloaded from the Internet would have been the .dll payload. Finally, this ransomware not only propagated through the network by exploit by also used PsExec as a network propagation attack vector. The MRG test was only for the EternalRomance exploit network propagation attack vector.

One of the multiple attack vectors employed by #NotPetya was a "waterhole" attack via drive by download from a popular Ukrainian infected web site in its capital city. Just accessing the web site would have resulted in the download.

Eset blocked #NotPetya exploitation activities, EternalBlue or EternalRomance - both were attack vectors, via its CVE exploit detection mechanism in its IDS protection mode within Smart Security. #NotPetya also attempted to attack via SMB access to Admin shares which Eset's IDS also protects against. Eset would have block the #NotPetya .dll payload via DNA signature since #NotPetya  was a modified version of the Petya malware sharing much its code.

FYI - the #NotPetya attack was successful due to the fact that there were a number of commercial concerns that had at least one unpatched server on their network. As such, the MRG test was appropriate.   

Edited by itman
Link to comment
Share on other sites

Thank you for your in depth explanation...however, I have to be honest and say that I did not understand more than 10%!!!

My question was a simple one: when ESET detected the exploit , already provided a name for it (Eternal Romance Synerg...); that means the detection is signature based, which is fine, but my expectation is to have some sort of generic detection, not based on a signature.

Today, ESET was lucky to have the signature; what about tomorrow, when another ransomware will appear and ESET will not have a signature for that????

Link to comment
Share on other sites

  • Administrators
5 hours ago, MSE said:

Today, ESET was lucky to have the signature; what about tomorrow, when another ransomware will appear and ESET will not have a signature for that????

Given that ESET was initially one of 3 security solutions to protect against the exploitation of the EternalBlue vulnerability, do you assume that the other 2 vendors had already magically protected against it when the vulnerability was not yet known to Microsoft? And then why only 3 vendors were able to protect weeks after releasing the patch by Microsoft? Weren't the other vendors too slow? :)

Link to comment
Share on other sites

The other vendors detected the exploit using  different mechanisms, while ESET detection was signature based;

ESET clearly mentioned in detection " Exploit Eternal Romance" , while HitmanPro says "APC Violation"

ESET 10 has an Antiransomware dedicated module, so users would expect to see this module at work...

Link to comment
Share on other sites

13 hours ago, MSE said:

The other vendors detected the exploit using  different mechanisms, while ESET detection was signature based;

This is getting a bit teediest.

Eset networking protection detected the EternalRomance exploit if you review the screenshot you posted. If Eset detected it by signature, it would have been via its real-time protection or anything that deploys it such as Web Access protection.

 

Link to comment
Share on other sites

7 minutes ago, itman said:

Eset networking protection detected the EternalRomance exploit

When networking protection provides a name for the detection, it is SIGANATURE BASED.

If it is not SIGNATURE BASED, the networking protection would have been something similar to Kaspersky:

The network attack has been blocked :

TCP from 192.168.0.107 to port 445

Link to comment
Share on other sites

  • Administrators

I, for one, doubt that a network vulnerability could be detected generically a long time before it's actually discovered. I'd say it's not possible without FPs. You seem to believe that any updates to security software are about signatures and that there is some security software that magically can recognize any vulnerabilities and malware before it's created / discovered without update. If it was that easy, why Microsoft doesn't generically patch any possible vulnerabilities that may be found in the future in their products? Also detection names don't tell much because it's just a name and we could call it simply "SMB exploit" based on which you would not be able to assume when the detection was created.

The fact is that the detection of EternalBlue exploit was added on April 25, about two weeks before the Wannacry outbreak. After the outbreak security programs were tested and ESET Endpoint Security v6 was one of 3 security products to have detected and blocked it at the network level. All other tested products failed. Unfortunately, nobody knows what the situation was on April 25 when we added the detection. It could be that ESET was the only vendor at that time to have proactively protected against any exploits of the vulnerability.

Link to comment
Share on other sites

19 hours ago, MSE said:

the networking protection would have been something similar to Kaspersky:

The network attack has been blocked :

TCP from 192.168.0.107 to port 445

Per the MRG test report:

Kaspersky Internet Security blocks the DoublePulsar install

EternalRomance installs a backdoor. It uses the DoublePulsar exploit to do so; just as was done by EternalBlue in the WannaCry attack. Kaspersky stopped this activity by detecting the attempt to install DoublePulsar on network device 192.168.0.107 using port 445.. So if anyone is using signature detection, it is Kaspersky.

Eset Smart Security stopped the EternalRomance exploit execution; the only tested vendor to do so. It prevented the execution of the exploit via its IDS intrusion detection protection using CVE detection as noted below from Eset online help documentation. If you don't know what a CVE is, click on the below link for further details:  

Intrusion detection

Protocol SMB – Detects and blocks various security problems in SMB protocol, namely:

Rogue server challenge attack authentication detection – Protects against an attack that uses a rogue challenge during authentication in order to obtain user credentials.

IDS evasion during named pipe opening detection – Detection of known evasion techniques used for opening MSRPCS named pipes in SMB protocol.

CVE detections (Common Vulnerabilities and Exposures) – Implemented detection methods of various attacks, forms, security holes and exploits over SMB protocol. Please see the CVE website at cve.mitre.org to search and obtain more detailed info about CVE identifiers (CVEs).

Edited by itman
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

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