Rotten to the core…A Roundup on Rootkits

December 11, 2012, by | Start Discussion

Rootkit is a common word in Computer Security. A word often spoken to describe a bad, vary bad type of malware.

A rootkit is a program that can be installed and hidden on a computer without the knowledge of its user. It can be included in a larger software package, or installed by successfully exploit vulnerabilities or by convincing the victim to execute it by a phishing email.

Generally, books and magazines talk about rootkits, but do not go deep in the description them. The argument is quite complex and requires a dose of programming skills to be completely understood.

Our intention is to approach the matter in a “friendly way” in order to offer a vision of the whole picture even to a reader without programming knowledge… So keep your seatbelt fastened, we are flying to the rootkit land.

Rootkit Evolution

Rootkits became known to the world at the end of the last century. The purpose of the rootkit, at time, was to conceal additional programs that would allow an attacker to “sniff” or spy on the traffic to and from a computer.
They earned the name “rootkits” because they were mainly used on Unix derived computer systems where the top-level administrative account is called “root”. Thus to “root” a system is to obtain top-level administrative privileges and hence obtain full control of the system.

Later, however, this kind of tools has grown in sophistication, changing its targets.

Windows users have become the primary targets, and the Rootkits have escalated the cybercriminal world.

Today rootkits have improved immensely to the point that many of them are now much difficult to detect. Some are now “all-in-one” malware with a large number of features. Additionally, many current rootkits have the ability to capture sensitive information and to help cybercriminals create and manage gigantic botnets.

These botnets can then be used in a variety of ways, including spam forwarding and extortion. In the evolution, rootkits functionality, infection strategies and persistence mechanisms have changed greatly. However, the core purpose remains to assume full control of the machine by downloading additional malware.

Rootkits, today, appear as very flexible malware. This flexibility is evident by looking at the features they have inherited by other classes of malware, such as Loggers, Trojans and Stealers.

Traditionally rootkits were not necessarily malicious per se; they hid other illegal activities, but were limited in their deployment by the adoption of a multistage infection: first rootkit, then the Trojan or the Keylogger.

Today, instead, attacker may be able to access information, monitor actions, modify programs, or inject other types of malware through the Rootkit.

In some circumstances, rootkits today can be mistaken for Trojan Horses. Technically rootkits are not Trojans but their level of functionality is now equal (or better), and when an attacker has no special needs, rootkits can be used for the same purpose.

The latest rootkits are now capable to subvert the memory of other applications running on the system, presenting the applications with a false view of the underlying system. This would effectively hide the rootkit from any antivirus scanning software.

To combat these threats, defenders have turned to the collection, analysis, and reverse engineering of malware as mechanisms to understand these programs, generate signatures, and facilitate cleanup of infected hosts.

Unfortunately, malware developers are perfectly informed about how a malware analyst works, what kind of tools he uses and which techniques are normally applied to check the system looking for malware.

During the times, malware writers have developed several techniques to divert and to avoid analysis of their “creatures” by the good-guys.

One of these techniques is the use of the so-called “antis”, a slang term to indicate a series of pieces of code used to detect and then evade the tools used by malware analysts, for example:

  • Anti-Sandbox
  • Anti-virtualization
  • Anti-antivirus

In the code snippet below (Snippet 1) we leave an example of an “antis”.

For these reasons, the analysis, in presence of a rootkit, should be performed in cycles trying to avoid false patterns or false discriminatory elements.

' anti sandboxie / cw sandox / vmware by t0fx
Private Declare Function GetWindowsDirectory Lib "kernel32" Alias "GetWindowsDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As Long
Private Function WindowsDirectory() As String  'get windows path
Dim Buff As String * 255
WindowsDirectory = Left$(Buff, GetWindowsDirectory(Buff, Len(Buff) + 1))
End Function
Private Function SystemDrive() As String 'get system drive letter
SystemDrive = Left$(WindowsDirectory(), 1)
End Function
Private Sub Form_Load()
If App.Path & App.EXEName & ".exe" = SystemDrive & ":sample.exe" Then
MsgBox "Caused exception at 0x44e85c", vbCritical, "CW sandbox"
End If
If fuckingprocesses("SandboxieRpcSs.exe") = True Then
MsgBox "Caused exception at 0x44e85c", vbCritical, "Sandboxie"
End If
If fuckingprocesses("SandboxieDcomLaunch.exe") = True Then
MsgBox "Caused exception at 0x44e85c", vbCritical, "Sandboxie"
End If
If fuckingprocesses("VMwareTray.exe") = True Then
MsgBox "Caused exception at 0x44e85c", vbCritical, "VMware"
End If
If fuckingprocesses("VMwareService.exe") = True Then
MsgBox "Caused exception at 0x44e85c", vbCritical, "VMware"
End If
If fuckingprocesses("VMwareUser.exe") = True Then
MsgBox "Caused exception at 0x44e85c", vbCritical, "VMware"
End If
End Sub

Snippet 1 – Example of “antis”

Rootkits Internals

The strength of rootkits is the ability to hide itself. In fact, it can become invisible to the user, application programs and the entire Operating System without losing its abilities.

To understand the basics of rootkits we introduce the concept of ring of protection. This concept is the baseline of the constitution of the modern x86 processors, the family of processors used in current systems. The architecture of modern operating systems is based on these concepts.

In x86 architecture, the protection rings (numbered 0–3) are simply privilege levels enforced by the CPU (and implemented by the OS) on executing code. Since all binary code, from operating system procedures to user applications, runs on the same processor(s), a mechanism exists to differentiate between system code and user code and restrict privileges accordingly.

Figure 1 – Rings

The OS executes at the highest privilege level, in Ring 0 (referred to as kernel mode or kernel land), whereas user programs and applications run in the lowest privilege level, Ring 3 (referred to as User Mode or Userland).

Since both user-mode and kernel-mode programs must utilize system memory to run, the memory spaces of the two are logically separated, and every page in memory is marked with the appropriate access mode the processor must be running in to use that memory page. User-mode programs must spend part of their life in kernel mode to perform various operations, so special processor instructions such as SYSENTER are used to make the transition. The operating system traps the instruction when it is used by a user-mode program and performs basic validation on the parameters being provided to the called function before allowing it to proceed at the higher-privileged processor access mode.

Kernel land is an extremely volatile environment where all executing code has equal privileges, access rights, and capabilities. Because memory address space is not separated, as implemented in processes in user mode, any program in kernel mode can access the memory, data, and stack of any other program (including that of the operating system itself). In fact, any component can register itself as a handler of any type of data—network traffic, keyboard strokes, file-system information, and so on, regardless of whether it needs access to that information. The only restriction: you have to “promise” to play by the rules. If you don’t, you will cause a conflict and crash the entire system.

This makes for a very convoluted and free-for-all environment. Anyone who knows the basic requirements and enough C (a programming language) to be dangerous can develop a kernel driver, load it, and start poking around.

Virtualization technologies has introduced new protection rings and thus new instruction sets has been added into the architecture. Essentially it was introduced a Ring –1 (ring negative one) that allows the hypervisor (in most cases, a sleek and minimal host OS) to monitor guest operating systems running in Ring 0, but not “true Ring 0” (thus they are not allowed to use actual hardware, but rather virtualized hardware). These new concepts have also led to significant advancement in rootkit technology, resulting in virtualized rootkits.

In general we can identify five types of rootkit, ranging from those at the lowest level in firmware (with the highest privileges), through to the least privileged user-based variants that operate in Ring 3.

  • User Mode – Rootkits run in Ring 3, along with other applications as user, rather than low-level system processes. They have a number of possible installation vectors to intercept and modify the standard behavior of application programming interfaces (APIs).
  • Kernel Mode – Run with the highest operating system privileges (Ring 0) by adding code or replacing portions of the core operating system, including both the kernel and associated device drivers.
  • Boot Kits – A kernel-mode rootkit variant called a bootkit is used predominantly to attack full disk encryption systems, for example as in the “Evil Maid Attack”, in which a bootkit replaces the legitimate boot loader with one controlled by an attacker; typically the malware loader persists through the transition to protected mode when the kernel has loaded.
  • Hypervisor Level – Rootkits have been created as Type II Hypervisors in academia as proofs of concept, by exploiting hardware virtualization features, this type of rootkit runs in Ring -1 and hosts the target operating system as a virtual machine, thereby enabling the rootkit to intercept hardware calls made by the original operating system.
  • Hardware/Firmware – A firmware rootkit uses device or platform firmware to create a persistent malware image in hardware, such as a network card, hard drive, or the system BIOS. The rootkit hides in firmware, because firmware is not usually inspected for code integrity.

Usually, when a rootkit infects a host, the workflow is structured as follows:

  • The infection vector allows for rootkit agent reaches victim’s system. (Drive-by-download, client side exploit or a dropper)
  • User-mode agent execution
  • Driver executable decryption and execution
  • System hiding from Kernel-mode.
  • Establishment on the host and Kernel-mode level monitoring/data-stealing.
  • Establishment of a covert data channel for network communications.

Rootkits Evolution

The earliest type of rootkit consists of replacement programs for commonly used administrative programs on the computer system. The replacement programs hide the activity of the actual payload from the system administrator. These kits are almost exclusive the Unix/Linux family of operating systems. These will be referred to as first generation rootkits.

The second generation of rootkits uses “hooks” to redirect application calls to operating system (kernel) functions.  The hook is used to intercept such legitimate function calls and reroute them to the rootkit’s own version of the function. They are more difficult to detect because they have moved a level closer to the kernel. Attackers then began to employ even more sophisticated techniques.

Third generation rootkits use techniques that go deeper into the system and modify dynamic data structures in the kernel, the main component of most computer operating systems.

Infection vectors for Rootkits are very similar to other high profile malware families currently circulating in the wild. Although not entirely comprehensive, the main distribution methods for rootkits can be split into two categories:

  1. Exploit Packs
  2. Social engineering

Another important aspect to consider is that the Rootkits are very small and subtle and they can sneak past organized defense without notice thanks to their proverbial ability to hide inside other processes or even inside the victim Kernel.

The rootkits studied here are very malicious so, in our attempt to uncover their behaviors and their innovative solutions to inject themselves in a victim System, our advisory will describe and compare them trying to offer a clear explanation “of the way the things are going” for all the different types of malware.

In this article we depict a series of rootkit representing the second and, the actual, third generation. These malwares have moved to massive deployment and have introduced important modification in their code or in their attacking mechanism. We present “real life” rootkits, caught in the wild and studied, as best example of the species:

  • HackDefender
  • TDSS/TDL/Alureon
  • ZeroAccess


HackerDefender, was created and released by Holy Father in 2006.

At time it became one of the most popular Windows rootkits and has remained one of the most significant piece of malware for Microsoft machines.

Main goal for its coder was to “write something new”: a userland rootkit easy to configure, to build and to use.
It is a persistent, user-mode rootkit that modifies several Windows and Native API functions, which allows it to hide processes, files, registry keys, system drivers and open ports from applications.

Despite the small size of its components, HackerDefender is a very complex piece of software so trying to describe its code and its functions is a complex matter that introduces discussion on methods used by rootkits such as Kernel Native API hooking, User Native API hooking, Dynamic Forking of Win32 EXE, Direct Kernel Object Manipulation, and Interrupt Descriptor Table hooking.

Latest version has introduced a strongest encryption system that makes the reverse a very complex matter.
The original HackerDefender rootkit consisted of two files: one executable file (.exe) and one configuration file (.ini).

The configuration file was used for defining all the settings for the rootkit.

The modern version is not dissimilar, but instead of using a clear text .ini file it uses a double hook, with a first driver (.dll) used for decryption of the real configuration file.

Figure 2 – Installation differences between original HackerDefender and modern version (2012)

Like most traditional rootkits, HackerDefender requires administrative privileges to install, this means to do some social engineering via “phish & scams”.

Once dropped and started the rootkit installs itself as a service that automatically starts at boot.

The actual behavior, in this way, is a replica of the older HackerDefender rootkit.

When launched, the executable creates a system driver (.sys) in the same directory as the executable, loads an encryption/decryption library (.dll) and then loads the configuration file (.ini) before activating its malicious functions.

It then installs permanently the driver and the library in an hidden folder (random) inside System32 directory and ensure its persistence by loading the driver to the following registry keys:

Additionally, HackerDefender makes sure it will be executed in safe mode by adding the following registry keys:

Hacker Defender allows the intruder to hide information from other user-mode applications. Criteria for the hidden items are defined in the configuration file. Following items can be hidden:

  • Files
  • Processes
  • Registry keys and values
  • System services and drivers
  • Allocated memory
  • Handles
  • Inbound and outbound TCP connections

HackerDefender hides information by modifying the execution path of several Windows and Native API functions. This allows it to alter data passing to and from the hooked function. The rootkit intercepts several system functions in the following libraries:

  • Ntdll.dll:
  • kernel32.dll:
  • AdvApi32.dll:
  • Ws2_32.dll:

In addition, Hacker Defender installs and loads a kernel-mode driver that implements two support functions utilized by the user-mode components. First, it adds system privileges into every process defined as a root process in the configuration file. Second, it helps the rootkit’s user-mode components to identify any handle pointing to a hidden object.

Figure 3– An apparently normal Task Manager in an infected HackerDefender Victim

At time (2006), the malware has generated a lot of hype in the underground, because it has demonstrated the reliability of this type of infection against the kernel, not bad for someone trying to “write something new…” alone.

Latest variant of HackerDefender (HacDef, or HxDef, like some Antivirus called it) is yet in-the-wild despite the high ratio of identification.


Rootkit.Win32.TDSS is a rootkit that can hide the presence of other malicious programs and provide escalation of privileges on an infected system.

It has recently evolved into “bootkit” and implements interesting attack mechanisms.

The Bootkits are an evolutionary path for the rootkit family that follows the trend of Builder Viruses (such as Zeus, Phoenix, MyWorm, etc …), malicious programs modularly “built” by the user through a GUI console before the spreading them.

This mechanism of malware “building” has become very popular among cyber criminals as the malware is easy to use and offers ample opportunity for dissemination. In addition, the ability of TDSS to work since System boot allows some resilience to the malware against removal.

To characterize in a more meaningful way, it should be noted that TDSS is being developed as a framework and is constantly updated and expanded with contributions of people from Eastern Europe but also from China and Latin America.

By default, the TDSS is a boot-rootkit with Trojan-clicker module, a module used to hijack the browser and to divert victim internet browsing to predetermined websites.

In the version we present, it uses a vulnerability to realize a privilege escalation in 32-bit and 64-bit Microsoft Operating Systems.

The vulnerability in question is Windows Task Scheduler Privilege Escalation .

This vulnerability was adopted also in Stuxnet malware.

The exploit allows TDSS to install itself on your system without any notification from the system’s security and protection tools such as Microsoft UAC (User Account Control).

After the launch of the rootkit in the system its process generates a filtered token with privileges “user”.

This process tries to inject the driver of the print spooler running a set of commands that, if does not complete, terminate with an error (ERROR_ACCESS_DENIED)

Figure 5- Malicious Dll recorded during the installation process (Stage 1)

The action, if successful, allow the attack to escalate against the system drivers and the installation of malware in specific areas such as the Master Boot Record.

Figure 5- Malicious Dll recorded during the installation process (Stage 1)

As mentioned above, the rootkit randomly chooses a system driver normally among those present in the folder:
->    %Windows%System32Drivers

It changes the resource section and use the link inserted to push the system to load a malicious dll.

At the same time it modifies the Master Boot Record (MBR) and uses the reserved areas to persist in the system.
It is interesting to note that the rootkit installer has a dedicated code that allows it to bypass certain security tools proactively. In fact, today some Antivirus hook function:
    NtConnectPort

to prevent malware such as TDSS and Stuxnet to inject their payload into spoolsrv.

The control made by Antivirus is based on the specific target port that is always:
->    RPC Controlspoolss

The default spooler’s file name.

When a process invokes the print spooler hooked to the default process name, the antivirus or anti-rootkit in the systems activates a preliminary inspection that, if the action is malicious, returns a notification allowing the user interaction and therefore the possibility of identifying the ongoing attack.

This implies that the process spools.exe is linked to the processes of inspection and therefore is active and connected.

The latest versions of TDSS4 have circumvented the problem by hooking the function ntdll.ZwConnectPort at the rootkit startup, verifying the value of the parameter: ServerPortName and when the result shows a result different from:
->    RPC Controlspoolss

this means, to the rootkit logics, the presence of an external element that could intercept the hook function to the spooler and manage it.

In this case the malware generates a symbolic link to the main directory of the spoolerss namespace bypassing the inspection by then calling the different function name for the spooler.

Figure 6- UnicodeStringCheck of ntdll.ZwConnectPort

To ensure its persistence, (by being loaded at Windows startup), TDSS rootkit uses to infect Windows system drivers.

TDSS checks the chain of drivers that handle hard drive I/O looking for last miniport driver object. When found, it infects driver’s PE file by overwriting 824 bytes of the resource section.

By doing so, it evades a simple check that some antirootkits usually use to detect hidden rootkits: file size cross check.

Usually rootkits that infect files can hide their presence by showing the original file instead of the infected one.
Antirootkits use raw disk reading techniques. They could read below the filter applied by traditional rootkits and could cross check file sizes looking for discrepancies.

TDSS could not be detected by file size cross check because file size of the original and infected files are exactly the same.

When the infected driver runs, it executes the 824 bytes loader which then runs the kernel mode component of the infection.

It creates a fake driver object, its relative device object, and hijacks every disk I/O communication at the level of drivers’s chain where the infected driver was located (i.e. infected driver could be atapi.sys, or iastor.sys).

Figure 7– TDSS I/O HD Driver Miniport Hijacker module

The rootkit intercepts every communication and filters out IRP_MJ_SCSI packets that have specific SRB flags set. By doing so, it hides patched driver on the disk and all disk sectors where its components are located. This is a really effective technique of disk hiding.

TDSS rootkit then sets up a Load Image notify routine to intercept every process that loads kernel32.dll library. When intercepted, it injects inside the specified process its user mode components of the infection, tdlwsp.dll, tdlcmd.dll. They are able to turn infected PC in a botnet’s zombie.

Config.ini, one of the components of the infection, contains settings of the botnet, commands to be executed, bot ID and C&C servers addresses.

Communication with C&C servers is SSL encrypted, to evade HTTP filters.

Figure 8– C&C for TDSS connection

TDSS rootkit is indeed a really worrying infection. Some antiviruses may throw up a warning about the presence of tdlcmd.dll or tdlwsp.dll, without being able to do anything.

Most of times users won’t be warned at all, they just don’t know their PC is part of a botnet and it is under the control of malware writers which can use their PC as they please.

The coders behind TDSS has shown a lot of skills by developing a rootkit to this level of complexity.

The ZeroAccess Rootkit Family

ZeroAccess malware family belongs to the Kernel Mode Rootkit category and is a dangerous threat that has been circulating for several years. During that time, ZeroAccess has seen a number of revisions, with modifications to its functionality, its infection strategy and its persistence mechanisms.

This rootkit is the youngest of this pool. It has been used as platform to deliver fake Anti Viruses or “Ransomwares” that locks the victim’s machine data and extorts money to release them. In this case the payload delivered is a bot that uses a p2p protocol in order to establish a connection towards other peers that acts as Command and Control (C&C).

Our probes have recently showed a proliferation of new variants appearing in the wild.

Despite its modification, the core purpose of the Rootkit has remained: to assume full control of the machine by adding it to the ZeroAccess botnet and to monetize the new asset by downloading additional malware.

As we said, ZeroAccess is a kernel-mode rootkit, similar to the TDSS (or TDL) family.

The followings are ZeroAccess key features:

  • It uses advanced techniques to hide its presence
  • Is capable of functioning on both 32 and 64-bit Windows Operating Systems from a single installer
  • Contains aggressive self defense functionality
  • And acts as a sophisticated delivery platform for other malware

The origins of this rootkit are dated in 2009.

Security researchers came across a rootkit able to kill most of security software as soon as they tried to scan specified folders in the system.

ZeroAccess was creating a new kernel device object called __max++>, this is the reason why the rootkit has quickly become known in the security field as the “max++” rootkit, also known as ZeroAccess due to a string found in the kernel driver code, presumably pointing to the original project folder called ZeroAccess:

This rootkit was storing its code in two Alternate Data Streams (ADS), win32k.sys:1 and win32k.sys:2. To avoid being detected, it kills every security software that attempted to scan for alternate data streams. It also created, in the system folder, a number of fake junctions (or reparse points or “Soft” Links) pointing to the fake rootkit device written above.

When security software tried to scan such specified folders for ADS presence (FileStreamInformationclass), the rootkit’s self-defense queued a work item in the security process able to immediately kill it. It became a non-trivial job scanning the system without being killed.

Note:an NTFS junction point is a feature of the NTFS file system that allows a folder to be linked to another local folder, becoming an alias for such target folder.

Other than this, ZeroAccess had the following capabilities:

  • Modern persistence hooks into the OS: it is very difficult to remove without damaging the host OS.
  • Ability to use a low level API calls to carve out new disk volumes totally hidden from the infected victim, making traditional disk forensics impossible or difficult.
  • Sophisticated and stealthy modification of resident system drivers to allow for kernel-mode delivery of malicious code.
  • Advanced Antivirus bypassing mechanisms.
  • Anti-Forensic Technolog: ZeroAccess uses low level disk and filesystem calls to defeat popular disk and in-memory forensics tools.
  • Serves as a stealthy platform for the retrieval and installation of other malicious crimeware programs.

Kernel level monitoring via Asynchronous Procedure Calls (APC) of all user-space and kernel-space processes and images, and ability to seamlessly inject code into any monitored image
At this point we can subdivide the infection into two main phases:

Phase I

It looks like the first phase of the infection aims to get a foothold on the victim machine as fast as possible.
This phase has definite characteristics that are associated with the ZeroAccess rootkit.

The malicious object that does actions in this phase is related with the initial dropper and then with a malicious tampered driver.

In the first phase the malware created a fake windows update directory in %SYSTEMROOT%:
->    C:WINDOWS$NtUninstallKB[random 5 digit]$

The name of the folder is randomly generated, for example $NtUninstallKB43041$, it presents a random 5 digit string at the end. This mimics a legit Windows Update installation folder in order to hide the rootkit presence into the system. Into this folder the malware saves all the files necessary to its functions and also uses this directory to store additional components such as other malwares and configuration files.

With this folder the dropper sets also an Alternate Data Stream resource. The data stream results to be an empty file. We know, that, in some versions, this feature should be a “bait” service used by the rootkit to defend itself. When a driver or an application is caught opening the ADS on that service, the process is killed. The fact that this stream is empty leads us to think that this functionality was deactivated.

Figure 9 – Alternate Data Stream

In addition, the malware protects the access to the folder by using the following mechanisms:

  1. Set “System” and “Hide” attributes, in order to hide the folder to Windows Explorer
  2. Set a reparse point (or symbolic link) to the C:WindowsSystem32config folder, in order to make the folder inaccessible to programs using standard Windows APIs. For example when a user clicks on the malicious folder it is redirected to the linked path. If the symlink directory is ignored and the full path is provided the encrypted files can also be accessed.  Figure 10– Symbolic Link
  3. Changes the Discretionary Access Control (DAC) grants to the folder in order to negate the access.

Figure 11 – DAC

This behavior is related to some variants of ZeroAccess.

Successively the malware creates a file with a name randomly generated.

The name is under the form of a string of ten numbers, in this case we have:
->    3362557451

The particularity of this file is that have a “Zero Byte” dimension. At this stage of the analysis we didn’t know what is the purpose of this file. Probably it is related to an abandoned feature. Even this file is protected with the creation of the symlink.

Figure 12- Zero Byte file

The next step is the creation of a subdirectory, of about nine or ten numbers, randomly generated. For example:
->    C:Windows$NtUninstallKB32445$594894280

This directory contains other two sub-folders, “U” and “L”, and two files:
->    @
->    Desktop.ini

Figure 13– Malware Generated Files and Folders

Not all files are created during this phase; in particular some files in the “U” folder are successively downloaded in the phase two, when the malware connects to the other botnet peers.

In the next step (for reference see figure 14, step 2), the dropper process chooses randomly a driver in the %systemroot%system32drivers folder and modifies it is startup data and imagepath into the Registry, in order to survive after reboot.

Then executes a remote thread injection into winlogon.exe. This is for load the driver into the kernel memory (Figure 14, step 4). The rootkit, once loaded in kernel memory, uses a proprietary disk I/O redirection framework.

This framework is used to control the access to the infected driver.

The registry modified values refers to a new service component named as the selected driver:
->    HKLMSYSTEMControlSet001services.<drivername>

In this case we have monitored that netbt.sys is the selected driver.

The values modified are:
->    Type data: 0x01
->    Start data: 0x03
->    ImagePath data: ?

This service refers to the randomly selected driver used that is injected by the dropper.

The selection of drivers to inject is always done into the C:WINDOWSSystem32drivers folder.

The above indicated values means that the driver is a kernel device driver (type 0x01) and it will be loaded on demand (0x03), probably by the infected winlogon.exe process.

This driver is overwritten with the malware data (Fig 14, step 3). The original driver is compressed and encrypted into the previously created “protected” folder, into the “L” directory (step 2):
->    C:Windows$NtUninstallKB32445$594894280Lxadqgnnk

The eight digits file into the folder is randomly generated (in this case xadqgnnk); this is the original driver compressed and encrypted.

The eight digits file into the folder is randomly generated (in this case xadqgnnk); this is the original driver compressed and encrypted.

Any attempt to read the infected driver would have to traverse the disk redirection, in which the rootkit on the fly decrypts the original file from its protected storage and presents the clean image, thus forging the view of the file to security tools.

Also, during a reboot the infected file would first load the malicious code in kernel, which can refer to its “protected” folder, and load the original file in kernel, thus ensuring the uninterrupted functionality of the original device.

Figure 14- Rootkit Operations

After this the selected driver was started and this ends the first phase, in facts the dropper process terminates itself.

Phase II

The second phase is related to the network communications of the bot and is much closer to the “Sirefef” infection. In this phase the operation are performed by the infected driver that controls the opening and closure of sockets at the Transport Drive Interface (TDI) level. The driver is the kernel-mode module of the infection.

This module then opened the file “@” that seems the key to the p2p communication system. According to other analysis this file shall be a binary data file containing a list of 256 peer IP addresses. The file is large exactly 2048 bytes, half of this are the IP addresses, the other half are a sort 4 bytes timestamp in order to record the last known IP address. In facts we noticed this file is opened and update after several times, during the infection.
The “@” file is structured in the following way (Fig 15): The first 4-tuple of bytes are IP addresses, the second 4-tuple is the timestamp. Then the third 4-tuple is an IP address and so on until the end of file.

Figure 15– Hex view of the “@“file

The difference we have noticed versus other analyses is that the IP addresses wrote on the @ file doesn’t have any match with the ones captured by our packet sniffer. We didn’t investigate this anomaly more in deep, but we think that probably such kind of obfuscation has been added to this file.

However, we can argue that the malware went through this list attempting to connect to each one. Once a connection was established, it sends some obfuscated commands to retrieve the peer’s contact list and updated its own list in the @ file. It continued to do this for all peers that accepted the connection. It reconnected to the first peer to respond and sends other encrypted commands to download and execute additional files.

These additional files were stored in the U subdirectory. These files are also encrypted and may be related to additional malware. We still are investigating on the obfuscation algorithm.

Figure 16– Additional Files

Periodically, every 20 minutes or so, this process would be repeated.

One of the goals of this rootkit is to create a powerful peer-to-peer botnet, which is capable of downloading additional malware on the infected system. This botnet is reportedly involved in click fraud, downloading rogue antivirus applications, and generating spam. In this analysis we have noticed only the ad-click fraud component. The rootkit works at the Transport Driver Interface (TDI) network layer, bypassing firewalls and security software that don’t monitor network activities at this network level.

We can now illustrate the infection process (Figure 18, Step 1).

Firstly, the malware contacts /geo/txt/city.php at to find out its location:

Figure 17- Geolocalization

Next, it makes a number of connections to /count.php at, passing in a unique id (Fig 18, Step 1). The parameter “unique id”, is very important because in this type of fraud determines who will receive the money from the clicks. Obviously this “unique id” is set by the attacker in his favor, so that his count will increase and will receive the money instead of the victim. There are also some malformed DNS lookup requests (sent to as we can see in the scheme below (Step 2):

Figure 18- Location and DNS Malformed

The rootkit sends an encrypted request to all the servers, the packet is always sent to the remote port TCP 16471. The 18 bytes of data looks encrypted, but elicited no response from the server.
Completed this preliminary procedures, the bot begins to contact the Peers with a combination of TCP/UDP connections to receive more lists of servers for fulfill the fraud. So the victim machine sends many UDP encrypted request, and if the peers responds, starts TCP connection on the same port, so it can get encrypted data.

Figure 19- Packet View

Figure 20- TCP/UDP Traffic scheme

In the following pictures we show the encrypted payload sent during the p2p communications:

Figure 21 – UDP Payload

Figure 22 – TCP Payload

It is worth to mention that the malware sample tested also attempted to download and install an update to the Adobe Flash player, this ties in what was said before in OS Modification on the installation mechanism of infection.

Figure 23 – Adobe Flash player

The rootkit allows the attacker to drop in the system further infections, by downloading and storing the relative files inside the protected folder, so that they become invisible to security software. These dropped files are in the form of kernel mode driver. This is because the main rootkit driver is able to load them from the kernel.

This process then leads to set up an architecture that aims to implement the “Click fraud”. Click fraud is a type of Internet crime that occurs in pay per click online advertising when a person, automated script or computer program imitates a legitimate user of a web browser clicking on an advertise (or “ad”), for the purpose of generating a charge per click without having actual interest in the target of the ad’s link. Click fraud is the subject of some controversy and increasing litigation due to the advertising networks being a key beneficiary of the fraud.

The payload of this ZeroAccess version falls into this category of software, and his way of completing the click is described in the diagram below:

Figure 24 – Ad-Click fraud scheme

Here we can see the mechanism that uses ZeroAccess, by first asking the list of sites where to click, and then click on it pointing to links that are passed in the list with the “unique id” set by the attacker. Scary right?


Ok, time and space are running out. We hope you like the roundup.

Studying malware is a very exciting job, but also a very challenging one and rootkits have a special place in the heart of every malware analyst. Understanding rootkits is often the key to find newest exploits and newest trend used by cybercriminal in massive exploitation. It is like unearth a forgotten treasure or look to an alien specimen, but the rootkit is also extremely dangerous and should be handled with care… Understanding how they work and how they can be identified is the best way to reduce their threat, so keep yourselfupdated and ready, the challenge is not going to end soon…

Thanks to all guyz @ Black Sun Labs for supporting us writing the article, and remember “We will be watching!”

Author bio not avialable

Leave a Reply