ZeroAccess malware revisited – new version yet more devious

Here at SophosLabs we have previously written in great depth about the menace of the ZeroAccess malware family, exploring its nature and documenting the changes this malware family has gone through over time.

Guess what?

The authors have pushed out another update and this time they are using some interesting techniques to ensure reboot persistence.

Persistence puts the “P” in APT (Advanced Persistent Threat). Simply put, malware has persistence if it automatically reloads itself when you logoff and log back on, or when you reboot. That makes the malware more dangerous, as it generally serves the cybercriminals for a lot longer.

The previous incarnation of the user-mode version of ZeroAccess stored its files in folders created in the Recycle Bin (usually C:\RECYCLER on XP or C:\$Recycle.Bin on Vista and later) to make them less obvious.

It also changed the Access Control List entries (ACLs) on the folders so that no user could read from or write to the files.

This time the files are dropped into a new location with the ACL trick again being used.

But the malware authors are also using the right-to-left override and several other non-printable Unicode characters in both file paths and registry entries to further hinder identification and removal of the ZeroAccess components.

Let me explain what this means.

The new ZeroAccess dropper copies itself to two locations: in the %Program Files% folder, and in the user’s local AppData area.

Each copy is placed in a folder that looks as though it is part of a Google product, using non-printable Unicode characters that make it hard to spot on some versions of Windows.

On Vista and later, the folder name is such that we cannot browse to it using Explorer:

We see more on Windows XP, though we are still stopped by the ACL trick described above:

To get further, we need to take ownership of the folder, which allows us to see its content:

If we examine the file paths being used in a hex editor we can see that unusual Unicode characters are being used:

The folder structure starts like this:


Below this is a folder made up of the following Unicode characters, highlighted in the hex editor screenshot above:

\x2e\x20 \xf9\xfb \x5b\x0e

The first character is the right-to-left override (RLO) character that is used to support languages that are written from right-to-left such as Hebrew.

RLO is often used by malware authors to hide the extension of malicious, executable file types.

Here, the ZeroAccess authors are combining it with other characters that Windows Explorer cannot display.

This as good as hides the files, and makes their removal challenging.

A service is created to start an EXE file (executable program) stored in this folder during startup; the Unicode character trick is used again in the service name.

The malware tries to make its service name look like gupdate, but we can see there is something amiss on post-XP versions of Windows because the service appears in the wrong place in the alphabetical listing.

It ends up amongst the names starting with ‘e’, rather than ‘g’:

When we click into the ImagePath value data for the service entry we can see the RLO character in action, because the data appears backwards as soon as the RLO override is encountered:

On XP, however, the RLO character is not honoured and we can see the path the correct way round:

The payload of ZeroAccess has not changed with this revision.

The malware connects to the same peer-to-peeer network as described in this technical paper, and is currently downloading modules that primarily carry out click fraud.

However, this update shows that active development is still under way, and that the focus of the authors is to increase the lifetime of ZeroAccess on infected systems by making discovery and removal a more difficult process.

Editor’s note: James Wyke will be looking at ZeroAccess in a paper at the Virus Bulletin 2013 conference in Berlin in October. He’ll be looking at the financial rewards that the malware brings for its owners, and exploring the likely future direction of the ZeroAccess botnet. Watch Naked Security for details of the paper, Back channels and bitcoins: ZeroAccess’ secret C&C communications, once it has been presented.

Sophos detects the various components of this malware as follows:

HPmal/ZAccess-A (proactively via HIPS)
Troj/ZAUMem-C (in memory, e.g. during cleanup)