Video Screencast Help

Bloodhound detection in Defwatch file

Created: 09 Nov 2012 | 6 comments

Hi

I am seeing quite a lot of bloodhound detections on a few of my servers-the latest one is this:

Risk    Filename    Original Location    Status
Bloodhound.Exploit.139    DWHC61.tmp    c:\Documents and Settings\All Users\Application Data\Symantec\DefWatch.DWH\    Infected

I'm assuming this tmp file was written during the definition update process of the SEP11 client.

This is the latest bloodhound detection on a group of my servers, and the only common factor between them is they are all running Double Take - but I have no idea how that would cause an issue with the SEP11 update process.

Any suggestions as to what I can check to see what us going on?

Thanks

 

Comments 6 CommentsJump to latest comment

.Brian's picture

What version of 11.x?

 

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.

.Brian's picture

Seems to be similar to this:

DWH***.tmp files are detected in the user profile temp directory

https://www.symantec.com/business/support/index?pa...

Defwatch temp files are re-detected in temp folder

https://www.symantec.com/business/support/index?pa...

Which of course wants you to upgrade to the latest version...

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.

Mick2009's picture

Hi Grumbleweed,

"Thumbs up" to brian81's links.  Judging by the filenames and locations, you are safe.

The latest releases of SEP 11 really reduce the liklihood of these being generated.  Upgrade to SEP 11 RU7 MP2 or above.

 

 

With thanks and best regards,

Mick

grumbleweed's picture

Brian and Mick - Thanks for the quick responses.

I think you are absolutely right, that does seem to fit the situation. Unfortunately I am already on v11.0.7 MP2, and no immediate plans to upgrade.

So..if these detections are due to files already in Quarantine - does that suggest those files really are infected, or possibly corrupt?

As far as I can see what happens is:

The Double Take server tries to back up a remote file, which has (or should have) been scanned by the SEP11 client on the remote system.  However when the file is written to the Double Take server the file is quarantined by the local SEP11 client.  I have not enabled network scanning in Autoprotect so the file should not be scanned twice on the remote system.

Somewhat confused now...

Thanks

Chetan Savade's picture

Hi,

Please check this article

When new virus definitions are in place and the quarantine is being scanned, a DWH file is created and detected by Auto-Protect

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

DWH***.tmp files are detected in the user profile temp directory

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

These detections do not indicate a new outbreak of a threat.  The .tmp files are created by the Symantec Endpoint Protection (SEP) or Symantec AntiVirus (SAV) Quarantine scan. The scan is normally initiated by a virus definition update.

There are also several known methods to work around the issue:

  • The quarantine scan on virus definition update can be disabled in the  Symantec Endpoint Protection Manager (SEPM): edit Antivirus and Antispyware policy > Windows Settings > Quarantine > General, under "When New Virus Definitions Arrive" choose "Do nothing".
  • Items in quarantine can be deleted.
  • If the indexing service is enabled it could be triggering the issue when the dwh***.tmp files are indexed.
  • Investigate other applications that are scanning the temp file for changes.

This issue is seen with latest version of SEP i.e RU7 MP2

Check following article for more details.

https://www-secure.symantec.com/connect/forums/dwh...

I hope it helps.

 

Chetan Savade
Sr Technical Support Engineer, Endpoint Security
Enterprise Technical Support
CCNA | CCNP | MCSE | SCTS |

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

grumbleweed's picture

After some further ingvestigation, I think part of the issue is that the server storage is on SAN disk rather than local disk.  The server is running Doubletake, and I was careful to exclude the replicated data using the appropriate Windows drive letters eg L, O, M etc

However, the files that are being quarantined are identified as being at a location that does not use a drive letter eg

\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Replicated_Files\ etc

Presumably I need to add exclusions based on paths like the one above in order to prevent the replicated data from being scanned,and hence stop the bloodhound detections.

Is it a valid method if I add a folder path to the centralized exceptions policy that does not include a drive letter, ie such as the path shown above?

Thanks