lists.openwall.net   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  linux-hardening  linux-cve-announce  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: uberguidoz at gmail.com (GuidoZ)
Subject: Rootkit For Spyware? Hide your adware from all Adware removers and Anti-viruses

I stand corrected. I hadn't thought about this...

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

Windows is likely the most susceptible to such an attack due to the
limited amount of people that fully understand the kernel and "flow
chart" of processes. (Or those that don't put 2 and 2 together, like
myself.) Excellent points, Harlan.

--
Peace. ~G


On Thu, 23 Sep 2004 08:41:36 -0700 (PDT), Harlan Carvey
<keydet89@...oo.com> wrote:
> 
> 
> > 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
> MCSEs.
> 
> > 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 word...tools and techniques for
> preventing and detecting infections from this type of
> malware.
> 
> > 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 http://www.rootkit.com.
> 
> > 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ