Real-time shellcode detection and prevention

Abstract

A method, storage system, and computer program product for protecting a computing device, including a processor and memory, and connected to a storage device that stores a set of one or more files. A call to a function designated for execution by the processor is detected, and a stack trace for the call to the designated function is generated in memory. When the stack trace detects a stack frame containing a return address that references a shellcode region in memory, where the shellcode region contains executable code that was not loaded from any given file on the storage device, the referenced executable code is then compared against a list of malicious shellcodes. Finally, when a match is found between the referenced executable code and one of the malicious shellcodes in the list, preventive action is initiated.

Description

Technical Field

[0001] The present invention generally relates to computer security. And in particular, it relates to detecting actions performed by a computing device in response to the execution of malicious shellcode.

Background Art

[0002] In many computer and network systems, multiple layers of security devices and software are deployed to detect and repel the increasingly expanding scope of security threats. At the most basic level, a computer uses antivirus software to prevent malicious software from being executed on the computer. At the network level, intrusion detection and prevention systems analyze and control network traffic to detect and prevent malware from spreading through the network.

[0003] The above description is presented as a general overview of related technologies in this field, and no admission is made that any of the information it contains constitutes prior art to this patent application.

Summary of the Invention

[0004] A method for protecting a computing device is provided according to one embodiment of the present invention. The computing device includes a processor and memory and is connected to a storage device that stores one or more sets of files. The method includes the steps of: having the processor detect a call to a function designated for execution by the processor; generating a stack trace in memory for the call to the designated function; and in the stack trace, detecting a stack frame that includes a return address referencing a shellcode region in memory, wherein the shellcode region includes executable code that was not loaded from any given file on the storage device; comparing the referenced executable code with a list of malicious shellcodes; and, upon detecting a match between the referenced executable code and one of the malicious shellcodes in the list, initiating a preventive action.

[0005] In one embodiment, the referenced executable code is executed in kernel mode.

[0006] In another embodiment, the referenced executable code is executed in user mode.

[0007] In an additional embodiment, the shellcode includes an application programming interface (API) hash algorithm.

[0008] In a further embodiment, the list of malicious shellcode includes a list of signatures, and the step of comparing a referenced executable code against the list of malicious shellcode includes extracting one or more shellcode buffers from the referenced executable code, and comparing one or more extracted shellcode buffers against the list of signatures.

[0009] In a supplementary embodiment, the signature in the list may include wildcards.

[0010] In one embodiment, the specified function loads an executable library into memory.

[0011] In another embodiment, the specified function creates a new thread in memory.

[0012] In an additional mechanism, the specified function creates a new process in memory.

[0013] In a further embodiment, the specified function initiates a new connection.

[0014] In a supplementary embodiment, the specified function listens for incoming connections.

[0015] In one embodiment, a specified function communicates with a kernel driver to provide a view of input and output data.

[0016] In another embodiment, the memory includes a set of memory pages, and the specified function allocates one or more of these memory pages to a process in memory.

[0017] In an additional embodiment, the memory includes a set of memory addresses, and the function specified herein modifies the memory permissions of a given memory address.

[0018] In a further embodiment, the specified function retrieves a buffer from an address in memory.

[0019] In a supplementary embodiment, the specified function writes a buffer to an address in memory.

[0020] In one embodiment, the specified function sets the thread context of a thread in memory.

[0021] In another embodiment, the specified function adds an APC to an in-memory queue of asynchronous processing procedure calls (APCs) within a thread.

[0022] In an additional embodiment, the specified function injects additional executable code into a process in memory.

[0023] According to one embodiment of the present invention, a device for protecting a computing device is also provided. The computing device includes a processor connected to memory and a storage device that stores a set of one or more files. The processor is configured to detect calls to a function designated for execution by the processor, generate a stack trace in memory for the calls to the designated function, detect in the stack trace a stack frame that includes a return address that references a shellcode region in memory, the shellcode region containing executable code that has not been loaded from any given file on the storage device, compare the referenced executable code against a list of malicious shellcodes, and if a match is detected between the referenced executable code and one of the malicious shellcodes in the list, initiate preventive action.

[0024] According to one embodiment of the present invention, additionally, a computer software product for protecting a computing device is provided. The computing device includes a memory and a processor connected to a storage device storing a set of one or more files. The computer software product includes a non-transitory computer-readable medium storing program instructions that, when read by a computer, cause the computer to detect a call to a function designated for execution by the processor, generate a stack trace for the call to the designated function in the memory, detect, in the stack trace, a stack frame including a return address referencing a shellcode area in the memory, where the shellcode area includes executable code not loaded from any given file on the storage device, compare the referenced executable code against a list of malicious shellcodes, and initiate a preventive action when a match is detected between the referenced executable code and one of the malicious shellcodes in the list.

Brief Description of the Drawings

[0025] The present disclosure is described herein by way of example only, with reference to the accompanying drawings. [Figure 1A] FIG. 1A, also collectively referred to herein as FIG. 1, is a block diagram illustrating one example of a computing device that uses hooked operating system functions and stack traces to detect malicious shellcode, according to one embodiment of the present invention. [Figure 1B] FIG. 1B, also collectively referred to herein as FIG. 1, is a block diagram illustrating one example of a computing device that uses hooked operating system functions and stack traces to detect malicious shellcode, according to one embodiment of the present invention. [Figure 2]Figure 2 is a block diagram showing processes and threads executed within the memory of a computing device, according to one embodiment of the present invention. [Figure 3] Figure 3 is a block diagram showing the mapping between stack frames within a stack trace and pages within the memory of a computing device, according to the first embodiment of the present invention. And [Figure 4] Figure 4 is a flowchart schematically showing a method for real-time malicious shellcode detection, according to one embodiment of the present invention.

Embodiments for Carrying Out the Invention

[0026] In the embodiments described herein, shellcode includes computer-executable code that the processor did not load (i.e., prior to execution) from an executable file stored on a storage device. In some examples, shellcode can be a set of malicious instructions (i.e., code) used for post exploitation (i.e., actions taken after a session has been initiated) in an operating system or software application. There are several types of malicious shellcode, each having a different purpose. Examples of malicious shellcode include the following. · Reverse Shell: This type of shellcode creates a reverse shell. It is a shell that is executed on the target system and connects back to the attacker's system. This type of shellcode is often used in remote exploitation scenarios where an attacker wishes to control the target system. • Bind Shell: This type of shellcode opens a shell on a specific port on the target system, allowing the attacker to connect to it directly. This type of shellcode is useful in situations where the attacker already has access to the target system but needs a more direct way to interact with it. • Download and Execute: This type of shellcode downloads a file from a remote location and then executes it on the target system. This type of shellcode is often used to download and install malware on a target system. • Add User: This type of shellcode adds a new user to the target system, giving the attacker additional access and control. This type of shellcode is often used in combination with other types of shellcode, such as reverse shells, to establish a persistent presence on the target system. • Execute Command: This type of shellcode executes a specific command on the target system, allowing an attacker to perform a particular task. This type of shellcode is often used in combination with other types of shellcode, such as reverse shells, to carry out more complex attacks. • Executable file loading (reflective loading): In this attack, an executable file is loaded from a storage device into memory (for example, via a network connection). In the attack, the executable file may be a module of the attacker's malware. Alternatively, the malware packer may have shellcode configured to load the unpacked executable file into memory. This attack is typically limited to computers running the WINDOWS® operating system, manufactured by Microsoft Corporation in Redmond, Washington, USA.

[0027] Embodiments of the present invention provide a method and system for protecting a computer device, comprising (a) a processor and memory, and (b) a storage device for storing one or more sets of files. As described below, once the processor detects a call to a function designated for execution (i.e., by the processor), a stack trace is generated for the call to the designated function. If a stack frame in the stack trace is found to contain a return address that references a shellcode region in memory, the referenced executable code is compared to a list of malicious shellcodes. Finally, once a match is found between the referenced executable code and one of the malicious shellcodes in the list, preventive action is initiated.

[0028] In embodiments of this specification, the computer device runs an operating system including a loader, and the shellcode region contains executable code that has not been loaded into memory from any executable file on the storage device by the operating system's loader.

[0029] In some embodiments, certain functions can be “hooked.” As a result, their stack traces can be analyzed in response to calls to those functions. By hooking certain functions, a system implementing embodiments of the present invention can analyze the stack traces of those functions before any malicious actions that may be performed by those functions (e.g., loading a library or creating a new process thread).

[0030] Malicious shellcode is typically encoded and therefore difficult to detect. A system implementing embodiments of the present invention enables the detection of encoded shellcode by analyzing the stack trace once a hooked function is called. Since this analysis is performed after the shellcode has been decoded / decrypted and execution has begun, implementing these embodiments makes it possible to detect shellcode in memory regardless of how it was encoded / encrypted.

[0031] System Description Figures 1 and 1A, also collectively referred to herein as Figure 1, are block diagrams illustrating an example of a computing device 20 configured to detect, in real time, a cyberattack using malicious shellcode 22 (hereinafter simply referred to herein as malicious code 22 or shellcode 22), according to one embodiment of the present invention. In the configuration shown in Figure 1A, the computing device 20 includes a processor 24 and memory 26.

[0032] In the embodiments described herein, the processor 24 and memory 26 within the computing device 20 are coupled to the storage device 28. In some embodiments, the computing device 20 may include a controller (not shown), such as a serial AT attachment (SATA) or serial attached SCSI (SAS), that connects the computing device to the storage device 28. In other embodiments, the storage device 28 may be in a network-attached storage (NAS) system or a storage area network (SAN) that is coupled to the computing device 20 via a network connection (not shown).

[0033] Memory 26 may store shellcode 22, an operating system 30 including a loader 31, a set of API callbacks 32, a stack trace 34, a list of malicious signatures 36 (also referred herein to as a list of malicious shellcode 36), and a set of extracted shellcode buffers 38. Storage device 28 may store a set of libraries 39, which include executable files 40 such as dynamic link library (DLL) files. Libraries 39 may also be referred herein to as executable libraries 39. In some embodiments, storage device 28 may store a set of additional non-executable files 41.

[0034] As described below, the shellcode 22 contains executable code (e.g., a dynamic link library) that the processor 24 did not load into memory 26 from a given executable file 40 (or file 41) on the storage device 28.

[0035] In some embodiments, the malicious signature 36 includes a byte sequence of known malicious code, such as malicious shellcode (e.g., METASPLOIT). TM Or COBALT STRIKE TMThis could involve using a framework, or other notorious API hashes. In shellcode cyberattacks, typically a small piece of code is used as a payload in post-exploitation of a software vulnerability. This is called shellcode because it typically starts a command shell from which the attacker can gain control of the compromised machine. However, any code that resides in memory and does not have an executable file on a storage device (i.e., was not loaded from one) can be called shellcode.

[0036] API hashing is a technique often used by malicious shellcode to make it difficult to detect suspicious API usage when using exploits, or to save space. If an attacker wants to dynamically load an API (i.e., when the malware / exploit is actually executed), they can use a modified (i.e., customized) version of the WINDOWS™ function GetProcAddress, which uses API hashing to return the API function address once a hash value is passed as a parameter (i.e., instead of a name being passed as a parameter).

[0037] The following is an example of assembly code for an API hash value passed as a parameter. [Table 1] This generates the following assembly opcode (i.e., instruction machine code). [Table 2] In this example, the given malicious signature 36 includes the generated opcode, and the "?" indicates a wildcard (i.e., "?" does not require a match).

[0038] As described below, the processor 24 can detect a cyberattack by (a) detecting shellcode 22, (b) comparing the detected shellcode with a malicious signature 36, and (c) detecting a match between the detected shellcode and a given malicious signature 36.

[0039] In the configuration shown in Figure 1A, the processor 24 can execute the operating system 30 from the memory 26. An example of the operating system 30 is Microsoft Windows. TM In addition to the loader 31, the operating system 30 may have a set of operating system functions 42, each having an operating system function identifier (ID) 44 and accessible via an application programming interface (API) 46.

[0040] Each API callback 32 includes a hooked function ID 48 and an API callback code 50. Once the operating system 30 receives a call via API 46 to a given function 42 having its respective function ID 44, the operating system compares the respective function ID with the hooked function ID 48. If the operating system 30 finds a match between the respective function ID and the given hooked function ID 48, the operating system calls the API callback code 50 for the given hooked function ID. Once the processor 24 executes the API callback code 50 for the given hooked function ID, the operating system 30 executes the given function (i.e., the one requested by the call).

[0041] In the embodiments described herein (as shown in Figure 1B), functions 42 and their respective function IDs 44 can be distinguished by adding letters to the identifying numbers, so that functions include hooked functions 42A and non-hooked functions 42B, and function IDs include function IDs 44A (i.e., for function 42A) and 44B (i.e., for function 42B).

[0042] In some embodiments, any function 42 whose respective function ID 44 matches any given hooked function ID 48 may also be referred to as a given hooked function 42A. Similarly, any function 42 whose respective function ID 44 does not match any given hooked function ID 48 may also be referred to as a given unhooked function 42A. Configuring a given function 42 as a given hooked function 42A is described in the following description with reference to Figure 4.

[0043] In embodiments of this specification, for each given hooked function 42A, the API callback code 50 generates and analyzes a stack trace 34, which includes a set of stack frames 52, where the second-to-last stack frame 52 in the stack trace refers to a call to a given hooked function. The stack frames 52 are described in the following description with reference to Figure 3.

[0044] In some embodiments, the operating system 30 also includes a set of registration routines 47 accessible via calls to the API 46. As described in the following description with reference to Figure 4, the registration routines 47 can “register” (i.e., associate) a given operating system function 42 with a given API callback code 50 in order to define the system function as a given hooked function 42A.

[0045] The processor 24 can run in different processor modes 54 (also known as states and privilege levels). Examples of processor modes 54 include, but are not limited to, kernel mode and user mode. A feature of kernel mode is that it can allow the processor 24 to have a high set of privileges, and as a result the processor has direct and unrestricted access to system resources and processes (described in the description with reference to Figure 2 below). Embodiments described herein utilize kernel mode triggers called from user mode, which allows the processor 24 to generate stack traces 34 for hooked functions 42A (i.e., hooks and callbacks) triggered by user mode programs without injecting code into all processes in the system.

[0046] In some embodiments, the computing device 20 may include one or more hardware subsystems 56. For example, a given hardware subsystem 56 may include input / output (I / O) devices such as a network controller or a storage controller.

[0047] Figure 2 is a block diagram showing the hardware and software components of memory 26 while the processor 24 is executing the operating system 30, according to one embodiment of the present invention.

[0048] In the configuration shown in Figure 2, memory 26 contains a set of memory pages 60 (i.e., memory 26 is divided into a set of memory pages 60, which may also be called a buffer 60), and has a set of memory addresses 61. While the operating system 30 is running, the operating system manages a stack 62 (i.e., an area in memory 26 that can store temporary variables created by function 42), and a set of processes 64, each having a thread 66. Each given thread 66 may have its own context 68 containing information that the given thread needs to seamlessly resume execution (i.e., if interrupted).

[0049] As described above, the mode 54 of the processor 24 can be either kernel mode or user mode. In the embodiments described herein, if the processor 24 is in kernel mode and the processor 24 is executing a given thread 66, the given thread may be considered to be running in kernel mode. Similarly, if the processor 24 is in user mode and the processor 24 is executing a given thread 66, the given thread may be considered to be running in user mode.

[0050] In some embodiments, the processor 24 stores the stack 62, process 64, and thread 66 in their respective memory pages 60. As described below, embodiments of the present invention enable the processor 24 to detect malicious shellcode 22 that was being executed in a given thread 66.

[0051] Figure 3 is a block diagram showing the mapping between a given stack frame 52 and a given memory page 60 in a stack trace 34, according to a first embodiment of the present invention.

[0052] In the configuration shown in Figure 3, each given stack frame 52 includes a start address 70 (i.e., in memory 26) and an end address 72 (i.e., in memory 26) that refer to a given memory page 60, as indicated by the arrow 74. In some embodiments, each given stack frame 52 may include the flags 76 described below.

[0053] Memory page 60 stores content 78 and has permission 80. Using the embodiments described herein, the processor 24 is configured to identify a given memory page 60 in which each content 78 contains malicious shellcode 22.

[0054] In embodiments described herein, the processor 24 can detect the shellcode 22 in a given memory page 60 by detecting in the stack trace 34 a given stack frame 52 that references a return address containing a return address 77 (i.e., a given address 61) for referencing a shellcode region 79 in memory 26. The shellcode region 79 contains (i.e., stores) the shellcode 22, which, as described above, contains computer executable code that the loader 31 did not load into memory 26 from an executable file 40 or file 41 (stored in the storage device 28).

[0055] In some embodiments, flag 76 indicates whether the content 78 has been previously loaded by the processor 24 from a given file 40 (or file 41) on the storage device 28. For example, WINDOWS TMIn the environment, the processor 24 may set flag 76 to True for a given memory page 60 if the processor detects the MEM_IMAGE flag for that memory page (i.e., the processor loaded content 78 from a given file 40 / 41 on the storage device 28). Similarly, the processor 24 may set flag 76 to False if the processor does not detect the MEM_IMAGE flag for a given memory page (i.e., the processor did not load content 78 from a given file 40 / 41 on the storage device 28). In embodiments herein, the content of a given memory page 60 for which each flag 76 is False is likely to contain shellcode 22 (i.e., benign or malicious).

[0056] The processor 24 includes a general-purpose central processing unit (CPU) or a dedicated embedded processor, which is programmed with software or firmware to perform the functions described herein. This software may be downloaded, for example, to the computing device 20 in electronic form via a network. Additionally or alternatively, the software may be stored on a tangible, non-temporary computer-readable medium, such as an optical, magnetic, or electronic memory medium. Furthermore, additionally or alternatively, at least some of the functions of the processor 24 may be performed by hardwired or programmable digital logic circuits.

[0057] Examples of memory 26 and storage devices 28 include dynamic random access memory, non-volatile random access memory, hard disk drives, and solid-state disk drives.

[0058] In some embodiments, the tasks described herein, performed by the processor 24, may be divided among multiple physical and / or virtual computing devices. In other embodiments, these tasks may be performed in a managed cloud.

[0059] Detection of malicious shellcode Figure 4 is a flowchart illustrating a method by which a processor 24 detects malicious shellcode 22 in real time, according to one embodiment of the present invention.

[0060] In step 90, the processor 24 configures (e.g., associates) a set of API callbacks 32 containing API callback code 50 for one or more functions 42, thereby "hooking" one or more functions 42A. Once a given hooked function 42 is called, the processor 24 executes the callback code associated with the given hooked function.

[0061] For example, if processor 24 is WINDOWS TM When the operating system 30 is running, in response to a call to a given registration routine 47 with parameters referencing a given API callback code 50, the processor 24 registers (i.e., associates) the API callback code 50 with a given operating function 42 so that the given operating function is defined as a given hooked function 42A. In embodiments herein, whenever a given hooked function is called, the processor 24 executes the API callback code registered with the given hooked function.

[0062] In some embodiments, a program instruction running on the processor 24 may use a registration routine 47 to “hook” a specific action performed by the operating system 30 (for example, creating a new thread 66 as described below). In these embodiments, the registration function hooks an operating system function that performs a specific action (i.e., registers a given API callback code 50 with a given operating system function 42). In other words, when coding a program instruction that includes a registration routine, the programmer (not shown) does not explicitly hook one or more operating system functions 42 (i.e., in the source code of the program instruction).

[0063] The following is a WINDOWS example that registers a given operating system function 42 with a given API callback code 50. TM This is an example of registration routine 47 in an operating system. · PsSetLoadImageNotifyRoutine: This registration routine 47 is executed on the processor 24 to register a given callback code with a given operating system function 42 which is configured to load a given library 39 (i.e., containing one or more executable files 40) from a storage device 28. · PsSetCreateThreadNotifyRoutine: This registration routine 47 is executed on the processor 24 to register a given callback code 50 (referenced by the passed parameters) with a given operating system function 42 configured to create a new thread 66. • PsSetCreateProcessNotifyRoutine: This registration routine 47 is executed on processor 24 to register a given callback code 50 (referenced by the passed parameters) with a given operating system function configured to create a new process 64. ·FWPS_LAYER_ALE_AUTH_CONNECT_V4: This registration routine 47 is executed on the processor 24 to register a given callback code 50 (referenced by the passed parameters) with a given operating system function 42 that is configured to initiate a new connection (for example, to a specific socket). ·FWPS_LAYER_ALE_AUTH_LISTEN_V4: This registration routine 47 is executed on the processor 24 to register a given callback code 50 (referenced by the passed parameters) with a given operating system function 42 that is configured to "listen" for new incoming connections (for example, to put a particular socket into a listening state).

[0064] In another embodiment, the programmer can explicitly hook operating system functions 42 when developing program instructions to be executed on the processor 24. The following describes WINDOWS TM This is an example of an operating system function 42 in an operating system (i.e., a system call that a program instruction can call via API 46). • NtDeviceIoControlFile: This operating system function 42 communicates with kernel-mode drivers to provide a view of input and output data. • NtAllocateVirtualMemory: This operating system function 42 allocates one or more memory pages 60 to a given process 64. • NtProtectVirtualMemory: This operating system function 42 modifies permission 80 for a given memory address 61. • NtReadVirtualMemory: This operating system function 42 reads a given buffer 60 at a given memory address 61 in a second process 64 (i.e., retrieves one or more values ​​from it). • NtWriteVirtualMemory: This operating system function 42 writes a given buffer 60 (i.e., one or more values) to a given memory address 61 in a given process 64. In some embodiments, a given process may be the current process or a remote process. • NtSetContextThread: This operating system function 42 sets the thread context 68 to a given thread 66. • NtQueueApcThread: This operating system feature 42 adds a new asynchronous processing procedure call (APC) to the APC queue within a given thread 66. • NtUserSetWindowsHookEx: This operating system function 42 injects a DLL (i.e., executable code) into a given process 64 (e.g., a remote process).

[0065] In some embodiments, a system administrator (not shown) can add, remove, or modify the API callback 32 as needed.

[0066] In step 92, the processor 24 detects a call to a given hooked function 42A. In other words, a program instruction executed on the processor 24 calls a given hooked function.

[0067] In step 94, in response to detecting a call to a given hooked function, the processor 24 generates a stack trace 34 (i.e., from multiple stack traces in memory 26), and its stack frame 52 contains a specific number (e.g., 20, 25, 30) of actions performed by a given process 64 that terminates with the detected call. TMIn this environment, processor 24 can call the operating system function RtlWalkFrameChain to generate a stack trace 34 by "walking" the stack 62 in reverse.

[0068] In step 96, the processor 24 analyzes the stack frame 52 using the embodiments described above to determine whether any of the preceding stack frames (i.e., stack frames preceding the stack frame that references the discovered call) contain the shellcode 22. Using the embodiments described above, the processor 24 can check whether flag 76 is false for any memory page 60 referenced by the preceding stack frame.

[0069] In some embodiments, steps 94 and 96 are performed by API callback code 50 executed on processor 24. To analyze the stack frame 52, processor 24 can iterate through the stack frame 52 and check for the (first) return address 77 corresponding to the shellcode memory area 79.

[0070] In step 98, if the processor 104 finds shellcode 22 in the content 78 of a memory page 60 referenced by one of the preceding stack frames, in step 100, the processor extracts one or more portions of the found shellcode and stores one or more extracted portions of the extracted shellcode in one or more extracted shellcode buffers 38. In some embodiments, each given extracted shellcode buffer 38 contains a sequence of bytes (i.e., in memory) that stores the shellcode 22.

[0071] In step 102, the processor 24 compares one or more extracted shellcode buffers 38 with a malicious signature 36.

[0072] If, in step 104, the processor 24 detects a match between the extracted arbitrary shellcode buffer 38 and a given malicious signature 36, in step 106, the processor initiates a preventative action, and the method proceeds to step 92.

[0073] In some embodiments, the preventive action may include identifying a given process 64 containing the detected shellcode, and then terminating the execution of the process. In some embodiments, if the processor 24 detects any additional processes 64 associated with (i.e., parent or child of) a given process, the processor may also terminate the execution of the detected additional processes.

[0074] Returning to step 104, if the processor 24 does not detect a match between the extracted shellcode buffer 38 and the malicious signature 36, the method proceeds to step 92.

[0075] Returning to step 98, if the processor 104 does not find the shellcode 22 within the contents 78 of memory page 60 referenced by any of the preceding stack frames, the method proceeds to step 92.

[0076] The following is an example of the contents of stack frame 52 (numbered 1-13). 1.c:\\windows\\system 32\\ntdll.dll+0xddc5 2.c:\\windows\\system 32\\ntdll.dll+0xda52 3.c:\\windows\\system 32\\ntdll.dll+0xd925 4.c:\\windows\\system 32\\ntdll.dll+0xc84c 5.c:\\windows\\system 32\\ntdll.dll+0xca9b 6.c:\\windows\\system 32\\ntdll.dll+0xa56d 7.c:\\windows\\system 32\\ntdll.dll+0x26a7e 8.c:\\windows\\system 32\\ntdll.dll+0x2651d 9.c:\\windows\\system 32\\ntdll.dll+0x9efc 10.c:\\windows\\system 32\\kernelbase.dll+0x2cd7f 11.c:\\windows\\system 32\\kernelbase.dll+0x25721 12.c:\\windows\\system 32\\kernelbase.dll+0x6b7e9 13.0x2012dbd In this example, stack frame "12" indicates that processor 24 decides to load a given library 39 (i.e., a given hooked function 42A), and stack frame "13" refers to shellcode 22.

[0077] The embodiments described above are cited as examples, and it will be understood that the present invention is not limited to those specifically shown and described above. Rather, the scope of the present invention includes both combinations and partial combinations of the various features described above, as well as variations and modifications thereof that can be conceived by reading the above description and that are not disclosed in the prior art.

Claims

1. A method for protecting computing devices, The computing device includes a processor and memory and is connected to a storage device that stores one or more sets of files, and the method is The steps include: detecting a call to a function designated for execution by the processor; The steps include generating a stack trace for the call to the specified function within the memory, The steps include: detecting a stack frame in the stack trace that includes a return address referencing a shellcode region in memory, wherein the shellcode region includes executable code that was not loaded from any given file on the storage device; The steps include comparing the referenced executable code against a list of malicious shellcode, The step of detecting a match between the referenced executable code and one of the malicious shellcodes in the list, and initiating preventative action, Methods that include...

2. The aforementioned referenced executable code is executed in kernel mode. The method according to claim 1.

3. The aforementioned referenced executable code is executed in user mode. The method according to claim 1.

4. The aforementioned shellcode includes an application programming interface (API) hash algorithm, The method according to claim 1.

5. The aforementioned list of malicious shellcode includes a list of signatures, The step of comparing the aforementioned referenced executable code against a list of malicious shellcode is: Extracting one or more shellcode buffers from the aforementioned referenced executable code, and Comparing the one or more extracted shellcode buffers against the list of signatures, The method according to claim 1, including the method described in claim 1.

6. The signature in the above list includes wildcards, The method according to claim 5.

7. The specified function loads the executable library into memory. The method according to any one of claims 1 to 6.

8. The specified function creates a new thread in the memory. The method according to any one of claims 1 to 6.

9. The specified function creates a new process in the memory. The method according to any one of claims 1 to 6.

10. The aforementioned specified function initiates a new connection. The method according to any one of claims 1 to 6.

11. The aforementioned specified function listens for incoming connections. The method according to any one of claims 1 to 6.

12. The specified function communicates with the kernel driver to provide a view of the input and output data. The method according to any one of claims 1 to 6.

13. The memory includes a set of memory pages, The specified function allocates one or more of the memory pages to a process in the memory. The method according to any one of claims 1 to 6.

14. The aforementioned memory includes a set of memory addresses, The aforementioned specified function modifies the memory permission for a given memory address. The method according to any one of claims 1 to 6.

15. The specified function retrieves a buffer from the address in the memory. The method according to any one of claims 1 to 6.

16. The specified function writes a buffer to the address in the memory. The method according to any one of claims 1 to 6.

17. The specified function sets the thread context of the thread in the memory. The method according to any one of claims 1 to 6.

18. The specified function adds an APC to the Asynchronous Processing Procedure Call (APC) queue in the thread in memory. The method according to any one of claims 1 to 6.

19. The aforementioned specified function injects additional executable code into the process in memory. The method according to any one of claims 1 to 6.

20. A device for protecting computing devices, Memory, and, A processor connected to a storage device that stores one or more sets of files, The aforementioned processor, The processor detects calls to the functions specified for execution, Within the memory, generate a stack trace for the call to the specified function, In the stack trace, a stack frame containing a return address that references a shellcode region in memory is detected, and the shellcode region contains executable code that was not loaded from any given file on the storage device. The aforementioned referenced executable code is compared against a list of malicious shellcode, and When a match is detected between the referenced executable code and one of the malicious shellcodes in the list, preventative action is initiated. It is structured in such a way. Device.

21. A computer program that protects computing devices, The computing device includes a processor and memory and is connected to a storage device that stores one or more sets of files. The aforementioned computer program includes computer instructions and is stored on a non-temporary computer-readable medium. When the aforementioned computer instruction is executed by the processor, the computer will: The processor detects calls to the functions specified for execution, Within the memory, generate a stack trace for the call to the specified function, In the stack trace, a stack frame containing a return address that references a shellcode region in memory is detected, and the shellcode region contains executable code that was not loaded from any given file on the storage device. The aforementioned referenced executable code is compared against a list of malicious shellcode, and When a match is detected between the referenced executable code and one of the malicious shellcodes in the list, preventative action is initiated. A computer program that causes something to happen.

Images