Another ransomware that escapes from ESET's detection

[0xDEADBEEF 43]

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.

[0xDEADBEEF 43]

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 

[itman 1,659]

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

[0xDEADBEEF 43]

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

[itman 1,659]

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.

[itman 1,659]

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.

[itman 1,659]

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. 

[0xDEADBEEF 43]

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.

Edited July 30, 2017 by 0xDEADBEEF

[itman 1,659]

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.  

Edited July 30, 2017 by itman

[0xDEADBEEF 43]

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

[0xDEADBEEF 43]

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.

[itman 1,659]

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.

Edited July 31, 2017 by itman

[itman 1,659]

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.

Edited July 31, 2017 by itman

[itman 1,659]

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.

Edited July 31, 2017 by itman

[cyberhash 188]

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 . That's if it's lucky enough to not throw a ntoskrnl.exe BSOD.

[itman 1,659]

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.

[itman 1,659]

@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.. 

Additional ref.:

https://twitter.com/JakubKroustek

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

 

 

Edited August 1, 2017 by itman

[0xDEADBEEF 43]

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.. 

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? 

Edited August 1, 2017 by 0xDEADBEEF

[Marcos 5,074]

32 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/

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.

[itman 1,659]

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.

Edited August 1, 2017 by itman

[itman 1,659]

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.

[0xDEADBEEF 43]

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)... 

[itman 1,659]

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. 

[cyberhash 188]

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.


 

[itman 1,659]

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.