Memory malicious software detection method based on IOCTL communication
Through IOCTL communication, the memory rootkit is detected, and the driver's DriverEntry pointer position is verified, which solves the problem of insufficient rootkit detection capabilities in the existing technology, and realizes efficient and low-impact memory rootkit recognition and real-time monitoring.
Patent Information
- Application Number
- CN202510357762.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-25
- Publication Date
- 2025-07-11
AI Technical Summary
The existing rootkit detection scheme lacks the Rootkit detection capability of unknown features, and it is difficult to effectively identify the rootkit in memory through file scanning and behavioral rules matching.
By traversing the device object and checking whether its image in kernel memory is supported by a valid module, using IOCTL communication to detect the memory rootkit, verifying whether the driver's DriverEntry pointer is in the loaded module address space.
It realizes accurate detection of unknown rootkits, reduces false positive rates, and reduces the impact on system performance. It is suitable for real-time monitoring and automated detection.
Smart Images
Figure CN120296734A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of information security technology, and particularly relates to a method for detecting memory malware based on IOCTL communication. Background Art
[0002] A Windows memory rootkit is a malware that executes and resides in the kernel memory. Its goal is to tamper with and control the kernel part of the Windows operating system to hide itself and its malicious behaviors. This rootkit manually maps the malicious driver program layout into the kernel memory and specifically resides in the kernel memory without writing to the disk, thus reducing the risk of being detected.
[0003] Existing rootkit detection solutions:
[0004] 1. By scanning driver program files and matching them with a feature library.
[0005] 2. Auditing the behaviors during the system operation, and discovering abnormal behaviors in the system through the method of behavior rule matching, and detecting possible Rootkits through this method.
[0006] Existing rootkit detection solutions have the following problems:
[0007] 1. The scanning file detection solution has a high dependence on the feature library. It can effectively detect Rootkits with known features, but it is difficult to detect Rootkits with unknown features.
[0008] 2. It has a high dependence on behavior rules. It can only match Rootkits with known behavior features, but it is difficult to match Rootkits with unknown behavior features. Summary of the Invention
[0009] The purpose of this application is to provide a method for detecting memory malware based on IOCTL communication to overcome the defects of the existing technology. The aim is to detect memory rootkits by traversing all device objects and checking whether their images in the kernel memory are actually supported by valid modules.
[0010] The purpose of this application is achieved through the following technical solutions:
[0011] A method for detecting memory malware based on IOCTL communication, the method includes:
[0012] Open a specified directory object and return a first handle;
[0013] Obtain the kernel pointer of the directory object according to the first handle;
[0014] Obtain and determine whether the driver entry address of the directory object is within the address space of a preset module. If the result is negative, it is determined that there is malware.
[0015] Further, the method further includes:
[0016] Before determining whether the driver entry address is within the address space of a preset module, obtain an exclusive lock for accessing the directory object, and release the exclusive lock after the determination step.
[0017] Further, the method further includes:
[0018] Count the reference count for the directory object.
[0019] Further, the method obtains the driver entry address by iterating through the hash bucket.
[0020] Further, the method checks whether the driver entry address is within the address space of a preset module by traversing the list of loaded driver modules.
[0021] Further, the traversing the list of loaded driver modules and checking whether the driver entry address is within the address space of a preset module specifically includes:
[0022] Loop through each entry in the linked list of driver modules. For each entry, calculate the start address and end address, and make a determination based on whether the driver entry address is between the start address and the end address.
[0023] Further, the method further includes:
[0024] Before opening the specified directory object, initialize a first structure that describes the object directory to be opened.
[0025] Further, the method further includes:
[0026] Place the thread accessing the directory object in a critical section.
[0027] The beneficial effects of this application are as follows:
[0028] (1) By verifying the position of the DriverEntry (driver entry) pointer, this application can accurately identify driver programs that point to unmapped memory regions or illegal regions. This method can accurately detect those malicious drivers that have been tampered with or disguised, rather than simply based on the driver program name or other easily disguised information. And the DriverEntry pointer of the driver program must be within the address space of the loaded module, so it is very difficult to avoid this address space-based detection method.
[0029] (2) This application only performs inspection and traversal operations on memory addresses, without performing a large number of complex calculations or frequent disk operations, thus having a relatively small impact on system performance.
[0030] (3) Since the DriverEntry (driver entry) pointer of the driver must be within the address space of the loaded module, the anti-evasion performance of malware detection is enhanced.
[0031] (4) The method of this application depends on the memory address of the driver and the address space of the loaded module, causing less interference to the normal behavior of the system, effectively reducing the false positive rate. A normal driver should always be located in a valid memory area.
[0032] (5) This application is applicable to automated detection, can periodically scan the system to ensure continuous monitoring of the integrity of the driver, and this real-time detection helps to quickly respond to and handle potential security threats. BRIEF DESCRIPTION OF THE DRAWINGS
[0033] Figure 1 is the flow chart of the rootkit's communication process based on IOCTL;
[0034] Figure 2 is the principle flow chart of the memory malware detection method based on IOCTL communication in the embodiment of this application;
[0035] Figure 3 is the specific detection flow chart of the memory malware detection method based on IOCTL communication in the embodiment of this application. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0036] The following uses specific specific examples to illustrate the implementation manners of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific implementation manners, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, without conflict, the following embodiments and the features in the embodiments can be combined with each other.
[0037] Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the scope protected by this application.
[0038] Existing rootkit detection solutions have the following problems:
[0039] 1. The scanning file detection solution has a high degree of dependence on the feature library, can effectively detect rootkits with known features, but is difficult to detect rootkits with unknown features.
[0040] 2. It has a high degree of dependence on behavioral rules and can only match Rootkits with known behavioral characteristics, making it difficult to match Rootkits with unknown behavioral characteristics.
[0041] To solve the above technical problems, the following various embodiments of a method for detecting memory malware based on IOCTL communication in this application are proposed.
[0042] The embodiments of this application provide a memory rootkit detection scheme. Memory rootkit files do not land and cannot be detected through file detection. However, most rootkits choose to communicate based on IOCTL, and the rootkit will create a device object. This scheme detects memory rookits that communicate based on IOCTL. The rootkit that communicates based on IOCTL displays the created device object in the Windows object manager. Memory rootkits are detected by traversing all device objects and checking whether their images in kernel memory are actually supported by valid modules.
[0043] First, analyze the rootkit's communication process based on IOCTL:
[0044] Refer to Figure 1 As Figure 1 shown is the flowchart of the rootkit's communication process based on IOCTL.
[0045] The driver creates a device object through IoCreateDevice. The device object is exposed to user-mode applications through a symbolic link.
[0046] The user-mode application opens a device object by calling the CreateFile function and obtains a device handle. Subsequently, the application uses the DeviceIoControl function to send an IOCTL request through this handle. The Windows I / O manager receives this request, encapsulates it as an IRP (I / O Request Packet), and passes it to the kernel-mode driver. The driver's DispatchDeviceControl routine processes this IRP and performs corresponding operations according to the IOCTL request. The entire process relies on the device object as a communication bridge to enable the application to interact with the driver.
[0047] Based on this, this application proposes a method for detecting memory malware based on IOCTL communication. Refer to Figure 2 As Figure 2 shown is the principle flowchart of the method for detecting memory malware based on IOCTL communication in the embodiments of this application.
[0048] When each driver is loaded into memory, Windows creates a DRIVER_OBJECT structure for it. This structure contains various information and callback functions of the driver. The DRIVER_OBJECT structure is a kernel object that describes the driver, including the entry point of the driver, the uninstall routine, the major function dispatch table (MajorFunction), and a pointer to the linked list of device objects.
[0049] A driver can create one or more device objects, and each device object is represented by a DEVICE_OBJECT structure. Device objects usually represent a logical or physical device controlled by the driver. The DEVICE_OBJECT structure describes a device object, including the status information of the device, a pointer to the driver object, the device extension, etc.
[0050] Each DEVICE_OBJECT structure has a pointer to the DRIVER_OBJECT structure that created it. This pointer is stored in the DriverObject field of the DEVICE_OBJECT structure.
[0051] Scan the \Driver directory to find driver objects and check whether their DriverEntry functions are within the address space of the loaded module to determine whether they are malicious rookit drivers.
[0052] Refer to Figure 3 , as Figure 3 shown is the specific detection flow block diagram of the memory malware detection method based on IOCTL communication in the embodiment of the present application. The specific detection process is as follows:
[0053] 1. Initialize object attributes and open the \Driver directory: Use the
[0054] InitializeObjectAttributes function to initialize an OBJECT_ATTRIBUTES structure, which describes the object directory to be opened. Here, we specify the directory name as \Driver and use the OBJ_CASE_INSENSITIVE flag to ignore case. Use the
[0055] ZwOpenDirectoryObject function to open the specified directory object (i.e., \Driver) and return a handle. This handle will be used for subsequent operations to reference the directory object.
[0056] 2. Referencing the directory object: The ObReferenceObjectByHandle function retrieves the kernel pointer of the directory object based on the previously obtained handle. This function increments the reference count of the object to ensure that the object is not deleted during the operation. directoryObject is a pointer to the OBJECT_DIRECTORY structure, which is used to access the content of the directory object subsequently.
[0057] 3. Obtaining the lock for accessing the directory object: The KeEnterCriticalRegion function places the current thread in a critical section, preventing thread scheduling switches and ensuring that the current thread runs exclusively.
[0058] The ExAcquirePushLockExclusiveEx function acquires the exclusive lock of directoryObject. This ensures that no other thread is operating on the directory object simultaneously when accessing and modifying it, thus guaranteeing thread safety.
[0059] 4. Iterating through the hash buckets to obtain the DriverEntry address: The for loop iterates through each hash bucket of directoryObject. A hash bucket is an array containing pointers to OBJECT_DIRECTORY_ENTRY structures, and each structure represents an entry in the directory. The inner while loop iterates through the entries in each hash bucket, checking if each entry is non-null and contains an object. For each entry, entry->Object is cast to a PDRIVER_OBJECT type pointer, which represents a driver object. The DriverInit address can be obtained based on this pointer. The DriverInit address is the same as the DriverEntry address.
[0060] 5. Making a judgment: The GetDriverForAddress function iterates through the list of loaded driver module lists to check if the given address is within the address space of a certain module.
[0061] g_drvObj->DriverSection is a pointer to the head of the driver module linked list. The for loop iterates through each KLDR_DATA_TABLE_ENTRY entry (up to 512) in the linked list. For each entry, the start address startAddr and end address endAddr of the module are calculated. If the given address is between startAddr and endAddr, the corresponding KLDR_DATA_TABLE_ENTRY entry is returned. If the address is still not within the scope of any module after iterating through all entries, NULL is returned.
[0062] 6. Release the lock: The ExReleasePushLockExclusiveEx function releases the exclusive lock of the previously acquired directory object. The KeLeaveCriticalRegion function leaves the critical section, allowing thread scheduling to resume normal operation.
[0063] In this embodiment, by verifying the position of the DriverEntry (driver entry) pointer, the driver programs pointing to unmapped memory regions or illegal regions can be accurately identified. This method can accurately detect those malicious driver programs that have been tampered with or disguised, rather than simply based on the driver program name or other easily disguised information. And the DriverEntry pointer of the driver program must be within the address space of the loaded module, so it is difficult to circumvent this address space-based detection method.
[0064] This embodiment only performs inspection and traversal operations on memory addresses, without performing a large number of complex calculations or frequent disk operations, thus having less impact on system performance.
[0065] In this embodiment, since the DriverEntry (driver entry) pointer of the driver program must be within the address space of the loaded module, the anti-evasion performance of malware detection is enhanced.
[0066] This embodiment depends on the memory address of the driver program and the address space of the loaded module, with less interference to the normal behavior of the system, and can effectively reduce the false alarm rate. A normal driver program should always be located in a valid memory area.
[0067] This embodiment is applicable to automated detection, can periodically scan the system to ensure continuous monitoring of the integrity of the driver program, and this real-time detection helps to quickly respond to and handle potential security threats.
[0068] The above are only the preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent replacements, and improvements made within the spirit and principle of the present application shall be included within the protection scope of the present application.
Claims
1. A method for detecting memory malware based on IOCTL communication, characterized in that, The method includes: Opening a specified directory object and returning a first handle; Obtaining a kernel pointer of the directory object according to the first handle; Obtaining and determining whether a driver entry address of the directory object is within an address space of a preset module. If the result is negative, it is determined that malware exists.
2. The method for detecting memory malware based on IOCTL communication according to claim 1, wherein The method further includes: Before determining whether the driver entry address is within the address space of the preset module, obtaining an exclusive lock for accessing the directory object and releasing the exclusive lock after the determination step ends.
3. The memory malware detection method based on IOCTL communication according to claim 1, wherein The method further includes: Counting a reference count of the directory object.
4. The method for detecting memory malware based on IOCTL communication according to claim 1, wherein The method obtains the driver entry address by iterating over a hash bucket.
5. The method for detecting memory malware based on IOCTL communication according to claim 1, characterized in that, The method checks whether the driver entry address is within the address space of the preset module by traversing a list of loaded driver program modules.
6. The method for detecting memory malware based on IOCTL communication according to claim 5, wherein The traversing the list of loaded driver program modules and checking whether the driver entry address is within the address space of the preset module specifically includes: Looping through each entry in the linked list of driver program modules. For each entry, calculating a start address and an end address, and making a determination based on whether the driver entry address is between the start address and the end address.
7. The method for detecting memory malware based on IOCTL communication according to claim 1, wherein The method further includes: Before opening the specified directory object, initializing a first structure that describes the object directory to be opened.
8. The method for detecting memory malware based on IOCTL communication according to claim 1, wherein, The method further includes: Placing a thread accessing the directory object in a critical section.