Monitoring method and device for white utilization in system

Abstract

The invention provides a monitoring method and device for white utilization in a system, and the method comprises the steps: responding to the creation of a legal process in a target system, and obtaining a DLL file called by the process; obtaining an export function of the DLL file; judging whether the derived function is an invalid function or a transfer function; if the derived function is an invalid function or a transfer function, determining that the DLL file is a malicious DLL file, and further determining that the process has white utilization; and if the derived function is not the invalid function and the transfer function, determining that the DLL file is a normal DLL file, and further determining that the process does not have white utilization. When a system creates a legal process, an export function of the DLL file called by the process is obtained, and then whether white utilization exists in the process or not is determined according to the type of the export function. When the derived function is an invalid function or a transfer function, it is indicated that the DLL file is suspicious, and then it is determined that white utilization exists in the process. Even for unknown white utilization, the system can realize monitoring, so that the accuracy of white utilization monitoring in the system is improved.

Description

Technical Field

[0001] The present application relates to the field of terminal security protection technology, and in particular to a method for monitoring white utilization in a system, a device for monitoring white utilization in a system, an electronic device, and a computer-readable storage medium. Background Art

[0002] White exploitation is a means of attack in which the attacker uses a legitimate executable program (white program) to load and run a malicious dynamic-link library (DLL) file, thereby bypassing the system's security detection and defense mechanisms, and performing malicious actions in the victim's system. For example, the ransomware attack on the system was carried out through white exploitation.

[0003] At present, to monitor the system for white-exploitation, it is necessary to collect the white-exploitation behaviors that have been discovered in advance, such as: collecting known legal executable program utilization methods, malicious DLL files, etc. In actual monitoring, every behavior of the system is obtained, and the obtained behavior is matched with the collected white-exploitation behaviors. If the match fails, it means that the corresponding behavior is not white-exploitation behavior, and white-exploitation protection processing will no longer be performed on this behavior. If the match is successful, it means that the corresponding behavior is white-exploitation behavior, and then the behavior is prevented from continuing in the system, so as to achieve the purpose of white-exploitation monitoring and protection in the system.

[0004] However, for white-exploitation behaviors that have not yet been discovered, the corresponding legitimate executable program utilization methods, malicious DLL files, etc. cannot be known. In other words, for unknown white-exploitation behaviors, the system is currently unable to effectively identify them, which leads to low accuracy of white-exploitation monitoring in the system. Summary of the invention

[0005] The purpose of the embodiments of the present application is to provide a method for monitoring white utilization in a system, a device for monitoring white utilization in a system, an electronic device, and a computer-readable storage medium, so as to improve the accuracy of white utilization monitoring in the system.

[0006] In order to solve the above technical problems, the embodiments of the present application provide the following technical solutions:

[0007] A first aspect of the present application provides a method for monitoring white exploits in a system, the method comprising: in response to the creation of a legitimate process in a target system, obtaining a DLL file called by the process; obtaining an export function of the DLL file; determining whether the export function is an invalid function or a transit function; if the export function is an invalid function or a transit function, determining that the DLL file is a malicious DLL file, and then determining that the process has white exploits; if the export function is not an invalid function or a transit function, determining that the DLL file is a normal DLL file, and then determining that the process has not white exploits.

[0008] Compared with the prior art, the method for monitoring white utilization in the system provided in the first aspect of the present application, for unknown white utilization, when the system creates a legitimate process, obtains the export function of the DLL file called by the process, and then determines whether there is white utilization in the process by the type of the export function. When the export function is an invalid function or a transfer function, it indicates that the DLL file is suspicious, and then determines that there is white utilization in the process. In this way, even if it is unknown white utilization, the system can also realize monitoring, thereby improving the accuracy of white utilization monitoring in the system.

[0009] In some changed implementation modes of the first aspect of the present application, determining whether the exported function is an invalid function or a transit function includes: using a disassembly engine to reverse process the exported function to obtain a target function; determining whether the target function is an invalid function or a transit function; if the target function is an invalid function or a transit function, determining that the exported function is an invalid function or a transit function; if the target function is neither an invalid function nor a transit function, determining that the exported function is neither an invalid function nor a transit function.

[0010] The export function is converted from machine code to assembly language through the disassembly engine, making the specific content of the export function easier to identify, thereby improving the judgment efficiency of the export function.

[0011] In some changed implementation modes of the first aspect of the present application, determining whether the target function is an invalid function or a transit function includes: substituting a preset assembly instruction into the target function, and controlling the execution of the target function after the instruction is substituted; determining whether a return or a jump occurs within a preset time length at the beginning of execution of the target function after the instruction is substituted; if a return occurs, determining that the target function is an invalid function; if a jump occurs, determining that the target function is a transit function; if no return or jump occurs, determining that the target function is not an invalid function or a transit function.

[0012] By substituting instructions into functions and controlling the implementation of the functions with the substituted instructions, it is possible to judge whether the function is an invalid function or a transit function based on the behavioral performance at the initial stage of function execution. This can avoid misjudgment caused by inaccurate static characteristics of invalid functions or transit functions, and can achieve judgment without paying attention to the entire execution performance of the function, while improving the accuracy and efficiency of function judgment.

[0013] In some changed implementation modes of the first aspect of the present application, there are multiple export functions. Before determining whether the export function is an invalid function or a transit function, the method further includes: obtaining the addresses of the multiple export functions; determining whether the addresses of at least two of the multiple export functions are the same; if so, determining that the DLL file is a malicious DLL file, and then determining that there is a white exploit in the process; if not, executing the step of determining whether the export function is an invalid function or a transit function.

[0014] Generally, only attackers will correspond different export functions to the same address, so that they can introduce system-related information to the address through the execution of different export functions, thereby achieving the purpose of attack. Therefore, when there are multiple export functions, and some export functions correspond to the same address, the DLL files corresponding to the export functions with the same address are directly determined as malicious DLL files, thereby determining that the process has white exploitation, without the need to make more specific judgments on the export functions, and improving the efficiency of white exploitation monitoring.

[0015] In some changed implementation modes of the first aspect of the present application, before obtaining the export function of the dynamic link library DLL file called by the process, the method also includes: matching the process in a white exploit database, the white exploit database including legitimate processes involved in known white exploits; if the match fails, determining whether the DLL file in the directory where the process is located or the current directory is malicious; if the match is successful, determining whether the DLL file called by the process is a known white file; if it is not a known white file, determining that the DLL file called by the process is a malicious DLL file; if it is a known white file, determining whether the DLL file in the directory where the process is located or the current directory is malicious; if there is maliciousness, determining that the DLL file called by the process is a malicious DLL file; if there is no maliciousness, executing the step of obtaining the export function of the dynamic link library DLL file called by the process.

[0016] Before using the export function of the DLL file to determine whether the process has a white exploit, the DLL file is first detected for maliciousness through the legitimate processes involved in the white exploit recorded in the white exploit database, as well as the known white files and the DLL files in the process directory or the current directory. Using known data for detection, that is, matching, can speed up the detection of malicious DLL files, thereby improving the efficiency of white exploit detection.

[0017] In some changed implementation modes of the first aspect of the present application, determining whether a DLL file in the directory where a process is located or in the current directory is malicious includes: obtaining a static DLL file from an import table and a delayed import table of the process; matching the static DLL file in a preset DLL file library, which includes DLL files that need to be called when the process is running normally; if the match is successful, determining that the DLL file in the directory where the process is located or in the current directory is not malicious; if the match fails, determining that the DLL file in the directory where the process is located or in the current directory is malicious; and or obtaining a dynamic DLL file called when the process is running; matching the dynamic DLL file in a malicious DLL file library, which includes known malicious DLL files; if the match is successful, determining that the DLL file in the directory where the process is located or in the current directory is malicious; if the match fails, determining that the DLL file in the directory where the process is located or in the current directory is not malicious.

[0018] To judge whether the DLL files in the process directory or the current directory are malicious, we can judge from two aspects: static DLL files and dynamic DLL files. Since static DLL files and dynamic DLL files can fully cover the DLL files in the process directory or the current directory, they can improve the accuracy of judging whether the DLL files in the process directory or the current directory are malicious.

[0019] In some changed implementation modes of the first aspect of the present application, if the export function is an invalid function or a transfer function, the DLL file is determined to be a malicious DLL file, including: if the export function is an invalid function or a transfer function, the DLL file is determined to be a suspicious DLL file; the suspicious DLL file is sent to a threat behavior identification engine, and the threat behavior identification engine is used to identify whether the suspicious DLL file has threatening behavior; receiving the identification result of the threat behavior identification engine; if the identification result indicates that the suspicious DLL file has threatening behavior, the suspicious DLL file is determined to be a malicious DLL file; the method also includes: if the identification result indicates that the suspicious DLL file does not have threatening behavior, the suspicious DLL file is determined to be a normal DLL file.

[0020] Before determining that a DLL file is malicious, the threat behavior of the DLL file is identified again, and normal DLL files are filtered out to avoid mistaking normal DLL files for malicious DLL files for transit functions that appear for normal needs or invalid functions that are mistakenly generated due to file configuration errors, thereby further improving the accuracy of system white-exploitation monitoring.

[0021] A second aspect of the present application provides a monitoring device for white exploitation in a system, the device comprising: a first acquisition module, for responding to the creation of a legitimate process in a target system, to acquire a DLL file called by the process; a second acquisition module, for acquiring an export function of the DLL file; a judgment module, for judging whether the export function is an invalid function or a transit function; if the export function is an invalid function or a transit function, entering a first determination module; if the export function is neither an invalid function nor a transit function, entering a second determination module; the first determination module, for determining that the DLL file is a malicious DLL file, and further determining that the process is white exploited; the second determination module, for determining that the DLL file is a normal DLL file, and further determining that the process is not white exploited.

[0022] The third aspect of the present application provides an electronic device, which includes: a processor, a memory, and a bus; wherein the processor and the memory communicate with each other through the bus; and the processor is used to call program instructions in the memory to execute the method in the first aspect.

[0023] A fourth aspect of the present application provides a computer-readable storage medium, the storage medium comprising: a stored program; wherein, when the program is running, the device where the storage medium is located is controlled to execute the method in the first aspect.

[0024] The device for monitoring waste utilization in a system provided in the second aspect of the present application, the electronic device provided in the third aspect, and the computer-readable storage medium provided in the fourth aspect have the same or similar beneficial effects as the method for monitoring waste utilization in a system provided in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] By reading the detailed description below with reference to the accompanying drawings, the above and other purposes, features and advantages of the exemplary embodiments of the present application will become easy to understand. In the accompanying drawings, several embodiments of the present application are shown in an exemplary and non-limiting manner, and the same or corresponding reference numerals represent the same or corresponding parts, wherein:

[0026] Figure 1 The process diagram of the monitoring method for white utilization in the system in the embodiment of the present application is shown as follows: Figure 1 ;

[0027] Figure 2 The process diagram of the monitoring method for white utilization in the system in the embodiment of the present application is shown as follows: Figure 2 ;

[0028] Figure 3 The structure of the monitoring device used in the system in the embodiment of the present application is shown in FIG. Figure 1 ;

[0029] Figure 4 The structure of the monitoring device used in the system in the embodiment of the present application is shown in FIG. Figure 2 ;

[0030] Figure 5 Schematic diagram of the structure of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0031] The exemplary embodiments of the present application will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present application are shown in the accompanying drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided in order to enable a more thorough understanding of the present application and to fully convey the scope of the present application to those skilled in the art.

[0032] It should be noted that, unless otherwise specified, the technical terms or scientific terms used in this application should have the common meanings understood by technicians in the field to which this application belongs.

[0033] At present, the white utilization monitoring in the system can only be based on the white utilization behaviors that have been discovered. Obviously, it is impossible to monitor the white utilization behaviors that have not been discovered, which reduces the accuracy of the white utilization monitoring of the system.

[0034] In view of this, the embodiments of the present application provide a method for monitoring white exploitation in a system, a monitoring device for white exploitation in a system, an electronic device, and a computer-readable storage medium. In addition to monitoring based on known white exploitation behaviors, monitoring can also be performed based on the export function of the DLL file called by a legitimate process. If the export function is an invalid function or a transit function, it means that the DLL file is suspicious. Combined with the fact that white exploitation is often achieved by loading malicious DLL files through legitimate programs, it can be determined that there is white exploitation in the process. In this way, starting from the attack starting point of white exploitation, more unknown white exploitation behaviors can be discovered, thereby improving the accuracy of system white exploitation monitoring.

[0035] First, the method for monitoring white utilization in the system provided in the embodiment of the present application is described in detail.

[0036] Figure 1 The process diagram of the monitoring method for white utilization in the system in the embodiment of the present application is shown as follows: Figure 1 , see Figure 1 As shown, the method may include:

[0037] S11: In response to the creation of a legitimate process in the target system, the DLL file called by the process is obtained.

[0038] The target system may refer to a system that has a white-exploitation monitoring requirement, such as Windows system, Linux system, Unix system, Android system, etc.

[0039] Applications are generally installed in the target system. When an application runs one of its functions, a process is created in the system. Since the system is attacked during the operation of the application, especially the white exploit is to call malicious DLL files through legitimate applications to attack the system, after the target system creates a process, a white exploit detection is required, that is, in response to the creation of the process in the target system, it is necessary to determine whether the process is a legitimate process, that is, to match the process with the process whitelist. If the match is successful, the process is determined to be legitimate. If the match fails, the process is determined to be illegal. If the process is determined to be illegal, an alarm is directly output. If the process is determined to be legitimate, continue to obtain the DLL file under the process to detect white exploits.

[0040] As for the monitoring of process creation in the system and the acquisition of DLL files in the process, the existing process creation monitoring method and DLL file acquisition method are adopted, which will not be repeated here.

[0041] S12: Get the export function of the DLL file.

[0042] Export functions are external interfaces provided by DLL files to executable programs.

[0043] For obtaining the export function of the DLL file, the existing export function obtaining method is also adopted, which will not be repeated here.

[0044] S13: Determine whether the derived function is an invalid function or a transfer function. If the derived function is an invalid function or a transfer function, execute S14; if the derived function is neither an invalid function nor a transfer function, execute S15.

[0045] In the specific judgment, since the export function of the DLL file directly obtained is a machine code, the characteristics of the invalid function and the transfer function under the machine code can be preset, and then the export function is matched with the pre-collected characteristics. If the match is successful, it means that the export function also has the characteristics of an invalid function or a transfer function, and the export function is determined to be an invalid function or a transfer function. If the match fails, it means that the export function does not have the characteristics of an invalid function and a transfer function, and it is determined that the export function is not an invalid function and a transfer function.

[0046] In the specific judgment, the export function can also be converted into assembly language first, and then the export function in the assembly language is matched with the features of invalid functions and transfer functions in the assembly language that are pre-counted. If the match is successful, the export function is determined to be an invalid function or a transfer function. If the match fails, it is determined that the export function is not an invalid function or a transfer function. Compared with the features of invalid functions and transfer functions in machine code, the collection of features of invalid functions and transfer functions in assembly language is simpler and more convenient, and the collected features are more accurate, thereby improving the accuracy of the judgment.

[0047] S14: Determine that the DLL file is a malicious DLL file, and then determine that the process has been exploited.

[0048] If the export function is an invalid function or a transit function, it means that the DLL file does not provide dynamic links normally, but actually controls the process by providing dynamic links. At this time, controlling the process is nothing more than attacking the system through the process. Therefore, once the export function is determined to be an invalid function or a transit function, the DLL file can be determined to be a malicious DLL file, thereby determining that the process is being exploited. At this time, an exploit warning prompt can be output to the system, and the exploited process and DLL file can be displayed in the exploit warning prompt, so that relevant personnel can promptly and targetedly deal with it to improve the security of the system.

[0049] S15: Determine that the DLL file is a normal DLL file, and then determine that there is no illegal exploitation of the process.

[0050] If the exported function is not an invalid function or a transit function, it means that the DLL file is providing a dynamic link normally, and it can be determined that the DLL file is a normal DLL file, thereby determining that the process does not have a white exploit. At this time, a white exploit detection prompt can be output to the system, and the white exploit detection prompt will display the process and DLL file that do not have a white exploit, so that relevant personnel can perceive the white exploit monitoring in real time.

[0051] As can be seen from the above content, the monitoring method for white utilization in the system provided by the embodiment of the present application, for unknown white utilization, obtains the export function of the DLL file called by the process when the system creates a legal process, and then determines whether there is white utilization in the process by the type of the export function. When the export function is an invalid function or a transfer function, it means that the DLL file is suspicious, and then determines that there is white utilization in the process. In this way, even if it is unknown white utilization, the system can also realize monitoring, thereby improving the accuracy of white utilization monitoring in the system.

[0052] Furthermore, as a Figure 1 As a refinement and extension of the method shown, an embodiment of the present application also provides a method for monitoring white utilization in a system.

[0053] Figure 2 The process diagram of the monitoring method for white utilization in the system in the embodiment of the present application is shown as follows: Figure 2 , see Figure 2 As shown, the method may include:

[0054] S21: In response to the creation of a legitimate process in the target system, the DLL file called by the process is obtained.

[0055] The specific implementation method of step S21 here is the same as that of step S11 in the aforementioned embodiment. Please refer to the relevant description in the aforementioned embodiment, and no further details will be given here.

[0056] S22: Match the process in the white-use database. If the match is successful, execute S23; if the match fails, execute S24.

[0057] The white-exploitation database includes legal processes involved in known white-exploitation. That is, for white-exploitation that has been discovered, the legal processes and malicious DLL files involved in the white-exploitation are determined, and then the determined legal processes and malicious DLL files are stored in the white-exploitation database to monitor the white-exploitation of other processes.

[0058] After a process is created and its DLL file is obtained, it is not necessary to first determine whether the DLL file involves invalid functions or transfer functions, but to match the process in the white-exploitation database to determine whether the process may be white-exploited. Compared with obtaining DLL files, obtaining export functions, and judging invalid functions and transfer functions, by matching the process with the white-exploitation database, it is possible to quickly determine whether the process is suspected of being white-exploited, reduce the number of times DLL files are obtained and judged, and improve the efficiency of system white-exploitation monitoring.

[0059] S23: Determine whether the DLL file called by the process is a known white file. If it is a known white file, execute S24; if it is not a known white file, execute S25.

[0060] In the system, various known white files can also be pre-stored. The so-called white files are files that have been determined to be normal. The known white files here can be all normal files involved in the system, all normal DLL files, DLL files that are misjudged as malicious, or a combination of the above files.

[0061] In the specific judgment, the name of the DLL file can be matched with the names of various known white files to improve the matching efficiency. The summary of the DLL file can also be matched with the summary of various known white files to improve the accuracy of the matching. If the match is successful, the DLL file is determined to be a white file. If the match fails, it is determined that the DLL file is not a white file.

[0062] S24: Determine whether the DLL file in the process directory or the current directory is malicious. If it is malicious, execute S25; if not, execute S26.

[0063] If the process is not a known white-exploited process, it cannot be ruled out that the process does not have white-exploitation. In this case, it is necessary to continue to judge whether the DLL file under the process is malicious.

[0064] On the one hand, all DLL files in the process directory can be obtained, and the export functions of all DLL files can be obtained, so as to determine whether the corresponding DLL file is malicious based on whether the export function is a transit function or an invalid function.

[0065] On the other hand, it is possible to judge from two perspectives: static DLL files and dynamic DLL files. By matching with some known databases, it is possible to judge whether the DLL files in the process directory are malicious.

[0066] Specifically, the above step S24 may include:

[0067] Step A11: Get the static DLL file from the import table and delay import table of the process.

[0068] The import table and delayed import table refer to the list of DLL files that the process will call when it runs. The import table and delayed import table may be modified by a malicious third party to add malicious DLL file information so that the process calls the malicious DLL file when it runs. Therefore, through the import table and delayed import table of the process, malicious DLL files can be discovered from the perspective of static files.

[0069] Step A12: Match the static DLL file in the preset DLL file library. If the match is successful, execute step A13; if the match fails, execute step A14.

[0070] Among them, the preset DLL file library includes DLL files that need to be called when the process runs normally. The corresponding DLL files will be configured during the initial configuration of the business corresponding to the process. In other words, it specifies which DLL files will be called when the process runs. By matching the static DLL files with the preset DLL file library, it is possible to determine whether the DLL files in the import table or delayed import table of the process have been tampered with, and then determine whether the static DLL files of the process obtained at this time are malicious.

[0071] Step A13: Determine that the DLL files in the process directory or the current directory are not malicious.

[0072] If the static DLL file exists in the preset DLL file library, it means that the DLL files to be called by the process at this time are all pre-set DLL files. It can be determined that the DLL files in the directory where the process is located or the current directory are not malicious.

[0073] Step A14: Determine whether the DLL file in the process directory or the current directory is malicious.

[0074] If the static DLL file does not exist in the preset DLL file library, it means that the DLL file to be called by the process is not the preset DLL file. It may be maliciously added by the attacker in the import table or delayed import table of the process, so that the process can call the malicious DLL file added by the attacker when running, thereby performing white exploitation. At this time, it can be determined that the DLL file in the directory where the process is located or the current directory is malicious.

[0075] Specifically, the above step S24 may further include:

[0076] Step A21: Get the dynamic DLL file called when the process is running.

[0077] Sometimes, the attacker does not introduce malicious DLL files through the process's import table or delayed import table, but may introduce malicious DLL files through other unknown means. In order to obtain these malicious DLL files, you can dynamically obtain them when the process is running, that is, obtain the dynamic DLL files called by the process when it is running.

[0078] Step A22: Match the dynamic DLL file in the malicious DLL file library. If the match is successful, execute step A23; if the match fails, execute step A24.

[0079] The malicious DLL file library includes known malicious DLL files. That is to say, for the malicious DLL files involved in the white-exploitation that have been discovered before, these malicious DLL files can be stored in the malicious DLL file library, so that the DLL files called when the process is running can be matched with the malicious DLL files stored in the malicious DLL file library, so as to find the malicious DLL files in the process.

[0080] In the specific matching, the name of the dynamic DLL file can be compared with the names of all malicious DLL files in the malicious DLL file library, and the summary of the dynamic DLL file can be compared with the summary of all malicious DLL files in the malicious DLL file library to achieve accurate and efficient matching. The complete content of the dynamic DLL file can also be compared with the complete content of all malicious DLL files in the malicious DLL file library.

[0081] Step A23: Determine whether the DLL file in the process directory or the current directory is malicious.

[0082] If the dynamic DLL file exists in the malicious DLL file library, it means that the DLL file called by the process at this time is a malicious DLL file. It can be determined that the DLL file in the directory where the process is located or in the current directory is malicious.

[0083] Step A24: Determine that the DLL files in the process directory or the current directory are not malicious.

[0084] If the dynamic DLL file does not exist in the malicious DLL file library, it means that the DLL file called by the process at this time is not a malicious DLL file. It can be determined that the DLL file in the directory where the process is located or the current directory is not malicious.

[0085] It should be noted here that the above steps A11-A14 and steps A21-A24 can be executed simultaneously, or one can be executed selectively according to different white space utilization monitoring requirements, which is not limited here.

[0086] It should also be noted here that after determining that the DLL files in the directory where the process is located or the current directory are malicious, the number of malicious DLL files in the directory can be further determined. If the number of malicious DLL files in the directory is less than the preset number, that is, there are a small number of malicious DLL files in the directory, it can be determined that the malicious DLL files in the directory are correctly determined. If the number of malicious DLL files in the directory is greater than or equal to the preset number, that is, there are many malicious DLL files in the directory. Generally speaking, attackers will not introduce too many malicious DLL files, but only a small number of DLL files to achieve their purpose of white exploitation. At this time, it is necessary to further verify whether the malicious DLL files in these directories are truly malicious.

[0087] S25: Determine that the DLL file called by the process is a malicious DLL file.

[0088] If the DLL file called by the process is determined to be a malicious DLL file through known white-exploitation data, it can be directly determined that the process has white-exploitation. If it is not possible to determine whether the DLL file called by the process is malicious through known white-exploitation data, it is necessary to judge through the export function of the DLL file.

[0089] S26: Get the export function of the DLL file.

[0090] When it is determined that there is no known white exploit in the process, there may still be undiscovered white exploits in the process. In this case, further white exploit detection is required through the export function of the DLL file.

[0091] It should be noted here that in addition to this situation, if there are other unknown DLL files in the process directory or the current working directory, it is also necessary to obtain the export function of the unknown DLL file for further white-exploitation detection.

[0092] In order to improve detection efficiency, in addition to directly judging the type of the exported function, if there are multiple exported functions, the addresses of multiple exported functions can be used for judgment first.

[0093] S27: Get addresses of multiple export functions.

[0094] When obtaining it specifically, you can first obtain the export table of the DLL file. The export table here can refer to the list of locations where the contents of the DLL file jump to next. The export table of the DLL file can be obtained using the existing export table acquisition method, which will not be repeated here. After obtaining the export table of the DLL file, you can parse the export table according to the PE file format. The address that can be obtained after parsing is the address of the exported function.

[0095] Of course, the address of the export function may also be obtained in other ways, for example, calling the export function to run the preset information, and then obtaining the final storage location of the preset information, and determining the location as the address of the export function.

[0096] S28: Determine whether the addresses of at least two of the multiple export functions are the same. If yes, execute S213; if no, execute S29.

[0097] If there are multiple export functions with the same address, it means that the DLL file corresponding to the export function with the same address is suspicious. Because different DLL files have different functions, the corresponding export functions also need to point to different addresses. If they point to the same address, it is obvious that the attacker is maliciously guiding them. Therefore, to determine whether there is an exception in the export function, if there are multiple export functions, you can determine whether the addresses of multiple export functions are the same.

[0098] For multiple export functions, as long as there are two export functions with the same address, it can be directly determined that there is a problem with the DLL file. The more export functions with the same address, the greater the probability that the DLL file is malicious. In practical applications, the number of export functions with the same address can be used to determine whether the DLL file is malicious based on the actual needs of system white-exploitation detection. For example: when the system does not allow any white-exploitation to be missed and allows false positives, as long as the number of export functions with the same address is two, the DLL file can be determined to be malicious. For another example: when the system does not allow false positives, the number of export functions with the same address needs to reach more than half of the export functions to determine that the DLL file is malicious.

[0099] When the addresses of multiple export functions are the same, it means that there are problems with multiple export functions, and then there is a problem with the DLL file. The export function addresses point to the same address, which is obviously not a normal operation of the system, but a guidance of the attacker. Therefore, the DLL file is determined to be a malicious DLL file, and then the process is determined to be a white exploit.

[0100] When the addresses of multiple exported functions are different, it is necessary to determine whether the exported function is an invalid function or a transit function.

[0101] S29: Use the disassembly engine to reverse process the exported function to obtain the target function.

[0102] Since the obtained export function is represented by machine code, directly parsing the export function is not conducive to judging the export function type (invalid function or transit function), and will reduce the efficiency and accuracy of export function judgment. Therefore, the export function can be converted into an easy-to-understand assembly language before judgment.

[0103] In the specific conversion, a disassembly engine may be used to convert the export function from machine code to assembly code, that is, to obtain the target function.

[0104] S210: Determine whether the target function is an invalid function or a transfer function. If the target function is an invalid function or a transfer function, execute S211; if the target function is neither an invalid function nor a transfer function, execute S212.

[0105] In specific judgments, in order to improve the accuracy of judgments, the objective function can be directly called and judgments can be made based on the execution results of the objective function.

[0106] Specifically, the above step S210 may include:

[0107] Step B1: Substitute the preset assembly instructions into the target function, and control the execution of the target function after the instructions are substituted.

[0108] The preset assembly instruction here can be any assembly instruction. For example, an assembly instruction related to the process content. In this way, it can be as close to the actual operation of the process as possible, improve the accuracy of the target function judgment, and ultimately improve the accuracy of the white utilization judgment.

[0109] Step B2: Determine whether the target function after the instruction is substituted has a return or a jump within the preset time length of the execution. If a return occurs, execute step B3; if a jump occurs, execute step B4; if no return or jump occurs, execute step B5.

[0110] After the preset assembly instruction enters the target function, if the target function has malicious invalidity or jump, it will generally be manifested at the beginning of the function running. Therefore, a judgment is made within a short period of time after the target function runs, that is, whether to return immediately after entering the function, or to perform a jmp jump, so as to determine whether the target function is an invalid function or a transit function. While ensuring that the judgment accuracy is not significantly reduced, the judgment efficiency can be improved.

[0111] Step B3: Determine that the target function is an invalid function.

[0112] Step B4: Determine the objective function as a transfer function.

[0113] Step B5: Determine that the target function is not an invalid function and a transfer function.

[0114] S211: Determine whether the export function is an invalid function or a transit function.

[0115] S212: Determine whether the export function is an invalid function or a transfer function.

[0116] The target function is an export function in assembly language. Whether the target function is an invalid function or a transit function means whether the export function is an invalid function or a transit function.

[0117] After confirming that the exported function is neither an invalid function nor a transit function, it can be determined that the DLL file is normal, thereby confirming that there is no white-exploitation in the process.

[0118] After determining that the exported function is an invalid function or a transit function, the DLL file can be further confirmed to ensure the accuracy of process white-exploitation monitoring.

[0119] S213: Determine that the DLL file is a suspicious DLL file, send the suspicious DLL file to the threat behavior recognition engine, and receive the recognition result of the threat behavior recognition engine. If the recognition result indicates that the suspicious DLL file has a threatening behavior, execute S214; if the recognition result indicates that the suspicious DLL file does not have a threatening behavior, execute S215.

[0120] Among them, the threat behavior identification engine is used to identify whether suspicious DLL files have threatening behaviors.

[0121] The export function of the DLL file is an invalid function or a transfer function. It may be that the normal DLL file has a transfer function configured in the DLL file based on the jump requirement, or the normal DLL file has an error in the function configuration, making the function invalid. Through invalid functions and transfer functions, suspicious DLL files are first filtered out from the DLL files of the process, and then the normal DLL files in the suspicious DLL files are filtered out based on the threat behavior identification engine. The remaining ones can be considered malicious DLL files.

[0122] The threat behavior here can refer to various threat behaviors, including but not limited to white-exploitation behaviors. If the DLL file is determined to be suspicious through invalid functions or transfer functions, and the suspicious DLL file is identified to have other threat behaviors, it can be determined that the threat behavior is white-exploitation behavior, but the behavior has not been found to be white-exploitation behavior before.

[0123] The threat behavior identification engine may include currently known threat behavior features, and determine whether the DLL file corresponds to a threat behavior through feature matching. A threat behavior analysis model may also be included, so as to determine whether the DLL file corresponds to a threat behavior based on the threat behavior probability output by the threat behavior analysis model.

[0124] S214: Determine that the suspicious DLL file is a malicious DLL file, and then determine that the process is being exploited.

[0125] The export function of the DLL file is an invalid function or a transfer function, and the corresponding DLL file also has threatening behavior. At this time, it can be determined that the DLL file is a malicious DLL file, and then it can be determined that the process has been exploited.

[0126] S215: Determine that the suspicious DLL file is a normal DLL file, and then determine that there is no free use of the process.

[0127] The export function of the DLL file is not an invalid function or a transfer function, or although the export function of the DLL file is an invalid function or a transfer function, there is no threatening behavior corresponding to the DLL file. At this time, it can be determined that the DLL file is a normal DLL file, and then it can be determined that the process does not have any white exploitation.

[0128] Finally, if new white-exploitation behaviors are discovered during this white-exploitation monitoring, the processes and DLL files corresponding to the discovered new white-exploitation behaviors can be stored in the white-exploitation database to enrich the data in the white-exploitation database and improve the monitoring efficiency and accuracy of known white-exploitations.

[0129] So far, the method for monitoring white utilization in the system provided in the embodiment of the present application has been fully described.

[0130] Based on the same inventive concept, as an implementation of the above method, an embodiment of the present application also provides a monitoring device for white utilization in a system.

[0131] Figure 3 The structure of the monitoring device used in the system in the embodiment of the present application is shown in FIG. Figure 1 , see Figure 3 As shown, the device may include: a first acquisition module 31 , a second acquisition module 32 , a judgment module 33 , a first determination module 34 and a second determination module 35 .

[0132] The first acquisition module 31 is used for acquiring the DLL file called by the process in response to the creation of a legitimate process in the target system.

[0133] The second acquisition module 32 is used to acquire the export function of the DLL file.

[0134] The judging module 33 is used to judge whether the derived function is an invalid function or a transfer function. If the derived function is an invalid function or a transfer function, the first determining module 34 is entered. If the derived function is neither an invalid function nor a transfer function, the second determining module 35 is entered.

[0135] The first determination module 34 is used to determine whether the DLL file is a malicious DLL file, and then determine whether the process has been exploited.

[0136] The second determination module 35 is used to determine that the DLL file is a normal DLL file, and further determine that there is no free exploitation of the process.

[0137] Furthermore, as a Figure 3 As a refinement and expansion of the device shown, an embodiment of the present application also provides a monitoring device for white utilization in a system.

[0138] Figure 4 The structure of the monitoring device used in the system in the embodiment of the present application is shown in FIG. Figure 2 , see Figure 4 As shown, the device may include:

[0139] The first acquisition module 41 is used for acquiring the DLL file called by the process in response to the creation of a legitimate process in the target system.

[0140] The process judgment module 42 is used to match the process in the white-exploitation database, which includes legal processes involved in known white-exploitation. If the match is successful, the process enters the file judgment module 43. If the match fails, the process enters the directory judgment module 44.

[0141] The file determination module 43 is used to determine whether the DLL file called by the process is a known white file. If it is a known white file, the process enters the directory determination module 44. If it is not a known white file, the process enters the malicious determination module 45.

[0142] The directory judgment module 44 is used to judge whether the DLL file in the directory where the process is located or the current directory has malicious intent. If it does, the malicious intent determination module 45 is entered; if it does not, the second acquisition module 46 is entered.

[0143] The directory judgment module 44 is specifically used to obtain static DLL files from the import table and delayed import table of the process; match the static DLL files in a preset DLL file library, which includes DLL files that need to be called when the process runs normally; if the match is successful, it is determined that the DLL files in the directory where the process is located or the current directory are not malicious; if the match fails, it is determined that the DLL files in the directory where the process is located or the current directory are malicious; and or, obtain dynamic DLL files called when the process is running; match the dynamic DLL files in a malicious DLL file library, which includes known malicious DLL files; if the match is successful, it is determined that the DLL files in the directory where the process is located or the current directory are malicious; if the match fails, it is determined that the DLL files in the directory where the process is located or the current directory are not malicious.

[0144] The malicious determination module 45 is used to determine whether the DLL file called by the process is a malicious DLL file.

[0145] The second acquisition module 46 is used to acquire the export function of the DLL file.

[0146] In the case where there are multiple export functions, the address determination module 47 is used to obtain the addresses of the multiple export functions and determine whether the addresses of at least two of the multiple export functions are the same. If so, the verification module 49 is entered. If not, the function determination module 48 is entered.

[0147] The function determination module 48 is used to determine whether the derived function is an invalid function or a transfer function. If the derived function is an invalid function or a transfer function, the verification module 49 is entered. If the derived function is neither an invalid function nor a transfer function, the second determination module 411 is entered.

[0148] The function judgment module 48 is specifically used to use a disassembly engine to reversely process the export function to obtain a target function; judge whether the target function is an invalid function or a transit function; if the target function is an invalid function or a transit function, determine that the export function is an invalid function or a transit function; if the target function is not an invalid function or a transit function, determine that the export function is not an invalid function or a transit function.

[0149] The function judgment module 48 is specifically used to substitute preset assembly instructions into the target function, and control the execution of the target function after the instructions are substituted; judge whether the target function after the instructions are substituted has a return and a jump within the preset time length at the beginning of execution; if a return occurs, the target function is determined to be an invalid function; if a jump occurs, the target function is determined to be a transit function; if no return and jump occur, it is determined that the target function is not an invalid function and a transit function.

[0150] The verification module 49 is used to determine whether the DLL file is a suspicious DLL file; send the suspicious DLL file to the threat behavior identification engine, and the threat behavior identification engine is used to identify whether the suspicious DLL file has threatening behavior; receive the identification result of the threat behavior identification engine; if the identification result indicates that the suspicious DLL file has threatening behavior, enter the first determination module 410; if the identification result indicates that the suspicious DLL file does not have threatening behavior, enter the second determination module 411.

[0151] The first determination module 410 is used to determine whether the suspicious DLL file is a malicious DLL file, and then determine whether the process has been exploited.

[0152] The second determination module 411 is used to determine whether the suspicious DLL file is a normal DLL file, and further determine that there is no free exploitation of the process.

[0153] It should be noted here that the description of the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0154] Based on the same inventive concept, an embodiment of the present application also provides an electronic device.

[0155] Figure 5 This is a schematic diagram of the structure of the electronic device in the embodiment of the present application, see Figure 5 As shown, the electronic device may include: a processor 51, a memory 52, and a bus 53; wherein the processor 51 and the memory 52 communicate with each other via the bus 53; the processor 51 is used to call program instructions in the memory 52 to execute the methods in one or more of the above embodiments.

[0156] It should be noted that the description of the above electronic device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the electronic device embodiment of this application, please refer to the description of the method embodiment of this application for understanding.

[0157] Based on the same inventive concept, an embodiment of the present application further provides a computer-readable storage medium, which may include: a stored program; wherein, when the program is running, the device where the storage medium is located is controlled to execute the method in one or more of the above embodiments.

[0158] It should be noted here that the description of the above storage medium embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the storage medium embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0159] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A method for monitoring white utilization in a system, characterized in that: The method comprises: In response to the creation of a legitimate process in the target system, obtaining an export function of a dynamic link library DLL file called by the process; Determine whether the derived function is an invalid function or a transit function; If the export function is an invalid function or a transfer function, the DLL file is determined to be a malicious DLL file, and further, it is determined that the process is being exploited.

2. The method according to claim 1, characterized in that The determining whether the derived function is an invalid function or a transit function includes: Using a disassembly engine to reverse process the export function to obtain a target function; Determine whether the target function is an invalid function or a transit function; If the objective function is an invalid function or a transit function, determining that the derived function is an invalid function or a transit function; If the target function is not an invalid function or a transit function, it is determined that the derived function is not an invalid function or a transit function.

3. The method according to claim 2, characterized in that The determining whether the target function is an invalid function or a transfer function includes: Substituting a preset assembly instruction into the target function, and controlling the execution of the target function after the instruction is substituted; Determine whether the target function after the instruction is substituted has a return or jump within the preset execution time; If a return occurs, the target function is determined to be an invalid function; If a jump occurs, the target function is determined to be a transfer function; If no return or jump occurs, it is determined that the target function is not an invalid function or a transfer function.

4. The method according to any one of claims 1 to 3, characterized in that The number of the derived functions is multiple, and before determining whether the derived function is an invalid function or a transfer function, the method further includes: Get the addresses of multiple exported functions; Determine whether addresses of at least two export functions among multiple export functions are the same; If so, it is determined that the DLL file is a malicious DLL file, and further it is determined that the process is being exploited; If not, the step of determining whether the derived function is an invalid function or a transit function is executed.

5. The method according to any one of claims 1 to 3, characterized in that Before obtaining the export function of the dynamic link library DLL file called by the process, the method further includes: matching the process in a white-exploitation database, the white-exploitation database including legitimate processes involved in known white-exploitation; If the match fails, determine whether the DLL file in the directory where the process is located or the current directory is malicious; If the match is successful, determine whether the DLL file called by the process is a known white file; if it is not a known white file, determine whether the DLL file called by the process is a malicious DLL file; if it is a known white file, determine whether the DLL file in the directory where the process is located or the current directory is malicious; If there is malicious intent, determining that the DLL file called by the process is a malicious DLL file; If there is no malicious intent, the step of obtaining the export function of the dynamic link library DLL file called by the process is performed.

6. The method according to claim 5, characterized in that The determining whether the DLL file in the directory where the process is located or the current directory is malicious includes: Obtaining a static DLL file from the import table and delayed import table of the process; matching the static DLL file in a preset DLL file library, wherein the preset DLL file library includes DLL files that need to be called when the process runs normally; if the match is successful, determining that the DLL file in the directory where the process is located or the current directory does not contain malicious intent; if the match fails, determining that the DLL file in the directory where the process is located or the current directory does contain malicious intent; and or, Obtain a dynamic DLL file called when the process is running; match the dynamic DLL file in a malicious DLL file library, which includes known malicious DLL files; if the match is successful, determine that the DLL file in the directory where the process is located or the current directory is malicious; if the match fails, determine that the DLL file in the directory where the process is located or the current directory is not malicious.

7. The method according to any one of claims 1 to 3, characterized in that If the export function is an invalid function or a transfer function, determining that the DLL file is a malicious DLL file includes: If the export function is an invalid function or a transfer function, determining that the DLL file is a suspicious DLL file; Sending the suspicious DLL file to a threat behavior identification engine, wherein the threat behavior identification engine is used to identify whether the suspicious DLL file has threatening behavior; Receiving the identification result of the threat behavior identification engine; If the identification result indicates that the suspicious DLL file has threatening behavior, determining that the suspicious DLL file is a malicious DLL file; The method further comprises: If the identification result indicates that the suspicious DLL file does not have any threatening behavior, the suspicious DLL file is determined to be a normal DLL file.

8. A monitoring device for white utilization in a system, characterized in that: The device comprises: A first acquisition module, for, in response to the creation of a legitimate process in the target system, acquiring a dynamic link library DLL file called by the process; A second acquisition module is used to acquire the export function of the DLL file; A judging module, used to judge whether the derived function is an invalid function or a transfer function; if the derived function is an invalid function or a transfer function, enter the first determining module; if the derived function is neither an invalid function nor a transfer function, enter the second determining module; A first determination module, used to determine that the DLL file is a malicious DLL file, and then determine that the process has a white exploit; The second determination module is used to determine that the DLL file is a normal DLL file, and further determine that there is no free use of the process.

9. An electronic device, characterized in that: The electronic device comprises: a processor, a memory, and a bus; wherein the processor and the memory communicate with each other via the bus; and the processor is used to call program instructions in the memory to execute the method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The storage medium comprises: a stored program; wherein, when the program is running, the device where the storage medium is located is controlled to execute the method as claimed in any one of claims 1 to 7.

Images