This article is about using global hooks and window subclassing to create a pseudo-rootkit capable of hiding files from Explorer, Task Manager, Registry Editor, etc.
It is assumed that the reader knows basic C++, Windows Programming, Global Hooks (for DLL injection) and of course, knows what a RootKit is.
Although The program has been well tested, I have to include this disclaimer: The following program attempts to modify your operating system, which may/can make your system unstable. By executing/compiling the program you agree that neither the author nor the site hosting this article shall be held responsible for any damages occured due to this program. This program comes with NO WARRANTY. USE AT YOUR OWN RISK!! If this scares you, you probably shouldn't run this program. The author hereby disclaims himself. This article may not be re-published elsewhere without the permission of the author.
Using the code
Compile the VC++ Project to obtain a DLL. You could write your own loader, but i have enclosed a small DLL Tester written in VB just in case. Once loaded, the DLL will establish a
Before I start a flame war or get found out by the Gurus out there, I'd like to state Kitkat is not a "System Roothit". It's more of a "User Rootkit" not to be confused with "UserMode Rootkits (Ring 3)"...
There are 2 basic kinds of Rootkits:
- Kernel Mode Rootkits (Run in Ring0 and filters requests at the highest level)
- UserMode Rootkits (Run in UserMode, uses API redirection, IAT hooking to get the job done)
The most powerful rootkits are no doubt the kernel rootkits. Usermode rootkits are less desirable because it is well known[^] that not all API calls can be hooked using IAT patching. (Link to Article)
So which of these does KitKat belong to? Actually, its None of the above. Most rootkits have the following model
OS ---> RootKit Filter ---> User
Every file that is being stealthed is hidden from the system itself, which means even if one programmatically tries to locate a file, you'll not be able to find it since the filter intercepts any such requests. As a result it effectively stealths the files/processes from BOTH the SYSTEM and THE USER. If an AntiVirus (AV) program requests a file that was being stealthed, the AV would get an "INVALID_FILE_HANDLE" response. In contrast, Kitkat is based on the following model:
Windows GUI ----> Kitkat RootKit Filter ----> User
As You can see, The OS doesn't figure in the diagram because KitKat only modifies/affects the GUI of the system. KitKat does NOT stealth your files from the system itself. It only hides your files from the "User's Sight". The files can be read and written programmatically by any program.
For example, say Kitkat is hiding the file c:\test.txt. Although you won't be able to see the file using Windows Explorer, if you tried to execute
notepad c:\test.txt it would work fine, since the system can "see" the file. The system remains unaffected; only the GUI is affected. As a result, this can be used to
- Hide process listing (from Task Manager, etc.)
- Hide files in Explorer (Folders, Files, Common Dialog Boxes)
- Hide entries in the Registry Editor (Regedit)
I hope that has clarified things.
The DLL injection method is based on Ivo Ivanov's[^] code. A million thanks to him.
Grab your trusty Spy++ and find the class name of the main window (where folders and files are displayed) used by
- Common Dialogs (Open File, Save File)
- Etc. (pretty much everything on your PC)
You'll notice all the the main windows (where folders and files are displayed) are of class
SysListView32 which is popularly called a
ListView. Note that almost every control in Windows is also a window and all are created using
CreateWindow. Windows differentiates between a
Button and a
List by means of a class name. In addition, every window has a
WinProc Window procedure.
For each class there are specific procedures. For a
WM_COMMAND may simulate a depressed button. The same
Message for a
List simply highlights the selection. As you can see, every control has its own in-built default procedure and we are going to redirect this default procedure to our filter.
Kitkat.dll is going to be injected into every process that has a message queue using the
CallWnd hook. Once injected, by using global subclassing we can redirect the default window procedure of
ListView to our own filter function. To perform the redirection, we only need one API call to
Hooking The ListView Procedure
HWND hWnd = CreateWindow("SysListView32","",0, 0, 0, 0, 0,NULL, NULL, hInstance, NULL);
OldWndProc = SetClassLong(hWnd,GCL_WNDPROC,(LONG)NewWndProc);
Once this is done, every
ListView created AFTER the hook was established will be affected. Note:
ListViews created before are unaffected, which is just one of the many drawbacks of the Kitkat method. Although it can be implemented using
SetWindowLong() we have to remember the old procedure for each one of them. After all, this is just a demo.
Notice, that we now have the
OldWndProc. You need to store this, because we'll need it to call the real procedure.
LRESULT CALLBACK NewWndProc(HWND Hwnd, UINT Message, WPARAM wParam, LPARAM lParam)
HWND hdr = (HWND)SendMessage(Hwnd,LVM_GETHEADER,0,0);
int Col = SendMessage(hdr,HDM_GETITEMCOUNT,0,0);
int i,j,k,itemCount = ListView_GetItemCount(Hwnd);
for(i=0;i < Col;i++)
for(j=0;j < itemCount;j++)
for(k=0;k < UBOUND_PROCLIST;k++)
return CallWindowProc((WNDPROC)OldWndProc, Hwnd, Message, wParam, lParam);
ListView can have multiple columns. Let's say I'm an evil malicious hacker dude that those guys at Microsoft always seem to be talking about. I now have my backdoor.exe which has created an AutoRun entry in the registry. Now, I want the entry to also be hidden. This is done as follows:
- Inject DLL into Regedit.exe
- Intercept the
- Search through ALL columns and rows to find
- If found, delete the entire row.
- Call the default procedure.
- Does not affect console programs (because they don't have message queue's)
- Any program can "detect" files, if we are actively looking for them. Assuming the user doesn't know he's been compromised, then he'll never look for the file.
- Controls created prior to hooking are unaffected.
Q : Why WM_PAINT?
A : I tried to monitor all messages that were sent to
SysListView32 and the only common message that was sent to Explorer.exe, Taskmgr.exe, and Regedit.exe was
WM_PAINT. There are other messages, but they are not consistent with all the applications
Q : In Explorer, there's an empty space where the icon (for the stealthed file) was supposed to fall. What's with that?
A : I'm guessing that the positions are assigned before
WM_PAINT is called, so when we filter the result, the space is already allocated for the icon. I guess if we intercept another message this could be fixed, but I haven't tried any.
Q : What is its Purpose?
A : Unfortunately, the only purpose I can tell you, involves malicious applications, but I hope something good can come out of it.
Q : Hey,I can see the stealthed files using
cmd. Can you implement a method that works for them?
A : It can be implemented, but we'll have to redirect
StdError using pipes, but that's a story for another time. Who knows, if I get the time I will do it.
Q : It doesn't work on my system?
A : As of now, I have tested it out on my system which is Windows 2000 SP4. If it doesn't work on your system please report it, so that the article can be corrected.
Q : It's a DLL, how do i execute it?
A : You could write your own loader, but I have enclosed a small DLL tester written in VB just in case. Once Loaded, the DLL will establish a
CallWnd hook. You can customize it for your own needs.
- The processes to hide are hardcoded. To make it more flexible you can use ini-files to check filenames.
- You can prevent the DLL from injecting itself into certain processes by matching
g_exePath with the filename (say explorer.exe)
- More notes can be found in the source code comments.
- 17 Feb 08 : Original Draft