Is VIPRE able to prevent ransomware - split thread from: VIPRE Antivirus + Antispywar

Re: VIPRE Antivirus + Antispyware is now released

How on earth is a program supposed to know that an application has been installed with a user consent or not? We've been talking about behavior analysis here, haven't we?

 

Re: VIPRE Antivirus + Antispyware is now released

Yes, we are talking about behavior analyzers here.

How does a program know if an app has been installed by a user? It doesn't know. But a user sure can tell it to allow or deny something in case an action is intercepted and make it create a rule for it.

In this particular case we're talking about ransomeware, so let's no deviate from this.

My first post talking about VIPRE and ransomeware came to mind after reading a thread where some user has made a few tests using, if I am not mistaken, gpcode against behavior analyzer, HIPS and disk shields.

Since VIPRE does include behavior analyzes I wondered if it was able to prevent it from encrypting files. Also because Sunbelt claims that VIPRE protects in 3 ways: signatures, heuristics and prevention at the core of the system (preventing malware from executing).

I got answered that VIPRE threats ransomeware as any other malware, they create detections for it.

I also was answered "If you're looking for behavioral detections of ransomware, I'd be interested to know just what behaviors you would have an anti-malware app fire on without causing scads of false alarms for users."

Then I wonder why there are HIPS (including classical HIPS) and behavior blockers. They exist so users have control on what runs and happens on their systems.
Users will have to make choices when something is asked to them. It may be a false alarm, it may be for real. The user must know what to answer. If it's for real and the user chooses the wrong option, then something bad will happen.
Users who don't know how to react to this type of situations, they just won't use this sort of security apps, because althought we're talking about security apps, on their hands they will be doing the opposite job.

So, we're talking about users who do know how to answer and how to react to such prompts from HIPS, behavior blockers and other security apps that use behavior blockers to some extent.

The truth is that we're talking about malware and anti-malware (anti-virus, etc). Some are signature-based, some are behavior-based, others are pure HIPS.

It's normal for an aged antivirus not be able to prevent new ransomewares, as there aren't any signatures. As a matter of fact, aged antivirus prevent nothing, they detect when the code is executed.

But we're talking about malware that should be prevented by HIPS and behavior blockers. After all HIPS stands for Host Intrusion Prevention System and behavior blockers should perhaps be programmed to prompt the user for an action when a process tries to encrypt something. If the user knows the process or after looking for info about it, then could safely allow it or deny it.


That sort of prompts happen everytime someones installs something new (and already installed apps) and executes the app for the first time. The user knows the process and will allow or deny it from doing something and the HIPS/Behavior blocker creates a rule, so that it remembers the user's choice.

If not wanting to "bother users", then why develop such security tools? They're useless.

So what if a user has to allow an encryption tool from doing its job. He/she allows it and a rule gets created. Won't be bothered again.
If they realize that what is trying to encrypt something is not known to them, they search info about it and if they realize it is unknown or find no info at the moment, then they can see if it is a system process, for example, and if they find out it isn't, then they can block it for the moment, until they find something more about it.

 

Sigh... This debate clearly doesn't go anywhere as it is.

1/ on-the-fly file encryption != ransomware
2/ on-the-fly file encryption != malicious behaviour.

You clearly need a different detection for ransomware than "wow it encrypts files, t3h noes stop it!"

Go suggest something usable for detection of this, not "it encrypts files without asking".

 

It is very frustrating reading this thread. I felt that Alex was answering the questions in a very logical manner. In short, behaviorial detection of encryption takes time and effort to code for. Even if is incorporated, because encryption has so many legitimate uses, it will be hard to separate the bad activity from the good. Thus an apporach like signature detection of malware is more appropriate.

As armchair observers, we might not appreciate the diffculties and challenges in building behavioral detection of ransomware into a comsumer based product. If you really want it, ask developers for a classical behavior blocker if they will put it into their product.

 

I've actually found this thread very informative, and interesting to see the challenges faced. Eric's replies regarding behavioral detection of ransomware make sense to me.

Suppose you are prompted prior to a file being encrypted: Either you caught ransomware, or you OK a "good" encryption app. If you don't save that response, you get asked again and again. If you OK it... Then what happens when, as mentioned, ransomware uses the product's libraries (or, the product itself if it has a CLI)? The user would need to get a constant barrage of warnings about encryption - I for one wouldn't want a product like that, and I doubt many would.

A question I do have (as I don't have the expertise in this field): Can you tel the difference between a file being encrypted vs. just being modified? In other words, can a security application tell the difference between me taking myfile.<some obscure extension> and adding a few changes to it, vs. an encryption software scrambling the file and re-saving it? Text files, .docs, etc. I can see, but for other types of files I don't know if that's possible.

 

Maybe in MS Windows Vista, it could be:

Code:

If [(on-the-fly file encryption) && (UAC)] = TRUE
   then behavior = !malicious
Else If [(on-the-fly file encryption) && (UAC)] = FALSE
   then behavior = malicious

Yes, I am assuming any legal encrypt app will be UAC approved and vice-versa if encryption app is UAC approved its legal. Its not perfect, but mixed with whitelist (for non-complaint encyption app) it will give much less FPs.

So what does everyone else think ??

 

Just thought of a Bayesian Rank based algorithm which could be used in XP and reduce FPs (with more exposure to risk )

Code:

SET Malicious_Trigger =  User_Settings.Malicious_Setting //Say User_Settings.Malicious_Setting is 1000
SET Malicious_Counter = 0
While [(New Application Execute/Run) && ( Malicious_Counter < Malicious_Trigger )]
{
   If [(on-the-fly file encryption) && (Office File)]
   Malicious_Counter = Malicious_Counter + Preset_Office_Priority // Say Preset_Office_Priority is 100
   If [(on-the-fly file encryption) && (System File)]
   Malicious_Counter = Malicious_Counter + Preset_System_Priority // Say Preset_System_Priority is 300
   If (New Application Execute/Run.directory = Temp Folder)
   Malicious_Counter = Malicious_Counter + Preset_Temp_Priority // Say Preset_Temp_Priority is 500
   If (New Application Execute/Run.directory = Browser Cache)
   Malicious_Counter = Malicious_Counter + Preset_Cache_Priority // Say Preset_Cache_Priority is 800
    .
    .
    .
    .
}

So by adding appropriate rules, with less FPs probably randsomware can be detected at the cost of having some initial files being encrypted.


Hope I could help.

 

Re: Is VIPRE able to prevent ransomware - split thread from: VIPRE Antivirus + Antisp

It's not possible. Not even for text files, docs, etc.

 

Re: Is VIPRE able to prevent ransomware - split thread from: VIPRE Antivirus + Antisp

What you're suggesting is not behavior based, it's just whitelist-based. Behavior based blocking assumes that you know NOTHING about the application being analyzed, and that you've never seen the application before; you must decide whether its behavior is malicious or suspicious exclusively on its behavior.

 

Re: Is VIPRE able to prevent ransomware - split thread from: VIPRE Antivirus + Antisp

I agree TNT, it was just a simple trick where UAC is used to mark a trusted source. Not very accurate. That's why I came up with a Bayersian Rank based algorithm for general behavior based detection.

Its post #32. Please have a look and give your comments on the same. Thanks