When malware meets rootkits

2005-12-01

Elia Florio

Symantec Security Response, Ireland
Editor: Helen Martin

Abstract

Elia Florio takes a detailed look at the rootkit technique known as 'DKOM using \Device\PhysicalMemory'


Introduction

There was a time when Windows rootkits were just stand-alone applications, but today it's very common to find advanced rootkit technologies used in worms and Trojans – and sometimes even in non-malicious programs. Although Windows rootkits were introduced only a few years ago, the number of programs that currently use stealth technology, or that will use it in the future, is growing very quickly, sometimes with unexpected consequences.

The art of hiding expressed in many form

This article will not cover all the techniques of rootkits, since the topic is huge. For information on rootkits and how they work on Windows operating systems, refer to [1].

This article deals only with a specific rootkit technique known as 'DKOM using \Device\PhysicalMemory'. This technique was observed recently in the worm W32/Fanbot.A@mm [2], which spread worldwide in October 2005. The article will also present some data on rootkit usage in malicious threats.

Rootkits are usually divided into two categories: user-mode rootkits that work in Ring3 mode, and kernel-mode rootkits that operate in Ring0. The latter represents a more sophisticated piece of code, which requires a lot of programming knowledge and familiarity with the Windows kernel.

Kernel-mode techniques are very powerful and the most advanced rootkits are able to subvert the Windows kernel [3] and hide files, folders, registry keys, ports and processes. This type of rootkit needs to operate as a system driver to manipulate the kernel because this interaction requires Ring0 privileges, which are not available for normal executables in userland space.

The major drawback of this implementation is that the rootkit always comes with two different binaries (one SYS driver and one EXE that installs the driver) and this fact raises some barriers to the practical integration of this type of threat into real applications. Even if the SYS driver can hide everything (including itself), it needs to keep static structures installed in kernel memory which can be detected [4]. Moreover, the installation process requires interaction with the Windows Service Control Manager (SCM), or alternatively the undocumented API ZwSetSystemInformation. Both methods can create some evidence of the threat's presence or can be blocked during the installation phase.

Ghost process in the system

For these reasons, the next generation of rootkits started to approach the Windows kernel in a different way, avoiding the need for a SYS driver and system hooks. This goal is achieved by mixing the idea introduced by the FU rootkit (known as DKOM, Direct Kernel Object Manipulation) with another technique that involves the manipulation of the \Device\PhysicalMemory object and does not require any additional driver. The method of 'playing' with the physical memory object was imported from the Linux world, where another (in)famous rootkit known as 'SucKIT' [5] is gaining a lot of popularity.

DKOM rootkits are able to manipulate kernel structures and can hide processes and ports, change privileges, and fool the Windows event viewer without many problems. This type of rootkit hides processes by manipulating the list of active processes of the operating system, changing data inside the EPROCESS structures. This method is well documented and was first implemented by the FU rootkit [6].

Essentially, the Windows operating system maintains two different lists of all process and thread information (PID, name, token, etc.). Every process has an associated EPROCESS structure, which is linked to the previous and the following process (double-linked list) using some pointers. Figure 1 shows, with a simplified diagram, how EPROCESS structures are interconnected.

Windows EPROCESS structures are connected to each other by a double-linked list

Figure 1. Windows EPROCESS structures are connected to each other by a double-linked list

However, many people don't realise that processes don't run; only threads run. The Windows operating system uses a pre-emptive, priority-based, round-robin method of scheduling threads, swapping the active status from one thread to another (process structures are not involved in the switch).

To hide a process the DKOM rootkit simply unlinks it from the list, linking its previous process with the next one. It's just a swap of a few pointers

Figure 2. To hide a process the DKOM rootkit simply unlinks it from the list, linking its previous process with the next one. It's just a swap of a few pointers

Considering this fact, DKOM rootkits exploit a very simple trick: they unlink their own EPROCESS from this list, connecting the pointers of the previous and of the next EPROCESS in a way that will skip the 'ghost' process.

With this simple change, a process becomes invisible to the task manager and other common process manager tools, but it still runs in the system as all its threads are still active. Only advanced tools (e.g. KProcCheck [7]) can detect the presence of the hidden process by traversing the handle table list or the scheduler thread list.

This kind of threat (DKOM rootkit that uses \Device\PhysicalMemory) is quite hard to code because it requires the following abilities:

  1. The ability to obtain read/write access to the \Device\PhysicalMemory object.

  2. The ability to manipulate the EPROCESS/ETHREAD structure correctly (these structures differ greatly between Windows 2000, XP and 2003).

  3. The ability to locate the 'System' process in kernel memory and patch it.

  4. The ability to translate the virtual address of a process to a physical address in memory.

While there have been good examples of the first three steps [8] in the past, the last step is the most difficult as the Windows addressing scheme is based on a complex layer of multiple arrays. Contiguous virtual addresses of a process may have different physical addresses mapped into kernel memory [9].

Worms using \Device\PhysicalMemory

It was surprising to find a practical (and well-written) implementation of this rootkit technique inside the W32/Fanbot.A@mm code. W32/Fanbot.A is not the only worm that uses the DKOM and \Device\PhysicalMemory technique. The first worm that tried to achieve this was W32/Myfip.H. However, the routine observed in this worm was a little buggy and did not work well under XP and 2003 systems as it used a simplified memory model (the trick introduced in [8]) to map logical addresses to physical addresses.

W32/Myfip.H tried to 'emulate' the kernel API MmGetPhysicalAddress by checking if the virtual address was in the range (0x80000000 – 0xA0000000) and applying to it an AND mask of 0x1FFFF000. However, MmGetPhysicalAddress changes a lot from Windows 2000 to XP, so the correct way to translate the virtual address is to use the page tables of the specific process that owns the virtual address to be translated.

The Myfip.H variant implemented a DKOM routine patching physical memory object, but it uses a simplified translation algorithm for addresses

Figure 3. The Myfip.H variant implemented a DKOM routine patching physical memory object, but it uses a simplified translation algorithm for addresses

Instead, W32/Fanbot.A implements a good algorithm for address translation that considers the Page Directory and the Page Table (including tests for large pages). It also follows all the basic memory management rules: it extracts PDindex from the virtual address, gets the correct PDE, locates the corresponding PTE, and finally calculates the correct physical address. The only limitation of the W32/Fanbot.A code is that it does not work on Windows versions with PAE (Page Address Extension), because it makes the assumption of four-byte entries for PD and PT.

A closer look at the rootkit code userd by fanbot

W32/Fanbot.A@mm is a worm that has all the typical mass-mailing techniques. This variant comes packed with NsPack and installs itself as a service. It can spread by email, copy itself into P2P folders, and exploit the universal plug-and-play vulnerability (MS05-039).

Once unpacked (276 KB of code), it's possible to locate the DKOM routine by searching for the unicode string '\Device\PhysicalMemory' and tracing its reference back to the virtual address 0x40F8A5, where the rootkit code begins. The nice thing (for malware writers) is that the rootkit routine of the worm is written in a modular way so that it can easily be extracted and reused in any other malware.

First, the worm loads the NTDLL.DLL library and gets the APIs that are necessary to operate (RtlInitUnicodeString and ZwOpenSection).

Next, it checks the OS version and uses an interesting technique to locate the PDB (Page Directory Base) of the 'System' process. DKOM rootkits need to locate the System process in order to get its PDB (which is necessary for physical address translation). For example, the FU rootkit tries to locate System by iterating all the EPROCESS structures and looking for the 'System' string in the name. Other rootkits find the System process by checking UniqueProcessID, because on Microsoft systems the following assumption is usually true:

  • Windows NT / 2000 => 'System' PID = 8

  • Windows XP / 2003 => 'System' PID = 4

However, W32/Fanbot.A uses a completely different method: it does not scan for a string or PID – it only checks the OS version and locates the PDB of the System process directly using one of the following offsets (as explained in [10]):

  • Windows 2000 => 'System' PDB = 0x30000

  • Windows XP => 'System' PDB = 0x39000

At this stage the worm is ready to open '\Device\PhysicalMemory' using ZwOpenSection. If it fails (usually because the current user has no rights to manipulate this object) then it uses the trick (described by Crazylord in [8]) of changing ACLs (adding Read/Write permissions) for the physical memory.

The rootkit routine of W32/Fanbot.A worm is able to work under Windows 2000 and XP, as it knows all the correct offsets of several kernel structures

Figure 4. The rootkit routine of W32/Fanbot.A worm is able to work under Windows 2000 and XP, as it knows all the correct offsets of several kernel structures

Once the worm has located the System page directory, it reads the PDB from memory and keeps a copy of it for all the address translations. The rootkit routine follows this procedure:

  1. Locate the current running ETHREAD structure at 0xFFDFF124 (FS:0x124).

  2. From ETHREAD jump to EPROCESS, using the pointer at offset 0x44 of the structure.

  3. Read FLINK and BLINK from ActiveProcessLinks of the current EPROCESS structure (these offsets change from 2000 to XP).

  4. Unlink the current EPROCESS from the ActiveProcessLinks list by connecting the previous process with the next one (just a swap of a few DWORDS!).

The Fanbot worm works under Windows 2000 and XP because the author implemented all the necessary checks for different OS versions, and because it uses the right offsets to handle the EPROCESS structures correctly, according to the following table:

 Windows 2000Windows XP WindowsWindows 2003
PID offset 0x94 0x9C 0x84
FLINK offset 0xA0 0x88 0x88
BLINK offset 0xA4 0x8C 0x8C

Table 1. Some important offsets of the EPROCESS structure that change for different Windows versions

After the end of the rootkit routine, the worm executable is completely hidden and disappears from the process list.

Rootkit technologies in the wild

The recent Sony digital rights management case is evidence of how mature rootkit technology has become a commercial entity (11 and p.11). This rootkit has caused general consumer uproar as can be seen simply on Amazon's feedback pages for several Sony CDs that ship with the rootkit (see http://www.amazon.com/).

NameThreat CategoryRootkit Characteristics
  Worm/Virus Backdoor/Trojan Adware/Spyware DLL/IAT hooking SDT/IDT hooking DKOM Use SYS driver Use "PhysicalMemory"
Adware/Elitebar     X X        
Adware/CommonName     X   X   X  
Spyware/Search     X   X   X  
Spyware/ElpowKeylogger     X   X   X  
Spyware/Apropos.C     X X X   X  
Backdoor/Greybird (fam.)   X   X X   X  
Backdoor/Haxdoor (fam.)   X     X   X  
Backdoor/Darkmoon (fam.)   X     X   X  
Backdoor/Berbew (fam.)   X   X X   X  
Trojan/Drivus   X     X   X  
PWSteal/Raidys   X     X   X  
W32/Spybot.NLX X       X   X  
W32/Theais.A@mm X     X        
W32/Tdiserv.A X       X   X  
W32/Mytob.AR@mm X       X   X  
W32/Loxbot.A@mm X       X   X  
W32/Myfib.H@mm X         X   X
W32/Fanbot.A@mm X         X   X

Table 2. List of malware and security risks that use rootkit techniques to hide files, processes or registry keys. In some cases it is possible to observe completely different rootkit techniques used by variants of the same family (e.g. Backdoor/Graybird). Some malware, like W32/Loxbot.A@mm, contain a modified copy of FU rootkit (msdirectx.sys) embedded in their code.

But if rootkits have gained this much popularity in the software industry, what's been happening in the 'malware industry’? A process of rootkit integration has already started and many examples of different rootkit techniques can be seen in Trojans, worms, and now also in spyware and adware programs. Malware writers have learned the lesson and they know that the hardest enemy to fight is the one that nobody can see!

Bibliography

[1] Patrick Runald, 'The trouble with rootkits' Virus Bulletin September 2005, p.4

[3] Greg Hoglund and Jamie Butler, Rootkits: Subverting the Windows Kernel, Addison-Wesley Professional, 2005

[4] 'modGREPER', a hidden module detector created by Joanna Rutkowska, http://invisiblethings.org/tools/modGREPER/modGREPER-0.2-bin.zip.

[5] Sd and Devik, ‘Linux on-the-fly kernel patching without LKM’, Phrack #58, Article 7, http://www.phrack.org/show.php?p=58&a=7.

[7] 'Win2K Kernel Hidden Process/Module Checker' KprocCheck by SIG^2 http://www.security.org.sg/code/kproccheck.html.

[8] Crazylord, 'Playing with Windows /dev/(k)mem', Phrack #58, Article 16, http://www.phrack.org/show.php?p=59&a=16.

[9] Pankaj Garg, 'Windows Memory Management', http://www.intellectualheaven.com/Articles/WinMM.pdf.

[10] Mark Russinovich and David Solomon, Microsoft Windows Internals, Fourth Edition, Microsoft Press, 2004.

[11] XCP (eXtended Copy Protection), the digital audio protection used by Sony which makes use of rootkit technology http://www.xcp-aurora.com/.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

VB2018 paper: Uncovering the wholesale industry of social media fraud: from botnets to bulk reseller panels

In this paper GoSecure researchers Masarah Paquet-Clouston and Olivier Bilodeau explore an undocumented segment of the social media fraud (SMF) industry: wholesaling, from botnet supply operations to bulk reselling.

VB2018 paper: Now you see it, now you don't: wipers in the wild

There has recently been a trend of APT campaigns including a 'wiper' functionality to destroy data, either as a means to remove evidence or as its core purpose. This paper examines three different classifications of wipers through examples of various…

VB2018 paper: Who wasn’t responsible for Olympic Destroyer

Paul Rascagnères & Warren Mercer present the malware that they have identified – with moderate confidence – as having been used in the attack against the 2018 Winter Olympic Games. They describe the malware’s propagation techniques and its…

VB2018 paper: From drive-by download to drive-by mining: understanding the new paradigm

Jérôme Segura discusses the rise of drive-by cryptocurrency mining, explaining how it works and putting it in the broader context of changes in the cybercrime landscape.

The dark side of WebAssembly

The WebAssembly (Wasm) format rose to prominence recently when it was used for cryptocurrency mining in browsers. This opened a Pandora’s box of potential malicious uses of Wasm. In this paper Aishwarya Lonkar & Siddhesh Chandrayan walk through some…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.