Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Endpoint Protection Detection of .tmp Files within Symantec Endpoint Protection > xfer Directory as Infected by JS.Alescurf

Created: 14 Jun 2013 | 8 comments

I have a Dell Studio running Windows 7 64-bit with an older version of Symantect Endpoint Protection (ver. 11.0.5002.333).

Starting about ten days ago, I found as a consequence of a manual scan a reported infection of a number of files which were reported by Symantec Endpoint Protection as being infected by the JS.Alescurf malicious code.  The files had names generally of a naming convention "51xxxxxx.tmp" and were located within the directory:

ProgramData > Symantec > Symantec Endpoint Protection > xfer

I usually operate the computer from a lower privileged account.  Running the scan in the regular privileged account identified the purported infection, but left the files unchanged.

So I logged onto a privileged account and ran the scan as an Administrator.  Endpoint Protection then identified and Quarantined about fifty files that it represented were infected by JS.Alescurf malicious code, all in the xfer directory.  (This was last week.)

I have since had several recurrences of the reported infection when I either scan the aforesaid directory OR open that directory and seek to check the properties of one or more of these files.

The appearance of the files in a xfer directory seemed to present either the possibility that Endpoint Protection was detecting its own Antivirus definition files OR that somehow infected files were being presented by an unknown vector within a directory that might somehow infect Endpoint Protection itself, which is particularly concerning.

Last night, I noticed that there was a new accumulation of upwards of 1,000 .tmp files in the xfer directory.  I manually ran LiveUpdate from the UNPRIVILEGED account about 3 AM and thereafter noticed that about 270 new files appeared within the xfer directory, suggesting that this was a transfer area for new definitions, etc.  The most recent files have names of the form "51babxxx.tmp". 

The xfer file now shows 1,607 items, all with dates within the past week.  It was completely CLEAR last week after I ran a complete scan of ProgramData.

I ran a new session of LiveUpdate this morning from an Administrator account, which seemed to download some new updates, but no new files seem to appear within xfer.  I am in the process of running a new scan now. 

I am wondering if anyone has any insight as to whether the xfer directory is a typical vector for exploit by JS.Alescurf or whether there is reason to expect or believe that Endpoint Protection is giving a false positive in respect of files properly transferred to the xfer directory, possibly through the LiveUpdate process.  Also, is there a reason files accumulate within this directory?  What is the regular process by which files in xfer are deleted if these, in fact, are associated with installation of new AntiVirus Definitions.

Any other suggestions or recommendations for troubleshooting or remediation of a JS.Alescurf infection are appreciated.  Endpoint Protection is reporting the successful Quarantine of these files when I run the scan in Administrator mode.  Is there anything else I should be doing in respect of a possible JS.Alescurf infection?   

Operating Systems:

Comments 8 CommentsJump to latest comment

Rafeeq's picture

This seems to be know bug in your version, check the below article.
Large numbers of .tmp files are being created in the xfer_tmp or 7.5\xfer folder and are being detected as threats.

 

http://www.symantec.com/business/support/index?page=content&id=TECH93590

Mithun Sanghavi's picture

Hello,

This was a known issue in the older version of SEP 11.0.5002 and has been resolved in the latest version of SEP 11.0.7300

http://www.symantec.com/docs/TECH103087

I would request you to please migrate to the Latest version of SEP 11.0.7300 OR SEP 12.1 RU3.

About Maintaining Consistency of Software Versions throughout a SEP 11 Organization

http://www.symantec.com/business/support/index?page=content&id=TECH131660

Large numbers of .tmp files are being created in the xfer_tmp or 7.5\xfer folder and are being detected as threats.

http://www.symantec.com/docs/TECH93590

tmp file (DWH*****.tmp) detected as  Trojan.Gen or Trojan.Gen.2 by Corp products 

http://www.symantec.com/business/support/index?page=content&id=TECH102953

Hope that helps!!

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

.Brian's picture

This is a known issue (and causes a false positive) for this version. I would strongly suggest getting to SEP 11 RU7 MP3 or SEP 12.1 RU3.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

waroper's picture

Thanks to each of you who provided feedback!

I finished running the scan mentioned in my original post and it found and Quarantined 1,607 files within the xfer directory.  The xfer directory is now EMPTY.

What I perceive from the responses is that the presence of these files in the xfer directory is due to some known BUG or DEFECT and that the discovery of these files yielding a false positive and the related Quarantine of these files is NOT impairing the viability of my defense against malicious code.  (It clearly IS a performance and User Friendliness issue!)

*

I remain a little perplexed because I installed EP on this machine at purchase three years ago and I first observed this problem last week.  Admittedly, I do NOT do a complete scan of the machine all that frequently, but I run the Quick scan at startup and scans of selected directories at least every few days.  I separately download and run the MS Malicious Software Removal Tool monthly.

Thus, it is a little baffling that the problem seemed to suddenly emerge only a week ago!  Maybe I missed something before, but usually I am fairly fastidious about security related issues.

*

This brings me to a second point.  The existence and ease of use of LiveUpdate seems to have lulled me into a false sense of complacency about the currency of my installed version.  I certainly understand that Symantec isn't going to push me a completely new version (e.g. EP 12) without purchasing an upgrade, licensing, etc., but I would have rather EXPECTED that LiveUpdate would bring me current to the latest release of EP 11.

To the extent that there are some compelling cross-platform enterprise compatibility and consistency reasons NOT to push the latest release to EVERYONE through LiveUpdate, it seems to me that the USER FRIENDLY approach would be to at least furnish a CONSPICUOUS User Notice informing the User that they do NOT have the latest version (and giving a valid link showing conveniently HOW TO GET IT).

For example, on the main EP Status Page, I am informed of the Date and Release Number of each of the various Definitions files.  But the Software Version Information is ONLY available if I Press the Help Button and then select "About".  Even then, I am advised of my CURRENT VERSION, but am NOT presented with any COMPARATIVE INFORMATION that would show that my Current Version of the software is NOT the latest release.

This seems to me to be BOTH a User Support as well as a Marketing issue!  To the extent that my version (Ver. 11.0.5002.333) is as effective at malicious code and network defense as the later version, perhaps it matters little.  But even if the ONLY reason for upgrading is to resolve known software performance issues, it would seem to me that gently coaxing customers to upgrade would improve customer satisfaction and experience, while also reducing the support burden.  When presented with a manual upgrade, some customers might also then also elect to do the full Version Upgrade bring you additional $$.

Thanks again to ALL!

waroper's picture

As you suggested, I have upgraded my EndPoint Protection version to 12.1.2015.2015.  Hopefully, this will resolve the problem going forward.

waroper's picture

Upon upgrade to Endpoint Protection 12.1, I ran a complete scan of my hard drive.  In an abundance of caution, I want to add to the prior discussion that this scan detected, reported and Quarantined a single file named "dwhf3d3.tmp" within the directory:

c:\programdata\symantec\defwatch.dwh

This file is again reported to be infected with the JS.Alescurf malicious code.

This still seems at least somewhat consistent with the theory that the reports I have been receiving are false positives associated with Endpoint Protection discovering and identifying its own data files as being infected.

It is still discomforting if Endpoint Protection cannot distinguish its own helper files from infected files.

Moreover, how am I to distinguish that the file that that has been Quarantined is not important to the successful operation of Endpoint Protection in detecting other real threats?

Is this file a Quarantine file or log file that was in place as a legacy of the prior false positives?  Or is this file actually important??

Rafeeq's picture

Might be it got carried from the previous version. can we delete  all the .tmp file and re-run a full scan again.

waroper's picture

See my related thread:

"Out of the Frying Pan and Into the Fire -- Accumulation of .tmp Files in the DefWatch.DWH Directory"
https://www-secure.symantec.com/connect/forums/out-frying-pan-and-fire-accumulation-tmp-files-defwatchdwh-directory

To summarize, I suggest that Symantec explore the possibility that either an unexpected shutdown of the machine OR a user running multiple sessions on a single machine by swicthing between Users might explain the accumulation of .tmp files in some EP directories.

While Symantec continues to explore remediation and patching, I would encourage users to take care when .tmp files appear after an unexpected shutdown of the computer AND to avoid using the feature that allows switching between users rather than logging off and back on under the alternative user account.  If switching, take particular care when either running a LiveUpdate session OR running a scan while both sessions are running.  When simultaneous EP instances are running in two or more sessions, each may fail to gracefully perceive the .tmp files created by the other instance!

Critique of these suggestions/theories is solicited, encouraged and appreciated!