Shell code detection method and device, equipment and storage medium

Abstract

The application provides a shell code detection method and device, equipment and a storage medium, and belongs to the computer security field. The computer equipment detects that a system entity on the computer equipment exists a creation behavior of a section, and then acquires the permission of the created section. In response to the fact that the created section has executable permission and the file path of the section matches the path of the network dynamic library, it is indicated that the system entity has the possibility of loading the network dynamic library, and the memory block running the section is further determined. In response to the fact that the memory block satisfies the shell code running condition, it is determined that the system entity has suspicious shell code execution behavior, the comprehensive detection of whether the system entity has suspicious shell code execution behavior is realized, the missed detection is reduced, and the applicable scene is more comprehensive.

Description

Technical Field

[0001] This application relates to the field of computer security, and in particular to a method, apparatus, device, and storage medium for detecting shell code. Background Technology

[0002] In an operating system, user mode is the environment in which applications run, while kernel mode is the environment in which the operating system kernel runs. Because user mode and kernel mode differ significantly in permissions, resource access, and system functionality, applications running in kernel mode cannot directly call application programming interface (API) libraries designed for user-mode applications. Furthermore, since shellcode is a piece of machine code executed to exploit software vulnerabilities and is a form of malicious code, it is often used to launch malicious attacks on computer systems. Shellcode can be used to perform specific tasks within the computer system, such as providing remote access or privilege escalation. Therefore, after a successful exploitation of a remote operating system vulnerability in kernel mode, a Trojan program or other malicious program often injects shellcode into user mode.

[0003] Therefore, how to detect shellcode in order to identify whether there is suspicious shellcode execution behavior on system entities on computer devices is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for detecting shell code, so as to detect whether there is suspicious shellcode execution behavior in system entities on computer devices. The technical solution is as follows.

[0005] Firstly, a method for detecting shellcode is provided. The method includes: a computer device detecting whether a section creation behavior exists on a system entity on the computer device, the creation behavior being used to create a section of the system entity, the system entity being generated after a sample program is run; in response to detecting the existence of the section creation behavior, acquiring the permissions of the section created by the creation behavior; in response to the section having executable permissions and the file path of the section matching the path of a network dynamic library, determining the memory block in which the section runs; and if the memory block meets the shellcode execution conditions, determining that the system entity has suspicious shellcode execution behavior.

[0006] System entities include, but are not limited to, processes, threads, or fibers. A sample program is used to refer to any application running on a computer device; for example, a sample program may be a browser, office software, or game software.

[0007] This method detects that a system entity on a computer device is creating a section, and that the created section has executable permissions. If the file path of the section matches a path in a network dynamic library, it indicates that the system entity may be loading the network dynamic library. Therefore, it further checks whether the memory block running the section meets the shellcode execution conditions. Once the memory block meets the shellcode execution conditions, the system entity is found to be executing suspicious shellcode. In this way, it can comprehensively detect suspicious shellcode execution behavior, reduce missed detections, and has a wider range of applicable scenarios, thereby improving the security of computer devices.

[0008] In one possible implementation, detecting whether a system entity on the computer device has section creation behavior includes: registering a callback function in a kernel-mode driver; and detecting whether the system entity has section creation behavior through the callback function.

[0009] By registering callback functions in kernel-mode drivers to detect the existence of section creation behavior, real-time detection can be achieved, facilitating timely interception of suspicious shellcode execution behavior on system entities and further ensuring the security of computer devices.

[0010] In one possible implementation, the driver is a kernel-mode filter driver, and registering callback functions in the kernel-mode driver includes:

[0011] Register the callback function IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION in the filter driver.

[0012] IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION is an opcode used to indicate that a file has been loaded into memory. When a section creation event occurs, it will determine whether a dynamic link library (DLL) has been loaded into memory, and then further determine whether the system entity has a section creation behavior, thus achieving accurate detection of the creation behavior.

[0013] In one possible implementation, before determining the memory block for running the section, the method further includes: calling FltGetFileNameInformation to obtain the file path corresponding to the section. FltGetFileNameInformation is a function used in Windows driver development to obtain file or directory name information, typically used in file system filter drivers to retrieve name information related to a specific file or directory, and supports various name formats and query methods. This application improves the reliability and accuracy of the obtained file path by calling FltGetFileNameInformation to obtain the file path corresponding to the section.

[0014] In one possible implementation, the memory block satisfies the shellcode execution conditions, including at least one of the following:

[0015] The size of the memory block is equal to the size of the memory page in the operating system;

[0016] The memory block has private permissions, write permissions, and execute permissions;

[0017] The memory block contains the format header of a portable executable (PE) file.

[0018] The detection order of the three operating conditions mentioned above is not limited, and they can also be detected simultaneously. Since shellcode needs to allocate a memory block in the computer device's memory before it can run, and the characteristics of the memory block used to run shellcode differ somewhat from those used to run normal applications, determining whether the memory block meets the shellcode execution conditions can further ensure the accuracy of detecting system entities with suspicious shellcode execution behavior.

[0019] In one possible implementation, matching the file path of the section with the path of the network dynamic library means that the filenames included in the file path of the section are identical to the filenames of the network dynamic library. Determining whether the file path of a section matches the path of the network dynamic library by using the filename is a relatively simple and efficient method.

[0020] In one possible implementation, after determining that the system entity exhibits suspicious shellcode execution behavior, the method further includes terminating the operation of the system entity. By terminating the operation of the system entity after determining that it exhibits suspicious shellcode execution behavior, timely interception is achieved, ensuring the security of the computer device.

[0021] Optionally, the execution of the system entity may be terminated before the system entity successfully calls the network connection function in the dynamic link library. Termination of the system entity's execution by the computer device includes, but is not limited to, closing the system entity and releasing the memory space occupied by the system entity.

[0022] In one possible implementation, before terminating the operation of the system entity, the method further includes: sending a detection instruction to a user-mode detection program, the detection instruction being used by the user-mode detection program to detect the system entity; receiving a detection result fed back by the user-mode detection program; and, if the detection result indicates that the system entity is attempting to execute shellcode, performing the operation of terminating the operation of the system entity.

[0023] Among them, the user-mode detection program is an arbitrary program that can detect whether a system entity has suspicious shellcode execution behavior. By sending a detection command to the user-mode detection program, the user-mode detection program determines whether a system entity has suspicious shellcode execution behavior. The computer device decides whether to block or allow the system entity based on the detection results fed back by the user-mode detection program, thus realizing dual detection and further improving the accuracy of the detection results.

[0024] In one possible implementation, the method is performed by security software running on the computer device. Optionally, the security software is endpoint detection and response (EDR) software or extended detection and response (XDR) software.

[0025] Secondly, a shell code detection device is provided. The detection device is located in a computer device and includes multiple functional modules that interact to implement the methods described in the first aspect and its various embodiments. The multiple functional modules can be implemented based on software, hardware, or a combination of both, and can be arbitrarily combined or divided based on specific implementations. Exemplarily, the detection device includes:

[0026] The detection module is used to detect whether there is a section creation behavior for the system entity on the computer device. The creation behavior is used to create a section of the system entity, which is generated after the sample program is run.

[0027] The acquisition module is used to acquire the permissions of the section created by the creation behavior in response to the detection of the existence of the section creation behavior;

[0028] A determination module is used to determine the memory block in which the section is executed in response to the section having executable permissions and the file path of the section matching the path in the network dynamic library;

[0029] The determining module is further configured to determine, if the memory block meets the shellcode execution conditions, that the system entity has suspicious shellcode execution behavior.

[0030] In one possible implementation, the detection module is used to register a callback function in the kernel-mode driver; and to detect whether the system entity has section creation behavior through the callback function.

[0031] In one possible implementation, the driver is a kernel-mode filter driver, and the detection module is used to register the callback function of IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION in the filter driver.

[0032] In one possible implementation, the acquisition module is further configured to call FltGetFileNameInformation to obtain the file path corresponding to the section.

[0033] In one possible implementation, the memory block satisfies the shellcode execution conditions, including at least one of the following:

[0034] The size of the memory block is equal to the size of the memory page in the operating system;

[0035] The memory block has private permissions, write permissions, and execute permissions;

[0036] The memory block contains the format header of the PE file.

[0037] In one possible implementation, matching the file path of the section with the path of the network dynamic library means that the file name included in the file path of the section is the same as the file name included in the path of the network dynamic library.

[0038] In one possible implementation, the device further includes:

[0039] The interception module is used to terminate the operation of the system entity after determining that the system entity has suspicious shellcode execution behavior.

[0040] In one possible implementation, the interception module is further configured to send a detection instruction to the user-mode detection program before terminating the operation of the system entity, the detection instruction being used by the user-mode detection program to detect the system entity;

[0041] Upon receiving the detection result from the user-mode detection program, if the detection result indicates that the system entity is attempting to execute shellcode, the operation of terminating the operation of the system entity is executed.

[0042] In one possible implementation, the device is executed by security software running on the computer device.

[0043] Thirdly, a computer device is provided, comprising: a memory and at least one processor. The memory stores program instructions, and the at least one processor, after reading the program instructions stored in the memory, causes the computer device to execute the methods described in the first aspect and its embodiments.

[0044] Optionally, there may be one or more processors and one or more memories.

[0045] Alternatively, the memory can be integrated with the processor, or the memory can be set up separately from the processor.

[0046] In the specific implementation process, the memory can be a non-transitory memory, such as read-only memory (ROM), which can be integrated with the processor on the same chip or set on different chips. This application does not limit the type of memory or the way the memory and processor are set.

[0047] Fourthly, a computer-readable storage medium is provided, wherein instructions are stored thereon, which, when executed by a processor, implement the methods described in the first aspect and its various embodiments.

[0048] Fifthly, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the methods described in the first aspect and its various embodiments.

[0049] In a sixth aspect, a chip is provided, the chip including programmable logic circuitry and / or program instructions, which, when the chip is running, implement the methods described in the first aspect and its various embodiments.

[0050] In a seventh aspect, another chip is provided, comprising: an input interface, an output interface, a processor, and a memory, wherein the input interface, the output interface, the processor, and the memory are connected via an internal connection path, and the processor is used to execute code in the memory, wherein when the code is executed, the processor is used to perform the methods described in the first aspect and its various embodiments.

[0051] It should be understood that the device mentioned in the second aspect above can be the chip mentioned in the sixth or seventh aspect, or the computer device of the third aspect. The beneficial effects achieved by the technical solutions and corresponding possible implementations of the second to seventh aspects of this application can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0052] Figure 1 This is a schematic diagram of the hardware structure of a computer device provided in an embodiment of this application;

[0053] Figure 2 This is a flowchart illustrating a shell code detection method provided in an embodiment of this application;

[0054] Figure 3 This is a schematic diagram of the structure of a shell code detection device provided in an embodiment of this application;

[0055] Figure 4 This is a schematic diagram of another shell code detection device provided in an embodiment of this application. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0057] In an operating system, user mode and kernel mode define different permission levels and access capabilities for applications within a computer system. User mode is the environment in which applications run, possessing lower privileges and unable to directly access hardware and system resources. Therefore, user-mode applications can only access a limited memory space. This memory space, also known as user space, is where application code and data are stored. It is precisely because of these restricted permissions in user mode that system stability and security are guaranteed. Kernel mode is the runtime environment of the operating system kernel, possessing higher privileges and able to directly access and control hardware and system resources. Kernel mode is responsible for managing the core functions of the operating system, such as process scheduling, memory management, and device drivers.

[0058] In some scenarios, switching between user mode and kernel mode is possible; this switching process is called context switching. For example, a user-mode application requests a kernel service via a system call, triggering a switch from user mode to kernel mode. Another example is when an application encounters an error (such as division by zero or a page fault), triggering an exception, which can then be handled in kernel mode.

[0059] Furthermore, since shellcode is a piece of machine code executed to exploit software vulnerabilities, it is often used to launch malicious attacks on computer systems. After a kernel-mode Trojan program or a remote operating system vulnerability is successfully exploited, shellcode is often injected into user space. The following examples of shellcode injection into user space will illustrate the role of shellcode injection.

[0060] Scenario 1: Windows Sockets (Winsock) is a set of APIs for network programming on the Windows platform. Designed for user-mode applications, it provides support for Transmission Control Protocol (TCP) / Internet Protocol (IP) based on the socket model. Winsock typically exists as a dynamic link library, making it a type of network dynamic library. Winsock allows developers to perform network communication through the TCP / IP protocol stack, implementing various network applications that rely on the user-mode network protocol stack and input / output processing mechanisms. However, drivers run in kernel mode, and the environment and operating system infrastructure they depend on differ significantly from user-mode applications. Therefore, they cannot directly call the Winsock library. Thus, after a kernel-mode Trojan (such as a rootkit) or a remote operating system vulnerability is successfully exploited, injecting shellcode into user mode is essential for achieving covert and persistent control.

[0061] This application does not limit the infrastructure provided by the operating system on which the driver runs in kernel mode. Any infrastructure that provides a runtime environment for the driver, enabling it to interact efficiently and securely with hardware devices and providing services to user-mode programs is included. For example, drivers typically need to handle interrupt signals generated by hardware devices; the operating system provides an Interrupt Descriptor Table (IDT) and an interrupt handling framework, allowing drivers to register interrupt handling functions. As another example, drivers need to allocate and manage memory, including kernel-mode memory and device memory; the operating system provides memory allocation functions (such as kmalloc and vmalloc) and memory mapping mechanisms (such as mmap). Furthermore, drivers may need to handle concurrent access from multiple threads or processes; the operating system provides synchronization mechanisms such as locks (such as spinlocks and mutexes), semaphores, and atomic operations to ensure data consistency and thread safety. Additionally, drivers need to support device power management, such as suspending, waking up, and hibernating; the operating system provides a power management framework and callback function interfaces. Finally, drivers are typically loaded and unloaded as kernel modules; the operating system provides module loading mechanisms (such as insmod and rmmod) and module lifecycle management. For example, the operating system provides module loading mechanisms (such as insmod and rmmod) and module lifecycle management. The operating system provides logging mechanisms (such as printk) and debugging tools (such as kprobes and ftrace). For example, drivers need to comply with the operating system's security policies, such as access control and the principle of least privilege; the operating system provides security mechanisms to restrict driver behavior.

[0062] In this scenario, since shellcode is just a piece of instruction and does not need to be written to a disk file, it can be executed directly in memory without leaving any traces in the file system, making it difficult to detect. Therefore, the injected shellcode will execute further attack instructions, such as downloading a remote control module from the attacker's control server and loading and executing it directly in memory.

[0063] Scenario 2: Malware typically doesn't store the actual malicious instructions and code in files. If the malicious instructions were in the file itself, the antivirus software would immediately detect and delete the file upon saving it to the hard drive. Therefore, the actual malicious instructions are usually encrypted and stored at a network address. After the Trojan runs, it downloads the encrypted code from that address, decrypts it, and executes it directly in memory. Throughout this process, the malicious instructions are never written to disk, maximizing evasion of antivirus detection. This code, downloaded from the internet, is shellcode. Shellcode is usually encrypted or obfuscated and stored in a PE file to further evade antivirus detection.

[0064] Scenario 3: To evade detection, malware may inject shellcode into legitimate system processes. The process of injection is as follows: First, it obtains a handle to the target process. This handle is used to identify and manipulate the target process, allowing subsequent operations to be performed on it. Next, it allocates memory in the target process's address space using the VirtualAllocEx function. Then, it writes the shellcode into the allocated memory using the WriteProcessMemory function. Finally, it creates a thread using the CreateRemoteThread function, allowing the target process to execute the injected shellcode. Most endpoint security software trusts legitimate processes, so executing subsequent malicious actions within a legitimate process has a very high probability of evading detection.

[0065] Scenario 4: Rootkit Remote Control Scenario. A rootkit is a malicious kernel-mode driver designed specifically for the Windows operating system, granting it the highest privileges on the system. Due to these privileges, a rootkit can allocate space within any user-mode process, copy shellcode to that space, and then create threads or use other methods to execute the shellcode. Furthermore, when the user system is already infected with a driver virus, directly receiving and sending data in kernel mode is very difficult. A common approach is to inject shellcode into critical system processes, and then the shellcode connects to the attacker's control server to exercise remote control.

[0066] Scenario 5: Remote code execution (RCE) vulnerability in the operating system. Successful exploitation of this type of vulnerability injects shellcode into critical processes such as Spoolsv.exe, Lsass.exe, and Winlogon.exe, enabling remote control.

[0067] The scenarios above are merely examples and are not limited to these. To achieve shellcode detection, related technologies register callback functions at the kernel level for process startup, thread startup, registry operations, dynamic library loading, and network behavior. These callback functions are used to check if the starting address of the current thread is suspicious for shellcode. However, this method only applies to scenarios where a new thread is started in user space using the `CreateThread` function to execute shellcode, resulting in limited scenario coverage. It fails to detect many other scenarios where shellcode is started in user space, such as using various callback functions to create fibers, leading to missed detections. Fibers are a lightweight thread implementation that allows developers to create and manage multiple threads in the Windows operating system. Compared to traditional threads, fibers have lower switching costs and resource consumption.

[0068] Another related technique typically uses asynchronous procedure calls (APCs) after a successful kernel-mode remote exploit. APCs are a mechanism that allows kernel and user-mode code to execute routines asynchronously within a specified thread context. APCs can be queued in any thread, waiting for that thread to execute the routines at an appropriate time (such as during waiting or scheduling). Therefore, using APCs to execute shellcode in user mode does not trigger the creation of new threads, which can also lead to missed detections.

[0069] Based on this, embodiments of this application provide a method for detecting shell code. This method can be applied to various computer devices that may be subject to remote attacks based on shellcode execution. Computer devices include, for example, terminal devices running a Windows operating system, and include, but are not limited to, servers, host computers, personal computers, mobile phones, or workstations.

[0070] Optionally, the computer device in this embodiment is a protected device located in a protected network. From the perspective of the computer device, the protected network where the computer device resides is an internal network, and the Internet is an external network. Optionally, the computer device is a protected server used to provide services to normal clients in the protected network and the Internet. For example, the computer device includes, but is not limited to, application servers or web servers. Among them, application servers include, but are not limited to, game servers, video application servers, file servers, search engine servers, instant messaging servers, etc. Web servers are also called World Wide Web (WWW) servers or website servers.

[0071] Figure 1This is a schematic diagram of the hardware structure of a computer device provided in an embodiment of this application. For example... Figure 1 As shown, the computer device 100 includes a processor 101 and a memory 102, which are connected via a bus 103. Figure 1 The processor 101 and memory 102 are described independently. Alternatively, the processor 101 and memory 102 may be integrated together.

[0072] The memory 102 is used to store computer programs, including an operating system and program code. Optionally, the operating system is a Windows operating system. The memory 102 can be various types of storage media, such as read-only memory (ROM), random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM), flash memory, optical storage, registers, optical disc storage, disk storage, or other magnetic storage devices.

[0073] The processor 101 is a general-purpose processor or a special-purpose processor. The processor 101 may be a single-core processor or a multi-core processor. The processor 101 includes at least one circuit to execute the shell code detection method provided in the embodiments of this application.

[0074] In one possible implementation, the computer device 100 further includes a network interface 104, which is connected to the processor 101 and the memory 102 via a bus 103. The network interface 104 enables the computer device 100 to communicate with other devices.

[0075] Optionally, the computer device 100 also includes an input / output (I / O) interface 105, which is connected to the processor 101 and the memory 102 via a bus 103. The processor 101 can receive input commands or data through the I / O interface 105. The I / O interface 105 is used to connect input devices to the computer device 100, such as a keyboard and mouse. Optionally, in some possible scenarios, the network interface 104 and the I / O interface 105 described above are collectively referred to as a communication interface.

[0076] In another possible implementation, the computer device 100 further includes a display 106, which is connected to the processor 101 and the memory 102 via a bus 103. The display 106 can be used to display intermediate and / or final results generated by the processor 101 executing the shell code detection method provided in this application embodiment, such as network address information of a remote server. For example, the display 106 is a touch screen to provide a human-computer interaction interface.

[0077] Wherein, bus 103 can be any type of communication bus used to interconnect internal devices of computer device 100. For example, a system bus. This embodiment of the application illustrates the interconnection of the aforementioned devices inside computer device 100 via bus 103 as an example. Optionally, the aforementioned devices inside computer device 100 may communicate with each other using connection methods other than bus 103, such as interconnecting the aforementioned devices inside computer device 100 via internal logical interfaces of computer device 100.

[0078] The aforementioned devices can be disposed on separate chips, or at least partially or entirely on the same chip. Whether to dispose of the devices independently on different chips or integrate them on one or more chips often depends on the needs of the product design. This application does not limit the specific implementation of the aforementioned devices.

[0079] Figure 1 The computer device 100 shown is merely exemplary. In the implementation process, the computer device 100 may also include other components, which will not be listed one by one in this document. Figure 1 The computer device 100 shown can detect shell code by executing all or part of the steps of the shell code detection method provided in the embodiments of this application.

[0080] The method flow of the embodiments of this application is illustrated below.

[0081] For example, Figure 2 This is a flowchart illustrating a shell code detection method provided in an embodiment of this application. Figure 2 As shown, the method includes, but is not limited to, steps 201 to 204. The method is applied to a computer device. Optionally, the method is executed by security software running on the computer device, such as endpoint detection and response (EDR) software or extended detection and response (XDR) software. Optionally, the computer device in this method has… Figure 1 The hardware structure shown.

[0082] In step 201, it is detected whether there is a section creation behavior for the system entity on the computer device. This creation behavior is used to create the section of the system entity, which is generated after the sample program is run.

[0083] In this application embodiment, "sample program" refers to any application running on a computer device, such as a browser, office software, or game software. In some cases, running a sample program can also be referred to as executing a sample program. The system entities generated after the sample program is executed include, but are not limited to, any entity on the computer device capable of executing shellcode. This application embodiment does not limit the type of system entity; for example, system entities include threads, processes, or fibers.

[0084] Regardless of the type of system entity, the detection of whether the system entity on the computer device has section creation behavior includes, but is not limited to: registering callback functions in kernel-mode drivers; and detecting whether the system entity has section creation behavior through callback functions.

[0085] In Windows operating systems, kernel-mode callback functions are a mechanism primarily used by the kernel or drivers to allow the operating system to call developer-defined functions when specific events occur. This mechanism is widely used in scenarios such as process startup, thread startup, registry operations, dynamic library loading, and network behavior. In Windows kernel-mode drivers, registering callback functions is typically done through specific APIs. For example, for I / O completion routines, the `IoSetCompletionRoutine` function can be used to associate the callback function with an IRP (I / O request packet). In filter drivers, `FltRegisterFilter` is used to register callback functions to handle file system operations. For other scenarios, such as device drivers, `IoCreateDevice` and other related functions may be used to register the corresponding callback functions, ensuring registration in the appropriate context to avoid system instability.

[0086] In this context, the driver is part of the operating system kernel and is responsible for direct interaction with hardware devices. The driver communicates with user-mode applications via system calls to handle hardware operation requests. In one possible implementation of this application, the driver is a kernel-mode filter driver, for example, a MiniFilter. A MiniFilter driver is a file system filter for the Windows operating system, providing a lightweight and scalable way to monitor and process file system operations. MiniFilter allows developers to insert custom logic at the file system layer to perform specific tasks when operations such as file reading / writing, opening, closing, and loading into memory occur.

[0087] In this embodiment, registering a callback function in the kernel-mode driver includes registering the callback function `IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION` in the filter driver. Thus, the registered callback function is notified when a file is loaded into memory; the opcode `IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION` indicates that a file has been loaded into memory. When this event occurs, it is determined whether a dynamic link library (DLL) has been loaded into memory, thereby further determining whether the system entity has performed section creation. A dynamic link library is a library file (DLL file) provided with the computer device's operating system. DLLs are used to support network communication for applications and include one or more network connection functions. By loading the DLL and calling the network connection functions within it, the system entity on the computer device can establish a network connection.

[0088] In computer systems, creating a section typically refers to defining a specific segment of code or data within a program or file. A section is a continuous block of code or data within an executable or object file. Sections are generated by the compiler or linker to organize code and data for program execution. The primary function of a section is to divide an executable or object file into smaller parts, facilitating program management and debugging. By grouping code and data into different sections, developers can better control the program's structure and behavior. Types of sections include, but are not limited to, the following.

[0089] Code segment (.text): Used to store program code, usually marked as ".text" or ".code". This code is generated by the compiler and combined by the linker to form an executable file or object file. At runtime, the code segment is usually read-only to protect the program code from accidental modification.

[0090] The data segment (.data) is used to store global and static variables of the program and is usually marked with ".data". These variables are initialized at runtime and remain unchanged throughout the program's lifetime.

[0091] Read-only segment (.rodata): Used to store program constants and strings, usually marked as ".rodata". This data cannot be modified during program execution.

[0092] Uninitialized data segment (.bss): This is where global and static variables of the program are stored, and it is usually marked with ".bss". These variables are not initialized during program runtime.

[0093] Regardless of the type of section created, once the system entity detects the creation of a section through the callback function, further detection steps can be executed to promptly detect the execution of suspicious shellcode.

[0094] In step 202, in response to the detection of a section creation behavior, permissions for the section created by the creation behavior are obtained.

[0095] This application does not limit the method of obtaining permissions for the section created by the creation action. For example, a command-line tool can be used to obtain the permissions for the section. The obtained permissions for the section include, but are not limited to, executable permissions, read and write permissions, etc.

[0096] In step 203, in response to the section having executable permissions and the section's file path matching the path of the network dynamic library, the memory block for running the section is determined.

[0097] Executable permissions play a crucial role in the operating system. If a section has executable permissions, it can perform various operations, such as triggering related operations, affecting system security, controlling the script execution environment, and supporting system services. Therefore, when a section has executable permissions, it is necessary to further detect whether the system entity that created the section exhibits suspicious shellcode execution behavior. For example, in this embodiment, the file path of the section is further obtained and matched with the path of a network dynamic library. If the file path of the section matches the path of the network dynamic library, it indicates that the system entity may be loading the network dynamic library, further determining the memory block in which the section runs.

[0098] In one possible implementation, before determining the memory block of the running section, the process includes calling `FltGetFileNameInformation` to obtain the file path corresponding to the section. `FltGetFileNameInformation` is a function used in Windows driver development to obtain file or directory name information, typically used in file system filter drivers to retrieve name information associated with a specific file or directory, and supports various name formats and query methods. Therefore, by calling `FltGetFileNameInformation` to obtain the file path corresponding to the section, the reliability and accuracy of the obtained file path are improved.

[0099] Subsequently, the computer device matches the file path of the section with the path of the network dynamic library. This embodiment of the application does not limit the matching process. For example, matching the file path of the section with the path of the network dynamic library includes, but is not limited to, the path included in the file path of the section being the same as the path of the network dynamic library, and / or, the file name included in the file path of the section being the same as the file name of the network dynamic library.

[0100] Network dynamic libraries (DLLs) are dynamic link libraries that are loaded and used over the network at runtime. They allow programs to dynamically acquire and use remote code and data as needed. DLLs provide basic network communication functionalities, such as TCP / UDP socket operations. Because they are loaded over the network at runtime, programs can dynamically acquire and use remote code and data resources without recompilation. Multiple programs can share the same DLL, reducing memory and disk space usage. DLLs include, but are not limited to, ws2_32.dll, wininet.dll, dnsapi.dll, winhttp.dll, mswsock.dll, or urlmon.dll.

[0101] The path to a network dynamic library (DLL) indicates where the operating system locates and loads the DLL. This location may be, for example, the DLL's storage location on the hard drive (consisting of a directory and filename). When an application attempts to load a DLL, the operating system searches directories in a specific order until it finds the DLL's filename. If the file path of a section created by a system entity includes a filename that matches the DLL's filename, it indicates that the system entity has the potential to load the DLL.

[0102] System entities on a computer device can achieve network connectivity by loading dynamic link libraries (DLLs) and then calling network connection functions within those DLLs. Optionally, the network connection functions in the network DLL include, but are not limited to, one or more of the following functions: InternetConnectA, InternetConnectW, UrlDownloadToFile, connect, WinHttpConnect, or DnsQuery. Determining whether the file path of a section matches the path of the network DLL by checking the filename is a simple and efficient method.

[0103] Furthermore, since the characteristics of the memory block used to run shellcode differ somewhat from those of the memory block used to run normal applications, the memory block for running the section is further determined when the file path of the section matches the path in the network dynamic library. This allows for the determination of whether the memory block for running the section is the memory block for running shellcode based on its characteristics. This application does not limit the method of determining the memory block for running the section. For example, it may determine the memory block by calling a debugger, by using the memory mapping relationship of the process, or by calling a memory analysis tool.

[0104] In step 204, if the memory block meets the conditions for shellcode execution, it is determined that the system entity has suspicious shellcode execution behavior.

[0105] The shellcode execution conditions are determined based on the characteristics of the memory block in which the shellcode runs. Before shellcode runs on a computer device, it needs to allocate a memory block in the device's memory for execution. Since the characteristics of the memory block used to run shellcode differ from those of the memory block used to run normal applications (including but not limited to memory block size, permissions, and content), this application summarizes these characteristics to determine whether the memory block containing the running code meets the shellcode execution conditions based on its size, permissions, or content. This further ensures the accuracy of detecting suspicious shellcode execution behavior in system entities. The memory block must meet at least one of the following shellcode execution conditions:

[0106] (1) Operating condition 1: The size of the memory block is equal to the size of the memory page in the operating system.

[0107] When the size of a memory block equals the size of a memory page in the operating system, the memory block is considered to meet the conditions for shellcode execution. The size of a memory page in the operating system is the smallest unit of memory allocation. For example, the default size of a memory page in Windows is typically 4 kilobytes (KB). In this case, condition 1 means that when the size of the memory block containing the executable code is 4KB, the memory block is considered to meet the conditions for shellcode execution. Since normal application code segments usually contain compiler code, the memory occupied by a normal application code segment is generally much larger than the size of a memory page in the operating system (e.g., 4KB). Shellcode, as machine code, requires very little memory to run, typically less than the size of a memory page in the operating system (e.g., 4KB). Therefore, if the size of the memory block containing the executable code equals the size of a memory page in the computer's operating system, then the executable code is very likely shellcode. It is worth noting that the size of a memory page in the operating system can be configured and modified; for example, the size of a memory page in Windows can be set to 8KB or 32KB, among other values.

[0108] (2) Operating condition 2: The memory block has private permissions, write permissions and execute permissions.

[0109] When a memory block has private, write, and execute permissions, it is determined that the memory block meets the conditions for shellcode execution. Since the memory block containing the code segment of a normal application typically only has read and execute permissions, while the memory block containing shellcode requires private, write, and execute permissions to support the normal operation of the shellcode, if the memory block containing the running code has private, write, and execute permissions, then the running code is highly likely to be shellcode.

[0110] (3) Running condition 3: The memory block contains the format header of the PE file.

[0111] When a memory block contains the header of a PE file, it is determined that the memory block meets the conditions for shellcode execution. Since the header of a normal application's PE file is read-only, while the code segment of a normal application's PE file is readable and executable, and permissions within the same memory block are identical, a normal application running in memory will have its PE file header and code segment loaded into different memory blocks, giving them different read and write permissions. However, when shellcode runs in the computer's memory, its PE file is loaded completely into the same memory block. Therefore, if the memory block containing the executable code also contains the header of a PE file, then the executable code is highly likely to be shellcode. Since the memory block containing the executable code must include the code segment of the PE file, if the memory block also contains the header of the PE file, it means that the memory block contains the complete PE file. Accordingly, the above statement that a memory block contains the header of a PE file means that the memory block contains the complete PE file, or that the memory block contains both the header and code segment of a PE file.

[0112] This application does not limit the order in which the three operating conditions are judged. For example, the computer device sequentially judges whether the size, permissions, and content of the target memory block meet the shellcode execution conditions. If the memory block does not meet the shellcode execution conditions, it means that the code used to load the dynamic link library in the memory block is normal code, and the computer device does not interfere with the network behavior after the code. Once it is determined that the target memory block meets the shellcode execution conditions, the judgment process stops. If the memory block meets the shellcode execution conditions, it means that the code used to load the network dynamic link library in the memory block is shellcode, and the computer device determines that the system entity has suspicious shellcode execution behavior and needs to prevent the network behavior after the shellcode.

[0113] In one possible implementation, after determining that a system entity exhibits suspicious shellcode execution behavior, the process further includes terminating the running system entity. This application does not limit the method of terminating the system entity; timely stopping the system entity's execution can prevent the system entity from executing shellcode to attack the computer device. For example, terminating the execution of the system entity before it successfully calls a network connection function in a dynamic link library. Terminating the execution of the system entity by the computer device includes, but is not limited to, shutting down the system entity and releasing the memory space occupied by the system entity.

[0114] In one possible implementation, before terminating the running system entity, the process further includes: sending a detection command to a user-mode detection program, the detection command being used by the user-mode detection program to detect the system entity; receiving the detection result fed back by the user-mode detection program; and, if the detection result indicates that the system entity is attempting to execute shellcode, performing the operation to terminate the running system entity.

[0115] This application does not limit the type of user-mode detection program, as long as it can detect whether a system entity is executing suspicious shellcode. By sending a detection command to the user-mode detection program, the program determines whether the system entity is executing suspicious shellcode. The computer device then decides whether to block or allow the system entity based on the detection results from the user-mode detection program, achieving dual detection and further improving the accuracy of the detection results.

[0116] In this embodiment, when a computer device determines that shellcode is running in a sample program, it treats the sample program as malicious, causing it to terminate execution before successfully calling the network connection function in the network dynamic link library. This prevents the application from connecting to a remote server, thus protecting the computer device from being controlled by an attacker via a remote server or having its internal data stolen by an attacker via a remote server. Furthermore, by registering callback functions in kernel-mode drivers to detect the existence of section creation behavior, the execution of suspicious shellcode in all system entities can be intercepted, including intercepting known and unknown operating system remote RCE vulnerabilities. This improves the comprehensiveness of shellcode detection and further enhances the security of the computer device.

[0117] Furthermore, the order of steps in the shell code detection method provided in this application can be appropriately adjusted, and steps can be added or removed as needed. Any variations that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application.

[0118] The following describes an example of a virtual device in an embodiment of this application.

[0119] Figure 3 This is a schematic diagram of the structure of a shell code detection device provided in an embodiment of this application. It has... Figure 3 The shell code detection device shown is used to implement the above. Figure 2 The method described in the illustrated embodiment. Optionally, Figure 3 The device for detecting the shell code shown is Figure 1The computer equipment shown, or, Figure 3 The device for detecting the shell code shown is Figure 1 The security software in the computer device shown. For example... Figure 3 As shown, the shell code detection device 300 includes a detection module 301, an acquisition module 302, and a determination module 303.

[0120] The detection module 301 is used to detect whether there is a section creation behavior for the system entity on the computer device. The creation behavior is used to create a section of the system entity, which is generated after the sample program is run.

[0121] The acquisition module 302 is used to acquire the permissions of the section created by the creation behavior in response to the detection of the existence of section creation behavior;

[0122] Module 303 is used to determine the memory block in response to the section having executable permissions and the section's file path matching the path of the network dynamic library;

[0123] The determination module 303 is also used to determine whether a system entity has suspicious shellcode execution behavior when the memory block meets the shellcode execution conditions.

[0124] In one possible implementation, the detection module 301 is used to register a callback function in the kernel-mode driver; the callback function is used to detect whether the system entity has section creation behavior.

[0125] In one possible implementation, the driver is a kernel-mode filter driver, and the detection module 301 is used to register the callback function of IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION in the filter driver.

[0126] In one possible implementation, module 302 is also used to call FltGetFileNameInformation to obtain the file path corresponding to the section.

[0127] In one possible implementation, the memory block satisfies the shellcode execution conditions, including at least one of the following:

[0128] The size of a memory block is equal to the size of a memory page in the operating system;

[0129] The memory block has private permissions, write permissions, and execute permissions;

[0130] The memory block contains the format header of the PE file.

[0131] In one possible implementation, matching the file path of a section with the path of a network dynamic library means that the filenames included in the file path of the section are the same as the filenames of the network dynamic library.

[0132] In one possible implementation, see Figure 4 The device also includes:

[0133] Interception module 304 is used to terminate the running system entity after determining that the system entity has suspicious shellcode execution behavior.

[0134] In one possible implementation, the interception module 304 is further configured to send a detection instruction to the user-mode detection program before terminating the running system entity, the detection instruction being used by the user-mode detection program to detect the system entity; receive the detection result fed back by the user-mode detection program; and, if the detection result indicates that the system entity is attempting to execute shellcode, execute the operation to terminate the running system entity.

[0135] In one possible implementation, the device is executed by security software running on a computer device.

[0136] Appendix Figure 3 or Figure 4 The described device embodiments are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module. Appendix Figure 3 or Figure 4 The aforementioned modules can be implemented either in hardware or as software functional units. For example, when implemented in software, the detection module 301, acquisition module 302, determination module 303, and interception module 304 can be implemented by an auxiliary component. Figure 1 The processor 101 reads the program code stored in the memory 102 and generates software function modules to implement it. Figure 3 or Figure 4 The aforementioned modules can also be implemented separately by different hardware components of a computer device. For example, the detection module 301, acquisition module 302, determination module 303, and interception module 304 are attached... Figure 1 A portion of the processing resources in the processor 101 (e.g., one core in a multi-core processor) are implemented.

[0137] This application also provides a computer device, including: a memory, a network interface, and at least one processor. The memory stores program instructions, and the at least one processor reads the program instructions stored in the memory, causing the computer device to execute the aforementioned instructions. Figure 2 The method shown. Optionally, the hardware structure of the computer device is as follows: Figure 1 As shown.

[0138] This application also provides a computer-readable storage medium storing instructions that, when executed by a processor of a computer device, implement the steps performed by the computer device in the above method embodiments.

[0139] This application also provides a computer program product, including a computer program, which, when executed by the processor of a computer device, implements the steps executed by the computer device in the above method embodiments.

[0140] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0141] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects, and should not be construed as indicating or implying relative importance.

[0142] In the description of the embodiments in this application, unless otherwise stated, "at least one" means one or more. "More than one" means two or more.

[0143] A references B, which means that A is the same as B or A is a simple variation of B.

[0144] In this application, the character " / " generally indicates that the objects before and after it are in an "or" relationship.

[0145] Optionally, in the above embodiments, all or part of the implementation is carried out by software, hardware, firmware, or any combination thereof. Optionally, when implemented using software, it is implemented in the form of a computer program product, which is implemented in whole or in part. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. Optionally, the computer is a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Optionally, the computer instructions are stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. Optionally, the computer-readable storage medium is any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. Alternatively, the available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video disks, DVDs), or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0146] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for detecting shell code, characterized in that, The method is performed by a computer device, and the method includes: The system entity on the computer device is detected to have a section creation behavior, which is used to create a section of the system entity, which is generated after the sample program is run. In response to detecting the existence of the section creation behavior, obtain the permissions of the section created by the creation behavior; In response to the section having executable permissions and the file path of the section matching the path of the network dynamic library, the memory block for running the section is determined; If the memory block meets the conditions for shellcode execution, it is determined that the system entity has suspicious shellcode execution behavior.

2. The method according to claim 1, characterized in that, The detection of whether a section creation behavior exists in the system entity on the computer device includes: Register callback functions in kernel-mode drivers; The callback function is used to detect whether the system entity has a section creation behavior.

3. The method according to claim 2, characterized in that, The driver is a kernel-mode filter driver, and registering callback functions in the kernel-mode driver includes: Register the callback function IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION in the filter driver.

4. The method according to any one of claims 1-3, characterized in that, Before determining the memory block to run the section, the method further includes: Call FltGetFileNameInformation to obtain the file path corresponding to the section.

5. The method according to any one of claims 1-4, characterized in that, The memory block satisfies the conditions for shellcode execution, including at least one of the following: The size of the memory block is equal to the size of the memory page in the operating system; The memory block has private permissions, write permissions, and execute permissions; The memory block contains the format header of a removable executable PE file.

6. The method according to any one of claims 1-5, characterized in that, The matching of the file path of the section with the path of the network dynamic library means that the file name included in the file path of the section is the same as the file name of the network dynamic library.

7. The method according to any one of claims 1-6, characterized in that, After determining that the system entity exhibits suspicious shellcode execution behavior, the process further includes: The system entity will be terminated.

8. The method according to claim 7, characterized in that, Before terminating the operation of the system entity, the following is also included: Send a detection command to the user-mode detection program, the detection command being used by the user-mode detection program to detect the system entity; Upon receiving the detection result from the user-mode detection program, if the detection result indicates that the system entity is attempting to execute shellcode, the operation of terminating the operation of the system entity is executed.

9. The method according to any one of claims 1 to 8, characterized in that, The method is performed by security software running on the computer device.

10. A shell code detection device, characterized in that, The detection device is located in a computer device, and the detection device includes: The detection module is used to detect whether the system entity on the computer device has a section creation behavior, the creation behavior being used to create a section of the system entity, the system entity being generated after the sample program runs; The acquisition module is used to acquire the permissions of the section created by the creation behavior in response to the detection of the existence of the section creation behavior; A determination module is used to determine the memory block in which the section is executed in response to the section having executable permissions and the file path of the section matching the path of the network dynamic library; The determining module is further configured to determine, if the memory block meets the conditions for shellcode execution, that the system entity has suspicious shellcode execution behavior.

11. The apparatus according to claim 10, characterized in that, The detection module is used to register callback functions in the kernel-mode driver; and to detect whether the system entity has section creation behavior through the callback functions.

12. The apparatus according to claim 11, characterized in that, The driver is a kernel-mode filter driver, and the detection module is used to register the callback function of IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION in the filter driver.

13. The apparatus according to any one of claims 10-12, characterized in that, The acquisition module is also used to call FltGetFileNameInformation to obtain the file path corresponding to the section.

14. The apparatus according to any one of claims 10-13, characterized in that, The memory block satisfies the conditions for shellcode execution, including at least one of the following: The size of the memory block is equal to the size of the memory page in the operating system; The memory block has private permissions, write permissions, and execute permissions; The memory block contains the format header of a removable executable PE file.

15. The apparatus according to any one of claims 10-14, characterized in that, The matching of the file path of the section with the path of the network dynamic library means that the file name included in the file path of the section is the same as the file name of the network dynamic library.

16. The apparatus according to any one of claims 10-15, characterized in that, The device further includes: The interception module is used to terminate the operation of the system entity after determining that the system entity has suspicious shellcode execution behavior.

17. The apparatus according to claim 16, characterized in that, The interception module is also used to send a detection instruction to the user-mode detection program before terminating the operation of the system entity. The detection instruction is used by the user-mode detection program to detect the system entity. Upon receiving the detection result from the user-mode detection program, if the detection result indicates that the system entity is attempting to execute shellcode, the operation of terminating the operation of the system entity is executed.

18. The apparatus according to any one of claims 10 to 17, characterized in that, The device is executed by security software running in the computer device.

19. A computer device, characterized in that, The computer device includes a memory and at least one processor. The memory is used to store program instructions. After the at least one processor reads the program instructions stored in the memory, it causes the computer device to execute the method according to any one of claims 1-9.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 9.

21. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the method as described in any one of claims 1 to 9.

Images