Log in

View Full Version : Question about Rootkit Unhooker

WaxfordSqueers
December 31st, 2008, 02:16
There was a thread on our board that linked to Rootkit Unhooker.

http://www.woodmann.com/forum/showthread.php?t=12159&highlight=unhooker

and their site is here: http://www.rootkit.com/newsread.php?newsid=902

Can someone fill me in on the controversy surrounding this product? I heard that Micro$oft had taken over the product or were working in cahoots with them. Now I see the guy defending his product against assertions that he is doing something weird (read article at 2nd link above).

Has anyone actually used version 3.8, either from his site or from the link provided in URL #1 above? Is it safe?
WaxfordSqueers
December 31st, 2008, 02:29
Quote:
[Originally Posted by WaxfordSqueers;78446]and their site is here: http://www.rootkit.com/newsread.php?newsid=902


BTW...there's an interesting article on this site at :

http://www.rootkit.com/blog.php?newsid=903

On how to adjust Filemon/Regmon for Vista. In the FAQ, in the manual that comes with RKU from the site, is this interesting ditty:

Q: Can I disassemble/reverse this?
A: No, but you can try.

The gauntlet has been thrown down for you advanced reversers.
GamingMasteR
December 31st, 2008, 11:30
Don't listen to people say RkU is backdoored .
And yes, RkU 4.1 sold to M$, but they still own rights on its developments, name etc.
WaxfordSqueers
December 31st, 2008, 22:42
Quote:
[Originally Posted by GamingMasteR;78450]Don't listen to people say RkU is backdoored .
And yes, RkU 4.1 sold to M$, but they still own rights on its developments, name etc.
Thanks for info.
Kayaker
January 14th, 2009, 00:32
Hi

A couple of notes about this, one reassuring, the other not.

To start with, for reference the latest (last?) version of RKU is here:

http://www.rootkit.com/vault/DiabloNova/RkU3.8.342.554.rar
http://www.rootkit.com/blog.php?newsid=912


First, in case anyone sees some "funny" stuff in their system logs and gets worried and goes off chasing ghosts, as I did... when you select Scan from the Files tab of RKU, it creates a separate service. The filename will be a random 8 hexadecimal character name temporarily created as ../windows/system32/********.exe

The action will be logged by ZoneAlarm, or probably by any other process monitor you may have active. As well, the Windows System Event Log will record the events through the Service Control Manager (SCM). For example:

The 2F07D778 service was successfully sent a start control.
The 2F07D778 service entered the running state.
The 2F07D778 service entered the stopped state.
The 2F07D778 service was successfully sent a stop control.


If you are quick you can grab a copy of the file in the system32 directory before it deletes itself. If you are even quicker you can set a breakpoint on StartServiceCtrlDispatcherW and live trace the actions of the service. I see no problems with this file, in fact it's quite interesting to analyse.


I'm sorry, but I find no evidence of "backdoors" in RKU

I've read most of the garbage surrounding RKU from the last couple of years, and it's seems to be just that - the usual internet flame war garbage we've all seen before.



However, I do have one major concern about RKU at this point. I saw it mentioned in one Sysinternals forum thread that the RKU driver has changed from a randomly named one in recent versions to a constantly named one, i.e. karlchen.sys. If you read between the lines of the flames, this appears to be an inside joke and slap of the face at a certain moderator on that forum, ..whatever.

That's all fine and dandy, but it appears to me that this is a MAJOR vulnerability to the covertness of RKU against malware, primarily because loading of karlchen.sys can now be detected through a PsSetLoadImageNotifyRoutine callback.


I have my own app (which I'll release + source soon btw) for detecting, dumping and optionally preventing execution of drivers through such a callback routine. I've already determined that I can detect the RKU driver loading, suspend execution of the callback thread, and notify usermode of the fact. If I was a malware I would then have unlimited time to clean up any userland hooks or send an IOCTL to my driver to clean up kernelmode hooks.

Immediately after sending an event to resume execution of the callback thread (and continue loading of the RKU driver), as a test I modified my code to then remove my PsSetLoadImageNotifyRoutine callback and terminate my app. By the time RKU has started fully it should see no trace of me, and indeed no longer records the PsSetLoadImageNotifyRoutine in its list.


So, if I can be so bold to say, I would NOT fully put my faith in RKU that your system is clean, unless you FIRST determine independantly that you have no covert PsSetLoadImageNotifyRoutine callbacks running.


I don't know of any other app that lists these system callbacks (PsSetLoadImageNotifyRoutine, PsSetCreateProcessNotifyRoutine, PsSetCreateThreadNotifyRoutine) that you could use independantly. I've described how to manually find one of them, somewhere else on this board (I believe the Ring 0 anti-debugger code in Daemon Tools thread), but I myself have never gotten around to coding an app to do that.


This kind of preventative measure (if a rootkit malware detects it might be being scanned it simply removes itself from active duty), has been talked about before of course so it's nothing new. Unfortunately, the fact that RKU now uses a "known" driver name has made it vulnerable to this action. So that is the point of my writing this cautionary warning.


Hopefully there is a good future for all this. If MS now owns the "VX" version of RKU, as it sounds, the innovations might be incorporated in a new/improved RootkitRevealer at some point. Then we can all rest easier knowing the only "backdoors" will come from MS itself.

Cheers,
Kayaker
evilcry
January 14th, 2009, 03:21
Really easy to deceive PsSetCreateProcessNotifyRoutine, the old aged trick of manually switching down the callback activation still works:

Code:


for(i = 0x80000000; i < 0xFFFFFFFF; i++)

{

    PsSetCreateProcessNotifyRoutine((PCREATE_PROCESS_NOTIFY_ROUTINE)i, TRUE);

}




About rumors around RKU Backdoors, every person with a bit of k/u space knowledge can read sources here http://antiprotect.com ( at the moment down) for paranoid++ just use the compile 'n compare approach

Have a nice Day,
Giuseppe 'Evilcry' Bonfa'
Kayaker
January 14th, 2009, 18:52
That's a cute trick, more malware than anti-malware oriented. Extrapolating on that idea though, if one were paranoid++, you should be able to secure your own system with a "home-brew" protection by taking a normal baseline reading and "filling up" the unused slots for each of those system callbacks (maximum of 8) with your own blank ones.

If a malware then tries to register one of those system callbacks it should receive a STATUS_INSUFFICIENT_RESOURCES error and the attempt will fail.

For example, on my system (according to RKU) there are 2 CreateProcess, 1 CreateThread, and 2 LoadImage callbacks registered, all by ZoneAlarm. For me this would be a "clean" baseline reading. If I then create my own autostart app to register 6 more PsSetLoadImageNotifyRoutine callbacks for example on bootup, then all 8 system callbacks of that type will be used.

If it so happens that at some future time my autostart app receives a STATUS_INSUFFICIENT_RESOURCES message while attempting to register those 6 extra callbacks, then it's quite likely a boot loading malware might have invaded my system and already installed its own and I should send up a red flag.

Hmmm, methinks a new coding project is in order..
evilcry
January 15th, 2009, 05:20
Hi,

Quote:

Extrapolating on that idea though, if one were paranoid++, you should be able to secure your own system with a "home-brew" protection by taking a normal baseline reading and "filling up" the unused slots for each of those system callbacks (maximum of 8) with your own blank ones.


Exactly!
indeed another Anti anti-rootkit technique is to render PsSetCreateProcessNotifyRoutine useless by filling up all 8 slots with dummy routines
GamingMasteR
January 15th, 2009, 05:50
Another Anti-ARK technique is to modify the NtBuildNumber value, if you do it properly (that means not putting any value) most ARK tools will show the message of "OS not supported"

This technique was mentioned by Fyyre .
rzr
January 25th, 2009, 09:21
Quote:
[Originally Posted by evilcry;78720]Really easy to deceive PsSetCreateProcessNotifyRoutine, the old aged trick of manually switching down the callback activation still works:

Code:


for(i = 0x80000000; i < 0xFFFFFFFF; i++)

{

    PsSetCreateProcessNotifyRoutine((PCREATE_PROCESS_NOTIFY_ROUTINE)i, TRUE);

}




About rumors around RKU Backdoors, every person with a bit of k/u space knowledge can read sources here http://antiprotect.com ( at the moment down) for paranoid++ just use the compile 'n compare approach

Have a nice Day,
Giuseppe 'Evilcry' Bonfa'


Well,

really unoptimized and dangerous routine but yes, it could work. It's easier to overwrite all slots or, even better, reset the counter.

RkU sources at antiprotect.com are far from being full sources. There are just some routine used to search for some stuff. Anyway yes, there aren't really any backdoor or malicious code inside it.
WaxfordSqueers
February 1st, 2009, 17:57
Quote:
[Originally Posted by Kayaker;78718]Hi A couple of notes about this, one reassuring, the other not.
Thanks for your detailed explanation, Kayaker, and sorry about not replying sooner. As I explained on another occasion, my main concern was the safety of online banking. I am now convinced that it is not that safe. I used RKU to check which apps were hooking what and identified all but one.

Most of the hooks were done by Sygate firewall, so I unloaded it and a few other drivers to see if I could eliminate the unknown hook. Rootkitrevealer, Sophos and F-secure antirootkit revealed nothing, so I still don't know what the hook is. I noticed some inconsistencies in RKU when used in console mode, especially in safe mode. I finally got it to load in safe mode, but it kept reporting a process that was loading as a 'parasite'. I found that odd because the so-called parasite only loaded immediately above it in thread ID.

For example, on one occasion, RKU was running thread id 1996 and reported a parasite at thread id 2000. I opened task manager, which was at thread id 2004. There was nothing showing in task manager at thread id 2000. If that was a rootkit, why would it open a thread with an id right above RKU? It could be some other driver monitoring, and I wondered about the softice driver, even though softice was not loaded. I unloaded softice as well, and I 'think' the hook was still there.

The unknown hook was listed at ntoskrnl +0x00005032 0x804DC032 -> 804DC039. otherwise, everything was accounted for.

With respect to online banking, I am now paranoid about keyloggers. The banks seem to be concerned only about phishing scams in which a popup window is presented asking for a re-entry of login info. It seems to me they should be worrying about a keylogger intercepting the keyboard data before it is encrypted. I have scanned my system fairly well with several antivirus apps, including a trial version of F-secure 2009 and Ewido, all with the most recent signatures. I also updated to the most recent version of Spybot. No viruses were detected.

If there is a rootkit running a keylogger, it is all for nought. Banks don't seem to understand that. When I talked to one of their security experts, they had no idea what I was talking about.

One question I asked them is where the 128 bit online encryption kicks in. I know the keyboard was directly accessible in the bad old days but with XP that has all been virtualized. What are the chances of a keylogger intercepting unencrypted information before it is encrypted to go online?
blabberer
February 1st, 2009, 20:20
oh well then there are lots of simpletricks to avoid the shit keyloggers from stealing your password

most simplest form of fooling would be
when you have logged into the form
go to the edit box where you need to supply your user name blah blah blah

type w then remove focus from edit box but not from form (click a bit outside and type random crap
then refocus on editbox type a
unfocus type some crap and so on so even if logged deciphering an usefull thing out of the maze will be a problem

if the keylogger is screen capturing
try using virtual onscreen keyboards (copy letter from charmap in start run accessories systemtools)

some ideas i state are summarized here

http://www.raymond.cc/blog/archives/2007/09/20/how-to-beat-keyloggers-to-protect-your-identity/

and here

http://www.nomad4ever.com/2008/02/21/8-tips-to-fool-keyloggers-in-public-internet-cafes/
Kayaker
February 1st, 2009, 21:48
Quote:
The unknown hook was listed at ntoskrnl +0x00005032 0x804DC032 -> 804DC039


You should crack open Sice or Livekd and check it out. 7 byte difference - that looks like the same false positive I get. Actually it's not really a false positive, RKU has correctly identified that ntoskrnl has been patched, presumably by comparing the disk file with the memory image, but it appears to be a normal Windows process during boot up.

Kind of an interesting code snippet. I get a similar report by RKU under Code Hooks:

ntoskrnl.exe + 0x00006056 0x804DD056 -> 804DD05D Inline - relative jump


Softice identifies the affected function as KeFlushCurrentTb. This is ntoskrnl as it is loaded in memory:

Code:


_KeFlushCurrentTb

0008:804DD054  0F20E0              MOV       EAX,CR4

0008:804DD057  257FFFFFFF          AND       EAX,FFFFFF7F

0008:804DD05C  0F22E0              MOV       CR4,EAX

0008:804DD05F  0D80000000          OR        EAX,00000080

0008:804DD064  0F22E0              MOV       CR4,EAX

0008:804DD067  C3                  RET

0008:804DD068  0000                ADD       [EAX],AL

0008:804DD06A  000F                ADD       [EDI],CL

0008:804DD06C  22E0                AND       AH,AL

0008:804DD06E  0090C38D4900        ADD       [EAX+00498DC3],DL

0008:804DD074  90                  NOP

0008:804DD075  90                  NOP

0008:804DD076  90                  NOP

0008:804DD077  90                  NOP

0008:804DD078  90                  NOP

@KiFlushSingleTb

0008:804DD079  0F013A              INVLPG    [EDX]

0008:804DD07C  C3                  RET



However, if you look at the disasm of the file ntoskrnl.exe, the instructions are entirely different:

Code:


sub_804DD054    proc near               ; CODE XREF: KeFlushEntireTb:loc_804E9DE9                  

:804DD054                            ; DATA XREF: INIT:806B1AC8  

               

:804DD054 0F 20 D8                          mov     eax, cr3

:804DD057 0F 22 D8                          mov     cr3, eax

:804DD05A C3                                retn

:804DD05A                   sub_804DD054    endp

:804DD05A

:804DD05B

:804DD05B                   ; =============== S U B R O U T I N E =======================================

:804DD05B

:804DD05B

:804DD05B                   sub_804DD05B    proc near               ; DATA XREF: INIT:806B1ACD

:804DD05B 0F 20 E0                          mov     eax, cr4

:804DD05E 25 7F FF FF FF                    and     eax, 0FFFFFF7Fh

:804DD063 0F 22 E0                          mov     cr4, eax

:804DD066 0D 80 00 00 00                    or      eax, 80h

:804DD06B 0F 22 E0                          mov     cr4, eax

:804DD06E

:804DD06E                   locret_804DD06E:                        ; DATA XREF: INIT:806B1AD9

:804DD06E C3                                retn

:804DD06E                   sub_804DD05B    endp

:804DD06E

:804DD06E                   ; ---------------------------------------------------------------------------

:804DD06F 90                                db  90h ; É

:804DD070 C3                                retn

:804DD070                   ; ---------------------------------------------------------------------------

:804DD071 8D                                db  8Dh ; ì

:804DD072 49                                db  49h ; I

:804DD073 00                                db    0

:804DD074 90 90 90 90 90                    db 5 dup(90h)

:804DD079

:804DD079                   ; =============== S U B R O U T I N E =======================================

:804DD079

:804DD079

:804DD079                   sub_804DD079    proc near

:804DD079 0F 01 3A                          invlpg  byte ptr [edx]

:804DD07C C3                                retn

:804DD07C                   sub_804DD079    endp

:804DD07C

:804DD07C                   ; ---------------------------------------------------------------------------

:804DD07D 90 90 90 90 90                    db 5 dup(90h)




What gives? Well, if you check one of the XREFS,
:804DD054 ; DATA XREF: INIT:806B1AC8
you can find that during INIT, 14h bytes at 804DD054 are overwritten by the bytes at 804DD05B.

Again using the superior symbolic name identification of Softice, we can identify that the relevant function is called _Ki386EnableGlobalPage.


Code:


INIT:806B1AAB _Ki386EnableGlobalPage proc near        ; DATA XREF: sub_806BE627+62

INIT:806B1AAB

INIT:806B1AAB arg_0           = dword ptr  4

INIT:806B1AAB

INIT:806B1AAB                 push    esi

INIT:806B1AAC                 push    edi

INIT:806B1AAD                 push    ebx

INIT:806B1AAE                 mov     edx, [esp+0Ch+arg_0]

INIT:806B1AB2                 pushf

INIT:806B1AB3                 cli

INIT:806B1AB4                 lock dec dword ptr [edx]

INIT:806B1AB7

INIT:806B1AB7 loc_806B1AB7:                           ; CODE XREF: _Ki386EnableGlobalPage+11

INIT:806B1AB7                 pause

INIT:806B1AB9                 cmp     dword ptr [edx], 0

INIT:806B1ABC                 jnz     short loc_806B1AB7

INIT:806B1ABE                 cmp     large byte ptr fs:51h, 0

INIT:806B1AC6                 jnz     short loc_806B1AE0

INIT:806B1AC8                 mov     edi, offset sub_804DD054

INIT:806B1ACD                 mov     esi, offset sub_804DD05B

INIT:806B1AD2                 mov     ecx, 14h

INIT:806B1AD7                 rep movsb

INIT:806B1AD9                 mov     byte ptr ds:locret_804DD06E, 0

INIT:806B1AE0

INIT:806B1AE0 loc_806B1AE0:                           ; CODE XREF: _Ki386EnableGlobalPage+1B

INIT:806B1AE0                                         ; _Ki386EnableGlobalPage+3C

INIT:806B1AE0                 cmp     byte ptr ds:locret_804DD06E, 0

INIT:806B1AE7                 jnz     short loc_806B1AE0

INIT:806B1AE9                 mov     eax, cr4

INIT:806B1AEC                 and     eax, 0FFFFFF7Fh

INIT:806B1AF1                 mov     ecx, cr3

INIT:806B1AF4                 mov     cr4, eax

INIT:806B1AF7                 mov     cr3, ecx

INIT:806B1AFA                 or      eax, 80h

INIT:806B1AFF                 mov     cr4, eax

INIT:806B1B02                 popf

INIT:806B1B03                 pop     ebx

INIT:806B1B04                 pop     edi

INIT:806B1B05                 pop     esi

INIT:806B1B06                 retn    4

INIT:806B1B06 _Ki386EnableGlobalPage endp



Doing a search for Ki386EnableGlobalPage we find a nice explanation, as there often is, in ReactOS.


00034 /* Now check if this is the Boot CPU */
00035 if (!KeGetPcr()->Number)
00036 {
00037 /* It is.FIXME: Patch KeFlushCurrentTb */
00038 }


KeGetPcr()->Number is equivalent to fs:0x51
kd> dt -r _KPCR 0xffdff000
+0x051 Number : 0 ''



http://www.reactos.org/generated/doxygen/de/de0/patpge_8c-source.html

Code:


00001 /*

00002 * PROJECT:         ReactOS Kernel

00003 * LICENSE:         GPL - See COPYING in the top level directory

00004 * FILE:            ntoskrnl/ke/i386/patpge.c

00005 * PURPOSE:         Support for PAT and PGE (Large Pages)

00006 * PROGRAMMERS:     Alex Ionescu (alex.ionescu@reactos.org)

00007 */

00008 

00009 /* INCLUDES ******************************************************************/

00010 

00011 #include <ntoskrnl.h>

00012 #define NDEBUG

00013 #include <debug.h>

00014 

00015 /* GLOBALS *******************************************************************/

00016 

00017 ULONG Ke386GlobalPagesEnabled;

00018 

00019 /* FUNCTIONS *****************************************************************/

00020 

00021 ULONG_PTR

00022 NTAPI

00023 Ki386EnableGlobalPage(IN volatile ULONG_PTR Context)

00024 {

00025     volatile PLONG Count = (PLONG)Context;

00026     ULONG Cr4, Cr3;

00027 

00028     /* Disable interrupts */

00029     _disable();

00030 

00031     /* Decrease CPU Count and loop until it's reached 0 */

00032     do {InterlockedDecrement(Count);} while (!*Count);

00033 

00034     /* Now check if this is the Boot CPU */

00035     if (!KeGetPcr()->Number)

00036     {

00037         /* It is.FIXME: Patch KeFlushCurrentTb */

00038     }

00039 

00040     /* Now get CR4 and make sure PGE is masked out */

00041     Cr4 = __readcr4();

00042     __writecr4(Cr4 & ~CR4_PGE);

00043 

00044     /* Flush the TLB */

00045     Cr3 = __readcr3();

00046     __writecr3(Cr3);

00047 

00048     /* Now enable PGE */

00049     __writecr4(Cr4 | CR4_PGE);

00050     Ke386GlobalPagesEnabled = TRUE;

00051 

00052     /* Restore interrupts */

00053     _enable();

00054     return 0;



I think that pretty much explains why RKU identified an ntoskrnl patch, even if it's not quite aware of what's going on.

All that remains is hitting the Intel docs for a refresher course to understand the details of the KeFlushCurrentTb patch.


Also, Joanna Rutkowska's System Virginity Verifier seems to identify the KeFlushCurrentTb() patch by name:
http://kareldjag.over-blog.com/article-1232492.html



Btw, I hope you're aware of the Canada Revenue Agency Phishing Web Site. Be safe - don't do *any* financial transactions online.

http://securitylabs.websense.com/content/Alerts/3282.aspx
WaxfordSqueers
February 1st, 2009, 22:40
Quote:
[Originally Posted by blabberer;79077]oh well then there are lots of simpletricks to avoid the shit keyloggers from stealing your password
thanks for the tips, blabberer. Food for thought. I read your links and each method still seems to have its downfalls, especially if the logger is using window capture for each mouse/keystroke. Although many of them may not be up to that sophistication yet, I'm sure they soon will be.

I am focusing on the proxy defense right now. Apparently you can d/l a free proxy (eg. fiddler at http://www.fiddlertool.com/Fiddler2/version.asp ), that sits in between your browser and the net. It can apparently be programmed to decipher your keyboard data from background nonsense typed in at random. Don't know how it works yet. Method is described here:

http://www.acsac.org/2006/papers/56.pdf

I need to learn more about the method of interception by the keylogger. One article refers to user32.dll and describes how the keyboard data is logged there. One concern I have, although it may be premature, is that typing a password interspersed with chaff (junk keystrokes) could be detected by examining spaces between entries. For example, when the focus is changed from the desired password entry window to the main banking window page, so that junk can be typed in, can the logger detect that a change in focus has taken place? Would that show up in the logged keystrokes somehow, or associated with them?

If a logger is hooking user32, you'd think RKU would reveal that. I am assuming the logger would have to hook user32, or something further down the line.
WaxfordSqueers
February 1st, 2009, 22:51
Quote:
[Originally Posted by Kayaker;79078]You should crack open Sice or Livekd and check it out.
I think you forgot to attach a smiley. I get a bit of a laugh out of what you consider easy. I'm a mere mortal who has difficulty even following your excellent explanations. BTW...thanks for the explanation.

More later...I've got a real virus, with accompanying chills and headache. I'm off to watch an episode of House to see if I can get any tips.
Kayaker
February 1st, 2009, 23:06
Aach, you don't give yourself enough credit Waxford.

OK,

"You should crack open Sice or Livekd and check it out."