Home page logo

basics logo Security Basics mailing list archives

Re: McAfee Anti Virus V4.5.1 SP1
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Fri, 28 Nov 2003 10:37:30 +1300

"Mike" <mjcarter () ihug co nz> wrote:

I have a question and  I can't get an answer from the vendor, their support
is not free for this question.

It should be.

Any antivirus tech-support folk who cannot answer this off the top of 
their head should not be employed in AV tech-support...

We have had 3 or 4 machines come up infected with Nachi today ...

Were they "actively infected" or simply had Nachi .EXEs on them?

... but the on
access scanner didn't pick it up. Carrying out a full system scan did pick
it up.

I'll hazard that this is because your on-access scanner is only 
intercepting file-open style accesses, whereas the on-demand scanner 
was set to look at all files.  For the on-access scanner to "see" the 
Nachi .EXEs they would have had to be "opened", either by some process 
trying to read them or to execute them.  Alternately, if the on-access 
scanner can be set to scan on modify and/or on file-close operations, 
it should have detected the files after the remote process infecting 
those machines closed the files.

I found the infected machines by going through Black Ice logs on my local
machine that showed RPC scans and then connecting to the remote machine's
C:\winnt\system32\wins directory and scanning the dllhost.exe and
svchost.exe files.

So the machines actually became actively infected?

Could the copies of McAfee on the infected machines detect the virus at 
all?  For the machines to be actively infected their on-access scanner 
would have had to fail entirely which most likely would be because it 
was disabled, had not updated its .DEF files in ages or something had 
gone badly wrong during an update.

I don't have access to any kind of network scanner, our security policy
doesn't allow me to use them (I'm just a field ops support person).

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.

Hmmmmm -- that suggests that the machines should not have been able to 
become actively infected, but that they could become hosts of Nachi's 
files as an on-access scanner cannot prevent the files being created 
(but should prevent access to them once they are created and closed
-- that is, after they are written and before they can be executed).

Everything is up to date, including the MS patch levels, but that's another

Excuse me, but that claim must be false.

_If_ the Windows patches are up to date then the machine cannot be 
vulnerable to Nachi infection.  This suggests that you are using a far 
from accurate method of determining patch currency.

Is there another variant that might be stopping the on access scanner ???

Any ideas?

There is one final possibility, yes.  IIRC, by default McAfee has its 
heuristics enabled for system (on-demand) scans but not for on-access 
scans.  A Nachi variant that is sufficiently different from the 
original that the McAfee's Nachi definition won't detect it "straight 
up" may be detected by heuristics, but that should be evident in the 
actual detection report.  Precisely how I cannot say, but the on-demand 
scanner detecting a new, possible Nachi variant with its heuristics 
should produce a different literal report than when it detects an 
existing, known Nachi sample.  If you have the latter to compare with 
you should be able to tell for yourself...

_Finally_, these machines had to have become infected from somewhere.  
Either you have another infected machine somewhere on your network or a 
hole in your perimeter defences allowing bad stuff from the outside 
into where it ought not be...

Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]