Please bear with me, as I'd like to address the three
posts I see in this thread all in one email...
First from the OP (shrink-wrap):
> but on the compromised machine it is impossible* to
> view these files or the directory.
Can you elaborate on what you mean by this? I know it
may sound like a question w/ an obvious answer, but
too many times I've run across folks who've examined
Windows boxen and made statements like this without
any sort of background info. What did you try? What
worked/didn't work?
> After reading more and more on windows rootkits- one
> of the common ways to use them is to pick a common
> string to hide and in my case all the files and the
> directory have the string "drop" as part of their
> name. As a test I created a directory in the root
of
> the drive named "dropper" and it also "disappeared".
I am familiar with the technique to which you're
referring...this was popularized by Greg Hoglund's
rootkit techniques. However, until your post, Greg's
proof-of-concept NTRootKit was the only one publicly
available (to the best of my knowledge). You use
plurals throughout your post...can you elaborate a
little bit on other Windows rootkits you found?
> how can I find this root-kit that is hooked into my
kernel?
From your reading, you should be looking for a device
driver file. If a listing from the running machine
doesn't show any unusual or suspicious drivers, I'd
suggest that you examine the image file for files
named "drop*.sys" within the system32 directory.
Would it be possible to get a zipped archive of all of
the files you listed in your post, as well as any
other files associated with this, w/ the directory
structure maintained? I'd greatly appreciate it.
Further, if the system is still up and running, could
you document the following and include the output in a
zipped archive?
1. output of netstat -an
2. output of fport
3. results of a comprehensive port scan of the system
4. output of pslist.exe, handle.exe, and listdlls.exe
(all from SysInternals)
Also, I'd be interested in examining a text dump of
the Registry from the image file.
> BTW, it hasn't matched up with a well-known root-kit
> yet (like slanret)
You're right. Symantec defines slanret as a Trojan,
though...and that bit of malware was detectable via a
particular Registry key.
> *=except 'cd'ing, via command prompt only, into the
> suspect (drop) directory and 'dir' listing all files
> *without* the "drop" name--possibly an error with
the
> root-kit?
Maybe in its architecture. Remember, you said
yourself that your reading regarding rootkits
mentioned the use of a particular string to "hide" the
files. Therefore, it would seem obvious that if the
file did NOT start w/ the target string ("drop", in
this case) then the files would be viewable.
----------------------------------------------------
For Rodrigo:
You said:
"...most Windows rootkits hide themselves by hooking
into to System APIs and "filtering" based on a
keyword..."
Again, like S-W, you use the plural. Are you familiar
w/ more than just Greg Hoglund's NTRootkit and
slanret, that use this technique? If so, could you
provide links or more detailed information?
> Another thing worth mentioning is that since it's
the
> local kernel that is "patched", a remote connection
> (like mapping a network drive to the volume in the
> compromised machine) should be clear of any
> filtering...
This is interesting. Have you tested this? If so,
can you document your testing procedure and results?
I'm very interested, as I'm currently writing a book
on Windows data forensics.
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Thu May 08 2003 - 14:49:01 PDT