Patent Description:
Windows® PowerShell® is a scripting engine and language that is included in more recent versions of the Windows® operating system. PowerShell® provides access to various operating system components and can be exploited by malware. Because PowerShell® can run scripts directly in memory, detection methods based on file content are not reliable. The same is true of other scripting engines and languages such as JavaScript®, Jscript, VBScript®, PerlScript, BASIC, Ruby, Visual Basic for Applications (VBA) etc. <CIT> discloses sub-extension execution environment controller which may be configured to control the behavior of a sub-execution environment. <CIT> discloses a device for receiving and processing data content having at least one original function call which includes a hook script generator and a script processing engine.

Accordingly the present invention is defined by the appended independent method claim <NUM> and independent apparatus claim <NUM>.

Implementations described herein provide enhanced visibility of and protection from malware that is designed to exploit the capabilities of certain types of scripting engines. Specifically, the described techniques can be implemented to detect and block malicious command content (e.g., commands and command scripts) from being executed by these scripting engines.

A scripting engine typically exposes a command line or graphical user interface that a person can use to control various computer settings. Some scripting engines allow command-based access to low-level computer parameters, settings, and information. Scripting commands are typically human-readable text strings, formatted in a language that corresponds to the particular scripting engine. The scripting engine interprets the commands at run-time to produce machine code that is executed by a computer (e.g., using a just-in-time, JIT, compiler), or to otherwise carry out program instructions (e.g., as in some non-JIT interpreters).

In some scenarios, a person may manually and interactively type commands to be submitted to the scripting engine. In addition, the functionality of a scripting engine is sometimes provided as a hosted software component that can be loaded, run, and utilized by a host process. A host process may use the scripting engine to execute command-line commands as well as to execute scripts that comprise multiple commands. An attacker might use this functionality to execute commands that impair or compromise a computer.

As an example of a scripting engine, the PowerShell® scripting engine is available for use within the Windows® operating system environment. The PowerShell® scripting engine is a software component that can be loaded and used by a host process. A user-facing shell application, which is referred to as the PowerShell® interactive UI shell, is also available for use with the PowerShell® scripting engine. The PowerShell® interactive UI shell allows a user to interactively enter commands and write, test, and debug scripts in a Windows®-based graphic user interface.

In use, the PowerShell® interactive UI shell is a host process that hosts an instance of the PowerShell® scripting engine and that submits interactively entered script commands to the PowerShell® scripting engine for execution. The PowerShell® scripting engine may also be hosted by other processes, which might seek to use the PowerShell® capabilities to attack various aspects of a computer and its network.

In addition to its use within the PowerShell® interactive UI shell, the PowerShell® scripting engine can be loaded and used by other user-mode host processes. In particular, user-mode processes, including the PowerShell® interactive UI shell, can create an instance of the PowerShell® scripting engine and submit commands to it.

Scripting engines are available for various different command languages, such as JavaScript®, JScript, VBScript®, PerlScript, BASIC, Ruby, Visual Basic for Applications (VBA), etc. Scripting engines for these languages may also be loaded by a host process and used to execute various types of commands and command scripts, including commands and scripts that access and/or modify system-level parameters and data.

In some examples described herein a scripting engine may be implemented to run within a run-time system such as the Common Language Run-time (CLR). Software written to run under the management of a run-time system includes intermediate-level code (sometimes referred to as "bytecode") that is compiled at run time into machine code, which is in turn executed by a computer central processing unit (CPU). A run-time code manager such as CLR manages code execution and in addition provides run-time services such as thread management, garbage collection, memory management, run-time reference checking, etc..

Code written to be to run within the CLR or another managed run-time environment is referred to as managed code. A software component or module using managed code is referred to as a managed software component or module. In the CLR environment, managed code is generated in accordance with what is known as the Common Language Infrastructure (CLI). C# compilers are typically used to generate CLI code for execution under the management of CLR.

In contrast, C and C++ compilers produce machine code that is executed directly by a CPU, without the benefit of run-time management and services. This type of code is referred to as unmanaged code. A software component or module using unmanaged code is referred to as an unmanaged software component or module.

Managed and unmanaged software modules are often packaged as dynamic link libraries and referred to as DLLs. A DLL written in C# is referred to as a managed DLL module. A DLL written in C or C++ is referred to as an unmanaged DLL module.

In order to detect malware and potentially malicious activities, it may be desired to monitor commands, including commands that are part of scripts, that a host process attempts to execute with a scripting engine. A software component referred to herein as a threat detection component may be configured to perform monitoring such as this. The threat detection component may be part of a larger malware detection system.

The threat detection component is configured to inject an unmanaged interface module into the host process. The unmanaged interface module is configured to detect situations in which the host process is loading a run-time system (e.g., CLR) or a scripting engine (e.g., the PowerShell® scripting engine, JScript scripting engine, or other scripting engine), and, in response, to load a managed interface module into the host process. The managed interface module hooks into relevant methods of a scripting engine to intercept commands before they are executed and to block commands if they are determined to be potentially harmful.

The managed interface module and the unmanaged interface module are configured to communicate with each other within the host process. The unmanaged interface module is also configured to communicate with the threat detection component, thereby forming a bidirectional communication channel between the managed interface module and the threat detection component.

In operation, the managed interface module intercepts commands before they are executed by the scripting engine, and sends them to the threat detection module through the unmanaged interface module. The threat detection component determines whether the script commands should be blocked, and if so, communicates that determination through the unmanaged interface module to the managed interface module. The managed interface module then blocks the script commands via its hooks into the scripting engine.

Although certain details are described herein with reference to the PowerShell® scripting engine, the same or similar techniques may be applied to scripting engines for different scripting languages such as JScript® and various other scripting languages.

As used herein, the terms "component," "module," and similar terms are intended to represent example divisions of the described operations (e.g., implemented in software or hardware) for purposes of discussion, and is not intended to represent any type of requirement or required method, manner or organization. Therefore, while various components and modules are discussed herein, their functionality or similar functionality can be arranged differently (e.g., combined into a smaller number of modules, broken into a larger number of modules, etc.).

<FIG> illustrates a software configuration, implemented on a computer <NUM>, that allows monitoring and blocking of command content that is submitted by a host process <NUM> for execution by an instance of a hosted scripting engine <NUM>. As used herein, the term "command content" refers to any combination of one or more commands and/or command scripts that are formatted to be interpreted at run-time and that are intended for execution by a command execution component such as is commonly referred to as a scripting engine. A script comprises one or more commands that are executed together. A command may in some embodiments comprise textual data, such as text strings, in a format that is readable, writable, and understandable by human operators. For example, commands may comprise ASCII strings. Command content may include script files, typed command strings, dynamically executed strings executed via the Invoke-Expression cmdlet of the PowerShell® scripting engine, commands supplied as command line parameters, etc..

Command content may in some cases be entered interactively by a person using a command line interface shell. For example, the Windows® PowerShell® interactive UI shell may be used to interactively enter commands to be executed by the PowerShell® scripting engine.

In the illustrated example, the host process <NUM> is a non-privileged, user-mode process. As one example, the host process <NUM> may comprise a user-installed application or any other computer software, including malware. As another example, the host process <NUM> may comprise a user interface (UI) shell for the scripting engine <NUM>, such as the PowerShell® interactive UI shell.

The host process <NUM> in this example includes managed code that runs under the management of a run-time system <NUM>, also referred to herein as a run-time code manager. For example, the run-time system <NUM> may comprise the Common Language Run-time (CLR). The host process <NUM> may utilize managed code developed in the. NET Framework or. NET Core environments for execution within CLR.

The host process <NUM> may be implemented by an application. The functions and operations of such an application are represented in <FIG> as application logic <NUM>. An attacker may provide or modify the application logic <NUM> so that it executes harmful command content using the scripting engine <NUM>. The application logic <NUM> may be implemented managed and/or unmanaged code.

In the illustrated embodiment, the scripting engine <NUM> comprises a hosted command interpreter that interprets and executes command content at run-time. For example, the scripting engine <NUM> may comprise an instance of the Windows® PowerShell® scripting engine, which is hosted as a managed software component within the host process <NUM>. In other embodiments, the scripting engine <NUM> may comprise a scripting engine for any other scripting language, including scripting engines that support JavaScript®, Jscript, VBScript®, PerlScript, BASIC, Ruby, Visual Basic for Applications (VBA) and other scripting languages.

The scripting engine <NUM> has one or more APIs that expose various methods <NUM> for access and use by the application logic <NUM> of the host process <NUM>. Most relevant to this discussion, the methods <NUM> allow the application logic <NUM> to submit command content for execution by the scripting engine <NUM>. In some cases, the application logic <NUM> may provide command content without user interaction. In other cases, such as when the host process <NUM> is the PowerShell® interactive UI shell, the application logic <NUM> may accept command content that is entered interactively by a user and may provide the command content to the scripting engine <NUM> through the methods <NUM>.

A threat detection component <NUM> is installed on the computer <NUM> as a privileged, kernel-mode component. The threat detection component <NUM> may implement various techniques for receiving intercepted command content, for determining whether to block the command content, and for blocking execution of potentially harmful software. Note that the threat detection component <NUM> is shown here as a representation of logical functionality that may be performed by any of various software components, and which may in some cases be performed by multiple software components. Generally, the threat detection component <NUM> comprises instructions for performing certain actions described herein. The instructions are represented in memory of the computer <NUM> as code that is executed by one or more processors of the computer <NUM>.

An unmanaged interface module <NUM> and a managed interface module <NUM> are used for communications between the host process <NUM> and the threat detection component <NUM>. In some embodiments, each of the modules <NUM> and <NUM> may comprise a dynamic link library (DLL), each of which comprises instructions for performing actions as described herein. In the case of the managed interface module <NUM>, the instructions are represented by managed code that is written for execution under the management of the run-time system <NUM>. In the case of the unmanaged interface module <NUM>, the instructions are represented by unmanaged code that executes outside of the run-time system <NUM>. The various software components and modules shown in <FIG> may communicate with each other using APIs (not shown) that are created and/or provided for that purpose.

Generally, the unmanaged interface module <NUM> and the managed interface module <NUM> work together to intercept command content from the scripting engine <NUM> and to provide the command content to the threat detection component <NUM> so that the threat detection component <NUM> can determine whether the command content should be blocked.

The threat detection component <NUM>, the unmanaged interface module <NUM>, and the managed interface module <NUM> may be configured to operate in either of two modes, referred to as "interpreter-only" mode and "full-visibility" mode. The interpreter-only mode is used to monitor command content provided by an interactive UI shell (UI) shell such as the PowerShell® interactive UI shell. In this case, the interactive UI shell is the host process <NUM> and provides interactively typed command content to the scripting engine <NUM>. The full-visibility mode is used to monitor commands that are provided not only by the user interface shell, but also by any other host process that uses the scripting engine <NUM>.

In the interpreter-only mode, the threat detection component <NUM> injects the unmanaged interface module <NUM> into the host process <NUM> when the host process <NUM> is identified as an interactive UI shell such as the PowerShell® interactive UI shell. In the full-visibility mode, the threat detection component <NUM> injects the unmanaged interface module <NUM> into the host process <NUM> when the host process <NUM> performs actions indicating that the scripting engine <NUM> or the run-time system <NUM> is going to be loaded.

The unmanaged interface module <NUM> is configured to detect when the host process <NUM> is loading either the scripting engine <NUM> or the run-time system <NUM>. In response, the unmanaged interface module <NUM> injects the managed interface module <NUM> into the host process <NUM>.

The managed interface module <NUM> is configured to intercept command content before its execution by the scripting engine <NUM>. When (managed) modules implementing certain of the methods <NUM> are loaded, the managed interface module <NUM> installs inline hooks in them in order to intercept command content and to block execution of command content that is determined to be harmful or potentially harmful. When a call to a particular function is intercepted by a component, the component may respond by calling the particular function again using the same or different arguments. In some cases, the component may be configured to not call to the particular function, in order to prevent the function from being executed. Alternatively, the component may call a different function or invoke other functionality. In some cases, the component may throw an exception to prevent the function from executing against the command content. In the action <NUM>, this capability is used to intercept calls to appropriate API methods of the scripting engine <NUM>.

NET Framework environment, inline hooking uses a technology called reflection, provided by the run-time system, to obtain metadata of the target function. Methods such as RuntimeHelpers. PrepareMethod, RuntimeHelpers. CompileMethod, or RuntimeMethodHandle. GetFunctionPointer are used to generate and obtain the address of native code to hook.

The unmanaged interface module <NUM> and the managed interface module <NUM> provide a bi-directional communication path between the threat detection component <NUM> and the hooked methods of the scripting engine <NUM>. The unmanaged interface module <NUM> is configured to relay communications, including intercepted command content, between the threat detection component <NUM> and the managed interface module <NUM>. For example, the unmanaged interface module <NUM> may relay intercepted command content from the managed interface module <NUM> to the threat detection component <NUM>. Similarly, the unmanaged interface module <NUM> may relay responses from the threat detection component <NUM> to the managed interface module <NUM>, such as responses indicating whether to block command content.

When command content is received by the threat detection component <NUM>, the threat detection component <NUM> determines whether the command content should be blocked from execution and communicates this determination back to the managed interface module <NUM> through the unmanaged interface module <NUM>. If the command content is to be blocked, the managed interface module <NUM> prevents the command content from being executed by the scripting engine <NUM>.

In some implementations, the threat detection component <NUM> may receive command content and determine that it is safe to execute. In this case, the thread detection component may provide a reply that contains the original command content, and the managed interface module <NUM> may return that original command content to the hooked method from which it was originally obtained. In the case that the threat detection component <NUM> determines that the command content should be blocked, the managed interface module <NUM> may throw an exception, which effectively blocks execution of the command content. Alternatively, the reply from the threat detection component <NUM> may specify modified command content, such as a null string or modified command string, which the managed interface module <NUM> returns to the hooked method to effectively block execution of the original command content. In some cases, blocking the command content may comprise "faking" the success of an operation by returning modified command content such that the hooked method reports successful execution even though the original command content was not executed.

In other implementations, the threat detection component <NUM> may provide a reply as a directive indicating that the original command content should be blocked. In these implementations, the managed interface module <NUM> may interact with the hooked method in a way that result in the command content being blocked, such as by returning a null string to the hooked method rather than the original command content.

<FIG> illustrates a software configuration for use with scripting engines that are implemented using unmanaged code and that do not run under management of a run-time system. Scripting engines such as this include JavaScript®, Jscript, VBScript®, PerlScript, BASIC, Ruby, Visual Basic for Applications (VBA) etc. The configuration of <FIG> is similar to that of <FIG>, except as described below.

<FIG> shows the computer <NUM>, a host process <NUM>, and a scripting engine <NUM>. In this example, the host process does not necessarily include managed code, and may not use a run-time system. In the illustrated example, the host process <NUM> is a non-privileged, user-mode process. As one example, the host process <NUM> may comprise a user-installed application or any other computer software, including malware. The application implements application logic <NUM> for performing its intended functions. In some cases, the host process <NUM> may comprise a user interface (UI) shell for the scripting engine <NUM>.

In the illustrated embodiment, the scripting engine <NUM> comprises a hosted command interpreter that interprets and executes command content at run-time. For example, the scripting engine <NUM> may comprise an instance of the JScript® scripting engine, which is hosted as an unmanaged software component within the host process <NUM>. In other embodiments, the scripting engine <NUM> may comprise a scripting engine for any other scripting language, including scripting engines that support JavaScript®, VBScript®, PerlScript, BASIC, Ruby, Visual Basic for Applications (VBA) and other scripting languages.

A threat detection component <NUM> is installed on the computer <NUM> as a privileged, kernel-mode component. The threat detection component <NUM> may implement various techniques for receiving intercepted command content, for determining whether to block the command content, and for blocking execution of potentially harmful software. The threat detection component <NUM> is shown here as a representation of logical functionality that may be performed by any of various software components, and which may in some cases be performed by multiple software components. Generally, the threat detection component <NUM> comprises instructions for performing certain actions described herein. The instructions are represented in memory of the computer <NUM> as code that is executed by one or more processors of the computer <NUM>.

In this example, an unmanaged interface module <NUM> is used to intercept command content and to provide it to the threat detection component. The unmanaged interface module <NUM> is injected into the host process <NUM> when the threat detection component <NUM> determines that the host process <NUM> is a process that runs a script engine such as the scripting engine <NUM>. The unmanaged interface module <NUM> is injected in the same manner as the unmanaged interface module <NUM>.

The unmanaged interface module <NUM> provides for communications between the host process <NUM> and the threat detection component <NUM>. In some embodiments, the unmanaged interface module <NUM> may comprise a dynamic link library (DLL), which comprises instructions for performing actions as described herein. The various software components and modules shown in <FIG> may communicate with each other using APIs (not shown) that are created and/or provided for that purpose.

The unmanaged interface module <NUM> monitors to detect loading of the scripting engine <NUM> and installs hooks into relevant methods <NUM> of the scripting engine <NUM> in order to intercept command content before it is executed by the scripting engine <NUM> and to send the command content to the threat detection component <NUM>. The unmanaged interface module <NUM> also receives communications back from the threat detection component <NUM> that instruct the unmanaged interface module whether or not to block execution of command content. The evaluation of command content by the threat detection component <NUM> is performed in the same way as described above with reference to <FIG>.

In some embodiments, an Antimalware Scan Interface (AMSI) may be available. AMSI is a software component used in the Windows® operating system environment. AMSI has APIs that allow antimalware applications, such as the threat detection component <NUM>, to scan command content before it is executed by the scripting engine <NUM>. In cases where AMSI is present, it may be used, and the unmanaged interface module may interface with the AMSI rather than hooking into the scripting engine <NUM>. Also, when AMSI is present the unmanaged interface module <NUM> can be loaded automatically by AMSI.

<FIG>, and <FIG> illustrate example techniques as logical flow graphs, each action of which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the case of software, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited action. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and/or in parallel to implement any illustrated technique.

The use of two different interface modules, one of which is managed and the other of which is unmanaged, allows for reliable detection of loaded modules in different situations. In particular, the managed code allows reliable detection of managed modules such as the scripting engine <NUM>. Unmanaged code is not able to reliably do this. In addition, unmanaged code is not able to locate appropriate methods of the scripting engine <NUM> in order to install hooks.

Because of system limitations, however, the kernel-mode threat detection module <NUM> cannot inject managed code directly into the host process <NUM>.

<FIG> illustrates an example technique <NUM> that may be performed by the threat detection component <NUM> (or another system component, and likewise throughout the remainder of this document) to inject the unmanaged interface module <NUM> into the host process <NUM>. The technique <NUM> may be used in conjunction with the techniques described below with respect to <FIG>, and <FIG>, for blocking harmful command content from being executing by a scripting engine.

An action <NUM> comprises identifying an executing process, referred to herein as the host process <NUM>, that is implemented using managed code and which therefore executes under management of the run-time system <NUM>. For example, the action <NUM> may comprise identifying a. NET Framework or. NET Core process (i.e., an application developed in the. NET Framework or. NET Core environments).

In the full-visibility mode, the action <NUM> may comprise determining that a process is going to load the run-time system <NUM> for use. In the CLR environment, for example, this may be accomplished by detecting that a file named mscoree. dll or coreclr. dll is loaded or is being loaded by the host process <NUM>. dll and coreclr. dll are software modules that load the CLR run-time system.

In the interactive-only mode, the action <NUM> may comprise identifying a user interface shell such as the PowerShell® interactive UI shell, which as described above is a host process that hosts the scripting engine <NUM> and provides interactively entered command content to the scripting engine <NUM>.

An action <NUM>, performed by the threat detection component <NUM> in response to the action <NUM> of identifying the host process <NUM>, comprises injecting the unmanaged interface module <NUM> into the host process <NUM>. This may be performed by redirecting a thread of the host process <NUM> using Asynchronous Procedure Call (APC), and more specifically by using the kernel-mode API named KeInsertQueueApc. The redirected thread is used to queue a job to a thread pool. The job performs the action <NUM> of loading (i.e., "injecting"), the unmanaged interface module <NUM>. The job may be submitted to the thread pool via the user-mode API named SubmitThreadpoolWork, as an example.

If a host process is not identified in the action <NUM>, the action <NUM> is repeated to continue monitoring for such host processes. The technique <NUM> therefore runs continuously or continually to detect multiple host processes that may be loaded over time.

<FIG> illustrates an example technique <NUM> that may be performed by the unmanaged interface module <NUM> to inject the managed interface module <NUM> into the host process <NUM>. The technique <NUM> may be used in conjunction with the techniques described herein with respect to <FIG>, and <FIG>. For example, the technique <NUM> may be performed by the unmanaged interface module <NUM> after the unmanaged interface module <NUM> is injected.

An action <NUM> comprises detecting loading of the run-time system <NUM>. In some cases, this may be performed by detecting the loading by the host process <NUM> of a target software component that implies the use of a run-time system such as CLR. More specifically, the action <NUM> may comprise detecting that any of the components clrjit. dll, coreclr. dll and mscorjit. dll are being or have been loaded. dll, coreclr. dll and mscorjit. dll are modules implementing the CLR run-time system. Other DLLs can additionally or alternatively be detected as indications that the run-time system <NUM> is being loaded. The action <NUM> may be performed by registering for callbacks with the OS link loader.

An action <NUM> is performed if the run-time system <NUM> is not detected in the action <NUM>. The action <NUM> comprises detecting the loading of the scripting engine <NUM>. In some cases, this may be performed by detecting the loading, by the host process <NUM>, of a DLL module corresponding to the scripting engine <NUM>. For example, the action <NUM> may comprise detecting whether either of the components System. Management. Automation. dll or System. Management. Automation. dll are being or have been loaded. Management. Automation. dll and System. Management. Automation. dll are modules implementing the Windows® PowerShell® engine. Other DLL modules can additionally or alternatively be detected as indications that the scripting engine <NUM> is being loaded, including modules that implement the JScript® scripting engine and/or other scripting engines. DLL detection can be performed as discussed herein with reference to action <NUM>, using the kernel-mode callback API named PsSetLoadImageNotifyRoutine.

An action <NUM> may be initiated in response to detecting that the scripting engine <NUM> or the run-time system <NUM> have been or are being loaded as determined in the actions <NUM> and <NUM>. The action <NUM> comprises injecting the managed interface module <NUM> into the host process <NUM>. The managed interface module <NUM> comprises managed code configured to execute under the management of the run-time system <NUM>.

Injecting the managed interface module <NUM> may be performed by retrieving an interface that allows the unmanaged interface module <NUM> to interact with the CLR. The CoCreateInstance API may be used on older versions of Powershell. The ICLRRuntimeInfoGetInterface may be used for newer Powershell versions. The unmanaged interface module <NUM> then instructs the CLR to load the managed interface component <NUM> using the retrieved interface. The AppDomainCreateInstanceFrom API may be used for this purpose.

If it is not determined that the scripting engine <NUM> or the run-time system <NUM> are being loaded, the technique <NUM> is repeated to continue monitoring for loading of the scripting engine <NUM> or the run-time system <NUM>. The technique <NUM> runs repeatedly to detect and respond to the loading of multiple instances of the scripting engine <NUM> within the host process <NUM>. For example, it is possible to concurrently run different versions of the Windows® PowerShell® engine within the same process. Repeating the technique <NUM> allows detection of multiple PowerShell® engine instances.

<FIG> illustrates an example technique <NUM> that may be performed by the managed interface module <NUM> to insert inline hooks into certain of the methods <NUM> in order to intercept command content. The technique <NUM> may be used in conjunction with the techniques described herein with respect to <FIG>, and <FIG>. For example, technique <NUM> may be performed by the managed interface module <NUM> after the managed interface module <NUM> is injected (action <NUM>).

An action <NUM> comprises determining whether one or more target assemblies of a target software component have been loaded. More specifically, the action <NUM> may comprise detecting the loading by the host process <NUM> of certain scripting engine assemblies. In particular, the managed interface module <NUM> detects the loading of certain components (e.g., assemblies) of the scripting engine <NUM> that are used when processing command content. Detecting that these target assemblies have been loaded may be performed using callback techniques that are analogous to those described above with reference to the actions <NUM> and <NUM>, except that a C# (or other CLR) API is used rather than a C++ API. Specifically, the AppDomain_AssemblyLoad event callback may be used. Depending on the PowerShell® version, the target assemblies may include System. Management. Automation and/or Microsoft. PowerShell.

An action <NUM>, performed by the managed interface module <NUM> in response to determining that one or more target assemblies have been loaded, comprises installing inline hooks in certain methods of these assemblies, to intercept command content before it is executed by the scripting engine <NUM>. NET Framework, inline hooking is performed using a method called PrepareMethod. NET Core environment, inline hooking may be performed using an undocumented method called _CompileMethod.

The methods that are hooked are methods that are invoked prior to execution of any command content. Table <NUM> below indicates the methods that are hooked in an example implementation. Table <NUM> also indicates the target assemblies that contain the hooked methods for different versions of PowerShell®.

After the techniques <NUM>, <NUM>, and <NUM> have been performed, there is a communication path from the hooked methods <NUM>, through the managed interface module <NUM>, through the unmanaged interface module <NUM>, to the threat detection component <NUM>. When a hooked method of the scripting engine <NUM> is invoked, the managed interface module <NUM> receives a callback, obtains the command content, and forwards the command content to the threat detection component <NUM>. The threat detection provides a reply to either allow or prevent execution of the command content.

Using this technique, the unmanaged software module <NUM> and the managed interface module <NUM> interface between the threat detection component <NUM> and the host process <NUM>, thereby limiting the amount of customization that is needed to the threat detection component <NUM> in order to intercept command content. The technique also allows the detection of more than one instance of a scripting engine within a managed process. For example, a given process may run PowerShell® versions <NUM> and <NUM> concurrently. The techniques described above allow the unmanaged interface module <NUM> to detect and hook both versions. In addition, the techniques allow detection not only of command scripts that are about to be executed, but also of interactively typed commands. This is because all script commands are processed by the hooked methods, whether the commands originate from a command script provided by a host process or from an interactively typed command.

<FIG> illustrates an example technique <NUM> that may be performed by a computer for blocking harmful command content from being executed by a scripting engine. The technique <NUM> may be used in conjunction with the techniques described herein with respect to <FIG>.

In the described embodiment, actions on the left of <FIG> are performed by the managed interface module <NUM> (e.g., after action <NUM>) and/or the unmanaged interface module <NUM> (e.g., after action <NUM>). In the described embodiment, actions on the right of <FIG> are performed by the threat detection component <NUM>.

An action <NUM> comprises intercepting command content that has been submitted to the scripting engine <NUM> for execution. In some embodiments, the action <NUM> may comprise using hooking techniques described above, in which hooks are placed in certain methods such as those shown in Table <NUM>, above. For example, the action <NUM> can be performed after the action <NUM>. The action <NUM> can include receiving command content that is about to be processed by the scripting engine. In many cases, the intercepted command content will be returned to the scripting engine for normal processing. In some cases, however, the action <NUM> may comprise throwing an exception to block execution of the command content. In other cases, the command content may not be returned to the scripting engine, or may be modified before it is returned, thereby effectively blocking the command content.

An action <NUM> comprises sending the intercepted command content to the threat detection component <NUM>. In described embodiments, this may comprise communicating the command content from the managed interface module <NUM>, to the unmanaged interface module <NUM>, which in turn relays the command content to the threat detection component <NUM>.

An action <NUM>, performed by the threat detection component <NUM>, comprises receiving the command content.

An action <NUM> comprises analyzing the command content to determine whether it should be blocked. If the action <NUM> determines that the command content should be blocked, an action <NUM> is performed, comprising setting a RESULT variable to "True". If the action <NUM> determines that the command content does not need to be blocked, an action <NUM> is performed, comprising setting the RESULT variable to "false". The RESULT variable can be represented as a Boolean variable, a number, a string, a bit flag, or another type of data.

In some embodiments, the action <NUM> may use precompiled regular expressions to detect malicious commands. Regular expression checking may be used to identify commands having malicious patterns. Expression checking such as this may be used for script files as well as interactively-typed commands. In the case of a script file, a hash of the file is compared against hashes of known malicious script files to determine whether the script file is malicious.

An action <NUM> is then performed, which comprises communicating to the managed interface module <NUM>, through the unmanaged interface module <NUM>, to either block the intercepted command content or to allow execution of the intercepted command content. In the described example, the action <NUM> comprises sending a reply to the managed interface module <NUM> via the unmanaged interface module <NUM>, where the reply specifies the RESULT value.

An action <NUM>, performed by the unmanaged interface module <NUM> and/or the managed interface module <NUM>, comprises receiving a reply specifying the RESULT variable.

Communications between the kernel-mode threat detection component <NUM> and the user-mode unmanaged interface module <NUM> are implemented as data objects copied into and from the kernel mode. Communications between the unmanaged interface module <NUM> and the managed interface module <NUM> may be performed using APIs that are implemented by the interfaces for that purpose.

In response to receiving the RESULT variable, an action <NUM> is performed of determining whether the RESULT variable is true or false (as expressed in the data type of the RESULT variable). If the RESULT variable is true, an action <NUM> is performed of blocking the intercepted command content, where the term "blocking" indicates that the intercepted command content is prevented from being executed by the scripting engine <NUM>, e.g., as discussed below. If the RESULT variable is "false", an action <NUM> is performed of allowing or causing the command content to be execute by the scripting engine <NUM>. In some cases, the command content may also be quarantined, such as by moving resources responsible for the command content to a different location on the storage of the computer.

The managed interface module <NUM> may block command content in various ways, depending on the details of the inline hooking that have been implemented. If no blocking is performed, for example, the action <NUM> may comprise calling the method that was hooked with the original arguments (e.g., the originally specified command content). If blocking is performed, the action <NUM> may comprise not calling the method, and throwing an exception. In some cases, the action <NUM> may comprise calling the method with altered arguments.

Communicating the result of the analyzing action <NUM> to the unmanaged interface module <NUM> and/or the managed interface module <NUM> may also be performed in various different ways, not limited to returning a true/false value as described above. For example, the reply from the threat detection component <NUM> might specify either the originally obtained command content (for no blocking) or modified command content (for blocking), where the modified command content is modified in a way such that its execution will not be harmful. The modified command content may for example comprise a null string or a command that displays an error message. The managed interface module <NUM> receives the reply and the specified command string, and calls the hooked method with this command string as an argument. This can be used to effectively block execution of the original command string.

In cases where the Windows® Antimalware Scan Interface (AMSI) is available, the managed interface module <NUM> may not be needed, and the unmanaged interface module <NUM> may communicate with AMSI directly to intercept and block command content. Specifically, the unmanaged interface module <NUM> may be registered as an AMSI provider to receive intercepted command content. The registering may be in lieu of the action <NUM>, for example, and the technique <NUM> may be omitted or performed by AMSI.

The example techniques are described herein in the context of detecting activities of malware or of attackers. However, the techniques may also apply to other non-malicious software, processes, or other system components. For example, techniques described herein can be used in determining which processes are accessing particular files or other system resources, or in analyzing causes of excess resource usage by processes. Accordingly, techniques discussed herein for analyzing scripts may be used by, among others, anti-malware security researchers, white-hat vulnerability researchers, or other analysts of event streams.

<FIG> illustrates an example technique <NUM> that may be performed by a computer for blocking command content from being executed by a scripting engine.

An action <NUM>, which may be performed by a threat detection component, comprises identifying a host process having first managed code that executes under management of a run-time system. In some embodiments, the action <NUM> may be performed as described above with reference to the action <NUM> of <FIG>.

An action <NUM>, which may be performed by the threat detection component in response to identifying the host process, comprises injecting an unmanaged interface module into the host process, wherein the unmanaged interface module comprises unmanaged code. In some embodiments, the action <NUM> may be performed above as described with reference to the action <NUM> of <FIG>.

An action <NUM>, which may be performed by the unmanaged interface module, comprises detecting loading of a target software component by the host process. In some embodiments, the action <NUM> may be performed as described above with reference to the actions <NUM> and <NUM> of <FIG>.

An action <NUM>, which may be performed by the unmanaged interface module in response to detecting the loading of the target software component, comprises injecting a managed interface module into the host process. The managed interface module comprises managed code that executes under the management of the run-time code manage. The managed interface module is configured to intercept command content before its execution by the scripting engine. In some embodiments, the action <NUM> may be performed above as described with reference to the action <NUM> of <FIG>.

An action <NUM> comprises communicating an intercepted command from the managed interface module, through the unmanaged interface module, and to the threat detection component. In some embodiments, the action <NUM> may be performed above as described with reference to the action <NUM> of <FIG>.

An action <NUM> comprises communicating a reply from the threat detection component, through the unmanaged interface module, to the managed interface module, wherein the reply is to block the intercepted command. In some embodiments, the action <NUM> may be performed above as described with reference to the action <NUM> of <FIG>.

An action <NUM>, performed by the managed interface module in response to the reply, comprises preventing the intercepted command content from being executed by the scripting engine. In some embodiments, the action <NUM> may be performed above as described with reference to the actions <NUM>, <NUM>, and <NUM> of <FIG>.

<FIG> generally illustrates further details of the computer <NUM> and an example environment <NUM> in which the described techniques may be implemented. The computer <NUM> may be communicatively connected to an adversary system <NUM> and a security service <NUM> via a network <NUM>. The computer <NUM>, the adversary system <NUM>, and the security service <NUM> may each be or include a computing device, such as a PC, a laptop computer, a server, a server farm(s), a mainframe, a tablet computer, a work station, a telecommunication device, a PDA, a media player, a media center device, a PVR, a television, an electronic book reader, a set-top box, a camera, a video game console, a kiosk, a gaming device, processor(s), integrated components for inclusion in a computing device, an appliance, an electronic device for inclusion in vehicles, a gaming device, or any other sort of device. For example, the security service <NUM> may be implemented as a remote security system (e.g., a cloud security service) or an on-premises security appliance. In some examples, the security service <NUM> can be deployed as a computing appliance operated by or on behalf of a particular user, group, or organization. For example, a corporation may deploy an appliance per office site, per division, or for the company as a whole. In some examples, the computing appliance can be a central, single-tenant, on-premises appliance. In some examples, a computing appliance can be used to implement at least a portion of security service <NUM> in addition to, or instead of, a cloud service.

In various embodiments, the adversary system <NUM> may be associated with any security exploit which is directed to a vulnerability of the computer <NUM>. The adversary system <NUM> may provide the security exploit to the computer <NUM> in some manner, such as by way of user-mode host process, as described above, that exploits capabilities of a hosted scripting engine. In some examples, an adversary may install malware directly on the computer <NUM>, e.g., via network <NUM> or other attack vectors (such as a thumb drive). Accordingly, techniques <NUM>-<NUM> may be used independently of whether an adversary system <NUM> is actively connected to the computer <NUM> via the network <NUM> at any given time.

In certain embodiments, the security service <NUM> may install the threat detection component <NUM> on the computer <NUM>, and the threat detection component <NUM> may then communicate with the security service <NUM> to provide threat detection, system monitoring, and threat remediation services.

The network <NUM> may be any sort of network or networks that connect the computer <NUM>, adversary system <NUM>, and security service <NUM>. Also, the network <NUM> may connect any of the computer <NUM>, adversary system <NUM>, and security service <NUM> to other devices. The network <NUM> may be any type of network, such as a wide area network (WAN), a local area network (LAN), or the Internet. Also, the network <NUM> may be public, private, or include both public and private networks. Further, the network <NUM> may be wired, wireless, or include both wired and wireless networks. The network <NUM> may utilize any one or more protocols for communication, such as the Internet Protocol (IP), other packet-based protocols, or other protocols. Additionally, the network <NUM> may comprise any number of intermediary devices, such as routers, base stations, access points, firewalls, or gateway devices.

The computer <NUM> includes processor(s) <NUM>, network interface(s) <NUM>, memory <NUM>, which includes both volatile memory and persistent storage. The processor(s) <NUM> may include any one or more central processing units or graphic processing units. The network interface(s) <NUM> may support both wired and wireless connections to networks, such as cellular networks, radio, WiFi networks, short range networks (e.g., Bluetooth, IR, and so forth.

The memory <NUM> may comprise tangible, non-transitory computer-readable storage media, which may include both volatile (e.g., RAM) and non-volatile storage (e.g. ROM). Non-volatile storage (sometimes referred to herein as the disk of the computer <NUM>) may include, but is not limited to, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other memory technology, or any other medium which can be used to store content, applications for access by the computer <NUM>. The term "non-transitory", as used herein, is a characterization of the medium itself (i.e., not a propagating electromagnetic signal) and does not imply any limitation with regard to data storage persistency. Accordingly, the various types of memory mentioned above, such as ROM, RAM, EEPROM, hard disks, flash memory, etc., are all examples of non-transitory media. The computer <NUM> may also use non-volatile cloud-based storage, and any of the components shown as being in the memory <NUM> may also, or alternatively, be stored on Internet-based or other network-based storage devices.

Various data and software components may be stored by and in the memory <NUM>, such as an operating system <NUM> and various applications <NUM>. The applications <NUM> may include an application that creates the host process <NUM>.

The memory <NUM> may also contain the run-time system <NUM>, the scripting engine <NUM>, a user interface shell <NUM> associated with the scripting engine <NUM>, and the threat detection component <NUM>. These software components may be stored in persistent storage and moved to and from volatile memory (e.g., RAM, memory cache, etc.) as needed.

The computer <NUM> may of course have many other components, such as a keyboard, a display, various input/output ports and interfaces, device drivers, audio components, video components, communication components, and so forth.

Many variations and modifications can be made to the above-described examples, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the claims. Moreover, this disclosure is inclusive of combinations of the aspects described herein. References to "a particular aspect" (or "embodiment" or "version") and the like refer to features that are present in at least one aspect of the invention. Separate references to "an aspect" (or "embodiment") or "particular aspects" or the like do not necessarily refer to the same aspect or aspects; however, such aspects are not mutually exclusive, unless so indicated or as are readily apparent to one of skill in the art. The use of singular or plural in referring to "technique" or "techniques" and the like is not limiting.

Example computer-implemented operations described herein can additionally or alternatively be embodied in specialized computer hardware, e.g., field-programmable gate arrays (FPGAs). For example, various aspects herein may take the form of an entirely hardware aspect, an entirely software aspect (including firmware, resident software, micro-code, etc.), or an aspect combining software and hardware aspects.

The word "or" and the phrase "and/or" are used herein in an inclusive sense unless specifically stated otherwise. Accordingly, conjunctive language such as, but not limited to, at least one of the phrases "X, Y, or Z," "at least X, Y, or Z," "at least one of X, Y or Z," "one or more of X, Y, or Z," and/or any of those phrases with "and/or" substituted for "or," unless specifically stated otherwise, is to be understood as signifying that an item, term, etc. can be either X, or Y, or Z, or a combination of any elements thereof (e.g., a combination of XY, XZ, YZ, and/or XYZ). Any use herein of phrases such as "X, or Y, or both" or "X, or Y, or combinations thereof" is for clarity of explanation and does not imply that language such as "X or Y" excludes the possibility of both X and Y, unless such exclusion is expressly stated.

As used herein, language such as "one or more Xs" shall be considered synonymous with "at least one X" unless otherwise expressly specified. Any recitation of "one or more Xs" signifies that the described steps, operations, structures, or other features may, e.g., include, or be performed with respect to, exactly one X, or a plurality of Xs, in various examples, and that the described subject matter operates regardless of the number of Xs present, as long as that number is greater than or equal to one.

Conditional language such as, among others, "can," "could," "might" or "may," unless specifically stated otherwise, are understood within the context to present that certain examples include, while other examples do not include, certain features, elements, or steps. Thus, such conditional language is not generally intended to imply that certain features, elements, or steps are in any way required for one or more examples or that one or more examples necessarily include logic for deciding, with or without user input or prompting, whether certain features, elements, or steps are included or are to be performed in any particular example.

Claim 1:
A method performed by a computer (<NUM>) for blocking command content from being executed by a scripting engine (<NUM>, <NUM>), the method comprising:
identifying (<NUM>, <NUM>) a host process (<NUM>, <NUM>) that runs a scripting engine (<NUM>);
injecting (<NUM>, <NUM>) an unmanaged interface module (<NUM>, <NUM>) into the host process (<NUM>);
receiving (<NUM>), by the unmanaged interface module, command content that is to be executed by the scripting engine;
communicating (<NUM>, <NUM>) the command content from a managed interface module to a threat detection component (<NUM>, <NUM>) through the unmanaged interface module (<NUM>, <NUM>), wherein the threat detection component (<NUM>, <NUM>) is installed as a kernel-mode component;
receiving (<NUM>), through the unmanaged interface module from the threat detection component (<NUM>), a reply to block the command content; and
in response, blocking (<NUM>) the command content.