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

[DarkButterfly]

I was wondering if VIPRE is able to prevent ransomware, such as gpcode. I ask, for VIPRE is suppose to detect suspicious behaviors. So, I guess that would make it possible to prevent them, right? Or not at all?

So far I haven't seen any behavior analyzer tool to stop it. Would be interesting to know if you guys at Sunbelt have already tried (ransomware) against VIPRE full power.

If not possible at the moment, are you considering to enhance VIPRE, so that it does protect against ransomware?

[eburger68]

DarkButterfly:

{QUOTE-> So far I haven't seen any behavior analyzer tool to stop it. Would be interesting to know if you guys at Sunbelt have already tried (ransomware) against VIPRE full power. <-QUOTE}

We treat ransomware just like any other form of malware -- we write detections for it, then we detect and remove it. If the user's box has already been compromised before we get there (and their docs or files are already encrypted and held for ransom), that's a whole 'nother kettle of fish.

Eric L. Howes
Sunbelt Software

[DarkButterfly]

{QUOTE-> DarkButterfly:



We treat ransomware just like any other form of malware -- we write detections for it, then we detect and remove it. If the user's box has already been compromised before we get there (and their docs or files are already encrypted and held for ransom), that's a whole 'nother kettle of fish.

Eric L. Howes
Sunbelt Software <-QUOTE}

Interesting point of view, considering that VIPRE stands for Virus Intrusion Prevention Remediation Engine.

So, where exactly can we see the Prevention part?

Lets suppose you have detections for X ransomware, but not for Y.
In this situation, despite the "Prevention" in VIPRE, there will be no prevention at all. Meaning that if a ransomware wants to do its job, it will.

I know that VIPRE reports for suspicious actions, after all I have been testing it since beta 3. That's why I was wondering if it would report any suspicious action take could be occuring, in this case caused by ransomware.

Best regards

[eburger68]

DarkButterfly:

Our detections can both preemptively block and remove after installation.

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.

Eric L. Howes
Sunbelt Software

[TNT]

{QUOTE-> Interesting point of view, considering that VIPRE stands for Virus Intrusion Prevention Remediation Engine.

So, where exactly can we see the Prevention part?

Lets suppose you have detections for X ransomware, but not for Y.
In this situation, despite the "Prevention" in VIPRE, there will be no prevention at all. Meaning that if a ransomware wants to do its job, it will.

I know that VIPRE reports for suspicious actions, after all I have been testing it since beta 3. That's why I was wondering if it would report any suspicious action take could be occuring, in this case caused by ransomware.

Best regards <-QUOTE}

How can you define any given ransomware's actions as "suspicious"? All they do is encrypt files. Something that changes the security settings for the browser is suspicious, something that tries to silently connect to the outside Internet is suspicious, something that hooks the keyboard is suspicious, but encrypting files is not a suspicious action. You can't expect a behavioral prevention to cover this kind of scenarios.

[Fly]

{QUOTE-> How can you define any given ransomware's actions as "suspicious"? All they do is encrypt files. Something that changes the security settings for the browser is suspicious, something that tries to silently connect to the outside Internet is suspicious, something that hooks the keyboard is suspicious, but encrypting files is not a suspicious action. You can't expect a behavioral prevention to cover this kind of scenarios. <-QUOTE}

I understand that VIPRE scans files just like 'other' AVs, using malware signatures ? That should at least partly do the trick.

[eburger68]

Fly:

You wrote:

{QUOTE-> I understand that VIPRE scans files just like 'other' AVs, using malware signatures ? That should at least partly do the trick. <-QUOTE}

We have several different types of signatures, plus we can do more prosaic hash-based detections as well. And VIPRE has basic heuristics, which we will be expanding over the next few months.

Eric L. Howes
Sunbelt Software

[TNT]

{QUOTE-> I understand that VIPRE scans files just like 'other' AVs, using malware signatures ? That should at least partly do the trick. <-QUOTE}
Malware signatures are not "behavior-based" protection. Nor are heuristics for that matter. And while I can see behavior-based protection covering several cases of unknown malware, I don't think 'ransomware' malware can be between them in any way. In fact, between heuristics, signature-based, sandbox-based, hips, etc, behavior-based is probably the most unlikely to be of any help with this type of malware.

[DarkButterfly]

{QUOTE-> How can you define any given ransomware's actions as "suspicious"? All they do is encrypt files. Something that changes the security settings for the browser is suspicious, something that tries to silently connect to the outside Internet is suspicious, something that hooks the keyboard is suspicious, but encrypting files is not a suspicious action. You can't expect a behavioral prevention to cover this kind of scenarios. <-QUOTE}

So, what you are saying is that a process encrypting files, without any apparent reason, is not a sign of a suspicious action?

I do not find suspicious Notepad creating a text file, for example. I do find it suspicious a process encrypting files, specially when we are not the ones encrypting them. Unless it is a process we know to be good. Then we can allow it.

Perhaps this is a wrong approach.

It is obvious there are tools that act as disk shields that do a pretty good job protecting, as they allow us to restore to a previous state. It is also obvious that malware still can bypass that kind of protection, hence I asked if VIPRE was able to prevent it.

I personally do not care at all, as I do not have any important files in my system.

But then again, I am not a security expert. I wouldn't know much.

[TNT]

{QUOTE-> So, what you are saying is that a process encrypting files, without any apparent reason, is not a sign of a suspicious action? <-QUOTE}"Apparent reason"? How do you define "apparent reason" in this case? How is the AV supposed to know whether you launched an encryption program willingly or not and if you know what it did or not? For all it knows, it's just an encryption program executing. Whether it's a malicious one or not can be only determined through signatures or at most heuristics, certainly not through behavioral analysis.

{QUOTE-> I do not find suspicious Notepad creating a text file, for example. I do find it suspicious a process encrypting files, specially when we are not the ones encrypting them. Unless it is a process we know to be good. Then we can allow it. <-QUOTE}"We"? How can a program know "who" is encrypting them?

[DarkButterfly]

{QUOTE-> "Apparent reason"? How do you define "apparent reason" in this case? How is the AV supposed to know whether you launched an encryption program willingly or not and if you know what it did or not? For all it knows, it's just an encryption program executing. Whether it's a malicious one or not can be only determined through signatures or at most heuristics, certainly not through behavioral analysis.
<-QUOTE}

I define apparent reason as in - what the hell would, for example, notepad want to shutdown the system or delete any important system file. There's no apparent reason for that.

Why the hell would a word document be encrypted, for example, if I did not perform such task. I ask does Microsoft Word or alike tool do it without your knowledge?

Why would a mp3 file, for example, want to eliminate the "C:\Windows" directory.

Those are things that are not suppose to happen. Those are reasons for suspicious behaviors.


{QUOTE->
"We"? How can a program know "who" is encrypting them?
<-QUOTE}

By intercepting the attemptive and alert the user for an action, perhaps?

You also said before:

"How can you define any given ransomware's actions as "suspicious"? All they do is encrypt files. Something that changes the security settings for the browser is suspicious, something that tries to silently connect to the outside Internet is suspicious, something that hooks the keyboard is suspicious, but encrypting files is not a suspicious action. You can't expect a behavioral prevention to cover this kind of scenarios."

If I change the security settings of my browser will that be considered a suspicious behavior? It isnt, but a good tool will intercept it and ask the user (who by sign is making the changes) for an action. And so on.

Anyway, all I wanted to know was if VIPRE was able to prevent unkown ransomware based on the "Prevention" it has on its name. That was all.

[eburger68]

DarkButterfly:

Your original question was about "ransomware," not Notepad shutting down the system or an MP3 file deleting the Windows directory. And TNT has done a pretty good job pointing out the problems with attempting to build behavioral detections for ransomware.

You can't translate "apparent reason" into anything that a software could determine by itself. You asked:

{QUOTE-> Why the hell would a word document be encrypted, for example, if I did not perform such task. <-QUOTE}

And there's the nub of the problem. How is a software program supposed to determine that YOU are not doing the encrypting and that it was not YOUR intention -- at least not without popping an AP box to ask. Are you going to pop an AP box every time encryption activity occurs on the PC? You could be flooding the user with AP prompts. See user responses to UAC for an indication as to how well that would go over.

Furthermore, at the point you're talking about intervening, the malware is already on the box and running. The whole point of Active Protection is to prevent the malware from even getting close to the point where it could encrypt some files.

Eric L. Howes
Sunbelt Software

[Kees1958]

{QUOTE-> And there's the nub of the problem. How is a software program supposed to determine that YOU are not doing the encrypting and that it was not YOUR intention -- at least not without popping an AP box to ask. ETC

Eric L. Howes
Sunbelt Software <-QUOTE}

Eric, eBurger

I read this thread because I am interested in a brand new AV and how it is going to be developed. In your argumentation your are posing 'return' questions, but this are questions which should be solved by the security industry

ThreatFire f.i. first checks after the first intrusion wheter it is a known malware, the series of events is key here. ThreatFire also uses some sort of differentiation between the infection risk of a security application, meaning system processes are allowed more than for instance webbrowsers and e-mail programs.

NeoavaGuard had an innovative approach of giving intrusions a bad behaviour value. When the threshold was reached it did intercept the process.

PRSC does classify intrusions into a behavior category and the risk it can evoke. The sequence of invents in which an intrusion builds translated to behaviour patterns are limited (e.g. < 1000 in PRSC's case).

Sensive Guard (old application) and Risng's AntiVirus HIPS part, some how do implement their limitations depending on whether the user started it (e.g. simply having Explorer as parent proces, without an hook, message, memory violation being the source of the trigger).

Policy sandboxes like DefenseWall and GeSWall have shown that LUA environment applied to threatgate application result in a simple, pop-up less defense.

Online Armor (next release) also has an option to run unknown programs in a limited environment. For a program that started as an Anti Executable that is a paradigm shift.

DSA has an anomoly detection which for instance triggers when a lot more emails are send than normal, So there are answers to the questions as long as your differentiate

[doktornotor]

{QUOTE->
Why the hell would a word document be encrypted, for example, if I did not perform such task.
<-QUOTE}

So, you'd flag TrueCrypt as ransomware because it does exactly that whenever you save/copy anything to an encrypted area (disk, partition, volume). ??? ::)

[spm]

I have to say that the posturing going on here is quite astonishing, and I am particularly concerned to see supposedly security 'experts' taking such a black-and-white view of issues. While I won't do so, it would be easy to interpret eburger68's postings here to mean that VIPRE is nothing more than an age-old signature-based engine which has no concept of 'behaviour'. That would be worrying indeed for a product Sunbelt hail as revolutionary.

Most anti-malware products nowadays have some sort of behavioural detection (and I use that term in its widest sense), and can detect such actions as installing keyboard hooks, adding values to the registry 'start' keys, or listening on TCP ports, etc. as dangerous or 'potentially unwanted', say. On this level, it could be argued (but see below) that encrypting files is a potentially-unwanted behaviour and should be intercepted. If VIPRE (or whatever) has a signature for the offending app then all well and good, but if not then it could check against an integrated whitelist of the known good encrypting apps (e.g., TrueCrypt and the like). If on the whitelist, the app would be allowed without further action, else the user would be prompted for an action. Whitelists associated with suspicious behaviors would be small and would not unduly increase the size of 'signature' databases or unduly increase the maintenance workload of the security software vendors.

The problem I see, in this particular case, is that it is difficult to detect 'encrypting' behaviour. There are so many encryption methods, and a limitless number of customised ones can be built that would make generic detection very difficult, and herein would lie the challenge for vendors.

Just my twopence worth.

[eburger68]

spm:

You wrote:

{QUOTE-> While I won't do so, it would be easy to interpret eburger68's postings here to mean that VIPRE is nothing more than an age-old signature-based engine which has no concept of 'behaviour'. That would be worrying indeed for a product Sunbelt hail as revolutionary. <-QUOTE}

And that would be a mistake, as VIPRE does indeed have behavioral-based protection such as you describe.

{QUOTE-> On this level, it could be argued (but see below) that encrypting files is a potentially-unwanted behaviour and should be intercepted. <-QUOTE}

That is the ultimately the question raised -- whether it would be productive to treat encryption activity as an inherently "suspicious" behavior. I'm simply skeptical of the relative value of such an approach.

{QUOTE-> If VIPRE (or whatever) has a signature for the offending app then all well and good, but if not then it could check against an integrated whitelist of the known good encrypting apps (e.g., TrueCrypt and the like). If on the whitelist, the app would be allowed without further action, else the user would be prompted for an action. Whitelists associated with suspicious behaviors would be small and would not unduly increase the size of 'signature' databases or unduly increase the maintenance workload of the security software vendors. <-QUOTE}

And there's another problem: what would be defined as a "known good encrypting app," given that "ransomware" could very well be using libraries associated with a "known good encrypting app" to do its dirty work.

Even putting aside that issue, the number of encryption apps and modules out there is vast -- it would not be a trivial task to put together such a list and maintain it.

{QUOTE-> The problem I see, in this particular case, is that it is difficult to detect 'encrypting' behaviour. There are so many encryption methods, and a limitless number of customised ones can be built that would make generic detection very difficult, and herein would lie the challenge for vendors. <-QUOTE}

And that is another issue, though presumably one could watch for calls to a list of known encryption modules which the bad guys would be likely to use. Coding strong crypto is itself not a trivial task, and if they wanted strong "protection" for the files they encrypted they would be likely to use something off-the-shelf. If they code their own crypto, then it's much more likely that the protection would not be strong and the files ultimately recoverable.

I don't doubt that some coder (or a team of clever coders) probably could come up with a scheme to flag potentially suspicious encryption activity. But I question the relative value of devoting all manner of resources to identifying suspicious crypto activity, when one could be using those resources to go after malware of all kinds in other ways.

Eric L. Howes

[eburger68]

Kees1958:

You wrote:

{QUOTE-> I read this thread because I am interested in a brand new AV and how it is going to be developed. In your argumentation your are posing 'return' questions, but this are questions which should be solved by the security industry

... So there are answers to the questions as long as your differentiate <-QUOTE}

The schemes you describe are all quite innovative and interesting as methods for guarding against potential malware intrusions, but they are using a wide range of potentially anomalous behaviors and qualities to sniff out malware. The problem with encryption activity performed by ransomware is that its behavior at that point would be difficult to characterize as anomalous.

There probably would be a whole range of behaviors associated with that malware's intrusion onto the box that one could and probably should flag, but those behaviors would be associated with malware more generally, not just ransomware.

I would be interested to know which of the apps you mention is actually using "encryption behavior" (however that is determined) as a flag in their schemes for identifying and limiting the intrusion of potential malware.

Eric L. Howes

[spm]

OK, Eric, there's a lot of "we can't do that" postings from you here. Might it not be better to post what you actually can do, or approaches that might be worth you looking at, instead? You can respond all you like about how difficult it is to defend against 'ransomware', but the simple fact is that it is a threat and it needs to be dealt with.

[Ilya Rabinovich]

{QUOTE-> but they are using a wide range of potentially anomalous behaviors and qualities to sniff out malware. The problem with encryption activity performed by ransomware is that its behavior at that point would be difficult to characterize as anomalous. <-QUOTE}
Eric, sandboxes do not "shiff out" malware- it's just a modified environment most malware can't survive with. Ransomeware is not an exception.

[eburger68]

Ilya:

You wrote:

{QUOTE-> Eric, sandboxes do not "shiff out" malware- it's just a modified environment most malware can't survive with. <-QUOTE}

I understand how sandboxes work -- it was hasty, poor choice of verbs to summarize the range of applications mentioned in the post I was responding to. Take my final *general* characterization instead: "schemes for identifying and limiting the intrusion of potential malware."

{QUOTE-> Ransomeware is not an exception. <-QUOTE}

And I never said that sandboxes (or any of the other schemes mentioned in that post) couldn't be a potentially effective defense against ransomware. The question under discussion, though, was behavioral detections of ransomware. And my point was that, in my view, it simply didn't seem productive to pursue that line in comparison with more general approaches to detecting or limiting the intrusion of malware more generally.

Eric L. Howes

[eburger68]

spm:

You wrote:

{QUOTE-> OK, Eric, there's a lot of "we can't do that" postings from you here. <-QUOTE}

Strictly speaking, I never said "we can't do that." Indeed, I even allowed that some kind of behavioral detection might be possible. My point was simply to highlight out the difficulties in developing such a thing and question whether that effort would be productive relative to other schemes for dealing with malware.

{QUOTE-> Might it not be better to post what you actually can do, or approaches that might be worth you looking at, instead? You can respond all you like about how difficult it is to defend against 'ransomware', but the simple fact is that it is a threat and it needs to be dealt with. <-QUOTE}

Again, I never said "ransomware" wasn't a threat or even that, generally speaking, it was a more difficult threat to deal with than other forms of malware. I was simply addressing the very specific question at hand.

Folks, the question of developing schemes for dealing with ransomware is an intriguing one. Perhaps this discussion ought to be split off into a dedicated thread?

Eric L. Howes

[Bubba]

{QUOTE-> Perhaps this discussion ought to be split off into a dedicated thread?

Eric L. Howes <-QUOTE}It was being considered, so We'll go ahead and attempt that move now. Hopefully the above beginning post was a suitable starting point and that all relevant posts made it on the voyage.

[Ilya Rabinovich]

{QUOTE-> The question under discussion, though, was behavioral detections of ransomware. And my point was that, in my view, it simply didn't seem productive to pursue that line in comparison with more general approaches to detecting or limiting the intrusion of malware more generally. <-QUOTE}
I completely agree with you. Generally, it's almost impossible to generalize behavioral detection for ransomeware. I even wrote it somewhere here, at Wilders previously. :)

[DarkButterfly]

{QUOTE-> So, you'd flag TrueCrypt as ransomware because it does exactly that whenever you save/copy anything to an encrypted area (disk, partition, volume). ??? ::) <-QUOTE}

I guess that TrueCrypt wouldn't be installed on the system without the user consentment, and same goes for other encrypting tools that we use to encrypt.

I don't think ransomeware would be something running with our consentment.

[eburger68]

Bubba:

You wrote:

{QUOTE-> It was being considered, so We'll go ahead and attempt that move now. Hopefully the above beginning post was a suitable starting point and that all relevant posts made it on the voyage. <-QUOTE}

Thanks. Although the subject still mentions VIPRE, I think it would be appropriate to open up the discussion to approaches/schemes for dealing with/flagging/managing ransomware more generally.

Eric L. Howes
Sunbelt Software

[doktornotor]

{QUOTE-> I guess that TrueCrypt wouldn't be installed on the system without the user consentment, and same goes for other encrypting tools that we use to encrypt.

I don't think ransomeware would be something running with our consentment. <-QUOTE}

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?

[DarkButterfly]

{QUOTE-> 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? <-QUOTE}

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.

[doktornotor]

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

[huangker]

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.

[CountryGuy]

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.

[vijayind]

{QUOTE-> 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". <-QUOTE}

Maybe in MS Windows Vista, it could be:

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

[vijayind]

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

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.

[TNT]

{QUOTE-> 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. <-QUOTE}It's not possible. Not even for text files, docs, etc.

[TNT]

{QUOTE-> Maybe in MS Windows Vista, it could be:

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 ?? <-QUOTE}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.

[vijayind]

{QUOTE-> 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. <-QUOTE}

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 (http://www.wilderssecurity.com/showpost.php?p=1299474&postcount=32). Please have a look and give your comments on the same. Thanks :thumb: