Files encrypted by ransomware

[local 0]

10 minutes ago, Marcos said:

but I have a hunch that files will get encrypted in this case

It may get encrypted either way, so what's the point of running a paid and over-sophisticated antimalware like ESET  ( did not count now, but an user can adjust over 120 parameters ) when a simple built-in antivirus (Defender) offers the same level of protection and zero headache???

[SeriousHoax 83]

I know about the HIPS rules blocking script execution, etc and have set it on mine. Those are post execution rule and I even have better pre execution blocking rules set with the help of Hard_Configurator but anyway these are not for average users.

I wouldn't say WD is better but it's enough for almost every home users and can be made better by enabling extra features but ESET has a lot more features and definitely the lightest.  ESET has everything but a behavior blocker that's why it struggles against unknown malware and specially against ransomwares. Good to see it was detected in Windows 10 with the help of AMSI so maybe WD would detect it too? I don't know. After the integration of Augur into the product I hoped to see it in action in such scenarios but personally haven't seen any.

[Marcos 5,071]

The difference between WD and ESET in this case is that with ESET only 1 file got encrypted. In my test case it was eicar in c:\1.

However, this was with WD and ESET disabled:

The conclusion is that in this case ESET did better than WD and protected the user. The malware was detected almost immediately after execution by the AMSI scanner and was killed.

[peteyt 393]

12 hours ago, local said:

Point is ESET is the last one to protect you against ransomware in spite of having a dedicated anti-ransomware module , HIPS, machine learning and all kind of fluffy stuff.

For Win 10, Defender offers comparable better protection for free.

I can't comment on that myself as I've never been infected

[itman 1,659]

The WD test against this sample was not needed.

My experience in monitoring WD detection rates on VT is if it doesn't detect a malware early in the global infection cycle, it will be some time till it does detect it. Such is the case here in that this sample is still not detected by WD per latest VT detection rates.

This recent ransomware sample employed various Windows "living off the land" legit executables. WD is no better than monitoring malicious use of those than anyone else.

BTW - WD protection can be enhanced by creating advanced surface reduction; i.e. ASR's, rules via PowerShell commands. The problem is the procedure is in many ways more involved than creating like Eset HIPS rules. Add to this Eset has a GUI for rule creation/maintenance; WD does not. This "hard confiigurator" software for WD often mentioned is a user created software maintained on GitHub. So assume the average user is oblivious to WD advanced mitigation options.

Edited January 7, 2020 by itman

[itman 1,659]

Since this latest ransomware was Nemty, let's talk about that.

Ref.: https://www.symantec.com/blogs/threat-intelligence/nemty-ransomware-trik-botnet

Originally Nemty was deployed via exploiting existing system vulnerabilities:

Quote

In the past, Nemty has been observed being spread via the RIG exploit kit, as well as via malicious spam campaigns targeting users in Korea and China, where the malware is attached inside an archive.

At this point, note that 76% of Nemty's targets are in China and the Korean pennisula.

Of late, Nemty is using:

Quote

In early October, we noticed that Trik had begun distributing Nemty as a payload, adding another channel for the ransomware’s delivery.

How Trik spreads Nemty using the SMB protocol

We observed a recent version of Trik delivering a tiny component that uses the Server Message Block (SMB) protocol and a list of hardcoded credentials to try to connect to remote computers with port 139 open.

Note the above "Trik" reference is to the Trik botnet.

At this point, note that if you've disabled NetBIOS on your IPv4 network adapter connection, SMB use is a moot point.

Finally, the thing that caught my eye was:

Quote

 

• Nemty 1.6 gains persistence by adding a scheduled task using the following command:

 cmd.exe /c schtasks.exe /create /sc onstart /tn “NEMTY_<FILEID>_” /tr “C:\Users\user\AdobeUpdate.exe”

Appears this latest sample has migrated to using WMI for persistence which is a much stealthier method.

Which gets us to malware testing methods. Eset has botnet protection. Which means if this ransomware was delivered via its current distribution method, it could have been blocked from downloading the payload.

Edited January 7, 2020 by itman

[local 0]

30 minutes ago, itman said:

it could have been blocked

This is the issue with ESET ; always "it could have been blocked it" but rarely does in real life....

[Marcos 5,071]

4 minutes ago, local said:

This is the issue with ESET ; always "it could have been blocked it" but rarely does in real life....

In fact, I provided a proof that on Windows 10 ESET detected and blocked execution of the ransomware and protected the user where the other "free" AV failed. If you have a proof that ESET doesn't protect users well, please provide a proof and support it with logs and other necessary stuff.

[itman 1,659]

Since regasm.exe was used in this Nemty ransomware sample, I will point out that there are more stealthy methods to deploy it for malicious purposes as noted here: https://securelist.com/using-legitimate-tools-to-hide-malicious-code/83074/ . One would be advised to monitor its execution per Mitre's recommendation: https://attack.mitre.org/techniques/T1121/ or at least minimally, monitor via firewall rules any outbound communication from it.

[SeriousHoax 83]

@Marcos Hello, off topic: Before it was possible to see all the sigantures added to each updates from here: https://www.virusradar.com/en/update/info/

But it's been a while it's not there anymore. Is this a permanent change? Is it available anywhere else?

[Marcos 5,071]

6 minutes ago, SeriousHoax said:

But it's been a while it's not there anymore. Is this a permanent change? Is it available anywhere else?

Correct, that was a permanent change:

https://forum.eset.com/topic/20969-virusradar-signature-database-unclickable/

[SeriousHoax 83]

2 minutes ago, Marcos said:

Correct, that was a permanent change:

https://forum.eset.com/topic/20969-virusradar-signature-database-unclickable/

Oh, bummer 😕

[itman 1,659]

FYI - Dr. Web has produced a detailed analysis on this latest Nemty ransomware here: https://www.virustotal.com/gui/file/b6e9eb3a56f495a13892859e3de26109cbc7950b1e8bd57d374e87c94c99c7e5/behavior/Dr.Web vxCube . Click on the "Full Report" link.

One very nasty bugger indeed! Amazing Eset was able to decipher that obfuscated PowerShell script via AMSI on Win 10. Glad to see it has worked out prior issues it had in this regard. Suspect this is the prime reason for still low detection of the bugger.

Of note is the bugger is using 32 bit PowerShell.

Edited January 8, 2020 by itman

[itman 1,659]

Here's a much better way to abuse regasm.exe use since no code injection of it is needed: https://medium.com/axon-technologies/threat-hunting-for-the-most-common-mitre-att-ck-techniques-part-4-72e4fc8178bc .

Just create a malicious .Net .dll; drop the .dll on the target device; and run that .dll directly from regasm.exe. Also note that detection of the malicious .dll is difficult since all it amounts to is a reverse shell that allows for network communication to the attacker's C&C server.

BTW - the IOCs listed in the linked article should be added to Augur's ML behavior rules.

Edited January 10, 2020 by itman