A technical paper by James Wyke, SophosLabs, UK
Once ZeroAccess is in memory there are two main areas of activity: the rootkit and the payload.
If running under 32-bit Windows, ZeroAccess will employ its kernel-mode rootkit. The rootkit’s purpose is to:
- Hide the infected driver on the disk
- Enable read and write access to the encrypted files
- Deploy self defense (some versions)
The primary function of the rootkit component of ZeroAccess is to hide the changes made to the driver that was infected during installation. This is achieved by hooking the LowerDeviceObject of the DR0 device of \Driver\Disk. A copy of the clean driver is stored in memory. Any process that attempts to read the infected driver from the disk will be presented with the clean driver.
If any of the components of ZeroAccess want to read or write to files stored inside the hidden folder then they need to do this without using the normal Win32 APIs, as Windows will see the folder as a symbolic link and not realize it is also a genuine folder with files inside. The files also need to be decrypted to make any sense out of them. The rootkit driver facilitates seamless read and write to the hidden folder by creating a device named ACPI#PNP0303#2&da1a3ff&0. When files are accessed through this device they are decrypted on the fly.
Many versions of ZeroAccess employ aggressive self defense that is designed to protect the rootkit from security and AV software. A process is created that is monitored by the rootkit and if any application attempts to open this “bait” process, the rootkit will attack that application. The bait process has data stored in an Alternate Data Stream so the process name appears with a colon inside it:
First, the ACL of the file for the process that has opened the bait process is changed so that the file can no longer be executed, using ZwSetSecurityObject:
The process itself is then attacked by injecting shell code into it that will terminate the process. This means that on ZeroAccess infected systems many security tools will be terminated and the ACL on their files will need to be changed before they can be executed again. This symptom is a good indicator of ZeroAccess infection and it would appear that the authors may have decided that this is too good an indicator of infection as most recent samples no longer include the self defense.
The payload of ZeroAccess is to connect to a peer-to-peer botnet and download further files. The network communication is initiated both from the kernel driver itself and from a component injected into user memory, usually inside either the address space of explorer.exe or svchost.exe, by the driver.
When initially installed, ZeroAccess includes a file that contains a list of 256 (0x100) IP addresses. Each IP address is followed by a dword time value that probably indicates the last contact time for each IP address as the list is sorted by the time value, highest first. This is the initial list of peers that the infected machine knows about in the botnet. The bot will attempt to contact each IP address in the list on a fixed port number that is stored inside the bot executable file. Once a successful connection is made commands will be issued.
The bot also listens on the same high numbered TCP port that outgoing connections use, thus it attempts to become another node in the peer-to-peer botnet. However, it should be noted that the infected machine will need to be directly accessible from the internet with a public IP address for other peers to connect to it. Otherwise the infected machine will effectively become a passive node that can only connect to other nodes and obtain data; it cannot be connected to by other nodes.
All communication across the peer-to-peer network is encrypted with RC4 using a fixed key. This key has been observed to be the same for all variants of ZeroAccess encountered, even variants that use different port numbers and are instructed to download different types of malware.
Upon successful connection to another node, the bot will first issue a ‘getL’ command. This command is regularly repeated and is the main way of keeping up to date with other nodes. The other node then responds with a ‘retL’ command which includes the list of 256 (IP address, time) pairs that it currently holds and a list of files and timestamps for each file that it has downloaded.
This keeps new nodes in the botnet updated with the currently accessible peers. A ‘getF’ command is then issued by the bot for each file contained in the list. This downloads the file and stores it under the hidden folder. Some variants will also store the downloaded files in a directory under the user’s %AppData% path. Each downloaded file contains a resource named ‘33333’ that contains a digital signature for the file. The bot verifies the signature is genuine using an RSA public key embedded inside it before the file is executed:
ZeroAccess has been seen to be downloading two main families of malware. The first is a type of click fraud malware that appears to be very tightly bound to ZeroAccess, so much so that it may have been authored by the ZeroAccess owners. This malware can redirect browser search results to URLs of the author’s choosing and will periodically query a server that will send back an xml file that contains a list of URLs and referrer URLs:
The infected machine will send HTTP requests to each URL specified in the <url> tag with the referer field of the HTTP request set to the URL from the <ref> field. This generates income for the affiliate whose ID is embedded in the referrer URL.
The click fraud payload can be said to be very tightly bound to ZeroAccess itself because the same DGA (Domain Generation Algorithm) is used to generate the Host field of the HTTP request when retrieving URL data:
The other main payload is a spambot. When this payload is downloaded it installs itself, downloads spam templates, and target email addresses and sends spam. It is likely that the authors of the spambot are renting a portion of the ZeroAccess botnet to deliver their malware.
The two differing versions are most easily identified by the port numbers that they use. The click fraud downloading variant tends to use ports 21810 and 22292 whereas the spambot downloading variety uses port 34354.
We have explored where ZeroAccess infections come from, how the rootkit establishes control over a system and what activities it carries out once installed.
We can say that ZeroAccess is an advanced malware delivery platform that is controlled through a difficult to crack peer-to-peer infrastructure. Once it gains a foothold on a system it can be very difficult to remove. It has adapted as its target environment has evolved, adding compatibility for 64-bit architectures and multi-user, multi-privilege systems.
ZeroAccess remains hidden on an infected machine while downloading more visible components that generate revenue for the botnet owners. Currently the downloaded malware is mostly aimed at sending spam and carrying out click fraud, but previously the botnet has been instructed to download other malware and it is likely that this will be the case again in the future. ZeroAccess should be considered an advanced and dangerous threat that requires a fully featured, multi-layered protection strategy.
P2P RC4 key
The RC4 key used in all P2P communications is the MD5 of the fixed dword value: 0xCD6734FE.
RSA public key
The RSA public key used to verify the signature on the downloaded files uses a 512 bit modulus, shown here. (By current cryptographic standards, this is considered weak.)
Detection names used by Sophos Anti-Virus
- Infected files will be detected and blocked as Mal/ZAccess-x, Troj/ZAccess-x, Mal/Sirefef-x or Troj/Sirefef-x , where x denotes an alphabetic suffix (-A, -B, etc.) On a properly-protected system, this should prevent infection in the first place.
- Active processes will be reported and blocked by the Sophos run-time HIPS (Host Intrusion Detection System) as HPmal/ZAccess-A. This gives an extra layer of safety by providing proactive detection and prevention even of samples which evade detection in (1) above.
- The Zero Access rootkit itself will be detected in kernel memory, and can be cleaned up, as Troj/ZAKmem-A. This means that the malware can be remediated even on systems where the rootkit is already active and stealthing.