Patent Description:
As computing devices become increasingly complex, viruses and malware also are becoming increasingly complex and difficult to detect and prevent. While the prior art includes many approaches for scanning non-volatile storage such as a hard disk drive for such threats, the prior art includes few satisfactory solutions for detecting malicious code loaded into memory or the processor itself.

<FIG> depicts an exemplary prior art computing device <NUM> comprising processor <NUM>, memory <NUM>, and storage device <NUM>. In this example, memory <NUM> is volatile and can comprise DRAM, SRAM, SDRAM, or other known memory devices. Storage device <NUM> is non-volatile and can comprise a hard disk drive, solid state drive, flash memory, or other known storage devices. One of ordinary skill in the art will understand that processor <NUM><NUM> can include a single processor core or multiple processor cores as well as numerous cache memories, as is known in the prior art. Processor <NUM> executes operating system <NUM>. Examples of operating system <NUM> include the operating systems known by the trademarks WINDOWS®by Microsoft, MacOS® and IOS® by Apple, CHROME OS® and ANDROID® by Google, LINUX, and others.

In <FIG>, data is stored in storage device <NUM>. There are numerous mechanisms to store data in storage device <NUM>, and two known mechanisms are shown for illustration purposes. In one mechanism, data is stored as blocks <NUM> and can be accessed by logical block address (LBA) or similar addressing scheme. In another mechanism, data is stored as files <NUM> and can be accessed using a file system. In the prior art, scanning module <NUM> can be executed by processor <NUM> and can scan either blocks <NUM> or files <NUM> to look for malicious code. This often is referred to as virus scan software and is well-suited for identifying and nullifying known malicious programs that are stored in non-volatile devices such as in storage device <NUM>.

While prior art techniques are well-suited for detecting known malicious programs stored in storage device <NUM>, there is no satisfactory technique for detecting malicious instructions that have been injected into memory <NUM> but not stored in storage device <NUM>.

Patent Application Publication No. <CIT> relates to techniques for detecting malicious computer software. For example, a method gathers information about processes and threads executing on a computing device. Instructions executed by a thread that is currently running are monitored. The method performs certain steps if a function to create a process or a function to load a library is called. The steps performed may include examining a thread information block, determining whether an address included in a stack pointer of the thread is in a range of addresses for a stack specified by the thread information block, and determining whether a first plurality of no-operation instructions is followed by shell code that is followed by a second plurality of no-operation instructions.

Patent Application Publication No. <CIT> describes a system and method for detecting malicious code disguised as a normal process by first determining whether a thread generated by a process running on a computer system is generated by malicious code and additionally analyzing a malicious code behavior in a virtual environment when the thread is suspicious to be malicious. In one example, the system includes a malicious code detection module and a forcible malicious code termination module. The malicious code detection module extracts information on a thread generated by a process running on a computer system to identify code related to the thread. It then preliminarily determines whether or not the identified code is malicious and extracts the code preliminarily determined to be malicious. The forcible malicious code termination module finally determines the code as malicious code based on an analysis result of behavior of the extracted code executed in a virtual environment and forcibly terminates execution of the code.

Patent Application Publication No. <CIT>, malware in a computer is found by detecting a sequence of function calls in a memory space of a process executing on a computer, tracing the process stack to locate members of the sequence in a database of non-malicious function calls, failing to locate the sequence in the database, and responding to the failure by a combination of logging the failure, alerting an operator and terminating, blocking or otherwise disabling the process or a system call initiated by the process.

Examples described in U. Patent Application Publication No. <CIT> provide for an electronic device that can be configured to intercept a process, store execution profiling for the process if the process involves a privileged resource or a privileged operation, and analyze the code involved in each stack frame to determine malicious activity. If the process does not involve a privileged resource or a privileged operation, then the process is not analyzed.

Patent Application Publication No. <CIT>, a thread related to an event is identified and a set of software modules of a computer system is enumerated. The thread is verified by determining whether the thread corresponds to one of the software modules. Code related to the thread is verified by loading code segments from storage into memory and comparing newly loaded code with original code segments in memory. The stack is verified by determining whether the thread matches one or more stack addresses of the stack. The execution path related to the event is verified by comparison to a set of predefined execution paths. If any of the security verifications fail, a security event is generated such as by blocking execution of code related to the event.

What is needed is a mechanism for detecting malicious instructions that have been injected into processor <NUM> or memory <NUM> but not stored in storage device <NUM> and generating an alert upon such detection and/or suspending execution of the malicious instructions.

For example, a malicious code detection module identifies potentially malicious instructions in memory of a computing device. The malicious code detection module examines the call stack for each thread running within the operating system of the computing device. Within each call stack, the malicious code detection module identifies the originating module for each stack frame and determines whether the originating module is backed by an image on disk. If an originating module is not backed by an image on disk, the thread containing that originating module is flagged as potentially malicious, execution of the thread optionally is suspended, and an alert is generated for the user or administrator.

Additional aspects of prior art systems will now be described. In <FIG>, processor <NUM> executes operating system <NUM>. Operating system <NUM> can manage multiple threads of instructions that are executed concurrently. Here, exemplary threads <NUM> and <NUM> are depicted, but it is to be understood that additional threads can be executed. Operating system <NUM> maintains a call stack for each thread. Here, exemplary call stack <NUM> is depicted, which is the call stack for thread <NUM>. Threads can be related to one another. For example, in this example, thread <NUM> was initiated by thread <NUM>.

In this simplified example, call stack <NUM> comprises variables <NUM>, <NUM>, and <NUM> and parameter <NUM>, which were placed in call stack <NUM> by thread <NUM>. Return address <NUM> also was placed on call stack <NUM> by thread <NUM>. Return address <NUM> is the address corresponding to the instruction in thread <NUM> that placed stack frame <NUM> in call stack <NUM>. A stack frame is a collection of data placed in a call stack as part of a procedure. Here, stack frame <NUM> comprises variables <NUM> and <NUM>, parameter <NUM>, and return address <NUM>.

Operating system <NUM> further comprises application programming interface (API) module <NUM>, which is a mechanism by which threads can invoke APIs specific to operating system <NUM>.

<FIG> depicts further aspects of the prior art. Here, memory <NUM> contains various types of programs, user data, and unassigned portions. Each of these items is stored in a particular address range within memory <NUM>, and memory <NUM> includes attribute information <NUM> that indicates whether each item is backed by a file stored in storage device <NUM> (e.g., whether that item is "backed on disk"). In this simple example, attribute information <NUM> includes address ranges for operating system <NUM>, utility program <NUM>, application program <NUM>, program <NUM>, user data <NUM>, and an unassigned area <NUM>. Attribute information <NUM> further indicates whether each item is backed by a file in storage device <NUM> or not. Here, all items are in fact backed by a file except for program <NUM>. Attribute information <NUM> typically is established and managed by operating system <NUM>.

With reference now to <FIG>, an embodiment of computing device <NUM> is depicted. Computing device <NUM> comprises processor <NUM><NUM> and operating system <NUM> as in the prior art. Computing device <NUM> further comprises malicious code detection module <NUM>, which comprises lines of code executed by processor <NUM>. Malicious code detection module <NUM> optionally can be part of the kernel of operating system <NUM> or can be code outside of operating system <NUM> that is given special privileges by operating system <NUM>, such as the ability to access attribute information <NUM> and/or to suspend execution of a thread.

The embodiments detect malicious code based on three characteristics that typically are present in malicious code. First, malicious code usually owns a thread of execution. Second, this thread of execution originates or operates from code that is not backed by a file on disk. Third, the thread of execution must call the operating system.

API module <NUM> directly in order for the malicious code to affect appreciable activity on the system. That is, in order for the malicious code to inflict harm, it inevitably must call operating system API module <NUM> directly. Although there are some exceptions, these three features generally are not found in benign application or operating system <NUM> itself.

Malicious code detection module <NUM> first enumerates the call stacks of each thread of execution. In one embodiment, malicious code detection module <NUM> assigns a unique identifier to each call stack. Once enumerated, each call stack is analyzed to determine if it is malicious in nature.

In the simplified example of <FIG>, malicious code detection module <NUM> starts at the top of call stack <NUM> and works down. The top of a call stack is almost always a system call originating from an operating system library. If not, the thread was likely performing a CPU intensive task and the thread is immediately deemed non-malicious. Here, the top of the call stack <NUM> is system call <NUM> (which represents a call made to API module <NUM>), and the analysis therefore continues.

Malicious code detection module continues down call stack <NUM> and determines the originating module for each stack frame in the reverse order in which the stack frames were added to call stack <NUM>. Here, stack frames <NUM> and <NUM> are shown. Malicious code detection module <NUM> determines the return address for stack frames <NUM> and <NUM>, which here are return addresses <NUM> and <NUM>, and determines the procedure within thread <NUM> associated with the return address. Malicious code detection module <NUM> then consults attribute information <NUM> to determine whether the code in which that procedure is contained is backed by a file in storage device <NUM>. If it is (as would be the case if the procedure is part of application program <NUM>), then the procedure and the thread containing it are deemed non-malicious. If it is not (as would be the case if the procedure is part of program <NUM>), then the procedure and the thread containing it are deemed potentially malicious.

With reference to <FIG>, when malicious code detection module <NUM> determines that a procedure and the thread containing it are potentially malicious, it optionally suspends the thread (if operating system <NUM> has given malicious code detection module <NUM> permission to perform such an action) and/or it generates alert <NUM>.

If suspended, thread <NUM> will not resume execution unless and until a user or administrator expressly instructs computing device <NUM> to proceed with execution of thread <NUM>.

Alert <NUM> can take any variety of forms. Alert <NUM> can be a message displayed on a display operated by a user or administrator. Alert <NUM> also might be an email, SMS message, MMS message, or other message sent to a device operated by a user or administrator. Alert <NUM> also might be an audible sound generated by computing device <NUM>.

With reference again to <FIG>, it is understood that each stack frame is analyzed in the reverse order in which the stack frame was added to the call stack. Optionally, malicious code detection module <NUM> can stop this analysis when threshold/event <NUM> is reached. Examples of different threshold/event <NUM> possibilities include: (<NUM>) Malicious code detection module <NUM> can analyze X stack frames and then stop; (<NUM>) Malicious code detection module <NUM> can analyze the stack frames that were added to call stack <NUM> within the last Y seconds; (<NUM>) Malicious code detection module <NUM> can analyze the stack frames that were added to call stack <NUM> since the last analysis performed by malicious code detection module <NUM> was performed on call stack <NUM>; or (<NUM>) Malicious code detection module <NUM> can analyze the stack frames until it identifies a return address associated with a certain type of procedure. This type of limitation might be desirable because call stacks can become very large, and continuing the analysis indefinitely may slow down processor <NUM> in performing other tasks.

Claim 1:
A method of detecting malicious code in a computing device (<NUM>) comprising a processor (<NUM>) executing an operating system (<NUM>) and a malicious code detection module (<NUM>), memory (<NUM>), and a non-volatile storage device (<NUM>), the method comprising:
identifying, by the malicious code detection module (<NUM>), a call stack (<NUM>) for a thread of execution (<NUM>, <NUM>) within the operating system (<NUM>);
determining, by the malicious code detection module (<NUM>), an originating module that initiated a stack frame (<NUM>, <NUM>) in the call stack (<NUM>);
determining, by the malicious code detection module (<NUM>), whether the originating module has been injected into the processor (<NUM>) or the memory (<NUM>), but is not backed by a file (<NUM>) stored in the non-volatile storage device (<NUM>); and
generating an alert (<NUM>), by the malicious code detection module (<NUM>), if the originating module is not backed by a file (<NUM>) stored in the non-volatile storage device (<NUM>).