lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: keydet89 at (Harlan Carvey)
Subject: Rootkit For Spyware? Hide your adware from   all Adware removers and Anti-viruses

> 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.

Powered by blists - more mailing lists