mailing list archives
Re: Tools for checking for presence of adware remotely
From: Harlan Carvey <keydet89 () yahoo com>
Date: Thu, 1 Jul 2004 03:43:00 -0700 (PDT)
It's not difficult to figure out how things work
Windows systems. Once you find that out, it's
simple. I will defer to Marcus Ranum's title of
"artificial ignorance" to describe how the Perl
scripts work...by identifying those things that
known to be 'good' entries and filtering those
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
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.
Full-Disclosure - We believe in it.