A technical paper by James Wyke, SophosLabs, UK
At installation, ZeroAccess will first ascertain if it is running on 32 or 64-bit Windows. This is achieved using the ZwQueryInformationProcess API with ProcessWow64Information as the ProcessInformationClass parameter:
This is where the decision between 32 bit and 64-bit installation path is made. The installer will then attempt to give itself SE_DEBUG_PRIVILEGE privileges using RtlAdjustPrivileges:
If this is successful then installation will continue as normal. If the attempt fails (usually because the process has been executed by a normal user) then ZeroAccess will attempt another method of privilege escalation.
ZeroAccess must elevate its privileges to install successfully, but in order to do this from a non-administrator account on UAC enabled versions of Windows, a UAC popup will appear. End users are more likely to be suspicious of a file they have just downloaded from the internet that they thought was an illegal keygen, crack or hacked version of a game; they may also be suspicious if an unknown exe file causes a UAC popup while the user is browsing the web (exploit pack infection vector).
As a result the user may choose not to allow the program to proceed, thus ZeroAccess installation may fail. To bypass this possible problem, ZeroAccess disguises itself by forcing the UAC popup to appear to come from a different, benign-seeming program. A clean copy of the Adobe Flash Installer (InstallFlashPlayer.exe) is dropped to a temporary directory and the DLL load order of Windows is abused to ensure that ZeroAccess is loaded into the clean file’s process address space when it is executed.
By dropping a DLL called msimg32.dll (one of the DLLs that InstallFlashPlayer.exe imports) into the same directory as the Flash installer file, Windows will load this DLL in preference to the genuine msimg32.dll because Windows looks in the current directory before the system directory when loading DLLs:
This means that the UAC popup now appears to be generated by the genuine Adobe Flash Installer which is much more likely to be authorized:
The Flash installer will then continue while ZeroAccess silently infects the system in the background, even if Flash is already installed:
ZeroAccess will next go about lowering security on the infected machine by disabling a number of Windows security-related services. The Windows Firewall is turned off and updates will no longer be retrieved from Microsoft. The full list of services that it will attempt to disable is:
- BFE (Base FilteringEngine service)
- iphlpsvc (IP Helper service)
- mpssvc (Windows firewall service)
- WinDefend (Windows Defender service)
- wscsvc (Windows Security Center service)
- WinHttpAutoProxySvc (Proxy Auto Discovery service)
Pseudo random domain generator
During installation many ZeroAccess samples will report back to an IP address embedded inside the executable with information about the infected machine. This is carried out with an HTTP Get request with the ‘Host’ field of the request set to a pseudo-randomly generated ‘.cn’ domain.
The generated domain name does not exist and does not need to exist as it is never looked up and no attempt is made to connect to any URL on the generated domain. The domain uses the current date and a seed value, and one domain will be generated per day:
This DGA (Domain Generation Algorithm) system is used in various places throughout ZeroAccess where communication needs to take place over HTTP. If the exact same HTTP request is made with an incorrect ‘Host’ field in the HTTP request then an empty response will be returned. In this way it is used as a pseudo-authentication system to verify that the server is only talking to a genuine ZeroAccess instance and not anything else, such as security researchers or search bots. The locale and the architecture of the infected machine are also added to the get request in the ‘User-Agent’ field:
The rest of ZeroAccess installation is markedly different on 32 and 64-bit platforms.
When installed under 32-bit Windows, ZeroAccess will install a kernel-mode rootkit. To load its code into the kernel an existing driver will be overwritten on disk. The original driver file and any subsequent files downloaded by ZeroAccess will be stored in encrypted form on a part of the disk not normally accessible to other applications.
The stealth technique used by ZeroAccess to hide its files has changed over time. Previous versions created an entire hidden volume to store their files but recent versions have used a much simpler but no-less effective technique. A directory is created under ‘%systemroot%‘ with a name designed to look like a legitimate directory created when a Microsoft patch is installed.
The directory name will be similar to ‘c:\windows\$NtUninstallKB35373$‘ with the last five digits being specific to the victim machine. Files stored inside this folder are encrypted using a modified version of RC4, and to make the folder inaccessible to programs using standard Windows APIs it is made into a symbolic link pointing to ‘\systemroot\system32\config‘:
The ACL (Access Control List) on the directory is also changed so that the target of the link cannot be browsed to:
However if the raw disk is accessed, or the directory is examined offline from a Linux OS, the contents can be seen:
If the symlink directory is ignored and the full path is provided, the encrypted files can also be accessed:
A special device is created that the rootkit uses to read and write into the hidden folder, decrypting and encrypting files on the fly, and the LowerDeviceObject of the DR0 device of \Driver\Disk is hooked to hide the overwritten driver.
Under 64-bit Windows, ZeroAccess does not use any kernel-mode code; all its execution takes place in user memory. The same technique of dropping the Flash Installer is used to elevate privileges. Reboot persistence is achieved through a file dropped into the user’s AppData folder and a registry entry under HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
Again, ZeroAccess attempts to make its files difficult to access, this time using no rootkit behaviour but by hiding inside the Global Assembly Cache (GAC). The GAC is a machine-wide cache of .NET assemblies used by Windows. It is located at %windir%\assembly. To view assemblies and add new ones, the Assembly Cache Viewer is used which is integrated into Explorer. When the GAC directory is browsed to the Cache Viewer is launched:
The Cache Viewer does not display the contents of the directory but displays information about the installed assemblies. ZeroAccess abuses this functionality by creating a directory inside the GAC folder and storing its files there. These files will not be observable by any casual user who browses the folder with Explorer, but they can be seen if the Cache Viewer shell extension is disabled or from the command line: