Root toolkits on Windows

I ran across this article and thought it was interesting

http://www.computerworld.com/printth...,99843,00.html

Michael

--

"Microsoft isn't evil, they just make really crappy operating systems." -
Linus Torvald

Michael Pelletier

"Michael Pelletier" <> wrote in message
news:6jq2e.30060$AN1.1807@fed1read03...
>I ran across this article and thought it was interesting
>
> http://www.computerworld.com/printth...,99843,00.html


You could visit http://www.rootkit.com which has been around a few years
to learn about rootkits but be aware that it seems to cater to both
whitehats and blackhats.

--
__________________________________________________ __________
Post your replies to the newsgroup. Share with others.
E-mail reply: Remove "NIXTHIS" and add "#VS811" to Subject.
__________________________________________________ __________

Michael Pelletier wrote:
> I ran across this article and thought it was interesting
>
> http://www.computerworld.com/printth...,99843,00.html
>
> Michael
>

Yes, and there are people who say it's been going on much longer than
than most people think and that there are more infected machines than
you might think: http://www.aplawrence.com/Words2005/2005_03_23.html

--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com

Tony Lawrence

Tony Lawrence wrote:
> Michael Pelletier wrote:
>
>> I ran across this article and thought it was interesting
>>
>> http://www.computerworld.com/printth...,99843,00.html
>>
>> Michael
>>
>
> Yes, and there are people who say it's been going on much longer than
> than most people think and that there are more infected machines than
> you might think: http://www.aplawrence.com/Words2005/2005_03_23.html
>

While you can not see these root kits easily you can see ones like
hacker defender and vanguard (and others) by using this tool from system
internals.

http://www.sysinternals.com/ntw2k/fr...itreveal.shtml

If you have an older version of this program you may want to upgrade to
the current version(ver 1.32). The whole concept of using a root kit is
to hide ones activity from the victim.

Root kits can be useful to use for monitoring systems without "users"
knowledge. Legalities of doing so depend on network policies and who
owns the asset and the network.

Hiding this stuff using alternate data streams and other methods can be
problematic, however this tool and others often reveal their presence.
But one usually has to suspect that such activity is taking place.
proper IDS on the network should be configured to look for the
communication fingerprints of these tools.

Personally I am having more issues with CSLIDS. Recently found HOTBAR
on a client that was embedded using a registered MS product CSLID with
no checksum. At the moment I can't remember the common MS product CSLID
but it don't run on our network anymore While castle cops has a
good CSLID DB to identify what the various CSLIDS are:

http://castlecops.com/CLSID.html

Its deficiency is it does not indicate if the ID has a checksum which
prevents CSLID hijack and it can be a very painful process identifying
the specific MALWARE involved. I would like to have a magic bullet but
haven't found one. I would prefer to be able to scan client registries
before IDS sees the miscreant communication and shuts down the client.
Anyone have an easier way?

Winged

winged

winged wrote:

> Tony Lawrence wrote:
>> Michael Pelletier wrote:
>>
>>> I ran across this article and thought it was interesting
>>>
>>> http://www.computerworld.com/printth...,99843,00.html
>>>
>>> Michael
>>>
>>
>> Yes, and there are people who say it's been going on much longer than
>> than most people think and that there are more infected machines than
>> you might think: http://www.aplawrence.com/Words2005/2005_03_23.html
>>
>
> While you can not see these root kits easily you can see ones like
> hacker defender and vanguard (and others) by using this tool from system
> internals.
>
> http://www.sysinternals.com/ntw2k/fr...itreveal.shtml
>
> If you have an older version of this program you may want to upgrade to
> the current version(ver 1.32). The whole concept of using a root kit is
> to hide ones activity from the victim.

The ones the article are referencing are about hiding itself from detection
(antivirus, etc). The problem with it is 1) Antivirus software gets it
information, indirectly, from the Windows kernel. Now, here is the problem.
If the kernel has been compromised and the virus is getting info from the
compromised kernel it really makes anti-virus software a total joke....

> Root kits can be useful to use for monitoring systems without "users"
> knowledge. Legalities of doing so depend on network policies and who
> owns the asset and the network.

Sure, but these applications are designed, and installed, for malicious
purposes...

> Hiding this stuff using alternate data streams and other methods can be
> problematic,

Not if your leach onto the NT Kernel. You have to remember that in Windows
they restrict any sort of direct access. Once it is installed the only way
to detect it is to pull system disk and scan it from an uncompromised
system. This make is a pain-in-ass just to check since the system will be
down.

> however this tool and others often reveal their presence.
> But one usually has to suspect that such activity is taking place.
> proper IDS on the network should be configured to look for the
> communication fingerprints of these tools.

They might be able to detect the first generation but not the upcoming...

> Personally I am having more issues with CSLIDS. Recently found HOTBAR
> on a client that was embedded using a registered MS product CSLID with
> no checksum. At the moment I can't remember the common MS product CSLID
> but it don't run on our network anymore While castle cops has a
> good CSLID DB to identify what the various CSLIDS are:
>
> http://castlecops.com/CLSID.html
>
> Its deficiency is it does not indicate if the ID has a checksum which
> prevents CSLID hijack and it can be a very painful process identifying
> the specific MALWARE involved. I would like to have a magic bullet but
> haven't found one. I would prefer to be able to scan client registries
> before IDS sees the miscreant communication and shuts down the client.
> Anyone have an easier way?
>
> Winged


I don't know. I think you are underestimating the impact that these will
have....


Michael

--

"Microsoft isn't evil, they just make really crappy operating systems." -
Linus Torvald

Michael Pelletier

"Michael Pelletier" <> wrote in message
news:JfL2e.34722$AN1.6527@fed1read03...
> winged wrote:
>
>> Tony Lawrence wrote:
>>> Michael Pelletier wrote:
>>>
>>>> I ran across this article and thought it was interesting
>>>>
>>>> http://www.computerworld.com/printth...,99843,00.html
>>>>
>>>> Michael
>>>>
>>>
>>> Yes, and there are people who say it's been going on much longer
>>> than
>>> than most people think and that there are more infected machines
>>> than
>>> you might think: http://www.aplawrence.com/Words2005/2005_03_23.html
>>>
>>
>> While you can not see these root kits easily you can see ones like
>> hacker defender and vanguard (and others) by using this tool from
>> system
>> internals.

Hopefully he meant the "Vanquish" rootkit since I'm not proliferating
any of this high-level OS programming code (yeah, I wish I was that
smart to understand that level of programming).

>> http://www.sysinternals.com/ntw2k/fr...itreveal.shtml
>>
>> If you have an older version of this program you may want to upgrade
>> to
>> the current version(ver 1.32). The whole concept of using a root kit
>> is
>> to hide ones activity from the victim.
>
> The ones the article are referencing are about hiding itself from
> detection
> (antivirus, etc). The problem with it is 1) Antivirus software gets it
> information, indirectly, from the Windows kernel. Now, here is the
> problem.
> If the kernel has been compromised and the virus is getting info from
> the
> compromised kernel it really makes anti-virus software a total
> joke....

Hence the continued need for AV software that can run from a bootable
floppy or CD so the suspect OS is not actually running when it is being
scanned.

>> Root kits can be useful to use for monitoring systems without "users"
>> knowledge. Legalities of doing so depend on network policies and who
>> owns the asset and the network.
>
> Sure, but these applications are designed, and installed, for
> malicious
> purposes...
>
>> Hiding this stuff using alternate data streams and other methods can
>> be
>> problematic,
>
> Not if your leach onto the NT Kernel. You have to remember that in
> Windows
> they restrict any sort of direct access. Once it is installed the only
> way
> to detect it is to pull system disk and scan it from an uncompromised
> system. This make is a pain-in-ass just to check since the system will
> be
> down.

Microsoft has their Strider Ghostbuster Rootkit Detection utility coming
out later (http://research.microsoft.com/*rootkit/) which purportedly
works similar to SysInternal's Rootkit Revealer except that it does an
in-the-box scan compared with an out-of-box scan (the SysInternals tool
only does an in-the-box scan and compare). Any anti-virus programs that
claim rootkit detection (beyond just using signatures which may not be
detectable under a compromised OS) will also be required to create
bootable media to provide an out-of-box scan.

The only real protection is boundary protection; i.e., never let it in
in the first place. Once in, it may be smart and corrosive enough to
prevent detection and even entangle itself so badly that removal will
result in corrupting the OS, and only out-of-the-box scanning would even
detect it.

--
__________________________________________________ __________
Post your replies to the newsgroup. Share with others.
E-mail reply: Remove "NIXTHIS" and add "#VS811" to Subject.
__________________________________________________ __________

Michael Pelletier wrote:
> winged wrote:
>
>
>>Tony Lawrence wrote:
>>
>>>Michael Pelletier wrote:
>>>
>>>
>>>>I ran across this article and thought it was interesting
>>>>
>>>>http://www.computerworld.com/printth...,99843,00.html
>>>>
>>>>Michael
>>>>
>>>
>>>Yes, and there are people who say it's been going on much longer than
>>>than most people think and that there are more infected machines than
>>>you might think: http://www.aplawrence.com/Words2005/2005_03_23.html
>>>
>>
>>While you can not see these root kits easily you can see ones like
>>hacker defender and vanguard (and others) by using this tool from system
>>internals.
>>
>>http://www.sysinternals.com/ntw2k/fr...itreveal.shtml
>>
>>If you have an older version of this program you may want to upgrade to
>>the current version(ver 1.32). The whole concept of using a root kit is
>>to hide ones activity from the victim.
>
>
> The ones the article are referencing are about hiding itself from detection
> (antivirus, etc). The problem with it is 1) Antivirus software gets it
> information, indirectly, from the Windows kernel. Now, here is the problem.
> If the kernel has been compromised and the virus is getting info from the
> compromised kernel it really makes anti-virus software a total joke....
>
>
>>Root kits can be useful to use for monitoring systems without "users"
>>knowledge. Legalities of doing so depend on network policies and who
>>owns the asset and the network.
>
>
> Sure, but these applications are designed, and installed, for malicious
> purposes...
>
>
>>Hiding this stuff using alternate data streams and other methods can be
>>problematic,
>
>
> Not if your leach onto the NT Kernel. You have to remember that in Windows
> they restrict any sort of direct access. Once it is installed the only way
> to detect it is to pull system disk and scan it from an uncompromised
> system. This make is a pain-in-ass just to check since the system will be
> down.
>
>
>>however this tool and others often reveal their presence.
>>But one usually has to suspect that such activity is taking place.
>>proper IDS on the network should be configured to look for the
>>communication fingerprints of these tools.
>
>
> They might be able to detect the first generation but not the upcoming...
>
>
>>Personally I am having more issues with CSLIDS. Recently found HOTBAR
>>on a client that was embedded using a registered MS product CSLID with
>>no checksum. At the moment I can't remember the common MS product CSLID
>>but it don't run on our network anymore While castle cops has a
>>good CSLID DB to identify what the various CSLIDS are:
>>
>>http://castlecops.com/CLSID.html
>>
>>Its deficiency is it does not indicate if the ID has a checksum which
>>prevents CSLID hijack and it can be a very painful process identifying
>>the specific MALWARE involved. I would like to have a magic bullet but
>>haven't found one. I would prefer to be able to scan client registries
>>before IDS sees the miscreant communication and shuts down the client.
>> Anyone have an easier way?
>>
>>Winged
>
>
>
> I don't know. I think you are underestimating the impact that these will
> have....
>
>
> Michael
>

I think you missed the point. The tool I referenced will show these
critters. A/V tools will not identify many backdoors. A/V tools are
effective only against known threats, and all fall short of stopping
malicious code. In the business environment A/V tools are essential,
but so are IDS monitors, layered firewalls, segmentation, filtering,
logging, etc. Yes, A/V tools are designed only to stop a limited scope
of malicious activity. When someone finds the GOD tool that stops all
malicious activity, I will be first in line to buy it, but I won't hold
my breath. It would probably quarantine IE.

Heck A/V won't identify a number of spyware hacks that are, for all
intents and purposes, remote control tools.

I have seen in IDS logs, "spyware" packages that upload complete
registries, install logs, downloader tools that embed more crud on the
system, etc. Those packages were in the clear on disk. I have seen
CSLID controls mounted in the winsock of XP machines (installed via a
browser exploit) that was remarkably sophisticated. In the forensic
analysis, it captured all locations connected to and any logins or
passwords used stored the data within a most recently used listing the
registry and transmitted the data to its home (Russia) once a day in an
encrypted port 443 session. The transmission was totally invisible to
the win API (netstat would not show the connection),and that software
was classed as spyware. While it did not have direct remote control
components that were identified, the component activity was no less
bothersome. There are a number of methods of running code in the Wins
environment, many more than the hkey_local windows run entry.

I am not a Anti-windows person however there are a number of systemic
design flaws with the registry/software interface and the WIN API
security. There are a number security issues with NTFS.

That said, all computer systems have flaws that can be exploited, it has
been true since the beginning of computers even before there was an
"Internet".

Their are several basic security flaws in the IPV4 protocols in use.
IPV6 will fix a some of those basic flaws but we are still several years
before IPV6 can be fully implemented.

Their are hardware flaws in the NIC cards on many systems that can
reveal computer memory data, widely deployed on the Internet. (Send an
ACK to a remote computer with a large window size capture the return
packet) While this is an inefficient method of gathering data, it can if
exploited properly reveal login credentials in the clear depending on
what data the remote system selected from memory for the pad. If the
ACK is sent to an open port, even though the system is stelthed via
firewall, it will say huh with a padded packet.

Yes rootkits such as vanguard, or hacker defender, are a threat folks
should be aware of, but this class of tools is by no means a new threat.
Hacker Defender, for example, has been in use for several years and has
gone through a number of revisions. The behavior is not "NEW" and has
been in use for some time. The key is understanding what the threats
are, how to mitigate the threat as much as possible, how to identify a
compromise, and how to respond when an exploit occurs.

Currently the web browser is the #1 tool for exploitation. This is one
reason blackhats have been focusing on web server exploits recently, so
they can compromise "visitors". Microsoft in their infinite wisdom
chose to marry the e-mail client with web browsers with very little
sandbox control. MS did this for functionality. This redoubled the
threat so now bad guys don't even have to get you to visit the
compromise site directly, just exploits the user via spam to the victim
that automatically connects the victim to the compromised site or runs
compromise code internally. At our site, a full 30% of SPAM caught by
filters is some sort of compromise attempt. The power of ActiveX, .NET
etc cannot be denied, however by providing this functionality with
poorly conceived control methodologies of who can use this power is one
reason alternate browsers such as Firefox have captured a large market
share in a short period of time.

I am amazed many folks never even look at their system logs, nor even
turn on many of the basic monitoring capabilities of their system. This
is compounded by MS crippling the security of a the largest segment of
their sales (XP HOME) by limiting accounts to either user or admin
(their is no in between).

IMHO MS made a serious error in judgment when they decided to use
security functionality as the major discriminator between their home
version and professional version of OS software. Can it be run securely,
yes, but 90% of users will not, because of basic human behavior. Pop-up
blockers added to the browser will not fix the browsers insecurity.
Perhaps they will do better in Longhorn, but somehow, from what I read,
we will see more exploits in the win OS not fewer. I recently read
about an exploit of a common DRM in use, that will be near invisible to
the average user. Hiding in legitimate processes is much harder to find.

Just wait, it is going to get more interesting.

Winged

winged

Vanguard wrote:

> The only real protection is boundary protection; i.e., never let it in
> in the first place. Once in, it may be smart and corrosive enough to
> prevent detection and even entangle itself so badly that removal will
> result in corrupting the OS, and only out-of-the-box scanning would even
> detect it.
>

AMEN. We run a number a packages to identify known crud on clients,
nothing catches everything. The flaw most malware has is it needs to
communicate. Monitoring network communications with IDS not only
catches the known, but often catches the unknown. Additionally one need
to matrix "normal" network communications which aides identifying that
which is abnormal.

If I were restricted to tools I could only run on the client, I would
fully miss 50% of compromises, maybe more, and I still worry about the
unknown. Even in the home environment I run basic IDS so I will know
when something has occurred. One has to be careful when playing with
darkside elements, sometimes the bad guys win.

Winged

winged