Anti-Executable and ThreatFire + other ?

I've seen several screenshots of ThreatFire, where .exe-files as threats were displayed.

1. When Anti-Executable = ON, these .exe-files can't run.
In that case ThreatFire won't do anything, because these .exe-files didn't run.

2. When Anti-Executable = OFF, these .exe-files can run.
In that case ThreatFire will check them on malicious behavior and warn me.

So my assumption is that these members, who posted these screenshots of ThreatFire, don't have Anti-Executable on board or disabled it. Am I right about this ?

--------------------

ThreatFire talks alot of zero-day threats. That's OK, but what has this to do with malicious behavior, which can be old or new.
So I assume than ThreatFire also will act, when the threat is much older.

The expression "malicious behavior" is vague to me.
Is this explained somewhere more in detail or is it a secret of ThreatFire ?

--------------------

"Events Analyzed" and "Programs Examined" does that mean that scripts are also analyzed and examined
on malicious behavior ? After all these scripts are doing something on your computer, when they run.

Thanks in advance.

 

Correct, they aren't using a whitelisting solution of any kind (SRP, Anti-Executable, etc)

- Threatfire detects and stops malicious behaviours. Obviously, their marketing focuses on 0-day/unknown threats since these are the most prevalent and the ones causing troubles to AV companies. You're worried about the next 0-day vulnerability to be exploited by a nasty rootkit, not by the Michelangelo virus.
- Example of malicious behaviour: dropping an executable in the browser's cache, copy it to a system folder, start a hijacked instance of iexplorer.exe, add an autostart entry in the registry and trying to control the Service Control Manager to install a driver. Obviously, the behaviours observed and how they're correlated are a trade secret. Behaviour blockers employ a sofisticated ruleset/algorithm to detect a big amount of malware while making few FPs (since some legitimate software exhibits malicious behaviour)

 

@Lucas,
SRP = ? What about scripts ?

 

It seems to me a very thin line when it comes to behavioral blockers because of F/P's, but then in ThreatFire it's but supposed to be an easy task to just return it back where it was if thats the case.

I think thats why i prefer HIPS and apps like AE, in AE like Eric mentions, it snags the executables right off the bat from the microsecond of signalling activating itself, in a HIPS the executable is aborted at the moment of signalling it's activation too but of course requires the command & control to come from the operator.

There is been a whole lotta discussion lately on ThreatFire. Are there any other strictly behavioral blockers aside from Symantec's that is noteworthy?

 

@Lucas,
Example of malicious behaviour:
- dropping an executable in the browser's cache
- copy it to a system folder
- start a hijacked instance of iexplorer.exe
- add an autostart entry in the registry
- trying to control the Service Control Manager to install a driver.
Yes but I remove these changes on reboot.

I'm trying to figure out, what TF does more than I already have.

 

I believe SRP can be setup to block scripts too. It has extensions like .vbs, .vbe, .wsf and stuff already in it's "deny" list already. You can add stuff like .js, .jse, .sct, etc...
These are script extensions no?

I've also blocked wscript.exe and cmd.exe just to be on the safe side.

 

Yes they are script extension, I have also a list of those.
.BAT, .CHM, .CMD, .COM, .CPL, .CRT, .EML, ,.HTA. HTM, .HTML, .INF, .INS, .ISP, .JS, .JSE, .LNK, .MSC, .MSG, .REG, .SCT, .SHB, SHS, .VBE, .VBS, .WSC, .WSF, .WSH
But I don't know what the abbreviation "SRP" means, Salt River Project ?

 

@erikalbert

LOL my bad It means "Software Restriction Policy".

 

I'm testing ThreatFire now and it looks quite good. What I don't understand is that why it want to connect home even I have unchecked Check for Updates and Community Protection?! So far I have build 4 Custom Rules and I have to say that I like if there is possibily put auto block or something similar. I build those rules to block something. I'm using Protection Level 5 with zero pop-ups in normal usage

 

For those who do use ThreatFire are you aware whether or not it still employs (4) drivers and at least 2 running processes?

If i recall from when it was CyberHawk, i tracked down my own issues originating from any one or more of those 4 drivers it impliments to help conduct it's interception routines.

 

1 Service and 1 Process when TF is only in tray. When you open GUI then there is 2 Processes.

 

Yes, AE is so sensitive, you can't even move your mouse over an unauthorized executable, like it has a radar.
If I try to download a new legitimate software installation file and I forget to turn off AE, I can't download the file, even when I turn off AE. I have to close Firefox and try again.

All the tests with killdisk, robodog, etc. have been done without AE, otherwise they couldn't test them.

 

With TF in tray and GUI not opened I have two items running as processes. They are "TFTray.exe" and "TFService.exe". I have one item for TF listed under Services, it is labeled "Threatfire". There are four drivers loaded they are "ThreatFire Filesystem Monitor", "ThreatFire Keyboard Monitor", "ThreatFire Network Monitor", and "ThreatFire System Monitor".

 

Thanks Firebytes

I knew PCTools with Novatix programmers had not deviated from this compilation of components and i'm not knocking it but i have experienced problems in the make up from one or more of those 4 drivers before and nothing else.

I'm sure it's vastly improved but i still can't help but feel not entirely confident enough as i once was when it was CyberHawk very early version. That one was lightning quick and immediately terminated any offending file as i'm sure ThreatFire does also, even better perhaps.

But again, please accept my concern on this, drivers alone, even a single one, can pull down even the best intended programs, and i'm just not confident that they chosen to keep the same programming layout as before with 4 drivers where other programs mostly impliment just one or even two in some cases.

I'm no security programming expert so i can't nod up or down to this type of programming for neutralizing offensive files via behavioral techniques, but untill explained in detail to satisfaction i'm not comfortable with that.

Hence, EQS plus Anti-Executable on a FD-ISR snapshot is my alternative to ThreatFire untill i see a day they completely redo the program again minus 4 drivers.

 

- SRP = Software Restriction Policy, a free anti-executable built-in right into Windows.
- I don't know how well Threatfire protects against macro/script malware (solcroft should know more) but if you're talking about drive-by downloads Threatfire works very well (since every drive-by exploit places an executable which in turn behaves maliciously)

The core of Prevx protection is behavior blocking, enhanced by a malware scanning engine, whitelists and herd intelligence.
Norton Antibot is a rebrand of Sana Security's PRSC. Micropoint (a Chinese product), Panda's TruPrevent, F-Secure's DeepGuard, Symantec's SONAR, Kaspersky's PDM are other examples of behaviour blockers. I'm surely missing others.

Today's malware is mostly executable-based, so AE is all you would need. TF offers the possibility of knowing when malware is attempting to install/execute while avoiding the "FPs" of AE on legitimate software. Different appraoches for different needs and pain thresholds

 

Just by looking at the names of the drivers, you can see that TF's developers have chosen to separate functions: one driver is hooking the filesystem, another is watching network connections, another hooks the main kernel functions (CreateProcess, CreateThread, etc) and the last one hooks the keyboard.
Also remember that, by design, TF needs to deal with active malware, so it needs to be fairly resistant to malware termination/unhooking. Maybe, using only one driver means having only one defense.

 

lucas,
Thanks for post #15, I don't think I need TF with AE on board and my way of restoring my system. Unless somebody has very good arguments, I'm going to ditch it next week.

 

I get all of that protection and MORE with EQSecure 4.0 Beta 2 plus a Sandbox to boot. Not only that but with Alcyon's Rulesets there leaves little if any room to enter anything including Folder creation. In fact EQS with it's Black List can be set to instantly deny access to as many registry entry points as you will as well as file protections and other areas. If i need to install a good app it's as simple as a one-button press to disable ALL potections just long enough to install them just like turning off AE to install a good program, so with all that protection and more ThreatFire just doesn't add up, especially when you consider it's lite as a feather and doesn't bog anything down with additional drivers or running processes.

EQS uses the core operating system tables itself to set up camp and shield off any intrusions, and with the proper self-protection theres not much any malware can do to penetrate a system and especially one teamed up with Anti-Executable!!!

 

Why do you compare a classical HIPS with a behav. blocker? With TF, you don't need to configure anything, import rulesets, disable protections or any other maintenance task. Just install it and forget it until you receive a malware alert or the ocassional FP.

The basic (and most important) function of every classical HIPS is execution control, so adding AE is completely pointless.

 

Because in my opinion Behavioral Blockers are more vulnerable then a HIPS. And a conscientious security minded user should always have at least some interactions on what decisions are made as opposed to a pre-programmed software that could make mistakes completely undetectable.

The install it and forget it is OK for an app like ThreatFire so long as theres other security fallback measures in place. For that matter even the best HIPS should be braced with some form of a fallback measure app because softwares + system are prone to unpredictable malfunctions do to any number of possible reasons.

Not neccessarily although chances are indeed remote but definitely not out of the questions for reasons just mentioned above.

Layers Matter.

 

Yep, because behav. blockers deal with already running malware. But HIPS are equally vulnerable once you grant execution permissions, even with those HIPS with all the bells and whistles (file monitor, reg monitor, interprocess communication, network monitor)
Once malware is executed, it becomes a Russian roulette game.

Sure, just create a LUA. Every security software becomes 10x more effective/reliable/safe if you work under LUA

Both (AE and classic HIPS) hook the same CreateProcess function, so they're interchangeable. It's just a matter of tastes/needs:
- Trust your entire system and then apply a default-deny approach with no questions and no choices = AE.
- Trust nothing, then grant execution permissions only for the applications you deem safe and set the behaviour for future requests of execution rights (prompt/allow, prompt/block, block/notify, block silently, etc). If you wish, also build a ruleset of the default behaviour of every app (who can launch it, what it can launch, what files can be created, etc) = HIPS.
In other words: PG free = AE = SSM with UI disconnected.

 

Can't dispute any of that. It sums things up pretty well enough.

I just like to see some competition in the behavioral blocker industry then whats available now because as much as i wouldn't mind running one again myself, the choices just don't suit for my taste ATM, but then thats just a personal preference.

One thing is clear and really good for all of us, and that is security vendors are really pushing the envelope these days like never before and thats a very welcome encouragement no matter how you look at.

 

But is TF as reliable as HIPS or is HIPS better than TF regarding protection ?

 

I don't understand your question Erik

 

An HIPS would offer more control of your system and better security if you know what you're doing.