RE: Strange servicepack.exe file (not service.exe) found.

[Lucretia <lucretias () shaw ca>]

If I may interject...

> -----Original Message-----
> From: Harlan Carvey [mailto:keydet89 () yahoo com]
> Sent: Wednesday, December 17, 2003 5:20 PM
> To: incidents () securityfocus com
> Cc: James C Slora Jr
> Subject: RE: Strange servicepack.exe file (not service.exe) found.
>
>
> James,
>
> > To be fair to the original poster, in hindsight
> > there was reasonable
> > association from other posts between the suspect
> > file and some complex
> > adware that downloads arbitrary additional
> > components and takes aggressive
> > actions like installing porno dialers similar to
> > what was found.
>
> You're mixing terminology.  In my experience, and I do
> have quite a bit of experience w/ adware and spyware,
> these things are annoying, yes, but hardly aggressive.
>  And complex is being...well...generous.

Yes, very few spyware has what I would deem black-hat characteristics.
However the truth of most spyware is that they are profiting from these
actions.  Gator has become one of the top internet web sites (according to
Alexa) as a consequence of their business model.  If more companies continue
in this fashion we will be bombarded with spyware that is uncontrollable.
Then someone will get nasty and all hell will break loose.

> I saw the response from Symantec on the item.  I also
> downloaded the file, and scanned it with the most
> recent defs for NAV...and got nothing.

Yes, however most NIDS detect this, in a varying degree of notification, and
I have noticed a couple different responses to this trigger event.

> > Rebuilding
> > might take less than an hour, while investigation
> > and cleanup might take a little more.
>
> The short term fix may be preferable...but investing a
> little bit of time in determining the initial
> "infection" vector might save a good deal of time in
> "cleaning up" other systems.

Barring your other arguments below...I agree, time is the main concern.
Getting machines back in operation is usually more important that doing any
forensics on the box, or really any auditing.

> > Recovery takes less skill and often less time than
> > forensics. That makes it
> > a positive thing provided one investigated enough to
> > know that recovery
> > eliminates any damage that might have occurred.
>
> Hhhmmm...again, perhaps in the short term - but not in
> the long run.

This is a good, albiet without substance, argument.

> > The downside as you say is one will never know. The
> > "infection" vector might
> > not be determined until it happens again. And it
> > would sure be nice to know
> > if the afflicted (if not infected) machine was
> > trying to do anything to the
> > rest of the network or if it was communicating
> > outside the LAN.
>
> And to be quite honest, it doesn't really take a great
> deal of time or skill to do these things.  It simply
> takes a bit of time invested in learning to do it.

I think you've hit the nail on the head.  Without an educated admin its
unlikely much will be done to prevent it from reoccuring (assuming it will
reoccur).

> > It is important to know what the machine did while
> > it was in a suspect
> > state, if possible. The rebuild doesn't help enough
> > if, for example, network
> > passwords were compromised.
>
> Very true.

This is a big point, and recommended activity, but look at virtual hosting
providers.  They will seldom disclose a issue to all parties potentially
involved simply due to the support backwash it would cause.  So they repair,
patch and put back into service with most customers not even aware there was
a problem.

> > Plus it would really be silly if machine gets
> > rebuilt when a reboot might
> > have sufficed.
>
> Yep.  However, I believe that the argument amongst
> Windows admins will continue to favor rebuilding will
> continue for the time being...however unfortunate that
> may be.

Funny you say this, I have encounted two occasions where I got a backup of a
system, they rebuilt it, and I found nothing wrong other than the stack had
completely been trashed.  Reboot the test system and it went back to work.
So it does happen.  In this case we found that Gelil (?) was infecting the
machine, but it was certainly cleanable.

Seasons greetings,

James Friesen
CIO
Lucretia Enterprises
http://www.lucretia.ca





---------------------------------------------------------------------------
----------------------------------------------------------------------------