Major shift in strategy for ZeroAccess rootkit malware, as it shifts to user-mode

SophosLabs has been monitoring a new strain of the infamous ZeroAccess rootkit that has been hitting the internet over the last few weeks.

ZeroAccess is a sophisticated kernel-mode rootkit that enslaves victim PCs, adding them to a peer-to-peer botnet from which they receive commands to download other malware. The rootkit has undergone several revisions since its inception but this new version represents a major shift in strategy.

All previous versions have employed a kernel-mode component on 32-bit Windows. However, under 64-bit Windows there was no kernel-mode component – ZeroAccess operated entirely in user-mode memory.

And operating entirely in user-mode is exactly the shift in strategy that this new version employs.

ZeroAccess no longer has any kernel-mode component. Instead, a DLL is loaded into services.exe and explorer.exe and all functionality is performed inside those processes.

The previous generation of ZeroAccess would maintain reboot persistence by overwriting a Windows driver. This version uses the registry to ensure it will start again at the next boot.

ZeroAccess will create two files on an infected machine, either of which can launch the Trojan:

%WINDOWS%\installer\{GUID}\n

%profile%\local settings\application data\{GUID}\n

These two files are launched through the registry by hijacking an existing COM object and by abusing the load order of user COM objects under Windows.

The first file is launched by hijacking a COM object associated with WMI. The following registry entry is changed so that the malicious ZeroAccess DLL is loaded in place of the legitimate wbemess.dll:

HKCR\CLSID\{F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1}\InprocServer32

Correct value:

%systemroot%\system32\wbem\wbemess.dll

Hijacked value:

\\.\globalroot\systemroot\Installer\{e051c979-bddd-5d1f-8953-4b8c940e9b4d}\n.

The second file is launched by creating the following COM object:

HKCU\Software\Classes\clsid\{42aedc87-2188-41fd-b9a3-0c966feabec1}

This object points to the file at:

%profile%\local settings\application data\{GUID}\n

This will ensure that the DLL is loaded because a legitimate COM object exists at:

HKCR\clsid\{42aedc87-2188-41fd-b9a3-0c966feabec1}

This COM object belongs to MruPidlList which will load shell32.dll on Windows 7 and shdocvm.dll on Windows XP.

Because the COM object that ZeroAccess creates is a user object, Windows will load it before the legitimate object located in the registry under HKCR. The real benefit of this approach is that it will work under both 32 and 64-bit versions of Windows.

The peer-to-peer protocol used by the ZeroAccess botnet has also changed. Previously all communications were RC4 encrypted using a fixed key. That has now changed. The main encryption algorithm used is now much simpler, DWORD XOR is applied with a key that is adjusted on each round:

The actual commands involved in the protocol have been slightly modified too.

The previous version would start by issuing a ‘getL’ command to each peer contained in its bootstrap file of peers. The command is issued over TCP and usually to one of ports 22292, 34354, 34355, 21810.

The remote machine would then respond with a ‘retL’ command that contained its own list of peers and a listing of files that the bot has downloaded. The new bot would then check the list of files and download any new files by issuing a ‘getF’ command. These files are signed with a 512 bit RSA key:

The new version also starts by issuing a ‘getL’ command. But this time the command is sent out over UDP, the port numbers being used are different and the structure of the command header has changed.

The remote peer still sends back a ‘retL’ command, this time over UDP and this time the file information is accompanied by a signature produced by a new 1024 bit RSA key. Now, instead of sending a ‘getF’ command to the remote peer to retrieve files the local peer doesn’t already have, the peer simply sends the encrypted file information (filename, length and timestamp value) to the remote peer over TCP on the same port number that the UDP communication took place.

The remote peer then sends back the file encrypted with RC4 and a key derived from the file information:

This new version of ZeroAccess is being aggressively distributed through the normal mechanisms – drive by downloads, fake keygens, fake game downloads, and new samples of the old variant have all but dried up.

It’s clear that the malware’s authors have decided on a more unified approach to supported platforms and to change the footprint of ZeroAccess both on infected machines and on infected networks.

This is most likely due to the increased attention that this malware family has been receiving from security companies, but also as more and more people are using 64-bit machines it makes sense for malware authors to focus on that platform, so maintaining a complicated kernel-mode component that only works on 32-bit systems seems less and less cost effective.

The goal of ZeroAccess remains the same: to download further malware onto the infected machine. The types of malware we are seeing downloaded are broadly the same: click fraud and spam bots, although a BitCoin miner has now been added to the mix.

SophosLabs will continue to monitor this threat and protect our customers. For more background information on ZeroAccess, be sure to read the technical paper we published earlier this year.

_{Laptop with red bacteria image courtesy of Shutterstock.}