GB2427716A

GB2427716A - Detecting Rootkits using a malware scanner

Info

Publication number: GB2427716A
Application number: GB0513254A
Authority: GB
Inventors: Mika Stahlberg; Kimmo Kasslin; Samuli Larvala; Antti Tikkanen
Original assignee: F Secure Oyj
Current assignee: WithSecure Oyj
Priority date: 2005-06-30
Filing date: 2005-06-30
Publication date: 2007-01-03
Also published as: GB0513254D0

Abstract

A method of detecting malware such as Rootkits within program code using a malware scanner comprises providing a first version of information relating to the program code to the scanner, causing a second version of the same information to be provided to the malware scanner by injecting code into a third party process, the third party process not being directly identifiable to malware as being associated with a malware scanner, and at the malware scanner, comparing the first and second versions of the information and identifying any differences that are indicative of the presence of malware. The injected code may be executable to collect the required information (fig. 1) or may be a launcher for a process that is executable to collect the required information (fig. 2). The third party process may be Windows (RTM) Explorer, Registry Editor, Task Manager or Command Prompt. The invention is able to detect Rootkits that have been developed to avoid detection by the "cross-view-diff" mechanism.

Description

Computer Maiware Detection Method and Apparatus

Field of the Invention

The present invention relates to a computer malware detection method and apparatus.

The invention is applicable in particular, though not necessarily, to the detection of a type of maiware known as "rootkits".

Background to the Invention

Computer maiware in the form of viruses, trojans, spyware, keyloggers and the like have been a threat for many years. Applications to prevent infection and to disinfect infected computers, generally referred to as "anti-virus" software, are constantly evolving to address new threats. Conventional maiware locates itself in the file system and/or the random access memory of a computer either as a standalone file or by embedding itself within an existing file. Such malware can be detected relatively easily as it will tend to have a distinct fingerprint. In the case of socalled polymorphic or self-encrypting malware the fingerprints are camouflaged but can still be detected through the application of emulation and cryptographic techniques. Anti-virus applications maintain a current list of known maiware signatures, and scan file storage areas, email messages and network downloads to identify malware. Anti-virus application may also use rules or "heuristics" to identify new malware for which a signature has not yet been derived or distributed. Heuristics define typical behavioural properties of malware.

Some early computer viruses employed so-called stealth techniques to hide their presence in a system. They intercepted file system calls and removed traces of their code when a program such as an anti-virus application inspected the file system and read the contents of files or boot sectors. Recently a new malware threat known as "rootkits" have appeared. Rootkits might be considered descendents of stealth viruses as they use similar techniques to cloak or hide the real threat, e.g. trojans, keyloggers, etc, from an anti-virus application. Rootkits arose in the mid I 990s and were initially identified in UNIX systems, where network administrators observed missing disk space, CPU cycles and network connections that did not show up with the usual administrator enquiry commands. Rootkits have now crossed over into the WindowsTM operating system world.

A rootkit is executable code that can intercept operating system calls or modify operating system structures to hide the presence of malware in the computer.

Sometimes a rootkit comes in the form of a modified system file or a collection of files that can replace operating system files to obtain access to the system at the administrator or root level. Whilst rootkits may operate at the application level, it is rootkits operating at the kernel or operating system that pose the greatest threat. As a generalization, Windows rootkits try to hide their files from Windows Explorer (explorer.exe), hide their registry keys from the Registry Editor (regedit.exe), hide their processes from the Task Manager (taskmgr. exe), and hide their network connections from the Command Prompt operations that display protocol statistics and TCP/IP connections (such as the "netstat" command of cmd.exe). This prevents system administrators from spotting the presence of the rootkits. Most rootkits are able to hide from all other processes as well, but this is the bare minimum in order to achieve reasonable stealth. By adopting such stealth techniques, rootkits are able to filter data provided to anti-virus applications to remove traces of malware present on the system. The conventional signature and heuristic based approaches will have limited means for detecting such maiware.

Anti-virus application vendors have introduced software to address the rootkit threat.

These include BlackLightTM from F-Secure Corporation and RootkitRevealerTM from Sysinternals. Microsoft Corporation has also made available documentation about a rootkit detection tool known as GhostBusterTM. The known detection techniques rely upon a so-called "cross-view-diff' approach. This collects information about files, processes, registry keys and other computer resources using conventional tools or operating system calls. The collected information will not contain traces of the malware as the rootkit will act to prevent this. The rootkit scanner then collects a trusted version of the information, for example using techniques that do not rely on the standard operating system calls. These techniques allow the scanner to inspect and gather information relating to the contents of the file system, process list and registry with less chance of interception by a rootkit. The information may well be affected by the rootkit, but in a different way form the information collected via the operating system.

The two sets of information are compared, and any difference(s) taken as being indicative that the system contains hidden objects, possibly implying the presence of a rootkit. Whilst it might be possible to detect a known rootkit using the trusted information alone, the cross-view-diff approach allows previously unknown rootkits to be detected. This is particularly important in the case of targeted rootkit attacks which, unlike wide scale attacks, will not quickly come to the attention of the anti-virus application vendors.

Rootkits have been developed that avoid detection by the cross-view-duff mechanism.

These rely upon detecting that a system information request originates from a known rootkit scanner. In this event, the rootkit does not hide any object from the rootkit scanner processes, but rather shows everything. When the rootkit scanner compares the information obtained using the conventional collection process with that collected using the trusted process, it finds that these are identical. Any previously unknown rootkit will go undetected.

Summary of the Invention

As has already been noted, rootkits would prefer to hide from a number of processes that would otherwise allow them to be detected. In the case of Windows, these processes include Windows Explorer, Registry Editor, Task Manager and Command Prompt. This feature can be exploited to allow the rootkit scanner to obtain "tainted" information for comparison with a trusted version of the information.

According to a first aspect of the present invention there is provided a method of detecting malware within program code using a malware scanner, the method comprising: providing a first version of information relating to said program code to the malware scanner; causing a second version of the same information to be provided to the maiware scanner by injecting code into a third party process, the third party process not being directly identifiable to malware as being associated with a malware scanner; and at the malware scanner, comparing the first and second versions of the information and identifying any differences that are indicative of the presence of malware.

The invention may be used to detect maiware consisting of or making use of rootkits.

The injected code may be executable code for collecting the required information, or launcher code for launching a separate process for collecting the information.

The third party processes from which information is obtained may be, for example, a standard process that is always or usually provided with the operating system that makes use of the program code. More preferably, the process is a process that is automatically run upon start-up of a computer system on which the program code resides or transits through, e. g. in the case of Windows the process may be one of Windows Explorer.

In an alternative embodiment, the third party process may be a process that is not always running on the system, but which is started by some other third party process that is always running. For example, the third party process via which the information is obtained may be, in the case of Windows, Registry Editor, Task Manager or Command Prompt, that process being started by Windows Explorer.

The method may comprise the step of making the third party process run executable code arranged to collect the required information and pass it to a means for performing the comparison. This may be achieved by loading a dynamic link library into the third party process and causing the process to run the loaded module, using procedure call mechanisms provided by the operating system or by writing the executable code directly into the process and instructing the process to launch a thread to run the

executable code.

According to a second aspect of the present invention there is provided a computer program arranged to detect maiware within program code, the program: obtaining a first version of information relating to said program code; obtaining a second version of the same information by injecting code into a third party process which is not directly identifiable to maiware as being associated with a maiware scanner; and comparing the first and second versions of the information and identifying any differences that are indicative of the presence of maiware.

According to a third aspect of the present invention there is provided apparatus for detecting maiware within program code, the apparatus comprising: first processing means for obtaining a first version of information relating to said program code; second processing means for injecting code into a third party process running on the apparatus and which is not directly identifiable to maiware as being associated with a malware scanner, the injecting code causing a second version of said information to be obtained; and third processing means for comparing the first and second versions of the information and for identifying any differences that are indicative of the presence of malware.

Brief Description of the Drawings

Figure 1 illustrates schematically a first embodiment of the present invention; and Figure 2 illustrates schematically a second embodiment of the present invention.

Detailed DescriDtion of Certain Embodiments The rootkit scanners described here rely upon obtaining a trusted version of information relating to data stored in the memory of a computer system as well as a tainted version, and performing a comparison of the two. The information that is obtained in respect of the stored data might include, for example, a listing of files, processes, registry keys, network connections, users, services, handles, etc, in respect of a permanent storage device of the computer system. In some cases, this information may also be obtained for dynamic storage devices of the system. The selection of which information to obtain will depend on the characteristics and behaviour of rootkits.

As has been discussed above, in order to avoid detection, rootkits may detect when a rootkit scanner is requesting system information and in response "uncloak" themselves and other malware that they are seeking to protect. However, it has been recognised that in order to avoid detection, rootkits would prefer to be hidden to at least certain system processes. For example, a system administrator may use the Windows Explorer process to examine the files stored on the computer system. A rootkit would want to make itself and any associated malware invisible to Windows Explorer. The rootkit detection approach adopted here makes use of a third party process, such as Windows Explorer, to obtain a tainted version of the system information for comparison with a trusted version. The trusted version may be obtained by implementing a user-mode process or kernelmode module (or driver) to gather the required information that is not affected by the rootkit. Information which may be collected includes, for example, lists of files gathered by directly reading the raw filesystem data from the hard disks.

In order to "force" a third party process to obtain system information, a code injection process may be used. When the rootkit scanner is initiated, e.g. on-demand by a user or at some scheduled time, it will obtain a trusted version of the required information as described. It will also perform a code injection into a running third party process. This process will typically be a process which is always present on the computer system and which is always running. In the case of Windows XPTM, a suitable process is Windows Explorer. Examples of common code injection functions available on Windows platforms are: * WriteProcessMemory * Set WindowsHookEx * Applnit_DLLs (registry) After the executable code (or "sensor") has been loaded into the Windows Explorer process, it is necessary to make that process run the sensor within its context. If a method is used that loads a dynamic link library into the process (i.e. SetWindowsHookEx or Applnit_DLLs), the process will run the sensor entry point.

We can therefore start our scan of objects at the entry point. If on the other hand, the sensor code is written into the memory space of the process (i.e. using WriteProcessMemory), the sensor code will need to be run by instructing the process to launch a thread that runs the sensor. This can be done using Windows functions such as: * CreateRemoteThread SetThreadContext The sensor injection process described above is illustrated schematically in Figure 1.

The injected code, when run, is designed to cause Windows Explorer to gather the required information through operating system calls that would be most likely to be intercepted and manipulated by rootkits, send the information to the rootkit scanner, clean up, and end the sensor thread. The rootkit scanner communicates with the sensor using any suitable interprocess communication scheme (e.g. events, shared memory, shared file, remote procedure call, etc).

An alternative approach is to inject the sensor into a process that is not initially running on the system, but which is launched on the initiation of the rootkit scanner. However, to perform this launch directly would alert the rootkit to the action and allow it to hide the malware. Thus, code to launch the host process, e.g. Registry Editor or Task Manager, is first injected into an always on process such as Windows Explorer. The rootkit will not see any association between the host process and the rootkit scanner.

The various approaches described above essentially create a thread or use an existing thread inside a third party process. This thread does the scanning and submits the results (a tainted view) to the rootkit scanner. After the scan is finished the thread cleans up after itself. The "host process" is not permanently affected and the scanning code is only present during the scan.

As an alternative to injecting the entire sensor code into the third party process, it is possible to inject just a code fragment that launches the sensor as a separate process.

This approach is illustrated in Figure 2. Whilst the approach of Figure 1 is perhaps the more powerful of the two, it is also riskier since any malfunction in the sensor will cause problems in the process where the code was injected, possibly even resulting in a system crash.

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments of the present invention without departing from the scope of the present invention. For example, where the sensor is injected into a third party process such as Task Manager and where that process is not automatically running and therefore needs to be started in a manner which does not reveal the presence of the rootkit scanner to the rootkit, rather than injecting a launcher into an already running process such as Windows Explorer, the Asynchronous Procedure Calls (APC) mechanism can be used to execute code in the context of, or "within", a chosen process. APCs can be used from within the kernel space. Mechanisms similar to APCs can also be used.

Claims

1. A method of detecting maiware within program code using a malware scanner, the method comprising: providing a first version of information relating to said program code to the maiware scanner; causing a second version of the same information to be provided to the maiware scanner by injecting code into a third party process, the third party process not being directly identifiable to malware as being associated with a maiware scanner; and at the malware scanner, comparing the first and second versions of the information and identifying any differences that are indicative of the presence of malware.

2. A method according to claim 1, wherein said malware scanner is a rootkit scanner.

3. A method according to claim I or 2, wherein said injected code is executable to collect the required information.

4. A method according to claim 1 or 2, wherein said injected code is a launcher for a process that is executable to collect the required information.

5. A method according to any one of the preceding claims, wherein said third party process is a standard process that is always or usually provided with the operating system that makes use of the program code.

6. A method according to any one of the preceding claims, wherein said third party process is a process that is automatically run upon start-up of a computer system on which the program code resides or transits through.

7. A method according to claim 6, wherein the operating system that makes use of the program code is a Windows operating system and said third party application is Windows Explorer.

8. A method according to claim 5, wherein said third party process is not automatically run upon start-up of a computer system on which the program code resides or transits through.

9. A method according to claim 8, wherein said third party process is one of: Registry Editor, Task Manager, and Command Prompt.

10. A method according to claim 8 or 9 and comprising starting said third party process via a process that is automatically run upon start-up of the computer system.

11. A method according to claim 8, wherein said process that is automatically run upon start-up is Windows Explorer.

12. A method according to claim 3 and comprising loading a dynamic link library to the executable code into the third party process and causing the process to run the loaded module, or by writing the executable code directly into the process and causing it to be run.

13. A method according to claim 8 or 9 and comprising starting said third party process using an Asynchronous Procedure Call.

14. A method according to claim 1, wherein said injected code is executable code, the method comprising causing said executable code to be run using an Asynchronous Procedure Call.

15. A method according to claim 13 or 14, wherein said Asynchronous Procedure Call is made from within the operating system kernel space.

16. A computer program arranged to detect malware within program code, the program: obtaining a first version of information relating to said program code; obtaining a second version of the same information by injecting code into a third party process which is not directly identifiable to malware as being associated with a malware scanner; and comparing the first and second versions of the information and identifying any differences that are indicative of the presence of maiware.

17. Apparatus for detecting maiware within program code, the apparatus comprising: first processing means for obtaining a first version of information relating to said program code; second processing means for injecting code into a third party process running on the apparatus and which is not directly identifiable to maiware as being associated with a maiware scanner, the injecting code causing a second version of said information to be obtained; and third processing means for comparing the first and second versions of the information and for identifying any differences that are indicative of the presence of maiware.