Emsisoft Anti-Malware

Very good question, indeed.

At the moment I only use default Vista security

Though, since people often ask me for an advise I try to be "in stream" with the security products in general, so from time to time I install and test different products. They were recently: PFW (it temped me by good score at matousec, but disappointed by the bad score with CLT), SpyShelter (paid version seems to be good, but free looks too restricted), mamutu (no free version, bad score with CLT and lafter I was pointed that the tests are irrelevant and I run some tests with the real malware). That is to say real malware tests didn't perform better than CLT. And finally Comodo. Installed it yesterday to x64 VM. I know Comodo can protect everything if you set it up right (this is what I hate to do, I like when product can protect everything in default configuration, like OA does).

 

thanks for the response Alex. Appreciate it.
i do agree with OA and comodo.

 

sorry pete, if you think this is an off-topic question. no problem.

thanks,
harsha.

 

I disagree then
I've always felt Mamutu lacks

 

Here is the quote from fabian, why both will be merging causes hefty amount of changes in code base...

https://www.wilderssecurity.com/showpost.php?p=1866528&postcount=46


thanks,
harsha.

 

As you can see here he have changed the opinion
http://support.emsisoft.com/topic/4839-online-armor-wishlist/page__view__findpost__p__28838

 

Everyone has their own opinion, but MRG tests still show Emsisoft and their behaviour monitoring is still very effective. From their tests, it'd be safe to say it actually kicks backsides.

alex_s, you should be using your expertise of security programs, working with eg. guys like Ilya on DefenseWall etc. Not that he needs help, just using an example.

 

It hasn't been posted on the forums yet how a virus was detected. It could very well be Ikarus (signature) or Ikarus (generic heuristics), which do account for most of Emsisoft's detection. However I share your opinion that the behavior blocker/Mamutu by Emsisoft is one of the best. I just don't see any reason to run a standalone behavior blocker. I think behavior blocking (and behavior analysis) is not powerful enough and, therefore, should be included as an additional layer (like in Emsisoft Anti-Malware).

 

When Emsisoft produces an even lighter package, then Mamutu sales will drop and Emsisoft sales will increase. Many on here continually state they'll use it if it's just that bit more resource friendly.

To me, Mamutu fits with MSE which is solid with its detections, but running a program which is adding autoruns, making an outbound connection, MSE won't be there. Same with MBAM or MSE users who are loyal to either, can find a place with Mamutu.

Someone who runs sandboxie, scans files with Hitman Pro, analyses a file in the sandbox, but still is hesitant if the file may later try to download from the internet, copy to another location, make unwanted connections, Mamutu could fit in too.

The examples above, I used Mamutu + sandboxie + Hitman Pro. Also used it with MSE. And another time with MBAM. And on another occasion, I used Emsisoft's free version on-demand, Mamutu real-time, and Hitman Pro. All of them, worked well and light too.

But you're right, vast majority would either go for Emsisoft's AM package over Mamutu. And Emsisoft's detections are right up there. To me, Mamutu is more for enthusiasts looking to tweak their free protection, or have a program which they don't want to replace, but need that bit of added security.

 

Flash tests cannot be called behavior monitoring tests, they allow signature detection, and yes, Ikarus has great detection rate, though, it also has a lot of the false positives. Do you really think the result would be the same if they took mamutu instead of EAM? I'm afraid nobody can say for sure what way the samples were detected with. In any case it is not correct to talk about behavior monitoring if signature detection is allowed by the test conditions.

As for BB results:

HIPS, Behavior Blockers, Anti-Loggers

Program Exploit 1 Exploit 2 Exploit 3 Exploit 4
DefenseWall N/A N/A N/A N/A
Zemana N/A N/A N/A N/A

Another test showed DW to be a winner.

DefenseWall 56 56 0

This is fair HIPS win, for DW doesn't use signature detection.

 

I agree, it's good to know which part of a program prevented the malware.

But as I said, Mamutu isn't promoted as a stand-alone app to be the be all and end all. So used in a combination with another program, eg. even with prevx/webroot, what prevx/webroot misses, Mamutu catches, and so on. It's an additional layer, which we've all learned is the way to go.

Take for example, friend's system. MSE bombs on a lot of these tests. But I have MSE, UAC on, sandboxie where I've added firefox sandboxed (risky surfing) to the desktop and firefox standard (saving work files), WOT blocking suspicious websites, Hitman Pro startup scan. MBAM icon for once a week scan. Winpatrol for terminating processes. Setup is as free as they come.

Now each on their own, insert Bow-Boow! sound. MSE (maybe 50/50 chance), UAC (unsure of percentage), Sandboxie ) ! cheer sound) , Hitman Pro/MBAM (sound - where's the real time brother?!), WOT (sound), WinPatrol (sound).

But working together, these programs are damn effective. And what are the chances of a user running more than 10 malware files a year compared to tests running 30 files in one hit? Where I'm going with this, the one program catching everything, might not be for me, nor be convenient for most. So I take testing with a pinch of salt, or work out how I can get the best security layers going on.

 

I think a test with just 4 examples against security with signatures is irrelevant. I mean previous test (http://malwareresearchgroup.com/2011/05/mrg-flash-test-5182011-exploits/). 4 could be enough to test HIPS (only in case they introduce different attack vectors) but it is too few to test detection. To test detection I believe you need at least 20-30 examples (to reduce error).

And it would be very interesting to get OA tested there (OA free would be enough). I believe it has all the chances to pass it flawlessly

 

Alex, have you read the more detailed information on MRG's forum? They detail which component of the product blocked the malware, e.g. signature, generic, behavior blocker. On the last test for which the breakdown was published the Mamutu component of EAM caught 2 of the 4 samples, i.e. signature detection failed on 2 of the 3 but the BB caught it. On the test before that Mamutu caught the 1 that slipped through the signatures and on the test prior it caught the 2 that slipped through signature detection.

So I don't know where you get this idea from that Mamutu adds little. The published evidence doesn't support your claims. In fact it shows that Mamutu is a very effective behavior blocker as a backup to signature detection.

 

CLT

OS Windows Vista SP2 build 2600
1. RootkitInstallation: MissingDriverLoad Vulnerable
4. RootkitInstallation: ChangeDrvPath Vulnerable
5. Invasion: Runner Vulnerable
8. Invasion: FileDrop Vulnerable
10. Injection: SetWinEventHook Vulnerable
11. Injection: SetWindowsHookEx Vulnerable
12. Injection: SetThreadContext Vulnerable
13. Injection: Services Vulnerable
15. Injection: KnownDlls Vulnerable
16. Injection: DupHandles Vulnerable
18. Injection: APC dll injection Vulnerable
21. InfoSend: DNS Test Vulnerable
22. Impersonation: OLE automation Vulnerable
23. Impersonation: ExplorerAsParent Vulnerable
24. Impersonation: DDE Vulnerable
25. Impersonation: Coat Vulnerable
26. Impersonation: BITS Vulnerable
30. Hijacking: SupersedeServiceDll Vulnerable
31. Hijacking: StartupPrograms Vulnerable
32. Hijacking: ChangeDebuggerPath Vulnerable
33. Hijacking: AppinitDlls Vulnerable
34. Hijacking: ActiveDesktop Vulnerable
Score 120/340

Just take in account how many injection techniques are not covered. Which means you can infect system processes in many ways.

 

I thought this silly argument about synthetic HIPS leaktests being the measure of a security applications effectiveness was killed off years ago. If that's your only argument then Mamutu users have nothing to worry about. Tests against real malware are far more significant and with those Mamutu appears pretty darn successful.

 

CLT might not be the "best" testing tool but it does shows where or what things certain programs are not covering which is not a bad thing

 

It's a HIPS test. Mamutu is a behavior blocker. CLT only becomes relevant if you know exactly what a 'perfect' behavior blocker should be scoring against it. Is 120/340 about as good a behavior blocker will ever do against this HIPS test? Since nobody knows that, it's a useless 'test' and even more useless as a means to judge a particular behavior blocker. Really, Alex should know better.

 

You do not understand something very important. Once HIPS fails to intercept code injection, it totally fails at this very moment, because it looses all the chances to prevent infection. The only difference between synthetic test and real malware is malware does harm, while synthetic test does not. And I also tested mamutu with real malware. Result was the same. But I was asked not to post my results and not to share my samples. Though, If you want to get them I can point you to a person I have shared my malware collection with. Then you'll be able to learn that test results are close to real malware test results if malware uses the same techniques.

As for coding, there is not any difference between intercepting test and intercepting real malware. Very basic example. If you fail to block global hook installation, your dll gets loaded to the system processes where it can do whatever it wishes to.

 

A few points:

1. Mamutu is not a HIPS, so why do you continue to try to evaluate it against HIPS criteria?
2. The only recent published results show Mamutu performing pretty well

Who knows what's in your 'collection'. It could be full of anything. Why would anyone believe your 'tests' over those of MRG for example?

 

1.) BB is just another flavour of HIPS. I'd say HIPS is the most generic name, while BB is specific. Any HIPS-based solution hooks system functions and blocks some of the calls to prevent infection. What logic blocking is based on is irrelevant.

2.) then just be happy

3.) my collection is a collection of very nasty malware, this is exactly what one needs to test security. But if you do not understand the technical details about how malware works, you'd better avoid to enter the technical discussions. Repeating what other people said is not the best way to argue.

 

It's not just another flavour of HIPS at all. A BB looks for suspicious actions and makes a decision whether to allow or alert. This may be based on a series of suspicious actions, where the cumulative effect triggers an alert, rather than just one action. A HIPS, as you know, is generally dumb.

Running CLT against a BB to judge how 'good' the BB is, is totally unfair.
Equally unfair would be running an executable against a HIPS with the expectation that the HIPS would make a decision as to whether the exe was likely malicious.

The actions they monitor can often be the same (e.g. access registry, set global hooks) but after that they diverge. The logic blocking, far from being irrelevant, is the single most relevant thing.

 

LOL. This is what every HIPS does

This is nothing but very outdated stereotype.

As for the series .. if code injection is the first and only action in a "series" then it seems that your BB just fails. And there are not any strict patterns in malware actions. Some (not too numerous) malware can be detected by pattern of actions, but in general case actions are absolutely unpredictable and in many cases just one action is enough to defeat security.

This is absolutely fair. But if you do not understand what is code injection, and how security works internally, our dispute becomes absolutely useless.

 

You need to go and read up on BB's and understand them a bit better - not only how they work but also their role in a layered security set up, in conjunction with an AV. Maybe that's the bit you're not appreciating.

Anyway, I think we will have to agree to disagree. The final word is yours....

 

The only role of any security is to prevent infection. If it failed to, then it is not a security but something else which is not a subject of this forum

Again, you may call it by any "cool words", but if security fails to prevent code injection this means it fails to prevent infection.