To add a bit more to this, Nachi tends to write itself in memory
(DLLHOST.EXE), so VirusScan 4.5.1 will not pick this up. Durring the
on-demand scan, it finds the two culprit files and deletes them.
VirusScan 7.0 has a memory scanner, so as long as the definition file is
current, it will catch Nachi before it writes to the drive.
However, as stated below, it does not beat patching the system or disabling
From: Robert Slade, Threat Response Manager
To: mjcarter () ihug co nz
Cc: security-basics () securityfocus com; focus-virus () securityfocus com
Sent: 11/27/2003 2:37 PM
Subject: Re: McAfee Anti Virus V4.5.1 SP1
We have had 3 or 4 machines come up infected with Nachi today but the
access scanner didn't pick it up. Carrying out a full system scan did
pick it up.
Not terribly surprising.
First of all, Nachi (and a great many others of its ilk) is a worm,
specifically by making an attack on a vulnerability in an application or
an operating system. In this case, it is, as you note, making RPC
(Turning off DCOM with something like dcomcnfg will prevent the attack
from succeeding, and shouldn't create any problems unless you are using
MS Exchange mail server.)
Nachi creates the files you note, but it does not necessarily read them.
Generally on-access scanners shortcut scanning (in order to improve
performance) and therefore the scanner will probably never scan the
The full scan, as you noted, does. (In addition, on-access or other
"automatic" scanners are always much less effective and accurate at
detection in comparision to the base manual versions.)
Anyway... I'm trying to figure out why McAfee on access scanner isn't
picking these files up but the full system scan is. There is no
difference in the setup we have between on access or full scan.
Hope this explains matters.