RoorKit Hook Analyzer

[Art]

I found this free product to be a useful addition to a arsenal
of various kinds of analysis tools:
http://www.resplendence.com/hookanalyzer

Out of curiosity, I spent some time the other day following
up on its findings of many .sys drivers it found hooking
to my Win 2K OS kernel. In most cases, the software
vendors of drivers are identified. Also, in many cases, it's
possible to Google the file name and obtain information.
You can then make judgements based on file size comparisons
to legit files, etc., as to whether or not a driver seems to
be legit. You can, of course, also upload files to Virus Total
or Jotti to see what a number of av products have to say
about the files.

One thing I learned along the way via some internet research.
Two files, dump_atapi.sys and dump_WMiLIB.sys are said
to be created files. I wondered, since I couldn't find them
on my drives ... and since another tool flags them as
"suspicious" since they don't exist, yet they are listed
as hooking the kernel. The files actually there are atapi.sys
and WMILIB.sys

Another thing, which isn't very surprising, is that I had
a case of a driver that did exist on my drive, but it was
part of a program that I had uninstalled. I managed to
track it down since the driver vendor was identified.

The way I look at it, this sort of thing is a part of getting
to know your system, and what's normal on it. You can
never be entirely sure your system is free of malware,
but there are many tools available which can help you
find suspicious or questionable stuff.

Art
http://home.epix.net/~artnpeg

 

[Ant]

I found this free product to be a useful addition to a arsenal
of various kinds of analysis tools:
http://www.resplendence.com/hookanalyzer

I have their "Registrar Lite", which is an excellent alternative to
regedit.

One thing I learned along the way via some internet research.
Two files, dump_atapi.sys and dump_WMiLIB.sys are said
to be created files. I wondered, since I couldn't find them
on my drives ... and since another tool flags them as
"suspicious" since they don't exist, yet they are listed
as hooking the kernel. The files actually there are atapi.sys
and WMILIB.sys

Searching the web for these names gives loads of hits on dump files
people want help with interpreting, but not much else. The only
comment (complete with typo) I could find was:

"the OS creates these images on its own based off of atapi.sys and
wmilib.sys (ie duplicates). this will happen when a dirver is in the
dump stack".

If you have Sysinternals' Process Explorer you can see the same list
of loaded modules in the lower pane by selecting the System process,
and choosing the "view DLLs" mode from the "view handles/view DLLs"
toolbar button.

You will notice that PE loads a temporary driver which does not appear
in the file system named PROCEXPnnn.SYS, where "nnn" is the version of
PE. However, this does create a registry entry under:
HKLM\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_PROCEXPnnn

Similarly, other Sysinternals utilities create these "ghost" drivers;
for example RegMon has one called REGSYSnnn.SYS.

The way I look at it, this sort of thing is a part of getting
to know your system, and what's normal on it. You can
never be entirely sure your system is free of malware,
but there are many tools available which can help you
find suspicious or questionable stuff.

I agree, and thanks for posting (it prompted me to discover the
Sysinternals info). Of course, the trouble with recommending these
sort of tools to "end users" is you have to deal with the GWF
syndrome.

See also http://invisiblethings.org/tools.html which I noted during
my search, but haven't tried any of them.

 

[Art]

I have their "Registrar Lite", which is an excellent alternative to
regedit.


Searching the web for these names gives loads of hits on dump files
people want help with interpreting, but not much else. The only
comment (complete with typo) I could find was:

"the OS creates these images on its own based off of atapi.sys and
wmilib.sys (ie duplicates). this will happen when a dirver is in the
dump stack".

That's similar to but not identical with something I found. Some guy
just responded briefly to a query and said they are created by
the system.

If you have Sysinternals' Process Explorer you can see the same list
of loaded modules in the lower pane by selecting the System process,
and choosing the "view DLLs" mode from the "view handles/view DLLs"
toolbar button.

You will notice that PE loads a temporary driver which does not appear
in the file system named PROCEXPnnn.SYS, where "nnn" is the version of
PE. However, this does create a registry entry under:
HKLM\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_PROCEXPnnn

Similarly, other Sysinternals utilities create these "ghost" drivers;
for example RegMon has one called REGSYSnnn.SYS.

Interesting. I've never noticed.

I agree, and thanks for posting (it prompted me to discover the
Sysinternals info). Of course, the trouble with recommending these
sort of tools to "end users" is you have to deal with the GWF
syndrome.

I'm glad you followed up.

See also http://invisiblethings.org/tools.html which I noted during
my search, but haven't tried any of them.

I had found a link to ModGREPPER (One tool listed on that page)
and in fact it's the util that gave me the "suspicious" warning
on the dump_ files. The author points out that at least a
couple of the utils listed there are old now, and that there are
better tools available. I didn't find that any of them were
useful to me, but perhaps some experts might still find some of
them useful.

My impression is that this stealth/rootkit stuff is a real rat race
of "one upsmanship" where somebody develops a detetor and
someone else finds a way around it in a seemingly endless
battle of wits.

Art
http://home.epix.net/~artnpeg

 

[kurt wismer]

Art wrote:
[snip]

My impression is that this stealth/rootkit stuff is a real rat race
of "one upsmanship" where somebody develops a detetor and
someone else finds a way around it in a seemingly endless
battle of wits.

the solution for stealth has been outside-the-box (ie. clean boot)
analysis for a long time now...

of course the malware answer to outside-the-box analysis is
non-persistence... time will tell whether that can work as a mainstream
counter-measure...

 

[Art]

Art wrote:
[snip]

My impression is that this stealth/rootkit stuff is a real rat race
of "one upsmanship" where somebody develops a detetor and
someone else finds a way around it in a seemingly endless
battle of wits.

the solution for stealth has been outside-the-box (ie. clean boot)
analysis for a long time now...

I wonder if there's a way that non-experts can determine whether
or not a machine has been compromised by stealth? I'm interested
in the problem of establishing a clean reference baseline, but I
don't know how to go about it, nor do I know if it can be done
by non-experts or even by experts with certainty.

Actually, I'd be satisfied with just a higher degree of
certainty ... much better than what can be done using various
available tools and antimalware products in Windows plus "formal"
scanning using a alternate OS.

Is it possible for a non-expert to accomplish the "solution" you
mention? Or is the analysis required too highly techical for those of
us incapaple of digging deeply into the innards of Windows?

Art
http://home.epix.net/~artnpeg

 

[kurt wismer]

Art wrote:
[snip]

My impression is that this stealth/rootkit stuff is a real rat race
of "one upsmanship" where somebody develops a detetor and
someone else finds a way around it in a seemingly endless
battle of wits.

the solution for stealth has been outside-the-box (ie. clean boot)
analysis for a long time now...

I wonder if there's a way that non-experts can determine whether
or not a machine has been compromised by stealth? I'm interested
in the problem of establishing a clean reference baseline, but I
don't know how to go about it, nor do I know if it can be done
by non-experts or even by experts with certainty.

Actually, I'd be satisfied with just a higher degree of
certainty ... much better than what can be done using various
available tools and antimalware products in Windows plus "formal"
scanning using a alternate OS.

Is it possible for a non-expert to accomplish the "solution" you
mention? Or is the analysis required too highly techical for those of
us incapaple of digging deeply into the innards of Windows?

theoretically it can... whether it can be done practically is a
different question... what's needed is integrity checking software that
is ntfs aware (in that it will also check ads streams)... i'm not sure
if there's a tool out there currently that will do that, the last time i
went looking for a good integrity checker i was kinda disappointed...
that's just to detect stealth generically, mind you - booting clean will
uncover the malware that was using stealth and make it susceptible to
detection by known-malware techniques...

if there was good integrity checking software, though, the output should
clearly indicate that file X cannot be seen when the system is running
and is therefore being hidden by some kind of stealth... often generic
techniques require a certain amount of interpretation on the part of the
user about whether something is good or bad, but if you're just testing
for stealth rather than good stealth or bad stealth then that
interpretation shouldn't be necessary so the non-expert should be able
to do it...