Jump to content

Archived

This topic is now archived and is closed to further replies.

0xDEADBEEF

Another ransomware that escapes from ESET's detection

Recommended Posts

13 hours ago, peteyt said:

I mean you only have to look at notpetya which used a well known legitimate program - compromised it and basically sent everyone an infected update

I think anti-exe is very limited against a lot of attack vectors. Digging common software exploits (including something like DLL hijack) can easily bypass these software if the rule is not carefully created.

Share this post


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

Eset's ransomware protection, I assume, is geared to detecting the Windows based crypto API's.

If this is true, I'd say it is of zero robustness 

Share this post


Link to post
Share on other sites
2 minutes ago, 0xDEADBEEF said:

This sample is just one example which pretends to be an unpopular VPN client.

Yeah, I notice VT updated its .exe name to VortexVPN.exe

Share this post


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

VT doesn't test anti-ransomware solutions; the only ones that have the auto backup feature that I am aware of.

As previously posted, a few of Next Gen/AI vendors detected it using extended sandboxed behavior analysis. A few of same did not. Everyone else detected the ransomware via signature detection - the same as Eset - with most creating the signature after Eset did.

I doubt the next gen ones deploy behavior analysis in VT. Most of them should be static detection only

Share this post


Link to post
Share on other sites
4 hours ago, 0xDEADBEEF said:

I doubt the next gen ones deploy behavior analysis in VT. Most of them should be static detection only

Correct.

Share this post


Link to post
Share on other sites
5 hours ago, 0xDEADBEEF said:

I personally don't consider SS as an effective advisory against malware because it simply generates too many FPs on legitimate programs

I have had the exact opposite experience. I can't recollect when browser based SmartScreen blocked anything let alone a download. Most likely due to Eset detecting anything "bad" in its web filtering monitoring.

As far as Win 10 native SmartScreen monitoring, it did trigger an unknown alert on process execution for a process Eset's rep scanner also flagged as unknown. This is exactly what I wanted since Eset let the process run unimpeded. This alert BTW is the only one I have obversed from Win 10 native Smartscreen.

Share this post


Link to post
Share on other sites
5 hours ago, 0xDEADBEEF said:

I think anti-exe is very limited against a lot of attack vectors. Digging common software exploits (including something like DLL hijack) can easily bypass these software if the rule is not carefully created.

True.

Basic anti-exec is the whitelisting of all processes encountered during training mode and the alerting for another other process execution after training mode has been disabled. Vendors have enhanced this by allowing all processes from the Win and program directories and adding mitigations against shell and script based execution. Some have added their own supplemental AI determination coupled with a scan against all the AV engines at VT when displaying a verdict on whether the process is safe or not. A few even claim to indeed have exploit protection which I take as flat out FUD. 

Share this post


Link to post
Share on other sites
On ‎07‎/‎29‎/‎2017 at 9:30 AM, MSE said:

I do not understand why "exposure" is so important , as long as ESET v10 has  DEDICATED ANTIRANSOMWARE module.

If ESET still bases its detection on a signature update and waits for the "sample" to be submitted, what's the point of the dedicated antiransomware module?????

Although I hate to say this, I have a similar feeling. I think calling ESET custom HIPS rules for file access monitoring as anti-ransom module is more appropriate, but that's not what a normal user will do. And I believe ESET will not like the idea because it is user dependent and hard to distinguish good file accesses from bad.

ESET is really powerful in detecting known ransomware families and their variants. I have observed that the old definition several months ago can still detect many of the new variants of known ransomware families (primarily through AMS, and some through anti-ransomware module) Maybe it is also because when hackers sell their products, the first proof-of-work is to bypass scan engines.

But I have a feeling that ESET is a bit "delayed" when reacting to newly born ransomware. This is fine for most threats because you can assume that most user will encounter a "known" threat rather than a new one. You can even say that if the prevalence of a threat grows really quickly, it will definitely catch ESET's attention and lead to a faster response. But If the attack uses some ways to quickly propagate itself, then then situation could be much worse. I agree that in most cases, people need to primarily optimize for common cases (known threats), but letting so-called corner cases fail gracefully is equally important from my perspective.

Share this post


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

Although I hate to say this, I have a similar feeling. I think calling ESET custom HIPS rules for file access monitoring as anti-ransom module is more appropriate, but that's not what a normal user will do.

Personally, I have never relied on Eset's built-in anti-ransomware protection alone instead manually creating HIPS rules noted here: http://support.eset.com/kb6119/ plus my own custom rules. One primary reason is Eset in their usual "tight lipped" manner will not disclose any details on exactly what their NOD32/SS anti-ransomware protection is.

BTW- @0xDEADBEEF did you discover how this current Lamda Locker ransomware payload .exe was actually executed; script, shell, e-mail, etc..?

-EDIT-

I will also add and should have mentioned this much earlier in this thread that testing of ransomware samples should simulate actual delivery and execution methods. This is especially critical in security solutions like Eset that do not employ direct behavioral analysis methods. These solutions condition their existing detection methods such as Eset's HIPS to monitor the methods ransomware is usually encountered; script, shell, e-mail, drive-by download, etc.. Running a ransomware executable directly via desktop, file explorer, or even manually from the command prompt are not methods by which ransomware is executed in the real world and most likely will not be detected unless an existing signature exists.  

Share this post


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

BTW- @0xDEADBEEF did you discover how this current Lamda Locker ransomware payload .exe was actually executed; script, shell, e-mail, etc..?

Nope, I didn't get this sample directly from their distribution source. But from my experience, this one is likely to be exec-ed by the user through file explorer

Share this post


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

I have had the exact opposite experience. I can't recollect when browser based SmartScreen blocked anything let alone a download. Most likely due to Eset detecting anything "bad" in its web filtering monitoring.

As far as Win 10 native SmartScreen monitoring, it did trigger an unknown alert on process execution for a process Eset's rep scanner also flagged as unknown. This is exactly what I wanted since Eset let the process run unimpeded. This alert BTW is the only one I have obversed from Win 10 native Smartscreen.

Hmm, maybe I just have too many "rare" stuffs.

Yes SS helps a bit sometimes. But it is user who finally decide whether to use it or not (SS usually doesn't flag something as malicious, but more of "IDK if it is benign or not"). If a user wants to use it, they will use it anyway unless something explicitly flag it as harmful.

Share this post


Link to post
Share on other sites

I will say this about ransomware. Statistical frequency studies have shown that over 90% of ransomware is delivered via e-mail. Also a large portion of those are directed to SMBs and corps.. So one should direct their attention to that ransomware attack vector. In that regard, most protective measures to not involve the use of a security solution.

Personally, the only ransomware attempts I have encountered were by browser based drive-by download which Eset's web filtering caught by DNA signature detection. -EDIT- Forgot that Eset e-mail scanning recently caught a "DHL" one. Glad it happened, since this was the first I every received from Eset originating from e-mail. Was wondering if that protection actually worked. It is a testament however that your best e-mail ransomware protection is using a third party e-mail provider. They will scan all incoming e-mail to their servers.

However sooner or later, I expect one will slip by Eset. Hence, my stance on whitelisting.

Share this post


Link to post
Share on other sites
15 hours ago, 0xDEADBEEF said:

Hmm, maybe I just have too many "rare" stuffs.

I will also say this although Eset won't publically admit it. Ransomware protection is not as extensive on Win 7 as it is on Win 10. Case in point is script protection. On Win 10, Eset uses the AMSI interface that allows it to scan obfuscated and packed scripts after the are unobfuscated and unpacked/ in memory but prior to their execution. No such capability exists in Win 7, so Eset has to do the same using AMS. Since AMS is port-execution detection, their is a likelihood part of its scanning has been bypassed.

Share this post


Link to post
Share on other sites

For those who like the idea of monitoring of crypto activities with auto backup and recovery, someone presented a kernel mode driver that does the same at Blackhat 2017: https://www.blackhat.com/docs/us-17/wednesday/us-17-Continella-ShieldFS-The-Last-Word-In-Ransomware-Resilient-Filesystems.pdf . Since they patented the POC, appears to me they are looking for AV vendors to sell it to.

Again the concept is not new since there are existing third party anti-ransomware doing same. This effort appears to be directed to AV vendors looking for the equivalent protection that could be added to their existing solutions.

Share this post


Link to post
Share on other sites
49 minutes ago, itman said:

For those who like the idea of monitoring of crypto activities with auto backup and recovery, someone presented a kernel mode driver that does the same at Blackhat 2017: https://www.blackhat.com/docs/us-17/wednesday/us-17-Continella-ShieldFS-The-Last-Word-In-Ransomware-Resilient-Filesystems.pdf . Since they patented the POC, appears to me they are looking for AV vendors to sell it to.

Again the concept is not new since there are existing third party anti-ransomware doing same. This effort appears to be directed to AV vendors looking for the equivalent protection that could be added to their existing solutions.

Just watched a demo video of that. Ranged from about 20%-99% cpu usage to protect 500 assorted doc/jpg files of small file size.

Novel idea , but .............. Fall update for windows 10 will probably be about the usual 3.5gb mark ..... download 5mins ...... install while running ShieldFS in the background ........ maybe get to use your pc next september lol :lol:. That's if it's lucky enough to not throw a ntoskrnl.exe BSOD.

Share this post


Link to post
Share on other sites
12 hours ago, cyberhash said:

Fall update for windows 10 will probably be about the usual 3.5gb mark ..... download 5mins ...... install while running ShieldFS in the background

Maybe I missed something in the .pdf write up, but by default ShieldFS is only monitoring files with .pdf, .jpg, and .doc  extensions. I assume others can be added. However, I know of no anti-ransomware that monitors .exe, .dll, and like files.

Share this post


Link to post
Share on other sites

@0xDEADBEEF, here's another one for you to check out that Eset is not detecting: https://www.virustotal.com/en/file/7dcb5a3b0928bc8308e3a1203f5c2e656dfd46630fb356bd4684924565bd4e7f/analysis/

Been in-the-wild for at least 17 hours. Is another Lamda Locker variant. Also is signed with a Comodo cert..:rolleyes: 

Additional ref.:

https://twitter.com/JakubKroustek

https://www.virustotal.com/en/file/7dcb5a3b0928bc8308e3a1203f5c2e656dfd46630fb356bd4684924565bd4e7f/analysis/1501536031/

 

 

Share this post


Link to post
Share on other sites
27 minutes ago, itman said:

@0xDEADBEEF, here's another one for you to check out that Eset is not detecting: https://www.virustotal.com/en/file/7dcb5a3b0928bc8308e3a1203f5c2e656dfd46630fb356bd4684924565bd4e7f/analysis/

Been in-the-wild for at least 17 hours. Is another Lamda Locker variant. Also is signed with a Comodo cert..:rolleyes: 

Additional ref.:

https://twitter.com/JakubKroustek

https://www.virustotal.com/en/file/7dcb5a3b0928bc8308e3a1203f5c2e656dfd46630fb356bd4684924565bd4e7f/analysis/1501536031/

 

 

Not surprised at all. Did you try and see if it bypasses AMS? 

Share this post


Link to post
Share on other sites
32 minutes ago, itman said:

The sample is already detected:

0ad6607cd53b7326acd8440a514e15d9976c238e - Win32/Filecoder.FV trojan

https://www.virustotal.com/en/file/7dcb5a3b0928bc8308e3a1203f5c2e656dfd46630fb356bd4684924565bd4e7f/analysis/1501601793/

The detection was added in 15842, we're already at 15843.

Share this post


Link to post
Share on other sites
37 minutes ago, Marcos said:

The detection was added in 15842, we're already at 15843.

Is Eset responsible for notifying VT of detection? Seems VT reporting of Eset detection is always behind the fact.

I received 15842 this morning at logon time. Don't know when it was actually created.

Share this post


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

Did you try and see if it bypasses AMS? 

No. I don't test live malware samples on my PC.

Share this post


Link to post
Share on other sites
1 minute ago, itman said:

No. I don't test live malware samples on my PC.

That's why I don't usually trust VT results (it is a poor indicator for saying if one product is bypassed or not)... 

Share this post


Link to post
Share on other sites
5 minutes ago, 0xDEADBEEF said:

That's why I don't usually trust VT results (it is a poor indicator for saying if one product is bypassed or not)... 

Yeah, all they run is the real time scan engines and not the full product. Basically, a signature detection only as far as I am aware of. 

Share this post


Link to post
Share on other sites

Have also seen instances where legitimate files are actually listed on VT as a threat by half the vendors, only to show as clean the following day. It's a mixed barrel and really only gives a clear picture if you have a new file that scan immediately, then rescan after a day or 2.


 

Share this post


Link to post
Share on other sites

There is one thing Eset can immediately do to improve its detection capability against ransomware and other malware. That is to increase its signature download frequency.

In reviewing my Eset event log, I receive signature updates every 3 - 4 hours with the norm being every 4 hours. This frequency has been a constant since I first installed Eset back in the ver. 8 days. For an AV whose primary detection method is signature detection, that is unacceptable. In contrast, Emsisoft which does employ dynamic behavior analysis in addition to signatures provided by Bitdefender detection updates their signatures on an hourly basis by default. So should Eset.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...