分类： 网络与安全
2011-08-17 14:08:36
By Marco Giuliani
Among the most infamous kernel mode rootkits in the wild, most of
them have had a slowdown in their development cycle – TDL rootkit, MBR rootkit,
Rustock are just some examples. The same doesn’t apply for the
ZeroAccess rootkit. The team behind it is working quite hard,
which we know for a fact because I’ve seen it.
We already talked about this rootkit and its evolutions in several blog posts, along with a white paper that documents more in depth all the technical features of the malware. The last major update released by the team behind ZeroAccess dates back a couple of weeks; That update implemented a strong self-defense routine able to kill security software programs that try to get access to its code, blocking the security software from running by manipulating access control list, or ACL, settings.
Last week ZeroAccess received another update, and again it’s a major one. The
rootkit shifted from a hidden encrypted file used as an NTFS filesystem volume
to a more comfortable hidden directory created inside the Windows folder, where
the rootkit still stores its configuration data and other malware in an
encrypted form.
If you’ve never seen ZeroAccess in action before, here’s a little video that shows what happens on a computer infected with the rootkit.
Despite being visible on the file system, the directory cannot be easily accessed because it is configured as a reparse point – a symbolic link pointing to a fake path. This approach prevents any software that works at the filesystem level from accessing to the content of the directory. Software that tries to access the contents of the folder by manually parsing the NTFS file system won’t get very far, either: Even though the files are accessible, the rootkit stores them in an encrypted form.
In my last blog post about ZeroAccess, I wrote that the rootkit was still using the RC4 encryption with a specific encryption key embedded in the rootkit body. This approach allowed us to easily decrypt the rootkit file containing the hidden volume and extract the rootkit plug-ins along with a clean copy of the infected system driver.
It looks like the rootkit authors made some changes to their malware. The rootkit no longer uses a shared embedded encryption key; instead the encryption key is different on each infected system.
The malware generates the key using some specific values retrieved from the victim’s computer, thus preventing the encrypted malware files from being decrypted if they are saved from the infected system and sent to antivirus companies, for example. And the encryption no longer uses the default RC4 algorithm: Now, the rootkit modifies the encryption so that, while it is still using the RC4 algorithm as its basis, it implements the encryption differently.
The rootkit still generates a RC4 S-Box with the encryption key retrieved from the current infected system, though it then generates another S-Box, which is just the data of the first S-Box, but inverted. ZeroAccess will use these two KeyStreams to encrypt and decrypt the files by permutating the bytes.
The folder where the rootkit will store its files is located at the path: C:\WINDOWS\$NtUninstallKBxxxxx$, where the Xs represent a unique number generated from characteristics of the infected system. Look familiar? That’s because Windows Update uninstallers create folders with this same naming convention on every patched Windows computer. Every time the rootkit has to read or write inside this folder, the disk I/O must pass through the rootkit device (with the memorable name of ACPI#PNP0303#2&da1a3ff&0), so that the kernel mode driver is able to encrypt and decrypt on the fly.
However, despite all the updates, the infection logic remains the same, though the code has been modified to raise the level of complexity. The rootkit kernel mode driver hooks the disk.sys DriverExtension object so that it hijacks LowerDeviceObject, enabling it to intercept every packet sent from the disk.sys system driver to devices lower in the stack. The rootkit uses this filter to hide the infected driver.
The self-defense routine we firstly saw implemented in ZeroAccess was located in a second kernel mode driver, which creates a sacrificial “goat” process, then monitors every access to it. When a security software program does a system scan, and tries to open a handle to the fake process, the rootkit self-defense driver will kill the security software by injecting in the security tool a payload code that invokes the ExitProcess() API call, succesfully killing the process. Then, the rootkit breaks the file’s ACL settings so that the file cannot be executed anymore unless the default ACL settings are restored.
In the previous update, ZeroAccess extended this effective self-defense routine to monitor the access to its ACPI#PNP0303#2&da1a3ff&0 device. If any software tries to open a handle to the device, without specifying the full path to the content (e.g., “ACPI#PNP0303#2&da1a3ff&0\L\xxxxxxx“), the rootkit interprets this as an attempt to analyze its device and will kill the caller process that tried to open the handle to it, using the same process+file kill method.
This new approach — added to the fact that we are seeing this rootkit becoming widespread and that it is able to effectively bypass and disable most of security solutions — makes ZeroAccess still more aggressive and more difficult to defeat, definitely one of the most advanced kernel mode rootkits available today.
