north security labs blog

The Case of Maximus (Mebroot-based) Bootkit

2011-12-10T12:30:00.019Z

The next guinea pig is Maximus bootkit based on notorious Mebroot/Sinowal/MaosBoot. This bootkit is dated by 2008. Its dropper waits some time (about a hour) to complete installation. Then it reboots the computer. It refuses to work on our Windows 7 test system, but perfectly works on Windows Server 2003. Let’s start Hypersight Rootkit Detector’s monitoring on the infected system:

We see about 40...60 “stealth code” events. This tells us about a relatively big code base of the rootkit.

There are some typical code pieces of this rootkit shown below.

The code called by patched call of tcpip!IPRcvPacket:

The hooked IRP_MJ_WRITE callback of disk.sys:

The code called from ndis.sys driver:

And finally, the piece of the bootkit’s image in the memory (“MaOS” is a signature typical for Mebroot bootkits):

Mebroot bootkit places its body into nonpaged pool beyond the code of kernel-mode modules. This helps to avoid detection by anti-viruses and software-based rootkit detectors. But it fails to hide from hypervisors.

The Case of AllInOne (Nailuj) Rootkit

2011-12-09T17:06:00.025Z

We continue writing about detection of various rootkits by Hypersight Rootkit Detector. Today we will test the AllInOne rootkit aka Trojan.Nailuj.A.
This is relatively old rootkit and it does not work properly in Windows Vista and Windows 7 (bugcheck 0x7E SYSTEM_THREAD_EXCEPTION_NOT_HANDLED).

However it installs correctly on Windows Server 2003. It drops the file VideoAti0.sys into %WINDIR%\system32\drivers directory. After rebooting it makes files of the dropper and the driver invisible.
Let’s start monitoring of Hypersight when rootkit has become invisible. We will see “Stealth Code Executed” activity:

The rootkit’s stealth code looks like

As we can see from return address on the stack, this is a IRP hook procedure.
ESI points to the DRIVER_OBJECT and EAX contains the number of IRP major function (IRP handlers are called by the opcode CALL [ESI + EAX * 4 + 0x38] in Windows Server 2003).

Where the stealth code is resided? To determine this, let's look at the list of kernel modules:

As we can see, the code is resided between two modules. We can conclude this is a code of driver, which is hidden by excluding from the list of drivers.

Finally, we can look at the dump of code page for each event to recover the rootkit's image in the memory:

That's all for today. Good luck with discovering new rootkits.

Release of Hypersight Rootkit Detector

2011-11-17T20:39:00.009Z

Greetings to all, we have great news. Hypersight Rootkit Detector is released. It is the first publicly available virtualization-based detector of kernel-mode rootkits for Windows NT.

The huge work is completed, and the product is ready for shipping. We would like to thank all people who helped us with advices, criticism and testing.

The purpose of Hypersight RD is monitoring the Windows kernel against the following malicious events:

Hypervisor-Like Activity. Attempts to start hypervisor (enter virtualization root mode) by kernel-mode code. This activity is blocked. Hypervisors cannot be started when monitoring is active.
Suspicious CPU Activity. Rootkits often change control registers. Mostly this is clearing the "write-protect" bit of CR0 register for subsequent modifying of write-protected code.
In-Memory Code Modifications. This is modifying of non-paged code of drivers, Windows kernel and HAL. SSDT modifications fall in this category as well (SSDT is located in the code section of the NT kernel). Both direct modifications (with CR0.WP clearing) and modifications with remapping (MmMapLockedPages) are intercepted.
Stealth Code. This is the favorite trick of rootkit writers: to execute code outside of drivers and kernel. Traditional rootkit detectors are unable to find such code in the general case.

These kinds of activity are typical for rootkits. Their interception reduces the scope for rootkit creators. It is still possible to write undetectable rootkit but with Hypersight this becomes a challenging task.

The activity is reported inside of the main window of Hypersight. A detailed description is provided for each intercepted event: CPU state, code, stack and list of kernel modules. Usually this information is enough to identify the threat.

Hypersight currently has the following requirements:

OS: Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 (x86 only for all systems)
Memory: 1GB minimum, 2GB recommended
Processors: Intel Core i3, i5, i7

Hypersight is a shareware. Evaluation period is 15 days. Each registered customer gets two years of support, which includes:

Consulting on events intercepted by program
Free updates of the application

The program is intended for technically advanced people who want to know what exactly happens in their computers. This knowledge helps to prevent negative consequences of targeted attacks and malware infections.

Anti-Virus Emulation Engine

2011-08-18T18:13:00.002+01:00

Hi all, we have a new product for your attention. Anti-Virus Emulation Engine (AVE Engine) is a fast and small emulator of Win32 platform for anti-malware purposes.

The emulator takes a Win32 binary (EXE or DLL) at input and executes it in virtual Win32 user-mode environment. In particular it emulates a subset of API functions necessary for unpacking.

Three aspects were taken into account during development: simplicity, correctness and performance.

Architecture of the emulator is simple and transparent. The emulator has been written in pure C, codebase size is approximate 20000 LOC. The code is easily portable to different platforms. Currently emulator works on Windows x86 and Linux x86 platforms. We are planning to add more supported platforms (Windows x64, Linux x86-64, Mac OS X x86/x86-64).

The emulator correctly handles complex issues of Win32 emulation: exception handling, SEH emulation, support of undocumented platform's features. It is resistant to anti-debugging and anti-emulation techniques. Currently it supports unpacking of PE executables packed with UPX, ASPack, MEW, FSG, PECompact, NSPack, WinUpack packers. Private packers used by malwares are unpacked as well.

AVE Engine uses dynamic translation technique to accelerating the emulation. Speed of emulation is high due to aggressive optimization of translated code. Memory footprint is small (1...2 MB for typical executable with size about 200...300KB).

Interface of the engine is simple and flexible. It allows setting time limit of emulation and tuning event filters. Event handlers can read code and data from emulated memory for subsequent analysis.

Emulator can be used:
- In anti-virus scanners for unpacking and heuristic analyzing of executable files
- In malware classification systems for obtaining relevant information for classification

We offer AVE Engine to researchers and anti-virus developers on terms of commercial license. Two licensing options are available: binary and source license. If you are interested in details, feel free to contact us via sales at northsecuritylabs.com. The offer is limited due to specifics of the product. We will give preference to companies working in the field of information security.

The Case of TDL3 Rootkit

2010-07-03T15:42:00.052+01:00

Let us check out the new facilities of Hypersight Rootkit Detector using a sample of TDL3 rootkit. This epic rootkit was a nightmare for virus analysts recently.

Testing environment: Windows 2003 SP2 system, Intel Core 2 Duo E6700 processor. The initial conditions of the test: Hypersight RD 1.0.1233.5523 beta is installed, PC has been rebooted and “Start” button is pressed inside of the UI.

After starting the sample we can see that Hypersight has found covert code execution on the processor.

Covert code detected by Hypersight

We can observe several events. Each event is the execution of covert code on a single page (pages are 4096 bytes long in IA32/IA32e architecture). After pressing “Save All” button we can save the rootkit’s profile of execution to the compresed binary dump. Also we can press “View Dump” button and view each event dump in the separate window. Each dump contains couple of memory regions with the code and the stack, processor state and loaded kernel modules at the moment of event occurring. The format of event dumps is open. We will publish open source tool for decoding dumps soon.

Dump of code launched from TDL3 dropper

If you have reverse engineering skills, you can check out the stack for return address and see that the code has been launched from the newly loaded kernel module (3.tmp).

Another typical dump: a hook installed on IRP callback. In this case, one of registers in the dump usually points to driver object (DRIVER_OBJECT) MajorFunction callback of which has been hooked.

Dump of IRP hook installed by TDL3. ESI points to DRIVER_OBJECT structure

For sure, TDL3 is not the only rootkit which can be detected and analyzed. Hypersight Rootkit Detector provides generic detection of kernel mode rootkits. We'll keep you in touch with the information of all the other rootkits as soon as we have more details.

Detection of Rootkits: the Next Step

2010-07-03T15:37:00.004+01:00

Everyone knows what a great challenge are modern rootkits. Millions of computers worldwide are infected with rootkit-based bots. Modern anti-virus and anti-rootkit solutions are useless to detect most of them. The common approach in recent years is the development of particular solutions detecting certain versions of some rootkit. Typically, these solutions do not work after the appearance of a new version of the rootkit.

Our company has conducted extensive research in the field of rootkit detection past 3 years. We concluded that the detection of rootkits is possible using virtualization technologies. The recent hardware virtualization technology Intel VT-x and AMD-V have facilitated this task.

We have designed Hypersight Rootkit Detector. It was the first Windows-based solution of this class. The first version of the program could intercept only a few actions, typical for rootkits: modification of control registers, modification of executable code, turning hardware virtualization on. It makes possible to detect many types of rootkits. Nevertheless, this was not enough. Detouring these interceptions was still possible from the rootkit side.

Now we are proposing a more generic criterion for detection of rootkits. For all rootkits, regardless of the technologies used (SSDT hooking, DKOM, DKOH, Shadow Walker, splicing), there is one common trait. They are executed on the processor. We have implemented the algorithm which performs basic checks on the code prior its execution. The technology was named Fast Code Test (FCT). The code executed at the privileged level, subjected to a number of basic checks. If checks fail, notification about undesirable activity is generated.

Currently, checks are quite simple. The code running outside of loaded drivers, kernel and HAL is considered as suspicious. This approach makes possible to detect the absolute majority of the currently known rootkits. Recent rootkits tend to run “covert” code in kernel non-paged pool in order to avoid detection by memory scanning. This is the activity detected by FCT.

Signature scanning and code whitelisting will be the further steps in the development of Fast Code Test.

Fast Code Test significantly complicates the task of writing "undetectable" rootkit. We plan to develop this technology in terms of productivity and efficiency. We hope it will help people to analyze new rootkits faster and more efficiently.

Catching Blue Pill

2008-06-22T23:23:00.016+01:00

HVT-based rootkits became a new headache for anti-malware vendors since their appearance in 2006. There are no working HVT rootkits yet (only PoC implementations), but who knows what happens later? It is possible (not easy though) to create a HVT rootkit with extra functions such as keylogging, HDD access, network communication or traffic interception. Plenty of helpful source codes are available for a rootkit creator (such as open source hardware drivers, open source operating systems etc). VT-based rootkits are very hard to detect when they are already installed. Moreover, no existing anti-malware product is capable of preventing a VT-based rootkit from installing.

So what is the solution? It is possible to detect HVT rootkits by monitoring indirect results of their activity. The advantages and disadvantages of this approach are well described in Joanna Rutkowska’s articles. The methods described are not generic and can be cheated by a rootkit (e.g. Blue Chicken method). Furthermore, they don't allow unambiguos detection of a rootkit since they don't give any access to the rootkit’s body.

We have found another approach. Here is its brief description.
The idea is to intercept a hypervisor's start by another hypervisor (let’s call the latter a Virtual Intrusion Prevention System, or VIPS). When any hypervisor (malicious or legitimate) starts, it turns VM root mode on. This event can be easily intercepted by a VIPS. So what's next? There are 2 ways to handle this event: blocking a hypervisor completely, or allowing it to work through emulation.

The first way consists in emulating a PC with disabled HVT feature in BIOS. This will block a HVT rootkit from working.

The second way consists in allowing a hypervisor to work through emulated hardware virtualization (or nesting). This should be done for legitimate virtualization software.

In both cases (blocking or emulating), a VIPS intercepts a hypervisor at the moment it tries to start. VIPS can read the hypervisor’s body and analyze it. A notification message can be shown.

At present only the first case is implemented - preventing a hypervisor's start. The second case is currently in development. We hope it to be ready soon.
To check the new feature of the Hypersight Rootkit Detector, we have used the CHKSVMX tool from Invisible Things Lab. When we run CHKSVMX on a PC with installed Hypersight RD, a message from HRD appears that a hypervisor’s start has been blocked. CHKSVMX tool also reports a disabled HVT feature (see images below).

Detecting and blocking hypervisor on Intel VT-x

Detecting and blocking hypervisor on AMD-V

We didn’t test the new HRD feature with the Blue Pill because the Blue Pill is currently implemented on x64 platform only. When we create a x64 version of Hypersight, it will be detecting the Blue Pill as well. The opportunity to catch a Blue Pill does exist and we have proven it.

The approach described can be successfully implemented in anti-malware software to achieve HVT rootkits blocking. It can also be integrated with virtualization software. The real BP stopping aproach can demotivate malware creators from exploring the area of HVT rootkits (mind that the creation of a full-scale HVT rootkit is a big challenge comparable to development of a mini-OS).

Detecting and blocking Shadow Walker

2008-01-27T00:30:00.000Z

Recently we got a sample of code that conceals itself in the memory by modifying the page table (a technology known as Shadow Walker). Shadow Walker is based on the fact that Intel IA-32 CPUs have 2 address-translation caches: for code pages (ITLB) and for data pages (DTLB). It works like this. A page fault handler (int 0x0e) is intercepted, and then the pages of concealed code in the page table are marked as missing pages. After that, any attempts to access those pages for read, write or execute lead to page faults. The page fault handler checks requested access to page: either execution or access to data. In the case of execution, the handler loads ITLB with a original code page. In the case of access to data, the handler loads DTLB with a fake page. Thus, using desynchronization of ITLB and DTLB, Shadow Walker conceals its presence in the memory.

We tried to run Shadow Walker on a computer with installed Hypersight RD 0.3.543.

Test 1. Detecting

In this test Hypersight RD worked with the default settings. By these settings, modifications of the page table are allowed and recorded. After running Shadow Walker we noticed the window Hypersight RD had started to scroll messages on writing to page table. Hypersight RD window had been looked as follows.

The figure shows that a code that doesn’t belong to any of the kernel modules, writes to the page table. This activity is performed by the page fault handler, marking concealed pages as present or absent when loading them to TLB.

Test 2. Blocking

For this test we have turned on the option "Disable page table modification (unsafe)". This option turns on blocking of the page table modification by untrusted code.

Then Shadow Walker was loaded. Hypersight RD window had taken the following form.

You can see that Hypersight RD blocked Shadow Walker’s attempts to modify the page table. Subsequent work of Shadow Walker became impossible since Shadow Walker was unable to mark pages of code as missing. Thus, the Shadow Walker had been completely blocked.

Renaming

2007-12-11T00:04:00.000Z

We have renamed our product code-named Raidho Rootkit Detector to Hypersight Rootkit Detector. Web site is coming soon.

Raidho Rootkit Detector 0.1 alpha

2007-11-19T16:04:00.000Z

We have designed Raidho Rootkit Detector 0.1 alpha. It works on CPUs with VT-x technology supported. Program detects presence of Rustock rootkit by intercepting its attempts to patch the kernel code.

Let's begin

2007-11-13T19:23:00.000Z

Okay, now we started this blog. All information about our future projects will be posted here.