From: keydet89 at yahoo.com (Harlan Carvey)
Subject: Tools for checking for presence of adware remotely

> > It's not difficult to figure out how things work
> on
> > Windows systems.  Once you find that out, it's
> pretty
> > simple.  I will defer to Marcus Ranum's title of
> > "artificial ignorance" to describe how the Perl
> > scripts work...by identifying those things that
> are
> > known to be 'good' entries and filtering those
> out,
> > you're left with the suspicious stuff.
> 
> but then the script that you produce will be made
> for you own site and they cannot be generalized
> beyond a point and how will you take care of the
> variations of the various computers like the servers
> / secretaries computers / high power workstations 
> which will all have different startup entries and
> other help objects. at the most the script will
> create a report that you can diff and see manually
> and decide what computers to visit. 

Wow, dude, you're really going out of your way to make
this difficult, aren't you?  A known good entry is a
known good entry, regardless of the system that it's
on.  If the secretary's machine has an entry for a
mouse driver that gets loaed via the 'Run' key, then
so be it...if that entry doesn't appear in the 'Run'
key on a server, so what?  

Having been in organizations that used machines from
Dell and Compaq, having a 'known good' list was a good
way to keep things in check, and to see only new
entries.  Submit a Scheduled Task to run the script at
a certain time every month, and I had my reports.

> this in my
> humble opinion is not good for a big enterprise,
> there you require something that when run
> automatically disinfects and cures all the other
> malware when it detects it, can be updated from one
> central location and be run from a login script -
> this would a solution that is required. 

Sure, I agree that something like that would be
useful.  However, where I've been involved, security
and system administration staffs have been underfunded
for such things, or have had to wait to use money that
was earmarked for a different fiscal quarter.  Not
having the funds available when spyware becomes a
major issue leaves those of us down where the rubber
meets the road working to meet the CxO's demand that
we fix the problem...now.  

So sure, in a more ideal situation, having such tools
would be great.  Fantastic.  However, not having such
tools, one needs to do what they can to be proactive,
and if that means using some home-brew method of
determining which machine needs to be 'fixed', so be
it.

I'll give you an example...using this script, I
located some interesting entries on a machine in
another building.  By feeding that system IP into
another script, I was able to find out the machine
name, who was currently logged on, and the names of
the users who'd logged on recently (ie, make an admin
connection, and get last access times on the
directories listed in "C:\Documents and Settings\"). 
Given this information, we knew exactly where the
system was located, and who was using it.  I was able
to get someone from the IT Dept to 'visit' the machine
and run the necessary tools to clean it up...rather
than having them go to every machine in the facility,
and running the tools on every one...just in case. 
Using the names, I was able to talk to the manager,
away from HR, and have her talk to the employees about
their surfing habits.  That way, we've started a
process for addressing the situation...one that can
lead to the necessary measures for rectifying the
situation if things do not approve.  And b/c I have
this nice little script, I can easily save the info I
collect, forward it to the sysadmins and HR, etc.

There's more than one way to approach these
situations.  Mine happened to be effective for me, and
may be effective for others, even in larger
organzations.  In fact, one can have all sorts of
actions take place...collect information and shut the
system down, send the user a pop-up...whatever.

Powered by blists - more mailing lists