Detection Example: DSE vs Sony BMG Extended Copy Protection (XCP) (aka. Sony Rootkit)
Description: In 2005 the Sony BMG company started releasing audio CDs that contained a digital rights management (DRM) protection system called Extended Copy Protection, or XCP. Although this protection system itself is not malicious and should not be considered malware it does actually use some low-level rootkit-style techniques in an attempt to hide itself. However in doing so it leaves the system vulnerable, allowing malware such as viruses to 'piggyback', using XCP to hide the virus in the same way XCP hides itself. For this reason it is also known informally as "the Sony Rootkit". (Click here for the Wikipedia article "2005 Sony BMG CD copy protection scandal")
XCP automatically installs as soon as you insert the CD (assuming CD-drive autorun is enabled, which it is by default). It then installs some files and creates kernel-mode hooks to hide those files, its processes, and its registry keys/values - exactly like rootkits do, and no means of uninstalling XCP are provided on the CDs (Sony has since made available a hotfix).
However, perhaps the most worrying aspect of XCP is not what it does, but what it makes possible for malware authors. For example, XCP will hide any file or directory if its prefix is "$sys$" (this is demonstrated later). Thus, any virus could simply check to see if XCP is installed and then rename itself to $sys$anything, and it too will then be hidden by XCP.
Detection: For our detection test we purchased the CD 'Get Right With The Man' by Van Zant, which was known to have XCP protection.
Deep System Explorer detects XCP in a variety of ways, and exposes the inner workings of XCP, revealing exactly what it does to the system.
However before we see how DSE detects XCP lets see a couple examples of how XCP is able to hide itself.
XCP installs itself to a directory which it creates and hides called $sys$filesystem in the \Windows\system32\ directory, yet as you can see in the following screenshot the directory is hidden, and thus can't be found by using the 'dir' command. However when we try to change to that directory it succeeds, proving the directory exists:
We also know that files created with a prefix of $sys$ will be hidden, so lets test that also. Here we use the 'echo' command to create a file called $sys$test.txt, but then when we use the 'dir' command it fails to see the file ... it has successfully been hidden. Just to be sure that the file is there we use the 'type' command to display the contents of the file:
Enter Deep System Explorer ...
The System Service Table hook detection tool allows us to instantly see exactly how XCP achieves its file/process/registry hiding capabilities:
NtCreateFile and NtQueryDirectoryFile are hooked to hide files & directories, NtEnumerateKey and NtOpenKey are used to hide registry keys, and NtQuerySystemInformation is hooked to hide processes. We can see that the culprit is ARIES.SYS, located in the hidden $sys$filesystem directory.
Using the Code Modifications detection tool we can see that five patches have been made in the kernel (ntkrnlpa.exe) that point to the aries.sys driver. We can also see that the oct.sys driver has been subtly modified with two single-byte patches:
The drivers are also clearly visible in the Drivers List utility (under the Tools menu):
Now lets search for its hidden process! ...
We can also see the process in the Process List utility (under the Tools menu):
... and hidden threads? Just a few! ...
It also hides its services:
As we saw before, XCP also hides its registry keys:
And last but certainly not least we can see that LIM.SYS is hooking IRP_MJ_DEVICE_CONTROL and IRP_MJ_INTERNAL_DEVICE_CONTROL:
Deep System Explorer provides possibly the most advanced and thorough detection coverage of XCP ever seen.
Copyright © 2008, Diamond Computer Systems Pty. Ltd. All rights reserved.