RE: [Full-Disclosure] Rootkit For Spyware? Hide your adware from all Adware removers and Anti-viruses

From: Harlan Carvey (
Date: 09/23/04

  • Next message: Todd Towles: "RE: [Full-Disclosure] MS04-028 Shell Exploit[Scanned]"
    Date: Thu, 23 Sep 2004 08:41:36 -0700 (PDT)

    > The thing that has me worried about this (at least
    > enough to justify the
    > posts) is that this seems to be an avenue for growth
    > in kits.

    That's exactly what it is.

    On a slightly tangential note, while many people I
    know of in the security community bash Microsoft, I've
    more often been thankful that they've created entire
    economies. With the variety of MS products, there is
    an entire economy for intergrators...and for those
    that don't do quite as good a job as could be done,
    "sweepers" (security folks, other integrators, etc) to
    come in and clean up.

    My point is that when you combine (a) the perceived
    glut of things that need to be done when managing
    Windows systems, and (b) the simple fact that most of
    them aren't done, you've got great opportunities for
    additional economies. It wasn't so long ago that
    three folks were arrested for renting out botnets of
    upwards to 45,000 systems. In the security arms race,
    the use of rootkits significantly ups the ante,
    particularly when dealing w/ home users and even

    > One of the things that has been protecting (perhaps
    > that is too optimistic
    > of a word here) people from rootkits is that most of
    > them don't work very
    > well or if so very pervasively. (admittedly there
    > are exceptions to this)
    > Admin's may never find the actual kits but the kits
    > (or their operators)
    > cause enough problems that he admin rebuilds the box
    > to get rid of the
    > annoying unexplainable problems (OK only in a shop
    > that is well kept, this
    > might not pertain in many IT departments)
    > If there is a new source of revenue I expect the
    > quality and therefore the
    > danger from kits will greatly increase.

    I'd agree with that.
    > You are probably right in what you were saying about
    > the need to get the word out.

    Not just the and techniques for
    preventing and detecting infections from this type of

    > In addition to setting proper user rights (something
    > that can be exceedingly
    > irritating to do in a Windows environment although I
    > am sure they are
    > working on it [I don't want to get into a religious
    > war here])

    I can see how the political/corporate culture can be
    an impediment to such things...though technically,
    it's a pretty trivial task.

    > and
    > tightening system account settings admins need to
    > start looking at tools
    > like Tripwire or other MD5 based monitoring
    > mechanisms. There are a number
    > out there and they don't all cost a fortune.

    True. In addition, there are great many freely
    available mechanisms that can be employed, with the
    only real "cost" being the time it takes for the admin
    to learn something new.

    > For those who are hazy we are not talking about
    > typical BO or NC type stuff
    > here (as useful as those tools might be to hackers
    > [and geeky/slightly
    > independent admins]) This is stuff that either
    > replaces Kernel components or
    > for some of the more advanced stuff sits between the
    > kernel and the hardware/bios.

    More specific to the Windows environment, what we're
    talking about is API hooking, and then more advanced
    stuff such as DKOM, or direct kernel object
    manipulation. This is where the linked listed used to
    maintain a list of processes is modified (kernel
    scheduling relies on threads, not processes) so that
    the process is there, but no longer part of the linked
    list maintained by the kernel.

    For more detail, go to

    > This means the OS can't even see what
    > is happening let alone the Admin or AV programs

    Given that the OS 'sees' what's going on through the
    use of it's own APIs, you're correct.

    > (Properly configured AV's could probably be made to
    > look for default settings but for alterable kits
    > this wouldn't matter.

    Some research I presented in my book supports this.

    > To go a step further if the code gets small enough
    > and public enough there
    > is a potential for some of it to end up in viruses.
    > I would think this is pretty difficult but ...

    Not at all.

    > By the way good site.

    Thanks. The book's even better.

    Full-Disclosure - We believe in it.

  • Next message: Todd Towles: "RE: [Full-Disclosure] MS04-028 Shell Exploit[Scanned]"

    Relevant Pages