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

Filed Under: Botnet, Featured, Malware, SophosLabs

Artistic interpretation of computer malware. Image courtesy of ShutterstockSophosLabs 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:

rol loop

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:

old filer

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:

new filer

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.

Artistic interpretation of computer malware. Image courtesy of ShutterstockThis 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.

, , , , , ,

You might like

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

  1. Gareth Connors · 686 days ago

    My approach to those who deliberately create such malicious software is search and destroy. I do not mean this only in a virtual sense but also in real world scenarios.
    The electron may be as fast as light but the bullet extinguishes the light, permanently.

  2. Nigel · 686 days ago

    Thanks for linking the technical paper article, where it says, "Yes, Sophos Anti-Virus can detect, block and remediate this rootkit and the various malware which uses it."

  3. Robert Wurzburg · 686 days ago

    Excellent article about a now persistent threat and exploit. Now I can really look for
    this on my machines with this information, not that I think it's present now.

    Hopefully we will see countermeasures with the new Malicious Software Removal
    Tool to be issued June 12, 2012 as part of this month's Microsoft Updates, and in
    updates to antivirus and antispyware programs from all vendors.

  4. Hello

    I saw this version was pushing a PE file into %windir%/Assembly/GAC/Desktop.ini
    What for? Have you seen this while reversing your variant?

  5. Tobal · 685 days ago

    is there a way to remove this newer version of the sirefef virus? The sophos virus removal tool when run on machines infected with this variant only causes windows to restart during the scan process.

  6. Lain · 685 days ago

    Well come on it's not like this is new news. 32-bit rootkits have been trying to install themselves on 64-bit machines for the longest time, and it never went well (clearly). So it's not surprising ZeroAccess is deciding to actually target them. Up til this year theres been no 64-bit rootkits in the wild as far as I knew.

  7. Nice coverage. Very clear and concise.

  8. njorl · 684 days ago

    Interesting detail from the technical paper: "to make the folder inaccessible to programs using standard Windows APIs it is made into a symbolic link pointing to 'systemrootsystem32config'".

    This suggests a design flaw in NTFS: a folder is able simultaneously to have contents of its own (files and other folders) and to be a link to another folder. Our expectation (as reflected by all normal software) is that each folder must be either a genuine container or some type of link.

    It's probably now completely impractical for the flaw to be removed (from the file system definition), but I think it can be countered by changes to the drivers.

    I suggest that, upon encountering a split-personality folder, the NTFS drivers should clear the link definition part, if writing is not barred by the context of the operation, or at least ignore it. Such a change would be fairly benign, as all data would be accessible. The loss of the link could, temporarily, disable some functionality, but our driver change is not breaking a good system; it's exposing a system that was already broken.

    In the absence of a corrective change to NTFS or its drivers, our antivirus scanners must allow for the flaw, by not taking link folders at face value. Are all major Windows security suites now on top of this?

  9. JimboC · 684 days ago

    Hi Lain,

    Unfortunately, 64 bit rootkits have been available for some time (as far back as August 2010).

    Here are some links to the relevant articles on these threats:

    Alureon 64 bit:
    http://blogs.technet.com/b/mmpc/archive/2010/08/2...
    http://www.symantec.com/connect/blogs/tidserv-64-...
    http://www.symantec.com/connect/blogs/backdoortid...

    64 bit MBR Rootkit:
    http://nakedsecurity.sophos.com/2009/10/02/w32xpa...
    http://www.symantec.com/connect/blogs/strange-cas...

    Apologies for posting links from competitor’s websites but I could not locate matching articles on this Sophos blog in all cases.

    Thanks very much James for this great article and the link to the technical paper. Both are very interesting and have encouraged me to bolster my defences even more.

    I really like this blog; I obtain extremely helpful information from it every day. Keep up the excellent work.

    Thanks again.

  10. Stephan Peters · 654 days ago

    Worked!

    When FixZeroAccess from Symantec did not (no infections found).

    Just edited one registry value, then deleted the other (after removing another suspicious file in localsettings/applicationdata that may have had nothing to do with ZeroAccess (could be an innocent file related to Java 5 r 5).

    I'll have to keep an eye on it to make sure it isn't still lurking on this computer.

  11. robert · 636 days ago

    Restarting explorer.exe causes the trojan to go dormant. Maybe useful if you want to retrieve data before a re-image.

  12. Sebastian · 628 days ago

    Kaspersky tdsskiller cleaned this quickly.. however I noticed that this virus attached itself to Akamai's netsession.dll what a way to spread eh?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

James Wyke is a Senior Threat Researcher with SophosLabs UK