Endpoint Protection

on my own laptop that is only used for email (runs against exchange server running filtering, premium antispam etc) word processing and internet use to known sites only - symantec, microsoft etc, the following auto protect just triggered:

threat=packed.generic.230
file=tmp.edb
location=c:\windows\softwaredistribution\datastore\logs\

this on a vista system running against WSUS server fully patch.

This is one computer that there is just NO WAY it could be infected or have accessed anything, or been exposed to anything.

Symantec auto protect deleted file, so I can't submit it.

What do you think?

Virus can come to your pc in lot of ways .Through copying a file which is infected with virus ,through network etc... A PC in fully patched and updated with latest update doesn't means virus should not come to that PC. It mean the possibility of compensating to that virus attack is less.. In your case autoprotect is able to detect and remove means your PC is protected. It is like a guard in the entrance .He cannot block the attacker to come up to the entrance ,but he can block the attacker in the entrance... 

Can you please paste the logs where it depicts that Symantec auto protect has deleted the file, may be we can get some information from it

Everything available in the log file  I referenced in my 1st post.

After researching this a bit more I've noted that packed.generic.xxx and tmp.edb gets tagged a lot falsely.

Interestingly I went back to that folder and inspected it and windows had inserted another tmp.edb file.  I manually scanned the folder and then the whole system and it came clean.

My concern here is that there is jsut no way that this PC could have been infected.  This laptop and network is extremely closed.  I'm the only one that uses it (laptop and network) and I know that there is no way that something dropped into this folder yesterday afternoon at 5PM that was a virus.  I hadn't even used the computer for about two hours prior to that.

Had I been online and had autoprotect picked up something in temp ie files I could see that, but not a legit file in a windows update folder while I was not even using the computer and had not been for two hours.

My concern here is the detection heuristic that thought this legit file was a piece of malware.

Generic packaging detections can be confusing, but often aren't actually false positives.

Packagers are ways to combine files into an easy to distribute single file.  A zip file is an example of what a packager does...combines a bunch of files and compresses it into a single file for distribution.  Zip, RAR, ACE, GZ, TAR...these are all examples of what a packager does.

There are *tons* of packagers out there for people to use, each with their own pluses and minuses.  Generally speaking, however, there are only a small handful of packagers that are used by most of the software vendors, both open and closed source.  This leaves a ton of unused packagers for threat writers to choose from.

AutoProtect doesn't scan within compressed files.  A packaged file is a compressed file...so, we don't scan within it.  We do this to help limit the amount of resources AutoProtect uses to scan with...and it's my understanding that most of our competitors do this as well.  The thought behind not scanning within compressed files is that if a compressed file containing a threat is on the box, it's okay, because as soon as something tries expanding that threat file from within the compressed file, AutoProtect will scan the "new" file, see it as viral and flag it.

AutoProtect *does* scan the compressed file itself, just not the contents.  Think of mailing a package...the person you hand the package to at the post office gives it a cursory glance to make sure everything looks okay, but they don't open it to make sure it doesn't contain something it shouldn't.  Later down the line it gets X-Ray'ed for just such a detection.

(Not a perfect analogy, but hopefully it helps to clarify)

So, back to packagers.  We get a lot of submissions, and we look at a lot of files, both infected and not.  We recognized, early on, that 99.9% of the files we saw packaged with the "other" packagers were viral.  Once in a blue moon we'd find one that was completely legitimate, but most of the time they were viral.  As we looked closer and closer at the packagers, we found that it seemed like it was mostly the people that use these obscure packagers were people packaging threats to try to get past our scanners. 

There was a business decision made at some level to flag these "other" packagers as viral.  All in all, we've gotten very few false positives as a result, and we've caught all sorts of threats trying to get into systems.

As always, if you feel the file that was detected is actually clean, submit it via our online submission process, then contact support so that we can get a developer to double check the file.  If it's found to be clean, your submission can help us refine the definition for that packager further.

Also, please understand that we are not faultless.  We've seen packager detections on some of our in-house support applications that we hand out to literally hundreds of customers every day.  :p

That explains why weekly scans catch things that have been on the computer for days without detection.
Makes sense - takes a lot of power to expand a packed file and check the contents.
However, I still can't figure out why I see things flagged in the middle of the night that were on a computer for hours or even days, then suddenly at 3am, with no one in the building, a computer finds an infected file?
No, there were no scheduled scans.................. not at that time.

I think I used to know that the AP scanning didn't check compressed files, but had forgotten. Good refresher.

I also suspect that once in a blue moon, a file or package of files is compressed in such a way that the bits just happen to line up to match a known threat or look very similar to. Sort of a random event because the package fingerprint would vary if even one letter in a text file in that package was different, so it might not match next time.
Just musing aloud............

>>As always, if you feel the file that was detected is actually clean, submit it via our online submission process, then contact support so that we can get a developer to double check the file.  If it's found to be clean, your submission can help us refine the definition for that packager further.<<

Ideally, set SEP to QUARANTINE instead of delete in cases of suspected false positives......... I seldom use delete, but rely more on quarantine as the effect is the same - the file is gone for all practical purposes, HOWEVER, it can be submitted, or restored. But it can't be executed or cause any harm.

Thanks all for the details and in kind responses.

This was AP.  While I can't look at the file and determine for certain, given the circumstances I'd have to say (and would have to hope) that this was false.

tmp.edb was the file.  As this is a legit file used by microsoft (i'm trying to get more information from them as to how it gets created) and given this PC and network I'd have to say this was a false.

I'd be curious though Chris how may actual positives are caught in this folder?  Is it possible that Symantec has ramped up the heuristic recently and thus the false positive?

If this was indeed malicious, what process would have placed it  there?  As I mentioned, I was not even using this computer for approx 2+ hours (even more perhaps) so there was nothing the laptop would have been doing to "bring in" the file.   I guess what I'm getting at (along with SPapa) is while I'm not a genious, I do know that malware just doesn't happen magically.  Something has to be done to let it in. 

Either that or a false positive.

P.S.

Just curious what app would open and run .edb?

Sadly, there's not much more information that I can give out about it.  We are aware of some false positives over the last few days, and while I can't definatively say this was a FP (since we don't have the file to examine), it sounds like it.  I do agree, however, that this was probably a false positive.

I'm not privy to how many false positive reports we're getting.  I *do* know we're getting some, but on exactly what I don't know.  We treat false positives very seriously, so whenever we have even ONE we jump on it as quickly as possible.  I do know that we've modified some of the detections, and I think this is what's generating the false positives.  Again, don't quote me as I'm not privy to the exact details.

As to how it got on the machine, assuming it's viral, I couldn't say.  Generally speaking, if this file is truly infected, it probably was placed on the machine before definitions were in place to detect it.  Of course, at this point that's just wild speculation.

I'm not sure what specifically uses .edb files, but a quick Google search says it has to do with Exchange databases.