[Solved] False positives reported but not corrected

[Lisandro]

I'm about to delete that files...

Since it is just a log file you can delete it (http://forums.cnet.com/7726-12546_102-5069671.html).
I suppose the virus analyst can check the file I've send by Chest, can't they?

[kubecj]

It's very weak signature taken from malware which deletes brazilian banking software.

I see your file in our fp queue. There is 1 submit (yours only, I suppose) and has 1 point. Because the queue is ordered by points (which are added or removed by various heuristics), it's very probable that there will be quite a while while before such file will get to the manual inspection of analyst, if ever.
The main reason for this slowness is unending flow of FP reports on files which are malware, most of them with helpful comments like
NAM: okjgkirfgj
VER:6.0.00
PUB:kdfjkk fglkprfgk


I can't suggest any better solution that to put them in exclusions.
We are currently working on some changes which could prevent some of such falses, but they need serious testing before deployment.

[Lisandro]

It's very weak signature taken from malware which deletes brazilian banking software.

Hmmm... I've did it, I mean, I've unadvertedly remove one of the banking software as I did not recognize it. The name of the files/folders are "Scopus" and the bank has other name, "Bradesco".
Could it be?

I see your file in our fp queue. There is 1 submit (yours only, I suppose) and has 1 point. Because the queue is ordered by points (which are added or removed by various heuristics), it's very probable that there will be quite a while while before such file will get to the manual inspection of analyst, if ever.

I see. Sorry for blaming. I always think I'll get some priority

The main reason for this slowness is unending flow of FP reports on files which are malware, most of them with helpful comments like
NAM: okjgkirfgj
VER:6.0.00
PUB:kdfjkk fglkprfgk

Have you ever thought on having a priority submission for Evangelists?
I mean, Polonus, Essexboy, Pondus... deserve it and won't send you such silly comments...

I can't suggest any better solution that to put them in exclusions.

I could do it, but I've sent the files to Chest and will try to generate them again without loading KillSwitch.
If it persists, I'll add to the exclusion lists.
If it disappears, I'll test KillSwitch again and if it comes again, I'll post in Comodo forums.

We are currently working on some changes which could prevent some of such falses, but they need serious testing before deployment.

Thanks. I'm glad to help.

[essexboy]

I have those etl file on my 7 system I am running a scan now to see if they alert

[essexboy]

No alert on my etl files - latest vps 110522-1

Could Avast be alerting on the way killswitch was changing the attributes on the files prior to deletion ?

[igor]

Well, hard to say, as I'm not sure what exactly that "trace log" is actually tracing/logging.
If it's common page fault areas, it could be some other tools signatures. Or, there may be some bug in the systems disk access to these files, and some garbage, previously present on the disk, got there?

I remember the same happened to me a few years ago on one of my office computers (which had a lot of malware on its disk, but not actively running - and no other AV tools running either). I was getting various infections in those ETL files (logged in on the computer, and a virus alert was waiting for me).

[Lisandro]

Files were not recreated yet. I need to reboot to test.

[polonus]

Hi Tech,

The issue is a little more complicated than you assume.

Here I also must say something to the defence of avast detection in this case. First thing, this was an "automatically generated detection on a test machine", so somehow someone has to report, before it will be critically observed. That is the point you made, and good you did.

Second complicating factor in this case is that it is a detection for a certain initial infection.

Good it is mentioned, reviewed and reanalyzed,
on the other hand if these diagnostic detections are missed as a result the OS can really become perverted by the malcode,

polonus

[Lisandro]

Thanks Polonus for jumping on.
Seems that the automatic generated signature must be revisited and I'm glad to participate on this process.
Thanks also for all other users that tried to help and, specially, Kubec for jumping

[igor]

Erm, who said it was automatically generated?

As for the revisiting... well, can be, but I still think (based on what happened to me back then) that this can happen for any signature, no matter how great it is.

[Asyn]

Thanks also for all other users that tried to help...

NP, Tech.

Erm, who said it was automatically generated?

I wondered, too.

[polonus]

Hi Asyn,

This was my interpretation of a write-up on the Trojan-Downloader.Win32.Tiny.afe virus I found. Could also mean that the write-up of the virus was generated automatically following an analysis of the program, and the procedure at avast may be different.
It is not such an important observation. What remains is the fact that it is an intial detection of infection and that missing these detections can have serious consequences, but FP's should be taken out,

polonus

[Lisandro]

Erm, who said it was automatically generated?

An experienced user, by IM... Sorry, maybe I just misunderstood.

Edited... Polonus revealed himself.

[Asyn]

Hi Asyn,

This was my interpretation of a write-up on the Trojan-Downloader.Win32.Tiny.afe virus I found.

I see.

[polonus]

Hi Asyn and Tech,

You see that these issues are not all black and white and you have to weigh a lot of considerations. I think avast should be proud of users like you that are so concerned, keep asking questions and keep the avast people that sharp. This is also why I am so proud to be part of the avast community,

polonus