DavidR
41
I’m not convinced that it is connected, just that it happened to be in the temp folder when you did your checking. If it were connected to the rootkit scan, then I guess after I clered the temp folder and the next day after boot there were some sig*.tmp files there but no afd.sys file as in the image in Reply #34 above and I can’t recall having seen that file in temp (not that I go looking in temp often).
Asyn
42
Seems I wasn’t clear enough. 
Ok, I try again…
There are several empty files and one file with the size of 136Kb for each day/reboot.
The 136Kb file is a copy of afd.sys (See Reply #27 & #29)
It’s not named afd.sys though.
Hope you understand what I mean now.
DavidR
43
Well that could have been the analysis of that file by the anti-rootkit scan as in the First post example of the contents of one of the files viewed in a text editor.
Asyn
44
No, it’s not an analysis of the file, it’s a copy of the file (afd.sys) itself.
But with a name like sig*.tmp
DavidR
45
But that doesn’t change the overall context of my answer, it is being analysed and that may require making a copy to work with. So it is still the same association, it is being scanned by the anti-rootkit scan not used by it as such.
system
47
Some more confirmations and progress… very nice!
WRT to that sig*.tmp file being identical to afd.sys (I hashed both of mine and they match), I see that right before creating that sig*.tmp file AvastSvc.exe performs a read of C:\Windows\system32\drivers\afd.sys. So the behavior appears explicit and purposeful, and at first blush consistent with examining something in afd.sys.
Asyn
48
Thanks for the confirmation. 
DavidR
49
I think we have concluded that there is something wron with the anti-rootkit scan in regard to the temp folder and sig*.tmp files already.
- Because A) drivers are going to be what the anti-rootkit would scan/check, B) if it were a required then, then I don’t see why it simply wouldn’t use the original file rather than create a copy with a .tmp file type C) only one other and you has mentioned this afd.sys file.
I have seen the 136KB file size in my temp folder but I haven’t done a hash check to confirm/deny afd.sys. I still think it is being scanned rather than used, but that is supposition as there really is no easy way to confirm its use, rather than just being scanned…
In the same way you see unp99999.tmp files in the avast folder these are copies of files copied there for scanning not use, that is the logic that I’m applying here; I don’t know if that logic would be correct for the anti-rootkit scan, but then it isn’t conforming to other scans, files not sent to avast sub-folder and files not removed after conclusion of scan.
DavidR
51
Well I have sent off an email with links to the topic and some posts within it.
Asyn
52
Great, thanks Dave. 
Let’s hope for a quick reply.
DavidR
53
Well it is the weekend and I wouldn’t call this one a high priority, a problem/bug yes.
system
55
My first look and post in this thread was extra rushed so as to share something productive before I went to sleep. I wanted to at least briefly revisit the “both AvastSvc.exe and cmdagent.exe access those files” subject today.
- When I captured that log of just AvastSvc.exe accessing the sig*.tmp files, I originally didn’t think I had disabled cmdagent.exe. I thought disabling all the Avast shields might somehow have kept cmdagent.exe out of the picture. Based on some things I see today, I suspect cmdagent.exe was disabled or crippled at the time I captured that log snippet I shared.
- I re enabled/configured Avast and Comodo as I normally use them, captured a log of their sig*.tmp accesses, and sorted that log to look at the sequence. It appears that cmdagent.exe accesses each file after AvastSvc.exe does and thus I’m thinking Comodo is responding to AvastSvc.exe rather than independently doing something with those files. I’d have to roll up my sleeves to decipher precisely what they are doing though.
- After everything was back to normal config, I went in and just disabled Avast’s rootkit scan on startup. Then restarted. I watched for anything (primarily AvastSvc.exe or cmdagent.exe) accessing such sig*.tmp files and did not see anything during the first 20 minutes post restart. Which reinforces my thinking that Comodo simply responds to AvastSvc.exe creating those files, and also confirms what you guys had determined about this being the result of the Avast rootkit scan.
So I suspect I’m on the same page as others and I think one can ignore the Comodo references. Hopefully the Avast software guys will evaluate things and finish up. Thanks for the volunteer contributions. I feel better. There for a brief moment I wondered if some advanced malware had managed to hook its way into both Avast and Comodo.
Asyn
56
- Yes.

- You’re welcome…!
And thanks for pointing us to it…!! 
system
57
Praise to the Sysinternals guys, and also Microsoft for continuing to make such tools freely available in standalone form (no Live nonsense) after they acquired Sysinternals.
Sysinternals Suite
http://technet.microsoft.com/en-us/sysinternals/bb842062
Asyn
58
A short update.
Today only the 136KB (afd.sys) file was created. No 0KB files at all.
So, it seems somebody is working on it. 
system
59
I can confirm: only one single sig*.tmp file at each boot today.
DavidR
60
I reported it to Igor and he passed it to the GMER rootkit guy, so looks like he has been working on the anti-rootkit scan.