Jump to content

Archived

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

wraith

Ransomware

Recommended Posts

7 minutes ago, Marcos said:

Well, I'm not sure if the 3rd party blockers are installed on millions of machines both in home user and business environments without adverse effect on various applications that are used there. We have to take into account false positives seriously as they could cause issues especially in business environment and not to detect every process that manipulates with files. Also we have to take into account impact on performance so creating some snapshots of files (especially of bigger files) would be really a problem. While it was thought of as a possible solution, it was denied because of the performance impact and the need for a lot of free disk space if I remember correctly.

Also I tend to believe that if we took any of the 3rd party ransomware blocker, it would not withstand attacks by various ransomware. If I remember correctly, we've analyzed several solutions and always found they failed at some point.

Last but not least, I'd like to remind that any further comments without investigation of the sample in question are futile.

If you don't mind me asking, can you please provide me with a screenshot of ESET Anti Ransomware in action stopping a ransomware for which ESET did not have any signatures?

Share this post


Link to post
Share on other sites

Getting back on topic in regards to this specific ransomware sample, it appears it is an attempt to hide an .exe attachment. If you use an ISP or a third party e-mail provider such as GMail, etc., you will never see such an e-mail arrive in your inbox. This is because these providers will delete any e-mail with an .exe attachment as part of their routine e-mail examination on their servers.

As far as the techniques employed by this ransomware sample, it is characteristic of a targeted attack employing APT like methods against a high valued target; i.e. enterprise level. The chances of an individual user receiving such an e-mail are about zip. In fact, almost all ransomware activities these days are criminal syndicate or state sponsored level against enterprise or government entities since these are the targets that are capable and willing to pay the ransom amount being demanded.

As such, individual user testing of ransomware samples they find is really of dubious value unless the intent is to show some flaw in their security software detection mechanism. Again consumer based security software is "tuned" to the threats encountered by individual users.

-EDIT- Another way this attack could be deployed is good old phishing. You're tricked into downloading what you believe is a .pdf file. You open it and you're nailed.

To prevent this, make sure you have Win Explorer always set to show File Name Extensions. It is assume you have the "smarts" not to open a .exe file downloaded in this scenario.

Share this post


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

Getting back on topic in regards to this specific ransomware sample, it appears it is an attempt to hide an .exe attachment. If you use an ISP or a third party e-mail provider such as GMail, etc., you will never see such an e-mail arrive in your inbox. This is because these providers will delete any e-mail with an .exe attachment as part of their routine e-mail examination on their servers.

As far as the techniques employed by this ransomware sample, it is characteristic of a targeted attack employing APT like methods against a high valued target; i.e. enterprise level. The chances of an individual user receiving such an e-mail are about zip. In fact, almost all ransomware activities these days are criminal syndicate or state sponsored level against enterprise or government entities since these are the targets that are capable and willing to pay the ransom amount being demanded.

As such, individual user testing of ransomware samples they find is really of dubious value unless the intent is to show some flaw in their security software detection mechanism. Again consumer based security software is "tuned" to the threats encountered by individual users.

-EDIT- Another way this attack could be deployed is good old phishing. You're tricked into downloading what you believe is a .pdf file. You open it and you're nailed.

To prevent this, make sure you have Win Explorer always set to show File Name Extensions. It is assume you have the "smarts" not to open a .exe file downloaded in this scenario.

I understand what you are saying, but people rely on their AV program to intercept any suspicious file.

If they do not see the double extention, and think its a .pdf they are infected. So in my opinion a AV program should block these immediately.
Thats why File Insight or a Sonar like active protection module should be in place to intercept any suspicious file.

Share this post


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

I understand what you are saying, but people rely on their AV program to intercept any suspicious file.

If they do not see the double extention, and think its a .pdf they are infected. So in my opinion a AV program should block these immediately.
Thats why File Insight or a Sonar like active protection module should be in place to intercept any suspicious file.

It's unlikely that such file would be undetected by ESET if downloaded or received via email.

Share this post


Link to post
Share on other sites

For those who want to "get into the nitty gritty" of this bugger, Dr. Web has a full behavior analysis here: https://www.virustotal.com/gui/file/32db24cc3456965ba75319617ef2094c9549874533b5fc6c13769a994dc57877/behavior/Dr.Web vxCube . I can see one reason this "flew under the Eset ransomware behavior detection radar." It's a "system hostage" ransomware. Appears to encrypt everything related to existing installed apps. I didn't see one reference to user personal directories being encrypted. Very strange ransomware. Also don't understand what it is trying to accomplish since system repair (Win 10 only) plus app re-installation would bring everything back to normal.

-EDIT- It is possible one of the system files it encrypted will block access to user personal directory files giving the impression that all your files have been encrypted.

Share this post


Link to post
Share on other sites

One final comment in regards to Live Grid's performance in this incident.

Refer back in this thread to the posted Live Grid screen shot showing ransom.exe running. Note the red color. What does that mean? Per Eset online v12 help:

Quote

Reputation – In most cases, ESET Internet Security and ESET LiveGrid® technology assign risk levels to objects (files, processes, registry keys, etc.) by using a series of heuristic rules that examine the characteristics of each object and then weigh their potential for malicious activity. Based on these heuristics, objects are assigned a risk level from 1 – Fine (green) to 9 – Risky (red).

Hum ........ It certainly appears Eset's front-end heuristic scanning did its job.

So why can't Eset offer an option to be alerted to "risky" processes pre-execution? It most certainly appears to be the correct and logical action to take. For me, I can only conclude the following:

1. Eset has such little faith in Live Grid's reputational analysis that it doesn't trust it for user alert purposes. In this case, get rid of the feature and just perform any submission activities in the background.

2. Eset's avoidance of a false positive detection has reached the level that it is jeopardizing overall system security.

Share this post


Link to post
Share on other sites

I'm new to this topic but just wanted to ask something and unsure if its been asked.

Firstly - I have no issue with Eset - I know nothing can ever be 100 percent.  However in regards to ransomware would there not be a way to detect something is encrypting files which in turn could force an alert from Eset.

I'm not talking about new unknown viruses, zero day etc but the act of encrypting itself. Basically could Eset not set it by default to alert users if it detects file encrypting and possibly even be set to pause the encryption until a user tells Eset to either allow or remove.

Surely with that approach it wouldn't matter if it was a new virus unseen that eset didn't know as it would still see the encrypting part. Or are these viruses able to hide that they are encrypting things until it is too late? I don't have a lot of knowledge on these things so sorry if it is a lot more complex than that.

Share this post


Link to post
Share on other sites

@peteyt, encryption of files is not a bad thing per se. There are many legitimate tools that are used to encrypt files, such as PGP and thus cannot be detected. On the other hand, they can be misused either directly by ransomware or an attacker can use them to encrypt files after connecting to a system via RDP. Moreover, even common archive packers support encryption by setting a password which was also misused by ransomware to generate password protected self-extracting archives.

Share this post


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

It's unlikely that such file would be undetected by ESET if downloaded or received via email.

I don't know that but ESET should have added a signature for that ransomware. It's pretty old and most AV vendors detect it.

Share this post


Link to post
Share on other sites
16 hours ago, Marcos said:

image.png

if only ESET displayed this warning for each and every unsigned file that tries to encrypt files.

Share this post


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

For those who want to "get into the nitty gritty" of this bugger, Dr. Web has a full behavior analysis here: https://www.virustotal.com/gui/file/32db24cc3456965ba75319617ef2094c9549874533b5fc6c13769a994dc57877/behavior/Dr.Web vxCube . I can see one reason this "flew under the Eset ransomware behavior detection radar." It's a "system hostage" ransomware. Appears to encrypt everything related to existing installed apps. I didn't see one reference to user personal directories being encrypted. Very strange ransomware. Also don't understand what it is trying to accomplish since system repair (Win 10 only) plus app re-installation would bring everything back to normal.

-EDIT- It is possible one of the system files it encrypted will block access to user personal directory files giving the impression that all your files have been encrypted.

The sample managed to encrypt all my document files i.e. docx, pdf, etc in my documents folder. I sent an encrypted file to marcos. 

Share this post


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

@peteyt, encryption of files is not a bad thing per se. There are many legitimate tools that are used to encrypt files, such as PGP and thus cannot be detected. On the other hand, they can be misused either directly by ransomware or an attacker can use them to encrypt files after connecting to a system via RDP. Moreover, even common archive packers support encryption by setting a password which was also misused by ransomware to generate password protected self-extracting archives.

I have been using ESET since version 2.5(NOD32). You have an amazing team of analysts and researchers. I don't think it would be that much hard for your team to design an efficient anti-ransomware module that can block any unsigned process trying to encrypt files. That way the probability of false positives will be greatly reduced. You can argue that signed malware and malware those exploit lolbins could still encrypt the files, but then I can argue that no antivirus can catch 100% threats, so why use ESET or any other AV? If you implement this one simple rule, ESET will be able to stop more than 50% ransomwares for which it does not have a signature for. But then again, I somehow feel that the ESET team is not open to suggestions or positive/constructive criticism.

Share this post


Link to post
Share on other sites
16 minutes ago, wraith said:

I don't know that but ESET should have added a signature for that ransomware. It's pretty old and most AV vendors detect it.

Re. the age of the sample, it seems to be 3 days old:

VirusTotal:

Creation Time: 2019-08-31 07:13:29

First Submission: 2019-08-31 07:18:44

image.png

Info from LG: Age: 3 days Cnt: 1 Rep: Bad (9)

 

Share this post


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

Re. the age of the sample, it seems to be 3 days old:

VirusTotal:

Creation Time: 2019-08-31 07:13:29

First Submission: 2019-08-31 07:18:44

image.png

Info from LG: Age: 3 days Cnt: 1 Rep: Bad (9)

 

In general ESET is usually one of the first to come with signatures. So 3 days seems pretty old to me. Many other vendors already have a signature for it. Btw did the researchers/analysts find anything about this sample?

Share this post


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

In general ESET is usually one of the first to come with signatures. So 3 days seems pretty old to me. Many other vendors already have a signature for it. Btw did the researchers/analysts find anything about this sample?

3 days means that it's NOW 3 days since the first submission to VT and since we received the sample.

ECLS Command-line scanner, version 7.0.2097.0, (C) 1992-2018 ESET, spol. s r.o.
Module scanner, version 19951 (20190901), build 42622

Scan started at:   Tue Sep  3 09:08:07 2019
name="test\ransom.ex", threat="MSIL/Filecoder.UN trojan", action="", info=""

Total:             files - 1, objects 1
Infected:          files - 1, objects 1

Share this post


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

@peteyt, encryption of files is not a bad thing per se. There are many legitimate tools that are used to encrypt files, such as PGP and thus cannot be detected. On the other hand, they can be misused either directly by ransomware or an attacker can use them to encrypt files after connecting to a system via RDP. Moreover, even common archive packers support encryption by setting a password which was also misused by ransomware to generate password protected self-extracting archives.

Does encryption run on a standard home user computer without them knowing.

What I mean is I have windows pro but don't use any encryption software so surely if something started encrypting something there would be a cause for alarm. I've thankfully never came across ransomware but I thought for a general home computer the fact something is being encrypted would look suspicious in itself

Share this post


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

Does encryption run on a standard home user computer without them knowing.

What I mean is I have windows pro but don't use any encryption software so surely if something started encrypting something there would be a cause for alarm. I've thankfully never came across ransomware but I thought for a general home computer the fact something is being encrypted would look suspicious in itself

It can run on a standard user but won't be able to encrypt system files. It can encrypt your personal files though. I agree with you. A process that is unsigned and new to LiveGrid, trying to encrypt files, should be blocked immediately by ESET even though it may be a false positive(although the chances would be extremely thin for a FP). I would rather deal with a FP than having my important files encrypted. 

Share this post


Link to post
Share on other sites

Some additional comments on how Live Grid should be configured by Eset.

1. The risky status alert option would be an "Advanced option" setting for the existing Live Grid setting in Eset's GUI. It would be disabled by default. Hence and God forbid, Eset gets "dinged" on an AV lab test because of it.

2. It is assumed that Eset already has in place criteria for handling of known assumed safe apps such as OS apps in their respective directories, etc.. I will state that I have never seen any process set to "Red" status in viewing Live Grid's status screen. As such, I am assuming the "Red" status is reserved for unknown reputation apps performing questionable system modification activities.

3. The alert would display additional descriptive information such as signing status, publisher, creation date, directory location, etc.

As I see it, the most that could happen in blocking the process from running would be some app installation or some process .exe you purposely downloaded is blocked/borked. App installers can always be rerun.

The above would allow one to submit the process to VirusTotal for additional verification or Hybrid-Analysis for a detailed sandbox analysis. Win 10 1903 users could additionally run the process in the  Windows sandbox.

Unfortunately, these Live Grid operational modifications have been suggested by me and others in the past and have "fallen on deaf ears" as far as Eset is concerned. After all, Eset always knows best when it comes to security features.

Share this post


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

It can run on a standard user but won't be able to encrypt system files. It can encrypt your personal files though. I agree with you.

It can encrypt the standard user account personal files but not those associated with the default local admin account. Additionally, it would not be able to encrypt system or app files as this ransomware sample did. Of course the prior statement assumes the malware hasn't escalated its privileges.

Share this post


Link to post
Share on other sites

The sample was internally evaluated as suspicious by the ransomware detection mechanisms, however, another antiFP mechanism came into play. We'll loose the conditions a bit and improve proactive detection of this kind of ransowmare as well.

@wraith, please collect logs with ESET Log Collector from the machine where you tested the sample and provide me with the generated archive. It looks like we didn't get it via the LiveGrid feedback system and couldn't react to it earlier.

Share this post


Link to post
Share on other sites

 

Since the above Eset's requested enhancements to Live Grid falls into the category of "wishful thinking," let's talk about a free solution built into Win 10 that has such capability. That is Windows Defender's Advanced Surface Reduction; i.e. ASR mitigations:

Quote

Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Since we are on that topic, let's list all the ASR mitigations available:

Quote

Attack surface reduction rules

The following sections describe each of the 15 attack surface reduction rules. This table shows their corresponding GUIDs, which you use if you're configuring the rules with Group Policy or PowerShell. If you use System Center Configuration Manager or Microsoft Intune, you do not need the GUIDs:

Rule name

 

GUID

 

File & folder exclusions

 

Block executable content from email client and webmail

BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550

Supported

Block all Office applications from creating child processes

D4F940AB-401B-4EFC-AADC-AD5F3C50688A

Supported

Block Office applications from creating executable content

3B576869-A4EC-4529-8536-B80A7769E899

Supported

Block Office applications from injecting code into other processes

75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84

Supported

Block JavaScript or VBScript from launching downloaded executable content

D3E037E1-3EB8-44C8-A917-57927947596D

Not supported

Block execution of potentially obfuscated scripts

5BEB7EFE-FD9A-4556-801D-275E5FFC04CC

Supported

Block Win32 API calls from Office macro

92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B

Supported

Block executable files from running unless they meet a prevalence, age, or trusted list criterion

01443614-cd74-433a-b99e-2ecdc07bfc25

Supported

Use advanced protection against ransomware

c1db55ab-c21a-4637-bb3f-a12568109d35

Supported

Block credential stealing from the Windows local security authority subsystem (lsass.exe)

9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2

Supported

Block process creations originating from PSExec and WMI commands

d1e49aac-8f56-4280-b9ba-993a6d77406c

Not supported

Block untrusted and unsigned processes that run from USB

b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4

Supported

Block Office communication application from creating child processes

26190899-1602-49e8-8b27-eb1d0a1ce869

Supported

Block Adobe Reader from creating child processes

7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c

Supported

Block persistence through WMI event subscription

e6db77e5-3df2-4cf1-b95a-636979351e5b

Not supported

Each rule description indicates which apps or file types the rule applies to. In general, the rules for Office apps apply to only Word, Excel, PowerPoint, and OneNote, or they apply to Outlook. Except where specified, attack surface reduction rules don't apply to any other Office apps.

https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/attack-surface-reduction

Share this post


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

It can run on a standard user but won't be able to encrypt system files. It can encrypt your personal files though. I agree with you. A process that is unsigned and new to LiveGrid, trying to encrypt files, should be blocked immediately by ESET even though it may be a false positive(although the chances would be extremely thin for a FP). I would rather deal with a FP than having my important files encrypted. 

Sorry didn't mean standard user account.

What I mean is unless you run encryption software does windows encrypt anything.

Let's say a general user who just uses a computer for games and music, videos etc. If they don't run any encryption stuff I presume nothing should be encrypting anything so if something started encrypting something that would automatically be suspicious.

@Marcos seemed to state it may be hard to determine genuine encryption from a virus but could eset not simply have an option to disable or warn about any attempts to encrypt

Share this post


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

I have been using ESET since version 2.5(NOD32). You have an amazing team of analysts and researchers. I don't think it would be that much hard for your team to design an efficient anti-ransomware module that can block any unsigned process trying to encrypt files. That way the probability of false positives will be greatly reduced. You can argue that signed malware and malware those exploit lolbins could still encrypt the files, but then I can argue that no antivirus can catch 100% threats, so why use ESET or any other AV? If you implement this one simple rule, ESET will be able to stop more than 50% ransomwares for which it does not have a signature for. But then again, I somehow feel that the ESET team is not open to suggestions or positive/constructive criticism.

 

As i say many time, it would be nice to have rules based on the livegrid if user want.

Full Green Know/safe : allow
Yellow : ask for launch / ask with high HIPS rules / ask for firewall
Red : block 

 

Share this post


Link to post
Share on other sites
On 9/3/2019 at 10:10 AM, Marcos said:

The sample was internally evaluated as suspicious by the ransomware detection mechanisms, however, another antiFP mechanism came into play. We'll loose the conditions a bit and improve proactive detection of this kind of ransowmare as well.

Now we are getting "at the meat" of the issue.

How about an ecmds initiated "aggressive" FP setting? This setting would do globally what you stated; loosen existing anti-FP detection. By keeping the setting out of the Eset GUI, it would prevent Eset "experimental" users from enabling it and subsequently complaining Eset is throwing alerts on some garbage they are trying to install.

At least, Eset should do something in this area to prevent long time users like myself from moving on to security solutions that have such capability.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...