Alexandr Matrosov summarizes the evolution of complex threats using hidden storage, as discussed in his presentation with Eugene Rodionov at Virus Bulletin 2012.

At the end of September at Virus Bulletin 2012 my colleague Eugene Rodionov and I presented the results of our research Defeating anti-forensics in contemporary complex threats , dealing with hidden file systems and modern complex threats. Hidden file systems are used by modern complex threats for evading detection by security and forensic software. We have already discussed forensic problems with hidden file systems more than once in our previous blog posts (Bootkit Threat Evolution in 2011) and in this research we have been concentrating on in-depth analysis of the most widely used anti-forensic technique the implementation of hidden encrypted storage as used by complex threats currently in-the-wild. Here is a self-explanatory diagram depicting the evolution over time of bootkit threats with hidden file systems:

These complex threats use hidden encrypted storage areas to conceal their data and to avoid relying on the file system maintained by the operating system. The number of complex malware families using hidden file systems grows every year, because it’s an effective way of bypassing detection by forensic software.

Anti-forensic features

Nowadays there are certain malware families that strongly resist forensic analysis. There are various means of hampering the detection and removal of malware from infected systems: these include encryption and obfuscation of the C&C communication protocol, encrypting files containing payload and configuration information, and so on. In this blog post we concentrate on one of the most advanced features, as found in modern in-the-wild complex threats, used to impede forensics namely, implementing hidden encrypted storage.

At the heart of this relatively new technology lies the implementation of a hidden virtual storage device, transparently encrypting the data being read or written. This allows malware employing such technology to gain the following advantages:

keeping its data secret and stealthy

providing a payload with a fairly standard interface in order to store information and to retrieve it from storage

bypassing security software

Covert storage

The point of maintaining hidden storage in the system is not just to provide confidentiality for the information being stored, but also to conceal the very presence of the data. More often than not, malware keeps its data in encrypted files on the hard drive, using the file system maintained by the operating system, and that eventually causes its presence in the system to be revealed. In the case of hidden storage as described here, however, there is usually no file available for analysis in the OS’s own file system. None of the data related to the malware are located outside the file system and are in any case encrypted. In such a case it is quite difficult to ascertain the presence of the malware based on the examination of a disk image. Such examination often takes place during forensic analysis.

Standard interface

Access to the data stored on the hard drive is usually through the standard API using calls such as:

CreateFile/CloseHandle

ReaFile/WriteFile

SetFilePointer

Alternatively, any other appropriate system routines may be used such as GetPrivateProfileString, WritePrivateProfileString, and so on. As a result the development of a payload module doesn’t require knowledge of any specific technologies. Data kept inside hidden storage can be accessed using standard system routines.

Hidden storage architecture

The general architecture of hidden storage implementation is presented in our paper. Some complex threats locate and allocate space on the hard drive, usually at the end of it, where they store the image of the hidden file system containing malicious data. Usually there is some free space up to several Mb to be found at the end of the hard drive, which won’t usually be already used by the system.

To access the data the malware performs low level readwrite operations, usually using the interface provided by the storage miniport kernel-mode driver located at the very bottom of the storage device driver stack. By sending IRP_MJ_INTERNAL_DEVICE_CONTROL requests to the miniport driver, malware is able to read/write sectors of the hard drive and thus maintain its hidden file system.

In the table below some features of the most widely spread complex threats implementing hidden storage are compared:

Hidden File System Reader tool

Implementing hidden storage makes forensic analysis more difficult since:

Malicious files are not stored in the file system (difficult to extract)

Hidden storage cannot be decrypted without malware analysis

Typical forensic tools do not work out of the box

To tackle the problem of retrieving the contents of the hidden storage areas one needs to perform malware analysis and reconstruct algorithms used to handle the data stored inside it. In the course of our research into complex threats we have developed a tool intended to recover the contents of hidden storage used by such complex threats as:

TDL3 and modifications

TDL4 and modifications

Olmasco

Rovnix.A

Rovnix.B

Sirefef (ZeroAccess)

Goblin (XPAJ)

Flame (dump decrypted resource section)

The tool is very useful in incident response and threat analysis and monitoring. It is able to dump the malware’s hidden storage, as well as to dump any desired range of sectors of the hard drive. In the next figure a screenshot of the tool’s output is presented:

The tool can be obtained here (HiddenFsReader download link).

Aleksandr Matrosov

Security Intelligence Team Lead