View Full Version : Mamutu 1.5.0.18 released [NEW]
maymoons
February 15th, 2008, 03:03 PM
Version 1.5 changes:
To avoid too many alerts on good programs, version 1.5 introduced the new community based alert reduction feature. Once an alert is triggered, you can see how other users decided about the alerted program. Mamutu is able to create allow rules for programs that have been allowed by eg. more than 90% of the community users.
The self protection has been improved. Mamutu is able to defend itself better from beeing shut down by Malware. On a manual program exit, you will see a captcha that requires that you enter a security code to confirm the shutdown. Mamutu protects other applications from being remote controlled and shut down too.
/**/
What is Mamutu?
# Monitors live all active programs for dangerous behavior (Behavior Blocking).
# Recognizes new and unknown Trojans, Worms and Viruses (Zero-Day attacks), without daily updates.
# Small but very powerful. Saves resources and does not slow the PC down.
Mamutu recognizes and reports the following types of behavior:
# Backdoor related behavior
# Spyware related behavior
# HiJacker related behavior
# Worm related behavior
# Dialer related behavior
# Keylogger related behavior
# Trojan Downloader related behavior
# Injection of code into other programs
# Manipulation of programs (patching)
# Invisible installations of software
# Invisible Rootkit processes
# Installation of services and drivers
# Creation of Autostart entries
# Manipulation of the Hosts file
# Changes of the browser settings
# Installation of debuggers on the system
# Simulated mouse and keyboard activity [version 1.5]
solcroft
February 16th, 2008, 01:36 AM
-{ Quote: "Version 1.5 changes:
To avoid too many alerts on good programs, version 1.5 introduced the new community based alert reduction feature. Once an alert is triggered, you can see how other users decided about the alerted program. Mamutu is able to create allow rules for programs that have been allowed by eg. more than 90% of the community users." }-
This is the biggest sign of a lousy security software.
Mamutu's FPs were absolutely atrocious, but instead of working on a better recognition algorithm and/or whitelist to solve the problem, they throw the problem to the users instead. WHY on earth should I care which users voted what on program X? Who are they anyway, qualified experts?
To quote ErikAlbert: "That's not security, that's gambling."
SystemJunkie
February 16th, 2008, 01:41 AM
I agree this software is relative useless, rootkit owned it in seconds and then it became very quiet.
But if I find the time I will try this new "gambling" version.
Kees1958
February 16th, 2008, 04:48 AM
SystemJunkie, Which rootkit owned it, how did you test.
Solcroft, which wave of FP's did you encounter, when it are that many, it should be easy to mention 5.
Let me make clear it is not that I am commenting on you, but the problem is that I do not want to check some previous posts of the person making the statement. This to get an idea of what this person is saying is total nonsense or that the fourm member has made in the past some sharp observations. In the last case he or she's current statement will problably also contain some truth/value.
When I hear this sort of comments, I can not help to think that it is all about preferences. Comodo V2 did tell you when a source code was changed, but did not do anything against it. Also the algoritme was CRC in itself a weak form. Nobody attacked comodo on this. Comodo was the champ on this forum.
Only some bad comments were made on the CRC check. When you are considering security in normal life perspective, you will see that most financial institutes use CRC as a trip wire to detect fraud, programming errors. CRC is not intended as a 'from outside protection' but as a from within (integrety and completeness). So it was not that stupid of the designers to use CRC to check whether already approved programs (meaning inside the protected zone) were untouched .
Wilders members are in favour of TF and against Mamuto. Also the FP problem, becomes a myth. People are telling this without having own observations on this. The few FP's I noticed were more or less the same as TF. Only PRSC is the ap with lowest FP's. But then everybody complaints on the scope of protection by PRSC. SO TF stays the darling of this forum.
Another example, SafeSpace personal is a wonderfull ap, stil gets its portion of bashing by Sandboxie fans. Off course we know sandboxie as a security program with a good reputation, but SafeSpace works out of the box, while Sandboxie needs some adapting. It is great that people like Sandboxie, stay happy with, no need to justify your choice by bringing down a competing ap.
Members like ZopZop, Aigle, Lucas1985, Stem, Blue, Pete always provide some background info. I really appreciate this. So I would ask others to backup their opinions with observations/tests also. THX
solcroft
February 16th, 2008, 11:08 AM
-{ Quote: "Solcroft, which wave of FP's did you encounter, when it are that many, it should be easy to mention 5." }-
IE6, WMP, 7-zip, and ThreatFire are four I can remember off the top of my head. I can't remember if I can attribute services.exe to it as well, or another rather jumpy behavior blocker I've also tested months ago. Of the four concrete ones I do remember, two of them are VERY common Windows programs.
-{ Quote: "Wilders members are in favour of TF and against Mamuto. Also the FP problem, becomes a myth. People are telling this without having own observations on this." }-
Kees, I was the one who started the "myth", IIRC. The very first thing it did after I installed it was to report IE6 as a backdoor trojan, and things only went downhill from there.
You might also want to consider that there might be a reason that that "myth" exists, especially since Mamutu is still a young program and has no past reputation, good or bad, to be carried over from its earlier versions.
-{ Quote: "The few FP's I noticed were more or less the same as TF. Only PRSC is the ap with lowest FP's." }-
Of course, that might be because you insist on running TF on level 4 and suffer from extra FPs without any real improvement in protection.
-{ Quote: "But then everybody complaints on the scope of protection by PRSC. SO TF stays the darling of this forum." }-
As far as my personal observations go, that complaint would be quite accurate - relative to TF, that is; I'm not trying to imply that PRSC is a weak program. You also seem peeved by the fact that people prefer TF, which admittedly sounds quite strange to me.
simmikie
February 16th, 2008, 12:25 PM
-{ Quote: "This is the biggest sign of a lousy security software.
Mamutu's FPs were absolutely atrocious, but instead of working on a better recognition algorithm and/or whitelist to solve the problem, they throw the problem to the users instead. WHY on earth should I care which users voted what on program X? Who are they anyway, qualified experts?
To quote ErikAlbert: "That's not security, that's gambling."" }-
could not agree more. it's fairly common knowledge that most people respond to pop-ups incorrectly, so this approach is akin to the 'blind leading the blind'.
Mike
SystemJunkie
February 16th, 2008, 03:21 PM
-{ Quote: "SystemJunkie, Which rootkit owned it, how did you test. " }-
Look screen below, latest Mamuta becomes disrupted.
http://i29.tinypic.com/fzcimq.png
197782
Kees1958
February 17th, 2008, 04:24 AM
Solcroft,
As stated my post it is not an attack on you, so hold your horses. When you did not get the message, I will repeat it: I am complaining about the fact that people are just make statements without backing them up.
My experience of false Positives of Mamuto and TF is different. IE7 WMP and 7-ZIP are programs also on my wife's PC and after installing Mamuto I tried all programs. I can not recall that Mamuto marked them, same applies to TF, see post: http://www.wilderssecurity.com/showpost.php?p=1183116&postcount=52
Now before you start reacting in detail on this response. Different users means different usage, so it could well be that you encounter a lot of FP with your PC usage. That is the reason that I would like some contextual information (mention test/situation).
I am also not peeved by the fact that TF is favoured, see http://www.wilderssecurity.com/showthread.php?t=183020 or http://www.wilderssecurity.com/showpost.php?p=1180282&postcount=7
Regards Kees
Kees1958
February 17th, 2008, 04:30 AM
-{ Quote: "Look screen below, latest Mamuta becomes disrupted.
http://i29.tinypic.com/fzcimq.png" }-
Okay seeing that Mamuto becomes disrupted, but how did CSRSS.exe become malware, is it a MSN or media file releated CSRSS malware version?
sukarof
February 17th, 2008, 04:33 AM
-{ Quote: "Look screen below, latest Mamuta becomes disrupted.
http://i29.tinypic.com/fzcimq.png" }-
Excuse my ignorance, I might misundertand the discussion here, but doesnt that picture just show that crss.exe and drwtsn.exe is trying to eliminate Mamutu.exe and Comodo intercepts that attempt before eventual Mamutu selfprotection did? What triggered crss.exe and drwatson (which are legit processes in windows, not mailicious rootkits) to try to kill Mamutu process? Are you saying that mamutu doesnt protect itself?
solcroft
February 17th, 2008, 04:50 AM
Just because it's named csrss.exe doesn't mean it's the legitimate copy that came with Windows. In fact, a lot of trojans are named svchost.exe and explorer.exe. It's just a filename, and trying to masquerade as system processes poses quite a few advantages.
One possible interpretation of what happened was that the trojan tried to kill Mamutu, which crashed, at which point DrWatson stepped in to kill the crashed process(es).
sukarof
February 17th, 2008, 06:46 AM
-{ Quote: "Just because it's named csrss.exe doesn't mean it's the legitimate copy that came with Windows. In fact, a lot of trojans are named svchost.exe and explorer.exe. It's just a filename, and trying to masquerade as system processes poses quite a few advantages.
One possible interpretation of what happened was that the trojan tried to kill Mamutu, which crashed, at which point DrWatson stepped in to kill the crashed process(es)." }-
Yes thats true solcroft, but we will never know until we know where that csrss.exe is located on his drive. Since he uses two HIPS type software I assume he didnt let the rootkit hijack the legit csrss.exe process in memory in both software. Unless Mamutu does not protect running processes of course.
SystemJunkie
February 17th, 2008, 09:24 AM
There is only one csrss.exe (from windows) and that seems to be owned by <unknown>. Some hypervisor could have control over it. The DrWatson Game is a favorite of those hackers, they or better said the Malware Type III escalate or bo any chosen executable and drwatson pops up and the chosen app is killed no matter if you choose block or allow in comodo. (my assumption blue pill+new undetectable stealth.mbr or vbootkit mod)
They do this game with black ice, mamutu, force field,... just to name a few.
solcroft
February 17th, 2008, 09:35 AM
-{ Quote: "There is only one csrss.exe (from windows) and that seems to be owned by <unknown>. Some hypervisor could have control over it. The DrWatson Game is a favorite of those hackers, they or better said the Malware Type III escalate or bo any chosen executable and drwatson pops up and the chosen app is killed no matter if you choose block or allow in comodo. (my assumption blue pill+new undetectable stealth.mbr or vbootkit mod)
They do this game with black ice, mamutu, force field,... just to name a few." }-
... Then again, you might not be the person best known for making objective (or even logical) observations...
Paul Wilders
February 17th, 2008, 09:46 AM
-{ Quote: "... Then again, you might not be the person best known for making objective (or even logical) observations..." }-
Please bear in mind personal attacks are a no-go area on this board. Therefore stick to technical arguments and comments.
regards,
paul
Kees1958
February 17th, 2008, 10:05 AM
-{ Quote: "Yes thats true solcroft, but we will never know until we know where that csrss.exe is located on his drive. Since he uses two HIPS type software I assume he didnt let the rootkit hijack the legit csrss.exe process in memory in both software. Unless Mamutu does not protect running processes of course." }-
Sukarof
Thx for the explanation.
subset
February 17th, 2008, 03:27 PM
-{ Quote: "
Wilders members are in favour of TF and against Mamuto.
" }-
Both have a really weak self protection and therefore they are most probably the first victims if an real attack starts.
So both fell out of my favour.
I don't really know how they should offer any additional protection, like many users to think.
Cheers
Rasheed187
February 17th, 2008, 03:35 PM
Well, wanted to test it, but can´t do it (no network inside VM), can it please be made so that you won´t have to login to be able to use this tool?
-{ Quote: "# Backdoor related behavior
# Spyware related behavior
# HiJacker related behavior
# Worm related behavior
# Dialer related behavior
# Keylogger related behavior
# Trojan Downloader related behavior " }-
I would like to know when these alerts will be triggered? I mean, it sounds a bit vague. Normally a HIPS will tell you exactly what an app is trying to do, like for example, making outbound connections, or loading global hooks.
-{ Quote: "
# Invisible installations of software
# Invisible Rootkit processes" }-
OK, can someone test this against a couple of rootkits?
-{ Quote: "
# Manipulation of programs (patching)" }-
Is this protection against file infectors?
-{ Quote: "
# Installation of debuggers on the system
# Simulated mouse and keyboard activity [version 1.5]" }-
I would like to get some more info about this. :)
solcroft
February 18th, 2008, 01:38 AM
-{ Quote: "Both have a really weak self protection and therefore they are most probably the first victims if an real attack starts.
So both fell out of my favour." }-
Do you have any example of a real attack that successfully disables TF?
emsisoft
February 18th, 2008, 02:19 AM
-{ Quote: "I would like to know when these alerts will be triggered? I mean, it sounds a bit vague. Normally a HIPS will tell you exactly what an app is trying to do, like for example, making outbound connections, or loading global hooks." }-
We can't publish all details how the triggers work, but the alert windows of Mamutu will tell you much more, why a program was alerted. The Spyware alert e.g. comes when a program invisibly sends or receives data from the internet. The detected behavior type is always described in detail on every alert box. Mamutu will never say "This IS Spyware", it will always say "This program acts LIKE Spyware". Well, if it detects spyware like behavior in a good program, that can not be counted as a false alert. It just means that the behavior is very similar to spyware behavior.
-{ Quote: "
Is this protection against file infectors?
" }-
I'm not sure what you understand on file infectors, but I guess it's exactly what you mean.
-{ Quote: "
I would like to get some more info about this. :)" }-
Debuggers are sometimes used to prevent security programs from being started at system startup. Mamutu catches the required system changes that would allow someone to register such a debugger.
Simulated mouse- and keyboard-activity is used by Malware to reproduce manual user actions, e.g. right click the Mamutu tray icon and select "Exit program". Mamutu can not be terminated with such actions.
SystemJunkie
February 18th, 2008, 06:13 AM
-{ Quote: "Mamutu will never say "This IS Spyware", it will always say "This program acts LIKE Spyware". Well, if it detects spyware like behavior in a good program, that can not be counted as a false alert. It just means that the behavior is very similar to spyware behavio" }-I think that´s important clarification for many outthere.
-{ Quote: "Quote:
Originally Posted by Rasheed187
Is this protection against file infectors?
I'm not sure what you understand on file infectors, " }-
I guess he is talking about things like virut and parite.
subset
February 18th, 2008, 01:35 PM
-{ Quote: "Do you have any example of a real attack that successfully disables TF?" }-
As this thread is about Mamutu, this is slightly off-topic, well...
I posted weeks ago here with a link and the post was deleted because of this link, therefore I have to explain the details.
A guy called Scrapie from german security forum Rokop Security wrote a small vb app called ByeByeThreatFire to demonstrate how easily ThreatFire is to disable.
Else he is able to bypass and/or blind ThreatFire because of it's "design weakness", like he wrote.
Cheers
Rasheed187
February 20th, 2008, 10:39 AM
-{ Quote: "
We can't publish all details how the triggers work, but the alert windows of Mamutu will tell you much more, why a program was alerted. The Spyware alert e.g. comes when a program invisibly sends or receives data from the internet." }-
Thanks a lot for the feedback. I suppose you can not publish everything because malware will try to circumvent it or something? But you already told me what triggers the "acts like spyware" alert, so you might as well tell me the other stuff? :D But if I understand it correctly, just like ThreatFire, Mamutu tries to be more "smart" to reduce alerts, and thus has certain rules that will only be triggered under certain conditions, am I correct?
-{ Quote: "
Well, if it detects spyware like behavior in a good program, that can not be counted as a false alert. It just means that the behavior is very similar to spyware behavior." }-
Well, personally I don´t care about "false positives" at all. I believe I have enough knowledge to decide if certain behavior is possibly malicious or not.
-{ Quote: "
I'm not sure what you understand on file infectors, but I guess it's exactly what you mean." }--{ Quote: "
I guess he is talking about things like virut and parite." }-
Well yes, looks like we are talking about the same thing. Would be a nice feature since most HIPS do not protect against this.
-{ Quote: "Simulated mouse- and keyboard-activity is used by Malware to reproduce manual user actions, e.g. right click the Mamutu tray icon and select "Exit program". Mamutu can not be terminated with such actions." }-
OK nice, but I also saw this in action in HIPS like EQSecure and ProSecurity, and I got alerts when clicking on the taskbar myself, so it was not exactly "fake". I wonder if this method can be made so that it will only be triggered when you (the user) really did not send any mouse/keyboard input yourself.
-{ Quote: "A guy called Scrapie from german security forum Rokop Security wrote a small vb app called ByeByeThreatFire to demonstrate how easily ThreatFire is to disable." }-
Very interesting, a simple .vbs file that can disable protection? Perhaps an idea to not run any unknown script/executable files, or are there any other ways to disable TF and other HIPS? :what:
Rasheed187
February 20th, 2008, 10:45 AM
-{ Quote: "Well, wanted to test it, but can´t do it (no network inside VM), can it please be made so that you won´t have to login to be able to use this tool?" }-
@ Emsisoft (Christian Mairoll)
Can you please remove the need to have an account? Come on, security tools don´t need this kind of nonsense. :gack:
emsisoft
February 20th, 2008, 11:54 AM
-{ Quote: "But if I understand it correctly, just like ThreatFire, Mamutu tries to be more "smart" to reduce alerts, and thus has certain rules that will only be triggered under certain conditions, am I correct?" }-
Exactly. Mamutu does not only alert things like "Program xy connects to the internet". It combines several parameters until it give an alert window.
-{ Quote: "
Well yes, looks like we are talking about the same thing. Would be a nice feature since most HIPS do not protect against this.
" }-
We'll test against that ones. But if they simply try to inject code into other processes, they'll be detected for sure.
-{ Quote: "
OK nice, but I also saw this in action in HIPS like EQSecure and ProSecurity, and I got alerts when clicking on the taskbar myself, so it was not exactly "fake". I wonder if this method can be made so that it will only be triggered when you (the user) really did not send any mouse/keyboard input yourself." }-
Please try it. We didn't get any user complaints so far about wrongly alerted user actions.
-{ Quote: "
Can you please remove the need have an account?" }-
Sorry, that's not possible. The server side licensing storage is a very effective way to avoid illegal use of the program. Every client side solution can be cracked too easily.
Btw. please don't test the program on a virtual machine. Lots of Malwares don't act harmful when they detect that they're running on a virtual environment. The next problem is: When you don't have web access on your VM, worms and trojans may not start at all and Mamutu can't detect any harmful actions (because there are none, just an empty process).
solcroft
February 20th, 2008, 12:57 PM
-{ Quote: "As this thread is about Mamutu, this is slightly off-topic, well...
I posted weeks ago here with a link and the post was deleted because of this link, therefore I have to explain the details.
A guy called Scrapie from german security forum Rokop Security wrote a small vb app called ByeByeThreatFire to demonstrate how easily ThreatFire is to disable.
Else he is able to bypass and/or blind ThreatFire because of it's "design weakness", like he wrote.
Cheers" }-
First off, VBS scripts have always been TF's biggest Achilles' Heel. Hopefully now that this is public knowledge they'll feel a bit more heat on their backs to plug this loophole.
Secondly, you didn't really answer my question. It's one thing for a programmer to spend hours to comb a program looking for loopholes, and then spend more time writing a POC program to demonstrate it. It's another for an amateur tester to just double click on that POC program, and then proclaim that program X is "easily" disabled. If you recall, I asked for an example of a real attack that successfully disables TF. I've seen a few myself, so I know it's not impossible, but they're the rarest of the rare.
subset
February 20th, 2008, 05:27 PM
-{ Quote: "
Secondly, you didn't really answer my question." }-
That's correct.
But if an security app for example allows to be uninstalled (ended) by an small vb app verysilent with message boxes suppressed and without restart, what do you think how long will it take for an skilled malware coder to trop some lines?
And I am not a ThreatFire user, nor tester or whatever, I told you what I know and if you don't like it, please ignore.
Cheers
solcroft
February 21st, 2008, 12:21 AM
-{ Quote: "But if an security app for example allows to be uninstalled (ended) by an small vb app verysilent with message boxes suppressed and without restart, what do you think how long will it take for an skilled malware coder to trop some lines?" }-
That has ALWAYS been the hallmark of security apps. There's no such thing as an unterminatable process if you have admin rights - if that was possible, we'd have seen viruses that cannot be uninstalled from the very enterprising malware writing business a long time ago. Just so you know, you don't need a custom POC program to kill ThreatFire, as several specialist system utilities like IceSword is capable of doing the job as well.
The real question, as always, is how well a security app stands up to real malware, instead of trying to pointlessly counter every benign/non-malicious driver and termination method method and introduce various system instabilities in the process.
I told you what I know and if you don't like it, please ignore.
solcroft
February 21st, 2008, 07:14 AM
-{ Quote: "Solcroft, which wave of FP's did you encounter, when it are that many, it should be easy to mention 5." }-
Kees,
I finally managed to find time to fire up the newest version of Mamutu on my test machine. A few facts beforehand: Mamutu was left at its default settings, and the computer had nothing (and I mean NOTHING) other than a default install of WinXP SP2, Returnil, and Mamutu. The images indicate what I ran into in less than ten minutes.
Keep in mind that the machine was virtually bare in terms of installed software, and the FPs were all on default Windows components and system files. On other machines with various other software installed, I have no problems imagining that the FP rate skyrockets exponentially.
Kees1958
February 21st, 2008, 07:48 AM
Solcroft,
Thanks. Yep this is consistent with my experience. I had disabled the protect Browser Settings, I have mailed Emsisoft that this generates FP (maybe you can recal we had a discsussion on disabling this feature).
The unregmp2.exe is new to me. Anyway good of you to back your words, thanks.
What do you think of the community check feature?
Regards Kees
emsisoft
February 21st, 2008, 07:52 AM
Alert 1: Seems you were offline during that alert because no suggestion was available. Usually you'd get a suggestion for IE to allow it. If more than 90% allow it, you would not see the alert box at all.
Alert 2: Mamutu suggests to allow. Badly 89% of the users decided to allow. 1% more and you would not have seen that alert at all.
Alert 3: Mamutu correctly suggests to allow.
Alert 4: Mamutu detects the hidde installation correctly, but suggest to allow based on the community.
But I agree with Kees that the Browser Settings alert is configured too high. We'll optimize that detection algorithm in the next build.
solcroft, did you get any other alerts after these?
Much more interesting than knowing what happened during the first 10 minutes, would be to see how many alerts you get after 2 days or so while working on the machine.
Kees1958
February 21st, 2008, 08:44 AM
Christian,
Thanks for the reply. What about adding some startup protection (for instance all the once you detect in your Hijack Free version in A2 Antimalware).
regards Kees
solcroft
February 21st, 2008, 09:02 AM
-{ Quote: "What do you think of the community check feature?" }-
Already expressed my opinion of this on the second post of this thread, so I won't be reiterating what's been said.
-{ Quote: "Alert 1: Seems you were offline during that alert because no suggestion was available. Usually you'd get a suggestion for IE to allow it. If more than 90% allow it, you would not see the alert box at all." }-
The FPs occured regardless. As far as the community alerts go, it isn't very comforting when my security program pops up an alert telling me something is wrong, but I should allow it anyway based on recommendations from a bunch of unqualified end users, whose expert opinion is demonstrated by 11% of them deciding to block/quarantine explorer.exe. ::) In the case of actual malware samples, there is often no useful information at all.
-{ Quote: "Much more interesting than knowing what happened during the first 10 minutes, would be to see how many alerts you get after 2 days or so while working on the machine." }-
Unfortunately I have already gotten rid of it as I only intended to test it to see if the afore-mentioned problems still exist, not suffer through it for two days. But I suspect the developers you employ are already very well aware of this problem, because it would be a very sad state of affairs for your company indeed if an end user were to know your product better than you do.
emsisoft
February 21st, 2008, 09:04 AM
Kees, most of them are already integrated in the protection routines. The rest needs special handling which will be added with one of the next updates.
solcroft
February 21st, 2008, 09:05 AM
-{ Quote: "# Recognizes new and unknown Trojans, Worms and Viruses (Zero-Day attacks), without daily updates." }-
Unfortunately, daily updates (community alerts) are required to prevent it from flagging critical system files as unknown trojans, worms and viruses. :ouch:
emsisoft
February 21st, 2008, 09:17 AM
You're right, both methods use the internet connection. But that's all, what they have in common. ;) Online lookups for specific hashes are something different than daily (signature) updates.
Daily signatures updates of virus scanners are REQUIRED to detect anything.
Online lookups are nice-to-have to make it easier to decide if an alerted program is maybe a good one, but not a requirement to detect Malware.
solcroft
February 21st, 2008, 09:20 AM
All I'm saying is that it's the other way round. Think of it as the reverse blacklist scanner, if you will. Not needing updates to detect stuff sounds great, but becomes a lot less impressive when you consider that it becomes an FP machine without them.
emsisoft
February 21st, 2008, 09:32 AM
-{ Quote: "In the case of actual malware samples, there is often no useful information at all." }-
This opinion is based on?
Our experience is, that this feature does its job very well. Much better than any technical false alert reduction algorithm. Any technical approach can be easily bypassed. It is much harder to manipulate tons of user decisions (but not impossible too).
-{ Quote: "
But I suspect the developers you employ are already very well aware of this problem, because it would be a very sad state of affairs for your company indeed if an end user were to know your product better than you do." }-
Which problem? If Mamutu alerts a behavior type, it isn't the same as a "This is Malware" alert. And that's imho the biggest misunderstanding on behavior blockers in general these days. Everybody expects that a software is able to say definitely if a program is Malware or not, but behavior blockers can't. They're simply not made to do that.
Behavior blockers are made to show up behavior types that 'might' be dangerous. Well, it's always on the user to decide what do to with that information. Better one alert more than necessary, than a missed one that infects the PC.
If you want a yes/no decision made by the security software, then please use a signature based malware scanner. But don't expect that it will protect you against new dangers that are unknown to its signatures.
Kees1958
February 21st, 2008, 10:22 AM
Solcroft,
I know ThreatFire team is happy with you because you send them malware samples. I know that you have tried PRSC, Mamutu, TF and Proactive Defense.
As said, I advice Mamutu to Security Noobs, because it is in Dutch and it gives some considerations (what others have done) when popping up suspicious behavior. Noobs seem to be more pleased with Mamutu, than TF. I think the 11 percent of Mamutu users who did not trust explorer would not trust svchost either. Imagine what the quarantiane option of TF would do their system setup. So for them it is a blessing when the community feature automatically makes these decisions. I hope (TRUST) that the staff of Emsisoft checks these community ratings.
I also paid for CyberHawk Pro just because the custom rule feature (I know your ideas on this). To me TF is a combo of classical HIPS which can be tweaked and an intelligent behavior blocker which uses very advanced quarantaine features. PRSC is the only option on Vista64. PRSC protection scope is not broad, but it is absolutely reliable. Proactive Defense is impressive in the way it determines suspicious behaviour (I guess CSI uses simular techniques), only it leaves me with choices.
Could you explain which (I guess TF and PD) you favour and why. Please elaborate why and provide observations and arguments.
Regards Kees
solcroft
February 21st, 2008, 10:52 AM
-{ Quote: "This opinion is based on?" }-
Based on the fact that your user community seems to have no data to offer when I execute malware samples. Admittedly I tried less than twenty (not a very large sample size), but of those I tried apparently your community has never seen a single one before.
-{ Quote: "Our experience is, that this feature does its job very well. Much better than any technical false alert reduction algorithm. Any technical approach can be easily bypassed. It is much harder to manipulate tons of user decisions (but not impossible too)." }-
Mr Mairoll, can you explain to me why anyone would want to go out of their way to bypass a false alert reduction algorithm and make sure that your product throws an FP on theirs? Because, in my experience, it's the malware recognition algorithms that they want to bypass, not the FP reduction one.
-{ Quote: "Behavior blockers are made to show up behavior types that 'might' be dangerous. Well, it's always on the user to decide what do to with that information. Better one alert more than necessary, than a missed one that infects the PC." }-
First off, Mr Mairoll, I am of the humble opinion that I know what a behavior blocker does. I may be wrong, but permit me to say that this is quite unlikely.
I guess, perhaps, that what you're trying to say is that your product is designed to be fundamentally different from other behavior blockers on the market. Other products like ThreatFire and PRSC are designed to trigger on malware and malware only - flagging a harmless program is considered a mistake to be fixed. From what I can discern from your post, your product is different in the sense that it does not attempt to do this. Anything that RESEMBLES malware is to be reported, and alerts on valid programs are not considered an error because those programs contain "malware-like behavior", as arbitrarily defined by your company.
Thanks for the clarification.
-{ Quote: "If you want a yes/no decision made by the security software, then please use a signature based malware scanner." }-
I don't expect that of a behavior blocker. But I do expect it to control its false positives to a low enough degree that the program is actually useful. As it stands, your product offers the useless noise of a classical HIPS, minus the ironclad leak-proof protection - the worst of both worlds.
solcroft
February 21st, 2008, 10:53 AM
Kees,
I'm not sure what PD is. Are you referring to Micropoint, by any chance?
solcroft
February 21st, 2008, 11:22 AM
-{ Quote: "I know ThreatFire team is happy with you because you send them malware samples." }-
Well, to be brutally honest I don't how much benefit they get out of my exercise. As PC Tools is quite a well-known and established security vendor the scope of what they can see and collect is most assuredly far beyond that of my own. But I do it anyway, just in case the occassional sample proves useful to them.
-{ Quote: "Imagine what the quarantiane option of TF would do their system setup." }-
It would do very little. For one, TF does not flag critical system processes. Secondly, even if it did due to malicious data loaded into those programs (e.g. cmd.exe and iexplore.exe, the latter due to browser exploits), TF recognizes them as benign and only terminates them, not quarantine.
On a side note, I have seen people complain that TF shuts down their IE when they visit infected sites. Unbeknownst to them this is actually a good thing, as shellcode exploits can cause the browser to freeze up and choke 100% CPU while you waste time waiting for it to respond again. Or you can click your way through hundreds of alerts if the site continuously bombards you with trojans. Terminating IE immediately is actually quite a good idea.
-{ Quote: "So for them it is a blessing when the community feature automatically makes these decisions. I hope (TRUST) that the staff of Emsisoft checks these community ratings." }-
I hope so too, but seriously I doubt that. I'm not sure if Mamutu uploads all flagged programs to Emsisoft or just the file hashes, but if it's the latter, then there is actually nothing much you can do with just the hash. Also, even if the community ratings are not to Emsisoft's approval, what are they going to do? Tamper with the ratings? That would destroy the credibility and point of the whole system.
-{ Quote: "PRSC protection scope is not broad, but it is absolutely reliable." }-
PRSC/AntiBot does actually monitor quite a lot, but the problem is that they have a relatively high tolerance threshold. While this means they enjoy minimum FPs, it also means they miss (relatively) more malware. It's a give and take situation, I suppose. Personally, I wouldn't hesitate to use PRSC if they release a free version.
Kees1958
February 21st, 2008, 11:28 AM
Yes,
Question is about Behavioral Blockers, you are from China and know a lot about behavioral blockers, so what else could it be 8)
Please respond, so I understand
EDIT ***
-{ Quote: " For one, TF does not flag critical system processes. Secondly, even if it did due to malicious data loaded into those programs (e.g. cmd.exe and iexplore.exe, the latter due to browser exploits), TF recognizes them as benign and only terminates them, not quarantine. " }-
My dear Solcroft you are absolutely right, but I was thinking about other harmless aps. ***
Kees
Kees1958
February 21st, 2008, 11:34 AM
-{ Quote: "I hope so too, but seriously I doubt that. I'm not sure if Mamutu uploads all flagged programs to Emsisoft or just the file hashes, but if it's the latter, then there is actually nothing much you can do with just the hash. Also, even if the community ratings are not to Emsisoft's approval, what are they going to do? Tamper with the ratings? That would destroy the credibility and point of the whole system." }-
Yes and No, you could say that the community is overwritten by the formal black and white list, so in this context I agree, but I was thinking about a Emsisoft specialist endorsed black and whitelist.
Regards Kees
solcroft
February 21st, 2008, 11:40 AM
For now I don't recommend using Micropoint outside of China, as they need to work on their FPs on foreign software.
Unlike TF, it's not freeware, but if they price it at, say, around 100 renminbi when it comes out of beta, Europeans and Americans should find it dirt-cheap thanks to the currency conversion rate. And when that happens, ThreatFire is going to find itself facing its first real (VERY) formidable competitor as far as I'm concerned.
emsisoft
February 21st, 2008, 11:42 AM
-{ Quote: "Based on the fact that your user community seems to have no data to offer when I execute malware samples. Admittedly I tried less than twenty (not a very large sample size), but of those I tried apparently your community has never seen a single one before." }-
Exactly! And therefore Mamutu recommends to block the program, right? Isn't that what everybody wants? Allow the good programs and block the bad ones? Remember, the aim of the community feature is to filter the false alerts.
-{ Quote: "
Because, in my experience, it's the malware recognition algorithms that they want to bypass, not the FP reduction one." }-
Do you agree, Mr anonymous solcroft, that the main intention of bypassing is, that the malware is not alerted at all? It doesn't make a difference if this is realized by bypassing the detection (which is damn hard on behavior blockers because you can't easily change the behavior, otherwise it's no longer acting like malware), or by suppressing the alert window by trying to look like a good program (to irritate the false alert filter).
-{ Quote: "
First off, Mr Mairoll, I am of the humble opinion that I know what a behavior blocker does. I may be wrong, but permit me to say that this is quite unlikely.
" }-
Depends what you expect from a 'behavior blocker'. The better the false alert reduction is, the more harmful malwares will go through it undetected. A main problem when developing behavior blockers is to find the line between good and bad programs. In many cases a software simply can't make a strict difference between good and bad, but users can.
I understand that the browser settings alert is configured to show too much, but we'll fix that asap. If you would have tried the software for more than 10 minutes, you would have seen that it is everything else than intrusive.
solcroft
February 21st, 2008, 11:54 AM
-{ Quote: "Exactly! And therefore Mamutu recommends to block the program, right? Isn't that what everybody wants? Allow the good programs and block the bad ones? Remember, the aim of the community feature is to filter the false alerts." }-
The problem is that Mamutu has thrown up so many useless alerts by then that the user is left wondering whether this new alert devoid of community user info is another good program like all those other warnings, just new and not very popular yet, or actually a bad one.
-{ Quote: "Do you agree, Mr anonymous solcroft, that the main intention of bypassing is, that the malware is not alerted at all?" }-
Yes.
-{ Quote: "It doesn't make a difference if this is realized by bypassing the detection" }-
Correct.
-{ Quote: "or by suppressing the alert window by trying to look like a good program." }-
I agree.
But that wasn't the question. You said that a false alert reduction algorithm can be easily bypassed, that's why you just throw the program out for your users to vote on. Being suitably baffled, I asked you who would want to bypass a false alert reduction algorithm on purpose so that Mamutu detects their program as malware. And I don't see a valid answer.
-{ Quote: "A main problem when developing behavior blockers is to find the line between good and bad programs. In many cases a software simply can't make a strict difference between good and bad, but users can." }-
Mr Mairoll, I don't know what to say anymore. Remind me again why is your product so great, if it's up to the users to do all the work?
emsisoft
February 21st, 2008, 01:11 PM
-{ Quote: "The problem is that Mamutu has thrown up so many useless alerts..." }-
4 alerts within 10 minutes. And 3 of them will be fixed with the next update. Well, really a very annoying noisy software..
Ever tried to enable the alert reduction that is based on technical analysis? You'll see that Mamutu would not alert any of these 4 behavior patterns.
We decided to disable this alert reduction by default to provide the highest possible protection against malware. On the cost of a few more alert windows, that come with recommendations.
-{ Quote: "But that wasn't the question. You said that a false alert reduction algorithm can be easily bypassed, that's why you just throw the program out for your users to vote on. Being suitably baffled, I asked you who would want to bypass a false alert reduction algorithm on purpose so that Mamutu detects their program as malware. And I don't see a valid answer." }-
Sorry for my bad spelling, I'm native German. What I was talking about is to cheat the false alert reduction algorithm so it does NOT alert the malware program at all (filtered by the fp reduction). There are really little differences between regular programs and typical malware files. Someone could build a piece of malware that behaves too similar to a regular program to cheat the fp reduction.
-{ Quote: "Mr Mairoll, I don't know what to say anymore. Remind me again why is your product so great, if it's up to the users to do all the work?" }-
Not the users do the work, Mr anonymous solcroft, Mamutu does the main work, detecting suspicious behavior. The community users do only the work of providing comfort to each other when it comes to wrongly alerted harmless programs. Please don't mix that.
Please do me a favor: If you didn't use a new program for while, please don't bash on it. If you don't like what the featurelist says, just ignore it. I guess there are many users in this forum who are interested in qualified comments and reviews of the product, but not in reading our never ending discussion. Don't you think so?
From my side: I'll stop the fight and not reply anymore.
Kees1958
February 21st, 2008, 01:12 PM
-{ Quote: "For now I don't recommend using Micropoint outside of China, as they need to work on their FPs on foreign software.
Unlike TF, it's not freeware, but if they price it at, say, around 100 renminbi when it comes out of beta, Europeans and Americans should find it dirt-cheap thanks to the currency conversion rate. And when that happens, ThreatFire is going to find itself facing its first real (VERY) formidable competitor as far as I'm concerned." }-
Solcroft thanks,
How is it possible that I have tested it during the trial period and it did not give false positives? At least in my terminology?
It asked my apporval after installation (liek OA). I would not count that as a FP. Yes it were normal applications but yes it did low level suspicious things. Best was it did recognise it before execution. :D
I agree this is one to watch. Any idea on the internals (how it works). Info is a bit cloudy on this.
Regards Kees
solcroft
February 21st, 2008, 01:40 PM
-{ Quote: "4 alerts within 10 minutes. And 3 of them will be fixed with the next update. Well, really a very annoying noisy software.." }-
Just in case you aren't aware, one of your competitors gave me three FPs on three scarcely used and unpopular programs over a course of four months. Another competing product gave me zero FPs. Yet another threw up two in the span of a two days, but were promptly fixed once reported, with no beating around the bush. If you really don't think that 4 false positives on Windows components/critical system files within ten minutes is a problem, I suppose I'll just have to disagree. Keep in mind that I tried it on a bare system - don't you think that other computers with a myriad of other software installed would produce even more?
And yes, I'm looking forward to your improving your product. More competition in the field is, I think, always a good thing. But until then, I think my remarks are quite justified.
-{ Quote: "Ever tried to enable the alert reduction that is based on technical analysis? You'll see that Mamutu would not alert any of these 4 behavior patterns.
We decided to disable this alert reduction by default to provide the highest possible protection against malware. On the cost of a few more alert windows, that come with recommendations." }-
Will you be telling me, if and when I turn that feature on and discover that Mamutu provides inferior detection capabilities, that I should turn that feature off?
My policy is to test the behavior blocker product class at their default settings. And it seems that your philosophy is that producing FPs is a more preferable choice than missing malware. I'm simply reporting that fact.
-{ Quote: "Sorry for my bad spelling, I'm native German. What I was talking about is to cheat the false alert reduction algorithm so it does NOT alert the malware program at all (filtered by the fp reduction). There are really little differences between regular programs and typical malware files. Someone could build a piece of malware that behaves too similar to a regular program to cheat the fp reduction." }-
Your competitors have proved quite adept so far at overcoming such problems. Of course it's easier to just have your users vote on the alerts, I'm just pointing out that the easy way out may not be without its own drawbacks as well.
Not the users do the work, Mr anonymous solcroft, Mamutu does the main work, detecting suspicious behavior. The community users do only the work of providing comfort to each other when it comes to wrongly alerted harmless programs. Please don't mix that.
Please do me a favor: If you didn't use a new program for while, please don't bash on it. If you don't like what the featurelist says, just ignore it. I guess there are many users in this forum who are interested in qualified comments and reviews of the product, but not in reading our never ending discussion. Don't you think so?
From my side: I'll stop the fight and not reply anymore." }-
Rasheed187
February 22nd, 2008, 06:53 AM
-{ Quote: "Exactly. Mamutu does not only alert things like "Program xy connects to the internet". It combines several parameters until it give an alert window." }-
Yes, I believe TF does this too. However, if some tool tries to install a service/driver, I suppose it will always alert you straight away? What about global/window hooks? Because sometimes, that´s the only thing an app tries to do.
-{ Quote: "
We'll test against that ones. But if they simply try to inject code into other processes, they'll be detected for sure." }-
I don´t think they try to inject code, instead they try to modify executable files. You also have some file infectors who only want to cause damage, and try to destroy .exe files.
-{ Quote: "
Sorry, that's not possible. The server side licensing storage is a very effective way to avoid illegal use of the program. Every client side solution can be cracked too easily." }-
OK, why not make only the test/trial version "account free"? Or are you afraid that people will crack the time limit too? :what:
-{ Quote: "
Btw. please don't test the program on a virtual machine. Lots of Malwares don't act harmful when they detect that they're running on a virtual environment." }-
Don´t worry, I have a small malware collection and they allmost all work inside a VM. Also, I´m using a lot of non-malicious testing tools, just to see how a HIPS reacts. ;)
Rasheed187
February 22nd, 2008, 07:27 AM
-{ Quote: "And that's imho the biggest misunderstanding on behavior blockers in general these days. Everybody expects that a software is able to say definitely if a program is Malware or not, but behavior blockers can't. They're simply not made to do that." }-
That´s what I thought also. But apparently, the new trend is that HIPS try to avoid as much "false positives" as possible. If I´m correct Mamutu tries to do this too. So basically, these "expert" HIPS will try to warn only when something real fishy is going on.
-{ Quote: "
Behavior blockers are made to show up behavior types that 'might' be dangerous. Well, it's always on the user to decide what do to with that information. Better one alert more than necessary, than a missed one that infects the PC." }-
In some other thread, that´s exactly what I said. Personally I still prefer "dumb" behavior blockers, they alert about everything that´s going on and let you make the decision. Apparently TF (and Mamutu?) will sometimes choose to not alert you about stuff, when they think it´s probably not malicious. But I´m afraid that they will sometimes get it wrong.
-{ Quote: "
Depends what you expect from a 'behavior blocker'. The better the false alert reduction is, the more harmful malwares will go through it undetected. A main problem when developing behavior blockers is to find the line between good and bad programs. In many cases a software simply can't make a strict difference between good and bad, but users can." }-
Exactly!
-{ Quote: "
Not the users do the work, Mr anonymous solcroft, Mamutu does the main work, detecting suspicious behavior. The community users do only the work of providing comfort to each other when it comes to wrongly alerted harmless programs. Please don't mix that." }-
I have to say, that I have never liked any "communities" feature, but I think it´s nicely done in Mamutu, eventhough I would most likely not use it.
-{ Quote: "Other products like ThreatFire and PRSC are designed to trigger on malware and malware only - flagging a harmless program is considered a mistake to be fixed." }-
Does this also mean that they have a so called "whitelist"?
-{ Quote: "
I don't expect that of a behavior blocker. But I do expect it to control its false positives to a low enough degree that the program is actually useful." }-
I have to say that eventhough I don't care about false positives, I do care about STUPID false positives.
DasFox
February 29th, 2008, 02:39 AM
-{ Quote: "This is the biggest sign of a lousy security software.
Mamutu's FPs were absolutely atrocious, but instead of working on a better recognition algorithm and/or whitelist to solve the problem, they throw the problem to the users instead. WHY on earth should I care which users voted what on program X? Who are they anyway, qualified experts?
To quote ErikAlbert: "That's not security, that's gambling."" }-
Well I came here for answers read this, sheesh, sounds like crap, so no Hootoo Mamutu for me, LOL...
I'm not impressed with their A-squared either... :thumbd:
Matern
February 29th, 2008, 05:07 AM
I'm a little disapointed,too.
It does not much more than WinPatrol Plus, and it has no detection of processes and it has failed one Spyware Driver at my Test, even a simple one, it was Gain Gator. If you run the PC Security Test It comes only two Popups, Autostart and Internetexplorer, if you allow Autostart the created Malware will not be detected. So what is when you have Malware in a "good" Programm that you allow, I don't believe that Mamutu does anythig against this.
IMO it is really essential that a behaivior Blocker is looking at the Processes.
cruelsister
March 1st, 2008, 11:16 AM
Total lovefest going on about Mamutu on another thread here. A post about Mamutu failing AKLT brought the response that the software probably knew AKLT was only a test so it failed on purpose.
Gotta love such critical insight.
Wordward
March 1st, 2008, 04:23 PM
-{ Quote: "Total lovefest going on about Mamutu on another thread here. A post about Mamutu failing AKLT brought the response that the software probably knew AKLT was only a test so it failed on purpose.
Gotta love such critical insight." }-
It wasn't critical insight, but only an opinion based on what has been said in the Emsisoft forum about Mamutu's inability to pass the trojandemo test. I don't really worry all that much about getting infected, so for me Mamutu along with Avira and PC Tools FW is pleny of protection. I just think Mamutu has a very well layed out GUI and I like how well it runs on my PC. I also like ThreatFire a lot and perhaps it may offer better protection. But I think Mamutu is definitley the more polished of the two.
Wordward
March 2nd, 2008, 04:12 PM
This program is now running well with PC Tools FireWall and Avira Personal Premium. What a nice piece of software.
Perman
March 2nd, 2008, 11:58 PM
Hi, baerzake:
If you browse this thread, please take a note:
You have published a test result of Mamutu against FOUR tough malwares, including Robot Dog, Panda etc on Kafan forum.
If you could tell us here, a lot of members will be greatly appreciated.
Too bad , I am not that tech savvy, can not translate them into proper English terms, although I am very much Chinese fluent.
Take care.
P.S. Another member of Kafan did a similar test of AntiBot against the same FOUR, results are quite different, can you elaborate it a bit ?
vBulletin® Copyright ©2000-2012, Jelsoft Enterprises Ltd.
Copyright ©2002 - 2012, Wilders Security Forums