PDA

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