ZeroAccess malware revisited - new version yet more devious

Filed Under: Botnet, Featured, Malware, Security threats, SophosLabs, Windows

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)

You might like

7 Responses to ZeroAccess malware revisited - new version yet more devious

  1. Cindy Armitage · 804 days ago

    You've presented both XP and Win7 here, but what about Vista, and Win8? Perhaps I'm a newbie, and not having other than the OS you've mentioned makes those who do have those you haven't, makes them, safe?!

    • Paul Ducklin · 803 days ago

      Good question!

      I've updated the article to say "Vista and later," or "post-XP versions of Windows" where before it just said "Windows 7."

      Generally speaking, there are two sorts of behaviour: "XP", and "everything after it".

  2. ABCguy123 · 804 days ago

    What confuses me is why crooks make a file look like 2/3 things. For example, in the photo, the icon is a computer & a telephone, the name is GoogleUpdate.exe, and the description is RegNow Download Manager. It'll arouse suspicion from the victim.

  3. slipstream · 803 days ago

    Heh. Talk about using old tricks..
    I mean, folders named just a bunch of spaces? what next, folders named as reserved DOS device names? i mean, this is just old ftp pubbers' tricks..

  4. Gavin · 803 days ago

    What confuses me is why Microsoft (and perhaps other OS vendors too) allows unicode characters in file names at all that they doesn't seem to support correctly in the GUI.

    I would think that the design choices for Windows here would be to either design explorer.exe so that it fully supports right-to-left formatting and other extended unicode features without throwing a bunch of errors in the GUI or simply not support them in places like file names and the registry at all.

  5. Jack · 803 days ago

    It seems that we (you?) know who these authors are. If so why are they not prosecuted? Or are the like vapor ware and no identification?

    Just curious


    • Paul Ducklin · 802 days ago

      There's a difference between "strongly suspecting that this is the same bunch of people who did X or Y or Z before" and 'this is that bloke Mr Z again."

      (In other words, "we feel certain the same guy just robbed the grocery store for the third time, but we don't know who he is or where he lives.")

      And there's just as big a chasm between having a suspicion who Mr Z might be, and having enough evidence even to think of doing something about it in a court.

      And there's yet another gap between between thinking about it and doing it - or, more accurately, finding the rght person, in the right jurisdiction, who is both willing and able to do something about it.

      That's why we make a point of congratulating law enforcement when they have a win against cybercrooks. It's often a long and arduous battle, requiring co-operation of dozens of police services...

Leave a Reply

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

You are commenting using your 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