Video Screencast Help

Question about Tracking Cookie Message

Created: 29 Oct 2009 • Updated: 15 Jun 2010 | 9 comments
This issue has been solved. See solution.

I have a user that runs a full system scan once a week..  Every time he gets a tracking cookie notification.  The filename is always "Unavailable", the risk type is "Trackware" and original location is always "Unavailable".  It says that the action, status, and current location is "Deleted".  And the Action Description is "The file was deleted successfully".

However, the next time he runs the scan, the same exact notification shows up.

1.  Is the "Tracking Cookie" actually removed?

2.  Why does it show up with every scan?

3.  What should I do about this?

Any help and/or ideas are greatly appreciated.


Comments 9 CommentsJump to latest comment

P_K_'s picture

  Tracking Cookies are used by Legitmate web sites to track how many times you access their sites.  Web sites that use this type of cookie usually require a log in to access the site.  

 Best to verify if this is being caused by the user is to perform a full scan, remove the threat and then reboot the machine. Once the machine is rebooted, then perform another full scan. If the full scan does not find the Tracking Cookie at that time, this means it is being placed there during the day while the user is working on the computer.

Run  the Full sacn in Safe Mode with System Restore turned Off

MCT MCSE-2012 Symantec Technical Specialist (SCTS)

sandeep_sali's picture

Once you update the virus definitions follow these steps to clean the tracking cookie

A.    Stop the viral process, or boot the computer to a state where the process is not loading:
i.    End the task - some threats may prevent this.
ii.    Start Windows in Safe Mode or Safe Mode Command Prompt only
iii.    Newer versions of Symantec AntiVirus (version 10) and Symantec Endpoint Protection may be able to stop the process as part of a full system scan.

B.    Remove the viral files:
i.    Full system scan – Recommended
ii.    Manually remove the files by finding and deleting them
iii.    Check if there is a removal tool available for the particular threat variant.

C.    Reverse the changes to system settings. It is important to make changes to the registry before rebooting the computer. Many viruses change boot setting so the user may be unable to log in once the virus is removed, if the registry changes are not undone.
i.    Undo Registry Changes
ii.    Undo changes to the following files – if necessary
1.    hosts
2.    win.ini
3.    sfc.dll – may need to be replaced with new copy
4.    Anti-virus and Firewall programs – may need to be reinstalled.

D.    Reboot the computer into normal mode, before connecting it back to the network. This is to determine that no additional viruses are detected and the cleaning was successful.

E.   If a rootkit or backdoor is detected it maybe necessary to re-image the computer to ensure security of the network.
Determine Infection Vector and Prevent Recurrence

    This last step is often overlooked but may be considered the most important. Most network wide infections use two methods to propagate:
    A.    Known vulnerabilities: These are generally OS vulnerabilities, but may also include other software vulnerabilities that allow code to be remotely executed on the computer.
    B.    Open Shares: Because viruses often load at start up they may be running with the current user's credentials. This means that any share that a user can reach without providing a user name and password is vulnerable to this type of attack. This includes the Admin$ and IPC$ shares.

    - To ensure security of the network going forward the Administrator password may need to be changed with a new “strong” password.
    - Only after computers are patched and cleaned should they be reintroduced to the production network.

Thanks & Regards

Sandeep C Sali

ShadowsPapa's picture

Tracking cookies are seen on a regular basis here. Placed by any number of sites. Even seen on computers that are not nor have ev ever been infected, inclding my own!
At times, they are nothing to be concerned about - they keep track of who you are and where you have been, esp for sites that require login, or forums, etc.
OR they can be used for evil, although a cookie is a TEXT file that can't DO anything but contain INFORMATION. They are not executable, etc.
I find they are most often found while doing a FULL MANUAL scan after SEP was triggered by something attempting to place a file to plant a worn or the phony AV apps, but have seen them on my OWN computers, which have never been infected, ever.
So it can be either - either it's a legit cookie and other than privacy, nothing to worry about, or it's there because something else TRIED to get there.

RonA123's picture

It seems that on several computers here, the report will show only 1 tracking cookie.  I know that numerous sites launch tracking cookies so why does it only report 1 cookie?  I know other AV products will report finding several cookies.  Is this just a Symantec way of doing it?

MitchNussbaum's picture

Are you sure it's showing only one cookie?  I just installed SEP on my computer, and I've noticed that every scan returns a single "Tracking Cookie" notification, but the notification covers a long list of individual cookies.  When I click on the entry to see details, I see multiple cookies, each with a description.

MitchNussbaum's picture

This is an interesting discussion, but it raises some questions:

  1. Is there a way to tell if the cookie that the scan finds is legitimate or malicious?
  2. If it is legitmate, what are the effects of deleting the cookie?
  3. If we don't want the cookie to be deleted, which policy do we modify to change SEP's action?

I'm asking this question because an on-demand scan on one of our computers found a tracking cookie and deleted it.  But the applicable policy for on-demand scans shows the first action as "quarantine," with "log only" specified if the first action fails.  So the scan shouldn't delete the cookie... or should it?

Grant_Hall's picture

Hi Mitch,

Just wanted to let you know that you posted on a pretty old subject (18 weeks old). Next time you should make a new post and provide a link back to this one since it is relavent. I only say this because most people will ignore old threads.

Now your issue:
Tracking cookies are, for the most part, completely harmless. As a result they will no be deleted or detected by auto-protect, however during a full scan the cookies are usually found and then deleted. In general this doesn't do any harm to the computer or user. Cookies are usually used by websites to track information about you. Usually the biggest reason people don't want cookies deleted is because that is how websites store their automatic log-in and password information when you click on "remember this password...". If you would like to hear more information on the subject or if you still have more questions please create a new thread.


Please don't forget to mark your thread solved with whatever answer helped you : )

MarvinK's picture

The frustrating part about tracking cookies is it is almost like crying wolf.  If you have your virus scan set to run manually every week, and you visit harmless sites like, you are going to get flag with a finding.  A lot of users see this as basically the same as "I have a virus." can explain to them, don't worry its just a tracking cookie.  When you do that, you've desensitized them to the scanning window.  If they've gotten the tracking cookie message for 12 weeks, and then they end up with a 0-day virus that didn't get caught until the scheduled scan--they're not going to look close enough to worry.  "oh, just another tracking cookie" is what they will think as they close the window.

Symantec needs to come up with a cleaner way to handle tracking cookies--and not handle it nearly the identical same way as bot, worm or trojan.  It is really ridiculous.

MitchNussbaum's picture

MarvinK --

I started a new thread on this question (people told me that  this thread was stale, and nobody would look at it), and I posted what I eventually learned in that thread. 

Basically, I figured out that the cookies were being flagged by TruScan, not Auto-Protect, and that I could suppress the notification popup by configuring Centralized Exceptions.  This is still not as elegant a solution as I'd like, but we aren't seeing popup windows on client computers.  The thread is at: