We recently completed the beta version of our malware analysis suite, VMRay Analyzer, and presented it to our pilot customers. The official product release date will be in July 2014, after we have fixed minor bugs in the high-level reports, as well as completed the .PDF and .DOC analysis. We will soon be providing you with comprehensive information about the VMRay system and its capabilities. However, we have recently received quite a few requests for such information, and in response we have published some screenshots with a few quick descriptions.
Webinterface
While VMRay Analyzer can be controlled completely by its flexible Python API interface, it is typically controlled using the comprehensive Webinterface:
Users you can submit samples, browse and display the generated analysis data, and search the database:
Each submitted sample is stored with some meta data, and users can save arbitrary comments:
Analysis Data
Each sample can be analyzed multiple times, i.e., with different guest operating systems:
When a sample is analyzed with VMRay Analyzer, several different analysis output files are generated, such as the:
- Transition log: comprehensive data about the system’s control flow with all the addresses, stack data, register data, module names, function names, location offsets, etc.
- Function call log: all performed function calls, with all the IN- and OUT-parameter values, grouped by processes and threads
- Generic log: abstract and normalized view of all performed high-level operations, giving a perfect data representation for machine learning algorithms
Besides this, the following files are captured and stored with each analysis:
- Screenshot PNGs, each time the screen content changes significantly
- PCAP file with all the network traffic
- All files that have been created/modified during the analysis run
High Level Reports
Based on the analysis data, comprehensive high-level reports, which consist of several parts, are generated. A summarizing overview displays meta information about the sample as well as the analysis run, i.e., if the sample crashed, whether kernel code was executed, or if the MBR had been modified meanwhile.
It is followed by a list of all monitored processes and the resulting process graph. Each time a monitored process starts a new process, installs a service/daemon, or modifies/injects code into an already running one, this target process is monitored as well.
If kernel code is executed, the complete system has to be monitored:
However, while all processes are monitored, only the code that was injected or modified is contained in the analysis,. Therefore, the generated reports only reflect the malicious and abnormal behavior of the system. This leads to rather small and condensed analysis reports. For each monitored process, additional process information is given, such as the modules loaded by it, a list of the executed threads, or the collection of all created and modified files (which can be downloaded directly via the webinterface).
Host Operations
The main part of the high level report shows information about the performed operations by the samples. This is shown either in an aggregated way, or separately for each monitored process. In the following example you can see how code is injected into explorer.exe and then executed. As a result, that injected code within explorer.exe is monitored as well, and all of its operations are logged and reported:
While the transition and function logs contain complete data about all called functions and system services, the high level report is condensed to give relevant operations from the following categories:
- File-system access (creating/reading/writing/deleting/searching/copying files)
- Registry access (creating/reading/writing/deleting/enumerating registry keys/values)
- Users operations (creating/enumerating/deleting users/groups/passwords)
- Process operations (starting/enumerating/stopping processes)
- Service operations (installing/starting/stopping daemons or (kernel-) drivers)
- Module operations (loading/unloading/enumerating modules, parsing import/export directories/etc.)
- Memory operations (allocating/accessing/changing process memory; code injection)
- Thread operations (starting/stopping/modifying threads; thread injection; EIP modification)
- System object operations (Mutexes, Named Pipes, Local Time, Local OS Pathes, Environment, CMOS access, etc.)
- Network Access (usage of OS-functions to access SMB, HTTP/FTP or DNS-functionality)
- GUI operations (enumerating/creating/searching windows or screens)
Network Operations
The second important component of the high-level report contains information about all performed network operations.
This covers low-level information, such as incoming/outgoing TCP connections and UDP messages, as well as comprehensive data about the utilized Layer 7 protocols.
At the moment, the following protocols are detected and appropriately parsed: HTTP, FTP, SMTP, IRC and IDENT. More will follow soon.
Kernel Rootkit Analysis
If, during the analysis, the execution of unauthorized kernel code is detected, VMRay Analyzer automatically enables the kernel-monitoring mode. While the usermode malware components are still analyzed in the same as before, all unauthorized kernelcode is now also monitored. Since it makes no sense to report kernelcode process-wide, so called “kernelcode sequences” are extracted and displayed:
A sequence is always invoked by the same trigger function, and consists of a unique list of function calls, while the particular parameter values are ignored. A reasonable trigger function would be „ntoskrnl.exe.PnpNotifyDriverCallback“, which marks code that is automatically executed each time a new PNP device is detected. Another example of this is „ntoskrnl.exe.PsCallImageNotifyRoutines“, which is always issued when a new DLL/SYS is loaded into a process. For each sequence, the following data is displayed:
- The trigger: the part/functionality of the operating system that invoked the malicious kernel code
- The starting address of the sequence
- The length of the sequence (in function calls)
- How often the sequence was executed in total
- Which processes the sequence was executed within
- All performed function calls of the sequence, plus the used parameter values of the first detected instance
TDL4 Examples
The kernel rootkit TDL4 waits within each process of the loading of „kernel32.dll“ (as a trigger to perform code injection). Therefore, the report contains a sequence, which is called within each process multiple times (once for each loaded module):
Once, the trigger is issued for kernel32.dll, a different sequence is executed. The following example shows how an APC is generated within SMSS.EXE in order to perform further action:
Of course, the resulting APC is also shown in the report:
By inspecting the longer kernel sequences, one can easily spot what the rootkit is doing. For example, you can quickly see the rootkit accessing the hidden hard disk area and reading its configuration file:
