If you know the file, you can submit the file to the followin link

Web URL: http://www.symantec.com/business/security_response...

Also try to run the any of the following tools

Power Eraser Overview
Web URL: https://www-secure.symantec.com/connect/videos/power-eraser-overview

Symantec Endpoint Recovery Tool (SERT)
Web URL: https://www-secure.symantec.com/connect/videos/sym...

Symantec detects the file as a virus.  It is already in the pattern files.   My question is why would/is the real time not blocking access to it.

The file path is actually given as

File path: c:\Documents and Settings\nimsr\Application Data\Sun\Java\Deployment\cache\6.0\43\e9853ab-3d29fb7b>>seopack.class

So is 'e9853ab-3d29fb7b' a file, a folder, or an archive?

For the example given, how was the detected made (Auto-Protect, manual scan, scheduled scan)?

Here's some info on what the "Left alone" action can mean.

Title: 'Best Practices for responding to "Left Alone" in the virus or threat history log'
http://service1.symantec.com/SUPPORT/ent-security....

sandra

I am having the same issue on my computers.  I get 10 of these a night now, and have been all week.

The files are being found by the Scheduled Scan, not the real time scanner, which is what the Original Poster was asking about.  How come these are not found right away?

The file "'e9853ab-3d29fb7b" is actually an idx file, which I think is some type of Java applet cache.

While we are glad that Symantec is finding and dealing with these files (in my case they are Quarantined), it would be nice to know why they sit on the computer till the scheduled scan.

Thanks for the help.  Attached is a screen shot of my SEPM notifications I have setup.

It is possible that the files existed prior to a detection being added to the definition set, so Auto-Protect wouldn't have seen it as it was being written, but a scan done after the definitions were updated would have caught it 'sitting' on the drive.  Hope that makes sense.

sandra

e9853ab-3d29fb7b is the file name, not the folder name.   It's like a JAR file, aka a ZIP file.   Inside of it is a java class which is a virus.

From what I am gathering, I am not blocked access to it because I have leave alone set and I am accessing the file across a network using the admin share to the C$ drive.   And the document above says that combination is not inspected for virsus.   Especially since I have scan network drives enabled, but to trust PCs running SEP.

I'm guessing the realtime is not picking it up because it knows it's an archive, and I have scanning of archives on the realtime scanner turned off, as per the recommendations found on symantec.com.

So am I safe in assuming that when java.exe unzips the jar into memory and tries to load it, that is when Symantec saves me from these Java viruses?   Using Zenworks I have Java 6 build 21 on all my PCs and I have removed all previous Java versions.   So I'm pretty safe, compared to others.  I'd just like clarification so I know what's going on.    eSet nod32, which is what I am coming from, blocked access to these files.   I could not open them up in notepad remotely.

I'm guessing the realtime is not picking it up because it knows it's an archive, and I have scanning of archives on the realtime scanner turned off, as per the recommendations found on symantec.com.

So am I safe in assuming that when java.exe unzips the jar into memory and tries to load it, that is when Symantec saves me from these Java viruses?

That's exactly what happens if an archive file containing suspect content is uncompressed--Auto-Protect would intercept.

sandra

If it is being treated as an archive file then it sounds like SEP is working by design:
 
-          If you right click and choose to scan an archive the infected file will be removed
-          If the file is scanned as part of a scheduled scan the infected file will be removed
-          If the infected file is extracted it will be detected by the real time protection as it is copied to the hard drive
 
If you are just viewing the archive the infected file is not removed or scanned whilst it is inside the archive container.