Mamutu 1.5.0.18 released [NEW]

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.

 

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

 

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.

 

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.

 

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

 

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.

 

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

 

Already expressed my opinion of this on the second post of this thread, so I won't be reiterating what's been said.

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.

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.

 

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.

 

Unfortunately, daily updates (community alerts) are required to prevent it from flagging critical system files as unknown trojans, worms and viruses.

 

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.

 

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.

 

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

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.

 

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

 

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.

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.

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.

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.

 

Kees,

I'm not sure what PD is. Are you referring to Micropoint, by any chance?

 

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.

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.

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.

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.

 

Yes,

Question is about Behavioral Blockers, you are from China and know a lot about behavioral blockers, so what else could it be

Please respond, so I understand

EDIT ***

My dear Solcroft you are absolutely right, but I was thinking about other harmless aps. ***

Kees

 

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

 

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.

 

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.

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

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.

 

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.

Yes.

Correct.

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.

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?

 

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.

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.

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.

 

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.

I agree this is one to watch. Any idea on the internals (how it works). Info is a bit cloudy on this.

Regards Kees

 

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.

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.

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.[/QUOTE]