The Case of Maximus (Mebroot-based) Bootkit

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

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

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

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.