Could someone using Threatfire 3.5 confirm my test result?

1. When I run AKLT.exe, select one of the keylogging methods and then type something in (for instance) notepad, I get a pop-up from Threatfire about keylogging activity. I then let TF just kill AKLT.exe.

2. Next I rename AKLT.exe in winlogon.exe run it and select one of the keylogging methods. Now I can type something in notepad and AKLT is simply logging it without any pop-ups from ThreatFire.

Could somebody either confirm these results or tell me his results are different from mine?

 

ENOUGH PEOPLE!!!

Name me one software that doesnt have issues based on user, user setup, user intelligence. Ok, I bought Rollback today because it is the only way I can load all Sims games at one time with each in its own snapshot. So I did a little testing for about 4 hours today and uninstalled and reinstalled it quite a bit to test.

With Avira set to only scan not all files it was fairly quick making snapshots. With it set to scan all files, it slowed down considerably. With Eset, now using, it is still slow but only when taking a snapshot.
With Threatfire and Sandboxie, SUPERFAST. It seems the scanning of the AV plays an integral role in the speed of snapshots. So before you blame it on Rollback, take a look at your setup.

 

It's been a while since I did the same test as you and as I remember TF did not catch the majority of the exploits.

 

What Protection Level you were using in the test? Also, if it was 3, what happens at 4 and/or 5? May be interesting.

1956 was a good year btw

 

Personaly I was never impressed with TF.
You could try GesWall or DefenseWall, both are excellent at blocking/stopping keyloggers.
GesWall has a free and paid version, DefenseWall has only a paid version but worth the money.

trjam,
Just a tip when making snapshots with Rollback Rx,
Create the snapshots using the tray icon, not Rollback's GUI. Its much faster.

 

Your quote apparently seems related to something completely different. Hey man wake up !!

 

Don't quite understand some replies (probably misposted).

The reason for this test is that I think the whitelist of ThreatFire is only consisting of executable file names.

This means that if I take a malicious application, in this case the keylogger AKLT.exe, and run it ThreatFire will produce pop-ups.

However, if I change the name of the malicious file (in my example AKLT.exe) into one on the whitelist of ThreatFire (like winlogon .exe) than it can do whatever it wants to do without any reaction from ThreatFire.

On my PC this seems to be the case (which would mean that the protection provided by ThreatFire can be easily circumvented, just by giving the malicious application a name which is on the whitelist).

I just would like to have a check made by someone else, to exclude that my result is caused by some conflict with other security software on my PC.

By the way, I run ThreatFire just as it is right after install.

Would appreciate it if someone could check this for me.

 

LMAO,Lets Give him a break, He Is Usually Awake when he writes

 

It's been a long day for trjam. Let's give him a break. It was rather warm here in Southwest Virginia today...I'm sure it was much warmer in Charlotte. Maybe heat stroke? .

Later...

 

Henk1956,

I tried renaming the aklt executable to winlogon.exe, but received an error message when trying to run it, so this test was not possible.

I'm running W2K and under a Limited User Account.

Where can one find the TF "whitelist"? I could try another name. I did rename it to kencat.exe, and this file behaved exactly as aklt.exe. I tested under Protection Level 5. At least TF hasn't been "padded" to just pass aklt.

I would hope that TF is smarter than relying just on a filename in a whitelist to allow it to do whatever it wants

For what it's worth, only tests 1 and 2 out of the 6 I would consider a pass (TF alert given for keylogging detected). Test 3 Failed completely, no TF alert and aklt detected the keys. Test 4,5 and 6 were dubious, where TF issued an alert (this program is attempting to manipulate....another program...) but if the process is allowed to continue, the keys will subsequently be detected.

Sorry I couldn't confirm winlogon. Hopefully someone else will be able to.

Edit: is there a space in your winlogon .exe file name as in your post? maybe that's why it ran?

 

Similar issue in this thread

 

Henk,

I did not check but this could well be the case. TF allows YOU to change a name, when another executable changes the name of another executable TF will pop-up!

Therefore the programmers problably have optimised the code and assumed that the white list is always a clean and reliable reference (because other rules protect exe name change).

So yes when this protection fails, this is a weakness. Considering the strength of TF, I would not worry about it.


A lot of members are mentioning the CPU usage of TF. This was the reason for me to do some testing. And Yes compared to Mamutu, ThreatFire uses about 600% more CPU time! in a 1 hour internet session. Now comes the surprise, when I checked disk access, CPU performance and multi thread performance, it turned aout that:
- disk access is as fast (of TF and Mamutu)
- multi thread performance of TF is about 8 percent FASTER!
- in CPU benchmarks TF scores a 11% BETTER/FASTER result


Regards Kees

 

The response of djames in that thread ("TF does not care about test apps") borders on the "we can't be fairly tested" alibis-of-old from Prevx, BOClean, etc.

No offense but -- if it cannot be tested, it cannot be trusted. At least, not in my book.

This could mean that (in 1 hour) Mamutu used 1 second of cpu whereas TF used 6 seconds. No big deal. I suggest you use absolute values rather than percentages in comparisons such as this. Just a thought -- no offense intended.

 

Damn, time to join AA. That post was ment for the Rollback thread. I sincerly apologize to all in this one.

 

Tried this test with Mamutu 1.7. Didn't detect any of the keylogging attempts :-(

 

Neither does ThreatFire, I've read a post, where ThreatFire failed to detect a keylogger.
Dangerous behavior blockers seem to have a problem to consider keylogging as dangerous behavior and keyloggers are one of the most dangerous malware around and they do their evil job immediately.

 

NO apology needed,Just one of thouse rear moments.It Happens to the best of us.

 

Ok, one more time

1-AKLT.exe is not malicious. If TF flagged it, it would be a FP.
2-People not understanding this in full, test TF with AKLT.exe, TF "fails" and they report by email, forum, comment with other people etc.
3-TF adds detection so people can see it working. However, apparently, if you change the name, TF will analyse it normally, and since AKLT.exe is not malicious, it will fail.

However, the OP seems to be only testing the whitelist. I would just note one thing. This is not a whitelist application afaik, ie, it's not excluding the executable from analysis, it's including it in a FP's list pop-up show.

 

that seems troubling - anyone who designs a whitelist based on filename has never considered how to attack a whitelist... ideally a whitelist should be based on some kind of hash of the program's contents rather than the filename... much harder to pretend to be a trusted program that way...

 

That's why I use AE with its quintuple verification of each whitelisted executable, including Delete/Copy Prevention and AE has a 100% detection rate, while ThreatFire is more a gamble, too vague.

 

It's not a whitelist, unless i'm missing something.
Easy to test if it's a security risk. Get a malware sample that TF can detect and block. Rename it AKLT.exe , run it.

 

Used to have TF but moved away as it is of course a freebie and the adware now in all these free SW versions turns me right off. I would want to know if it is calling home.

I thought TF also used behavior monitoring to pick up baddies? So if that is right, the name change alone should not have "worked".

If it is only white list based on file name it is worthless, the exe hash should be used at least to id the keylogger.

Strongly suggest you post your question on the PC Tools user forum or scan the FAQ there to get direct info.

 

It's obvious i'm talking to myself..

 

I always have that feeling. Doesn't really matter to me as long my post counter increases.

 

Thanks for all respons and sorry for this late post (had to get some sleep and go to work).

kencat:
- winlogon.exe did not have a space in it (typo)
- The whitelist is probably in the Program Files\ThreatFire\TFWL.db4 file.
I can't read it, but know for sure that some essential windows executables will be certainly included in the list (among which winlogon.exe, smss.exe, ntoskrnl.exe, csrss.exe, userinit.exe, lsass.exe) to ensure windows will boot.

MrBrian:
- Thanks for the link you provided.
In the mean time I did another test not involving AKLT.exe with similar results. This strengthened my believe that indeed the whitelist just consists of executable names only. Any executable having such a name (being the either the proper or a malicious exe) can do what it wants, without a beep from TF.

kees1958:
- TF allows YOU to change a name, when another executable changes the name of another executable TF will pop-up!
Thanks Kees, I did not know this. Will TF always notify me when this happens or does the application have to violate multiple rules?

Pedro:
- Yes, I only wanted to test the whitelist: Does TF only test for the names on the whitelist or does it test for more, like full path or MD5 checksum).
To test this I just needed an application that would trigger TF to produce pop-up warnings. AKLT was just one that was available. I did not want to test if TF fails/passes keylogging tests.

- You say "This is not a whitelist application afaik, ie, it's not excluding the executable from analysis, it's including it in a FP's list pop-up show".
Maybe TF is analysing each executable, but if it is on the whitelist it does not only stop pop-ups it also does not prevent any malicious activity. The result is the same as not analysing executables on the whitelist.

kwismer:
- I was also expecting TF to check the full path and/or MD5 checksum for executables on the whitelist, but this doesn't seem to be the case. I noticed that TF did not use the full path when I was trying to add an executable to the trusted list. To add the executable I used the browse button. In that case the full path is added to the trusted list which did not have the effect I expected (it seemed as if the trusted list was simply ignored by TF). However, if I just add the executables name to the trusted list (without path) it works like expected. This was the reason why I wanted to test if the whitelist was also containing only file names.

Escalader:
Already posted it at PC Tools (http://www.pctools.com/forum/showthread.php?t=51887) but moderator is only saying that they don't use filenames but a file's MD5 Hash. At the moment, I find this very hard to believe.