CN116975857A

CN116975857A - Lesu software detection method, system, equipment and storage medium

Info

Publication number: CN116975857A
Application number: CN202210435635.9A
Authority: CN
Inventors: 张钊
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-04-24
Filing date: 2022-04-24
Publication date: 2023-10-31

Abstract

The application discloses a method, a system, equipment and a storage medium for detecting lux software, wherein the method comprises the following steps: acquiring behavior information of a first process, wherein the behavior information comprises one or more of a process of a preset category, which is selected to be ended by the first process, a service of a preset category, which is selected to be deleted by the first process, and a planning task of the preset category, which is selected to be deleted by the first process; and determining whether the first process is a process of the luxury software according to the behavior information. The scheme of the application can effectively identify the luxury software before the luxury software executes encryption operation, so that the luxury software can be treated in time, and the influence of the luxury software is avoided.

Description

Lesu software detection method, system, equipment and storage medium

Technical Field

The present application relates to the field of software security technologies, and in particular, to a method, a system, an apparatus, and a storage medium for detecting lux software.

Background

Luxury software (ransomware) is a popular type of malware. An attacker encrypts key data, files and the like under a computer system through the luxury software, so that user data assets or computing resources cannot be used normally, and the user is paid for redemption. Individuals or businesses are exposed to critical data assets, data leakage, business interruption, economic loss, and other serious impacts after suffering from a luxury software attack.

Traditional antivirus software is analyzed based on static characteristics of a lux software file, and the unknown lux software cannot be detected depending on a characteristic library of the known lux software. The existing method for detecting the luxury software based on the bait file can detect the attack of unknown luxury software, but the method for detecting the encryption behavior of the luxury software has poor timeliness, and other files in a computer system can be encrypted by the luxury software when the encryption behavior of the luxury software on the bait file is identified, so that the method cannot provide timely and comprehensive protection.

Disclosure of Invention

The application provides a method, a system, equipment and a storage medium for detecting luxury software, which can effectively identify the luxury software before the luxury software executes encryption operation, so that the luxury software can be treated in time, and the influence of the luxury software is avoided.

In a first aspect, the present application provides a method for detecting a lux software, the method comprising: acquiring behavior information of a first process, wherein the behavior information comprises one or more of a process of a preset category, which is selected to be ended by the first process, a service of a preset category, which is selected to be deleted by the first process, and a planning task of the preset category, which is selected to be deleted by the first process; and determining whether the first process is a process of the luxury software according to the behavior information.

It should be noted that, the lux software usually has some preparation actions before performing the encryption operation, and the scheme of the application is based on the preparation actions of the lux software before performing the encryption to realize the lux software detection. Specifically, by acquiring the behavior information of the first process (i.e., which operations are specifically executed by the first process, and the dynamic behaviors thereof), particularly, selecting a process, service and/or planning task under a preset category that is ended or deleted by the first process, whether the first process accords with the preparation behavior of the luxury software before the encryption operation is judged, so that whether the first process is the process of the luxury software can be judged accurately.

It should be appreciated that the behavior of the luxury software traversing files is highly random, and it may traverse disks, directories and files in sequence, or randomly. Thus, in conventional bait file-based detection methods, when the modification of the bait file by the luxury software is monitored, the luxury software may have already made cryptographic damage to other files. Obviously, the method for detecting the encryption behavior of the luxury software is poor in real-time performance, the luxury software cannot be identified and treated before the luxury software executes the encryption operation, and the service data cannot be comprehensively protected. The additional arrangement of bait files on a computer system may also have some impact on normal business.

In the scheme of the application, by detecting the preparation behavior of the luxury software before the encryption operation is performed, particularly the operation behavior of the luxury software on a specific (by setting a preset category) process, service, planning task and the like, not only the unknown luxury software can be identified, but also the luxury software can be effectively identified before the luxury software performs the encryption operation. Compared with the method for detecting the encryption behavior of the luxury software, the scheme of the application can discover the potential threat of the luxury software earlier, treat the luxury software in time, prevent the luxury software from encrypting files, protect the data asset security of common users, enterprises and the like, and provide comprehensive and effective protection.

Based on the first aspect, in one possible implementation, the preset categories include one or more of a database category, a file editing category, a network communication category, a backup and restore category, a security protection category, a restart and exit category.

It should be appreciated that the lux software performs an end or delete operation on some processes, services and/or scheduled tasks before performing the encryption operation, and by analyzing a large number of lux software samples, a regular summary of the processes, services and/or scheduled tasks that the lux software will typically choose to delete or end can be made.

Therefore, in the scheme, the processes, services and planning tasks of which the luxury software usually deletes or ends are divided according to a certain standard, and some categories (namely preset categories) are preset, which can specifically include database categories, file editing categories, network communication categories, backup and recovery categories, security protection categories, restarting and exiting categories and the like. Then, by detecting the operation behaviors of the first process on the processes, services and planning tasks under the preset category and analyzing the behaviors of the first process, whether the first process accords with the pre-encryption behavior of the luxury software or not is judged, so that the efficient detection of the luxury software can be realized.

Based on the first aspect, in one possible implementation, the first process is determined to be a process of the luxo software if one or more of the following conditions are met: the number of the processes of the preset category, which are selected to be ended by the first process, is larger than or equal to a first threshold value; or, the number of the processes of the preset category selected to be deleted by the first process is larger than or equal to a second threshold value; or, the number of the scheduled tasks of the preset category selected to be deleted by the first process is greater than or equal to a third threshold; or, the sum of the number of processes of the preset category to which the first process selects to end, the number of services of the preset category to which the first process selects to delete, and the number of scheduled tasks of the preset category to which the first process selects to delete is greater than or equal to the fourth threshold.

It can be seen that there are various possible ways to determine whether the first process is a process of the le-su software in the present solution, and specifically, the first process may be determined as a process of the le-su software by setting various preset conditions as long as the first process meets at least one of the preset conditions. The first threshold, the second threshold, the third threshold and the fourth threshold are all configurable parameters, and can be properly adjusted according to actual conditions, and are not particularly limited.

Based on the first aspect, in a possible implementation manner, in a case that the first process invokes an application programming interface (application programming interface, API)/system command in a monitoring list, behavior information of the first process is obtained, wherein the monitoring list includes one or more of an API and/or a system command for querying a process running on an operating system, querying a running service, querying a set plan task, ending a process, deleting a service or deleting a plan task.

It should be appreciated that the Leuch software typically invokes certain APIs and/or system commands to perform its pre-encryption preparation, including APIs and/or system commands for querying processes running on the operating system, querying running services, querying setup scheduled tasks, ending processes, deleting services, deleting scheduled tasks.

Therefore, in the scheme, the related information of the API and/or the system command is written into the monitoring list, so that the calling conditions of the API and the system command in the monitoring list are monitored. When the first process has calling behaviors on any API and/or system command in the monitoring list, the first process is used as a suspicious process (namely, the first process is possibly a process of the luxury software), and then whether the first process is actually the process of the luxury software is accurately judged by acquiring the behavior information of the first process.

Based on the first aspect, in a possible implementation manner, in a case that the first process calls the first API, an execution result of the modified first API is sent to the first process, where the first API includes one or more APIs for querying a process running on the operating system, a running service, or a set planning task.

It should be appreciated that if the first process makes a call to an API for querying a process running on the operating system, a running service, or a set scheduling task, the first process may be a process of the luxury software. In the scheme, in order to reduce the influence of the luxury software on normal processes, services and planning tasks, the execution result of the API called by the first process can be changed, and the changed execution result of the API is sent to the first process, namely fake information is returned to the first process.

For example, assuming that the first process is a process of the luxury software, when it is monitored that the first process calls an API for querying the process list information, an execution result of the API may be changed, and falsified process list information (not correct process list information) is returned to the first process. Since the first process takes a piece of forged process list information, the influence of the first process on the process currently running by the operating system can be reduced.

Based on the first aspect, in a possible implementation manner, the execution result of the modified first API includes part of information in the execution result of the first API, or the execution result of the modified first API includes part or all of information except the execution result of the first API in a first blacklist, where the first blacklist is an information set of processes, services and planning tasks of a preset category.

In this scheme, only partial modification may be performed on the execution result of the first API, that is, some true/correct information may still be retained in the information returned to the first process. The execution result of the first API may be completely changed, that is, the information returned to the first process does not include the information of the actual execution result of the first API, and the information returned to the first process may be generated based on the first blacklist. The first blacklist may be preconfigured by the user, information of various processes, services and planning tasks belonging to a preset category is configured in the first blacklist, and information except for a real execution result of the first API in the first blacklist may be returned to the first process, that is, the first process obtains the modified execution result of the first API.

Based on the first aspect, in a possible implementation manner, the behavior information of the first process may further include one or more of an operation of deleting the curl by the first process and an operation of emptying the recovery station by the first process.

It should be appreciated that operations such as deleting a shadow, flushing a recovery station, etc. typically occur before the encryption operation, and these actions may also be used to determine whether the first process is a process of the halyard software.

Based on the first aspect, in a possible implementation manner, after determining that the first process is a process of the luxury software, performing a killing operation on the luxury software corresponding to the first process, where the killing operation includes one or more of ending the process of the luxury software corresponding to the first process, isolating the corresponding luxury software, and deleting the corresponding luxury software.

That is, after the first process is determined to be a process of the lux software, a corresponding killing operation may be performed thereon.

Based on the first aspect, in a possible implementation manner, after determining that the first process is a process of the luxury software, prompting the user that the first process is a process of the luxury software, and presenting behavior information of the first process.

That is, after the first process is determined to be a process of the luxing software, a prompt may be presented to the user informing the user of the relevant information.

In a second aspect, the present application provides a lux software detection system, the system comprising: the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring behavior information of a first process, wherein the behavior information comprises one or more of a process of a preset category, which is selected by the first process, to be ended, a service of a preset category, which is selected by the first process to be deleted, and a planning task of the preset category, which is selected by the first process to be deleted; and the determining module is used for determining whether the first process is a process of the luxury software according to the behavior information.

The above-mentioned lux software detection system may further comprise other functional modules, and the lux software detection system is specifically configured to implement the method of any of the embodiments of the first aspect.

In a third aspect, an embodiment of the present application provides a lux software detection device, including a processor and a memory; the processor and the memory may be interconnected by a bus or may be integrated. The processor is configured to read the program code stored in the memory to cause the apparatus to perform the method of any of the embodiments of the first aspect described above.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium; the computer readable storage medium is for storing implementation code of any one of the methods of the first aspect described above.

In a fifth aspect, embodiments of the present application provide a computer program (product) comprising program instructions for performing the method of any of the embodiments of the first aspect described above, when the computer program product is executed.

Drawings

FIG. 1 is a schematic workflow diagram of a Leso software provided in an embodiment of the present application;

FIG. 2 is a schematic diagram of an exemplary embodiment of a Leso software detection system;

FIG. 3 is a schematic diagram of a host deployment scenario provided in an embodiment of the present application;

fig. 4 is a schematic diagram of an end-cloud co-deployment scenario provided in an embodiment of the present application;

fig. 5 is a schematic flow chart of a method for detecting a lux software according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a workflow of a Leso software detection system according to an embodiment of the present application;

FIG. 7 is a schematic workflow diagram of yet another Leso software detection system provided in an embodiment of the present application;

FIG. 8 is a flow chart of another method for detecting Lesu software according to an embodiment of the present application;

FIG. 9 is a schematic diagram of yet another Leso software detection system provided in an embodiment of the present application;

Fig. 10 is a schematic structural diagram of a lux software detection device according to an embodiment of the present application.

Detailed Description

In order to facilitate understanding of the technical solution in the embodiments of the present application, the following description will be given for simplicity of the workflow of the lux software. Referring to fig. 1, by analyzing a large number of lux software samples, the workflow of the lux software can be summarized as follows:

s101, the luxury software starts to run, and the operations of file release, installation, registry modification and the like are executed.

In this step, the lux software behaves similarly to other types of malware, and is not described here too.

S102, preparing before executing encryption operation.

Specifically, the lux software may perform some preparation before the lux software formally performs the encryption operation in order to prevent processes or services running on the Operating System (OS) from affecting the encryption operation to be performed subsequently and to prevent the victim from being able to restore data by itself after the encryption operation of the lux software is completed. The preparation before encryption generally includes deleting a volume (delete shadow), clearing the recovery station, ending a specific process, deleting a specific service, deleting a specific scheduled task, and the like, which are described below:

(1) Deleting roll shadow (copy roll shadow)

To prevent victims from backing up/restoring data through the volume, the halyard software typically deletes the volume before performing encryption operations. The le cable software may implement the operation of deleting the roll shadow by using wmic, vssadmin, powershell, and some specific examples are given in table 1:

table 1 examples of ways in which the Lesu software deletes the shadow volume

(2) Empty recovery station

Similar to the purpose of deleting the shadow, the halyard software empties the recycle bin before performing the encryption operation in order to prevent the victim from recovering data through the recycle bin. The specific manner in which the purge recovery station is implemented by the halyard software is not described here too.

(3) Ending a particular process, deleting a particular service

It should be appreciated that certain processes, services, may affect the cryptographic operation of the luxury software. For example, when the lux software attempts to encrypt a structured query language (structured query language, SQL) file, a database service such as MySQL, oracle, etc., running on the operating system may be operating the SQL file, possibly resulting in a failure of the lux software to encrypt the SQL file. For another example, when the luxury software attempts to encrypt a document, an application program process for editing the document is performing a modification operation on the document, which may cause the luxury software to fail to encrypt the document.

In order to prevent some specific processes and services from operating on files to be encrypted of the luxury software, so as to influence the encryption operation of the luxury software, and simultaneously prevent some specific services (such as database services) from executing backup operation, the luxury software needs to finish some specific processes and delete some specific services before executing the encryption operation.

By analyzing a large number of luxury software samples, processes and services which are usually selected to be deleted or ended by the luxury software can be divided into database classes, file editing classes, network communication classes, backup and recovery classes, safety protection classes and the like. Where a database class refers to a service or process associated with a database, such as may include various common database-associated services. A file editing class refers to a process or service of an application/tool for file editing, and a file may include a document, a form, an image, and the like, and is not particularly limited, such as a process or service of various common office software/tools. The network communication class refers to a process or service related to functions of surfing the internet, communication, etc., such as a process or related service that may include various browsers, mail applications/tools, etc. Backup and restore classes refer to such processes or services that are associated with file backup or data restore, including processes or services that provide file backup, data restore, and the like. The security class refers to processes or services related to the security function of an operating system, including processes or services of application software that provides security, such as processes of some common antivirus software and services of some security products. It should be noted that the classification is only an example, and other classification methods may be adopted.

For example, table 2 shows the names of some processes that the lux software will typically select to end, and table 3 shows the names of some services that the lux software will typically select to end.

TABLE 2 Process List_1

Table 3 list of services

(4) Deleting specific scheduled tasks

It can be appreciated that if the system suddenly performs operations such as restarting, shutdown, logout, backup and recovery during the encryption operation of the lux software, the encryption operation of the lux software is likely to fail. Similar to the purpose of the lux software deleting a specific process and a specific service, the lux software usually deletes a scheduled task (timing task) for performing operations such as restarting, logging off, shutting down, backup and recovery of the system in order to prevent the encryption process from being affected by the operations. Through analysis of a large number of luxury software samples, the normally selected deleted planning tasks of the luxury software can be divided into a backup and recovery class and a restarting and exiting class, wherein the backup and recovery class planning tasks refer to the planning tasks for realizing file backup or data recovery, and the restarting and exiting class refers to the planning tasks for realizing operations such as restarting, logging off or shutting down of the system. Of course, other division modes can be adopted, and the application is not particularly limited.

For example, table 4 shows the names of some of the scheduled tasks that the lux software would typically choose to delete:

TABLE 4 planning task list

In one possible way, the lux software itself has a preset blacklist, and it can decide which processes, services, and planning tasks running on the current system to end or delete according to the preset blacklist.

For example, the lux software may determine which processes the operating system is currently running by calling an application programming interface (application programming interface, API), e.g., by calling an API such as the ntquery system information to obtain a process list, including information such as the names of the various processes running on the system, process identification numbers (process identification, PID), etc. Then, the lux software traverses the process list, matches the process list with a preset blacklist according to the process name, hash (hash) value and the like, and determines the matched process (namely the process belonging to the preset blacklist) as the process to be ended. The lux software then ends the process by calling a corresponding API or a system command, for example, by calling an API such as ntterminateeprocess to end the process (kill process), or calling a system command such as taskkill to end the process, which is not particularly limited.

It should be appreciated that the lux software may not query which processes are running on the system, but rather may perform the end process operation on each process on the preset blacklist directly by calling an API or system command. At this time, if a certain process on the preset blacklist does run on the current system, the lux software can successfully end the process; if a certain process on the preset blacklist does not run on the current system, the ending process operation of the lux software does not have an actual effect.

For another example, the lux software may determine which services the system is currently running by calling an API, e.g., by calling an API such as enumservicestatus exa to obtain a service list, including information such as names of various services running on the system. And then the luxury software traverses the service list and matches with a blacklist preset by the luxury software, and the matched service (namely the service belonging to the preset blacklist) is determined as the service to be deleted. The trade software then deletes the service by calling the corresponding API or system command, such as by calling an API (delete service) such as ControlService, deleteService, or by calling an sc command (e.g., sc delete servicename), without limitation.

For another example, the lux software can determine which planning tasks are set on the current system by calling an API, for example, calling an API such as a CoCreateInstance to query a planning task list, so as to obtain information of various planning tasks set in the system. And then, the luxury software traverses the planning task list, matches with a preset blacklist, and determines the matched planning task (namely belonging to the preset blacklist) as the planning task to be deleted. The halyard software deletes the scheduled task by calling the corresponding API, for example, by calling the DeleteTask API to delete the scheduled task (delete task), which is not particularly limited.

It should be noted that, in all the above three examples, it is assumed that names of processes, services and planning tasks that the lux software needs to end or delete are set in the same preset blacklist. In fact, the luxury software may set the processes, services and planning tasks that need to be ended or deleted in different black lists, which are not particularly limited. For example, the luxury software may preset a process blacklist (including the names of the processes that it needs to finish), a service blacklist (including the names of the services that it needs to finish), and a scheduled task blacklist (including the names of the scheduled tasks that it needs to finish). Similar to the previous examples, the lux software may determine which processes, services and scheduled tasks to perform ending or deleting operations based on the several pre-set blacklists, respectively, as described above, but is not described here.

It will be appreciated that the lux software will not typically end up with some specific system processes in order not to affect the running of the lux software itself. For example, table 5 shows the names of some system processes that the lux software will not normally end:

TABLE 5 Process List_2

Thus, in yet another possible manner, the lux software itself has a preset whitelist, from which it can decide which processes to keep (i.e., not end) running on the system, or which processes to end from the preset whitelist. That is, the lux software may use a preset blacklist to determine which processes to end in addition to which processes currently running in the system.

For example, the luxury software obtains a process list by calling an API, traverses the process list, matches each process in the process list with a preset white list thereof, determines that a process which is not matched (i.e. is not in the preset white list) is a process to be ended, and determines that the matched process is a process which needs to be reserved. The lux software may then end the process to be ended by calling an API or system command, as described herein without limitation.

In yet another possible manner, the lux software may preset a blacklist and a whitelist at the same time, determine according to the preset blacklist and whitelist, perform a kill operation on a process belonging to the preset blacklist, and not perform a kill operation on a process belonging to the preset whitelist, which is not described herein too much.

S103, traversing the disk, the directory and the file, and executing encryption operation.

That is, the lux software begins traversing the disk, directory, and file after the preparation before encryption is completed. The traversal behavior of the luxury software has strong randomness, and the directory and the file can be traversed in sequence, and the file to be encrypted can be determined by random traversal. The luxury software can determine which files are files to be encrypted according to certain judging criteria, and then perform encryption operation on the files to be encrypted.

A lux software detection system 200 according to an embodiment of the present application is described below.

Referring to fig. 2, fig. 2 is a schematic diagram of an lux software detection system 200 according to an embodiment of the application, where the lux software detection system 200 is used for detecting lux software.

It should be appreciated that there are many possible ways of dividing the functional modules/units within the lux software detection system 200, and the present application is not particularly limited. Fig. 2 is an exemplary partitioning of the lux software detection system 200, which includes a configuration module 201, a monitoring module 202, a behavior analysis module 203, a treatment module 204, and a presentation module 205, as described below.

1. Configuration module 201: for entering configuration information of the lux software inspection system 200, including the monitored list, the first blacklist, and/or the first whitelist.

Wherein the monitoring list is an information set of APIs and/or system commands that the lux software detection system 200 needs to monitor. The security operator can input information of some APIs and/or system processes that the lux software will typically call into the monitoring list through the configuration module 201, and then the monitoring module 202 in the lux software detection system 200 will monitor the calling situation of the APIs and/or system commands in the monitoring list based on the monitoring list.

It should be appreciated that by analyzing a large number of samples of the Leucasian software, it is possible to determine which APIs, system commands are commonly used/may be invoked by Leucasian software, including APIs and system commands for querying or operating (ending or deleting) information about processes, services, and planning tasks. For example, as can be seen from the foregoing description, the API for querying the process list, the service list, the timed task list, etc. is likely to be called by the luxury software, and the API for ending the process, deleting the service, deleting the task, and the system command are also likely to be called by the luxury software, so that the security operator may input the information such as the name of the API and/or the system command in the monitoring list, so that the monitoring module 202 may monitor the call of the API and/or the system command.

The first blacklist is an information set of some processes, services and planning tasks which the luxury software may select to end or delete. The behavior analysis module 203 in the lux software detection system 200 may perform behavior analysis on suspicious processes based on the first blacklist (to be described later).

As can be seen from the foregoing description, in order to prevent the encryption operation from being affected, the luxury software typically performs an end or delete operation on the processes and services of the database class, the file editing class, the network communication class, the backup and restore class, the security protection class, and possibly performs a delete operation on the scheduled tasks of the backup and restore class, and the restart and exit class. Thus, the security operator may input information such as the names of the processes, services, and planning tasks of the above-mentioned category in the first blacklist, so that the behavior analysis module 203 can analyze the behavior of the lux software based on the first blacklist. For example, the security operator may enter as many names of processes, services and/or scheduled tasks belonging to the above category as possible in the first blacklist to cover processes, services and scheduled tasks that the luxury software may choose to end or delete as much as possible.

In some possible embodiments, the processes, services, and planning tasks may be categorized in advance (e.g., the categorization methods described above, preset categories). Corresponding identifiers can be preset for different types of processes, services and planning tasks, and the types of the processes, services and planning tasks of which the luxury software is selected to be ended or deleted can be determined through the corresponding identifiers.

It should be appreciated that while different luxury software determines which processes, services, and scheduled tasks to perform an ending or deleting operation based on its own default blacklist and/or default whitelist, respectively, their default blacklists/whitelists do not differ too much, and essentially all involve one or more of the foregoing default categories. The probability that various processes, services and planning tasks are finished or deleted by the lux software can be counted by analyzing a large number of lux software samples. The security operator may write the names of the processes, services, and scheduled tasks that have a relatively high probability of being ended or deleted to the first blacklist, while processes, services, and scheduled tasks that have a relatively low probability of being ended or deleted may not be written to the blacklist.

In the above examples, the process name, the service name, and the scheduled task name are all set in the same first blacklist. In practice, the method may also be separately set, where the name of the process that the luxury software will normally select to end is put in the first process list, the name of the service that the luxury software will normally select to delete is put in the first service list, and the name of the scheduled task that the luxury software will normally select to delete is put in the first scheduled task list. The former is described below by way of example unless otherwise specified.

The first white list is an information set of some system processes that the lux software will not normally end, and can be configured by security operation staff. The behavior analysis module 203 may also perform behavior analysis (described later) on the suspicious process according to the first white list.

2. The monitoring module 202: monitoring calling conditions of APIs and/or system commands in a monitoring list based on the monitoring list in the configuration module 201; when a process is monitored to call an API or system command in the monitored list, the process is marked as a suspicious process and relevant information is reported to the behavior analysis module 203.

Specifically, the monitoring module 202 may monitor calls to these APIs in the monitoring list via Hook (Hook) technology. It should be appreciated that the Hook technique may intercept the process's API calls for viewing and statistics, and may even change the execution results of the API, as described herein without limitation. After a hook is performed on an API, once a call action to the API appears in the system, the monitoring module 202 will receive a notification from the system, so that relevant information (information such as a process and parameters for calling the API) of the call of the API can be timely obtained. When it is monitored that a process has a calling action on any one or more APIs in the monitored list, the monitoring module 202 may mark the process as a suspicious process (which may be a luxury software process), and then send information, parameters, etc. of the suspicious process and the APIs called by the suspicious process to the action analysis module 203, where the action analysis module 203 will perform further action analysis on the suspicious process to determine whether the suspicious process is a luxury software process.

Similarly, when the monitoring module 202 finds that a certain process has a calling action on any one or more system commands in the monitoring list, the process is marked as a suspicious process, and then the suspicious process and the information of the called system commands are sent to the action analysis module 203, and the action analysis module 203 performs further action analysis on the suspicious process to determine whether the suspicious process is a luxury software process.

In a possible embodiment, the monitoring module 202 may monitor the APIs and the system commands in the monitoring list in real time, or periodically monitor the APIs and the system commands in the monitoring list at preset time intervals, which is not particularly limited.

3. Behavior analysis module 203: for further behavioral analysis of the suspicious process determined by the monitoring module 202 to determine if the suspicious process is a lux software process.

Specifically, after receiving the information of the suspicious process sent by the monitoring module 202, the behavior analysis module 203 further analyzes the behavior of the suspicious process based on the first blacklist and/or the first whitelist in the configuration module 201, and determines whether the behavior of the suspicious process accords with the pre-encryption behavior of the luxury software, so as to determine whether the suspicious process is a luxury software process.

In one possible embodiment, in a case where the number of processes, services and/or scheduled tasks belonging to the first blacklist is greater than or equal to the first threshold among the processes, services and/or scheduled tasks that the suspicious process selects to end or delete, the behavior analysis module 203 determines the suspicious process as a luxo software process. The first threshold is a configurable parameter, which may be set by a security operator in the configuration module 201, and may be adjusted according to an actual situation, and is not specifically limited.

In yet another possible embodiment, the behavior analysis module 203 may further determine, based on the first white list in the configuration module 201, that specific conditions are as follows: if the suspicious process selects to end or delete the process, the service, the scheduled task are all in the first blacklist, the process, the service, the scheduled task which is not to end or delete are all in the first blacklist, and the number of the suspicious process selects to end or delete the process, the service, and the scheduled task exceeds the second threshold, the behavior analysis module 203 determines the suspicious process as a luxury software process. The second threshold is a configurable parameter, and may also be set by a security operator in the configuration module 201, and may be adjusted according to an actual situation, which is not particularly limited.

The above two embodiments are not limited to being implemented using techniques such as statistics, artificial intelligence (artificial intelligence, AI) models, and the like, and the type of AI model is not particularly limited. For example, the types, the numbers and the like of processes, services and tasks of which the luxury software samples are selected to be ended or deleted are taken as characteristics of the luxury software, normal software samples (such as aspects of selecting some common benign application programs including offices, entertainment, learning, system tools and the like) are taken as characteristics of the normal software, and the types, the numbers and the like of the processes, the services and the tasks of which the luxury software samples are selected to be ended or deleted are trained to train an AI model based on the characteristics to identify and classify the luxury software. After training the AI model, selecting the types and the numbers of the processes, the services and the tasks which are finished or deleted by the suspicious process, inputting the types and the numbers as the characteristics of the suspicious process into the AI model, and outputting a judging result of whether the AI model is the luxury software or not. It should be noted that, besides the above features, the AI model may be trained by combining some features of other dimensions (such as static features of the lux software file, dynamic behavior features of deleting the curl, emptying the recovery station, modifying the registry, etc.), which is not particularly limited.

From the foregoing, it will be appreciated that the luxury software is likely to call an API for querying information such as a process list, a service list, or a scheduled task list, and thus, the monitoring list configured by the security operator may include information of the API, so that the monitoring module 202 can monitor the call of the API. When the monitoring module 202 monitors the calling behavior of a certain process to any API, the process is set as a suspicious process and the behavior analysis module 203 is notified of relevant information. That is, the behavior analysis module 203 can determine which API(s) the suspicious process specifically calls to query the process, service, or planning task based on the information sent by the monitoring module 202.

In one possible embodiment, when the behavior analysis module 203 knows that a suspicious process calls an API for querying a process list, a service list or a scheduled task list, the suspicious process can obtain the real execution result of the API without modifying the execution result of the API.

For example, when knowing that the suspicious process calls the API of the ntquery system information to query the process list, the behavior analysis module 203 does not modify the execution result of the API, so the system will return the real process list, that is, the information of the various processes currently running by the operating system, to the suspicious process. If the suspicious process is indeed a luxury software process, it will compare the queried information with its preset blacklist/preset whitelist to determine which processes currently running on the system are to be ended, thus affecting the processes running on the system.

In yet another possible embodiment, when the behavior analysis module 203 knows that a suspicious process calls an API for querying a process list, a service list or a scheduled task list, the execution result of the API is changed (for example, by using an API Hook technology), and the changed execution result of the API is sent to the suspicious process, that is, forgery information is returned, which is not the real execution result of the API.

For example, when knowing that the suspicious process calls the API "enumservicestatus ex" to query the service list, the behavior analysis module 203 changes the execution result of the API, returns falsified information, i.e., erroneous service list information, to the suspicious process instead of real service list information (information of the service running on the system). If the suspicious process is indeed a luxury software process, it may misuse that the received fake information is the real execution result of the API, and then the fake information is compared with its preset blacklist/preset whitelist to select which services running on the system are to be ended. Since the lux software obtains the forgery information, which performs the service deletion operation based on the forgery information, the influence of the lux software on the service running on the system can be reduced or avoided.

Regarding the counterfeit information, there are a plurality of possible generation manners, and the present application is not particularly limited.

In one possible scheme, the behavior analysis module 203 may compare the real execution result of the API called by the suspicious process with the first blacklist, and return the information except for the real execution result in the first blacklist to the suspicious process, so as to avoid the influence of the lux software on the process, service or planning task running on the system.

For example, knowing that the suspicious process called the API, enumservicestatus ex, to query the service list, the behavior analysis module 203 may first obtain the actual execution result of the API, that is, the actual service list, including the information of the service currently running in the system. And then comparing the real execution result with a first blacklist, and returning the information of (partial or all) services except the services in the real execution result in the first blacklist to the suspicious process in the form of a service list, wherein the suspicious process can be mistakenly forged information to be the real execution result of the API. That is, the behavior analysis module 203 replaces the real execution result of the API with the forgery information, where the forgery information does not include information of the service currently operated by the system, but includes only information of the service that is on the first blacklist and that is not operated by the system, i.e., the suspicious process obtains the forgery information and does not include any real information.

It will be appreciated that if the suspicious process is indeed a luxury software process, it does not have any practical effect (the luxury software chooses to delete a service in the fake information but the service is not running, the delete operation is actually invalid) when it calls an API or a system command to perform a delete operation on a service in the fake information based on the fake information, avoiding the luxury software from affecting the service running on the system. From the foregoing, it can be seen that, because the embodiments of the present application may return spurious information to the luxury software process, the luxury software process selects a process, service, and scheduled task that ends or deletes, which refers to those processes, services, or tasks that the suspicious process invokes a corresponding API or system command to end/delete, but does not necessarily succeed in performing the end/delete operation.

In another possible scheme, the behavior analysis module 203 may compare the real execution result of the API called by the suspicious process with the first blacklist, and return part of the information in the real execution result and the information except for the execution result in the first blacklist to the suspicious process, so that on one hand, the influence of the luxo software on the currently running process or service of the system can be reduced, and on the other hand, the influence of the luxo software on the normal process (non-malicious software)/service in the system can be reduced.

For example, when the behavior analysis module 203 knows that the suspicious process invokes the API of the ntquery system information to query the process list information, the real execution result of the API may be obtained first, that is, the information of various processes running on the system is obtained, then the real execution result is compared with the first blacklist, and the information of the partial processes except for the process in the real execution result in the first blacklist and the partial information in the real execution result are returned to the suspicious process together in the form of the process list. That is, the true execution result of the API is replaced with the falsified information, which contains the information of the partial process currently running in the system (i.e., the partial real information) and also contains the information of the partial process that is in the first blacklist and not currently running in the system (i.e., the partial false information).

It will be appreciated that if the suspicious process is indeed a luxury software process, it misuses the true execution result of the API that it calls for the fake information received, and then will perform an end process operation on the process in the fake information based on the fake information call API or system command. Because the lux software only obtains partial real information, the process of the lux software to select and finish may be the current real operation of the system or may not be the current operation of the system, so that the influence of the lux software on the process operated on the system can be reduced. If the suspicious process is not malware, but is some normal application process currently running on the system, the application process needs to call the API query process list just as well for some purposes, and the application process is marked as suspicious. At this time, since the falsified information returned to the application process still contains part of the real information, the influence on the application process can be reduced.

Note that, the above-mentioned fake information may further include information of a part or all of the processes in the first whitelist, that is, fake information returned to the suspicious process, which may include not only information of a part or all of the processes in the first blacklist, that is, information of a process that the lux software will normally select to end, but also information of some system processes that the lux software will not normally select to end. The falsification information comprises process information to be ended by the luxury software and process information which is not ended by the luxury software, so that the falsification information is more true, and suspicious processes are prevented from doubting the authenticity of the falsification information.

Thus, in yet another possible solution, the behavior analysis module may compare the real execution result of the API called by the suspicious process with the first blacklist and the first whitelist, and compare the information in the first blacklist except for the real execution result with all the information in the first whitelist (or the information in the first whitelist except for the real execution result, or the information belonging to the first whitelist in the real execution result, etc.), where the two together form the forgery information, and replace the real execution result of the API to return to the suspicious process.

4. Treatment module 204: for performing a killing operation on the lux software determined by the behavior analysis module 203.

The searching and killing operation may include ending the process of the lux software, isolating or deleting the lux software, and the like, and is not particularly limited.

5. The presentation module 205: the method is used for prompting the user of the luxury software event and presenting the luxury software event. The relevant information of the lux software determined by the behavior analysis module 203 may be displayed, including behavior information of the lux software (information of operation behaviors of the lux software on a process, a service, a planning task, etc.). The information is used as key evidence obtaining information for security operation staff to analyze and respond safely to the luxury software, the scope and influence of the luxury software event are known, and the security team can also use the information to investigate and prevent attacks.

In a possible embodiment, the presenting module 205 may also present information about the killing operation performed by the handling module 204 on the le sos software, such as what type of killing method, time of killing, result of killing, and so on, which are not specifically limited.

It should be noted that, the above-mentioned lux software detection system 200 is flexible to be deployed, and may have a plurality of different deployment manners.

1. The host deployment, that is, each functional module in the above-mentioned lux software detection system 200 is deployed on the same host.

For example, the above-described lux software detection system 200 may be integrated into products of the types of antivirus software, endpoint detection and response (endpoint detection and response, EDR) (intended to monitor and identify endpoint security threats and prevent attacks by implementing automatic security measures on endpoint devices), host intrusion prevention systems (host intrusion prevent system, HIPS), etc., the host having the detection capabilities of the lux software detection system 200 by installing/deploying any of the above-described products.

As another example, as shown in fig. 3, the lux software detection system 200 may be deployed on a host operating system in the form of a stand-alone agent (agent). The independent agent is understood herein to be an independently running software entity that is scheduled to run by the operating system for implementing the functionality of the lux software detection system 200 on the host.

2. The end cloud is deployed cooperatively, that is, a part of functional modules of the lux software detection system 200 are deployed on the cloud (cloud server side), and another part of functional modules are deployed on the host side.

For example, fig. 4 is a schematic diagram of a collaboration scenario of an end cloud system provided in an embodiment of the present application, where a part of modules in a lux software detection system 200 are deployed on a cloud server side, and another part of modules are deployed on a host side. As shown in fig. 4, the cloud server side deploys the configuration module 201, the monitoring module 202, the behavior analysis module 203, and the presentation module 205 in the above-mentioned lux software detection system 200, and the host side deploys the file acquisition module 206 and the disposition module 204. The file collection module 206 is configured to collect a file on the host, and then upload the file to the cloud server for analysis and detection to determine whether the file is a file searching software.

In a possible embodiment, the file collection module 206 may screen the files on the host side, and upload the screened suspicious files to the cloud server for detection. For example, the file collection module 206 may take a file without a valid signature and without a white list program on the host side as a suspicious file, and then upload the suspicious file to the cloud server for analysis and detection, and the manner of screening the suspicious file is not particularly limited. The cloud server executes the suspicious file in the built simulation environment (namely the simulated running environment and the virtual environment), analyzes the behavior of the suspicious file to determine whether the suspicious file is the luxury software or not, and then returns a detection result to the host side.

It should be understood that the cloud server side may build a simulation environment through technologies such as a Virtual Machine (VM), a container, a sandbox (or referred to as a sandbox), and the like, which is not particularly limited, that is, an analysis environment of the lux software is built, and a real running environment is simulated, so that not only can the security in the lux software detection process be ensured, but also the analysis purpose can be achieved.

In some possible embodiments, when the cloud server detects a certain file uploaded by the host side, the host side may perform processing such as isolation on the file, so as to ensure that the file is not run until a detection result returned by the cloud server is obtained, so as to ensure the security of the host side.

It should be noted that the deployment of each module in fig. 4 is only an example, and not limited to this, and each module may have other distribution manners, and the lux software detection system 200 may also have other module division manners. For example, the presenting module 205 may also return the detection result to the host side after the cloud server performs the detection, the presenting module 205 of the host side presents the detection result to the user, and the processing module 204 of the host side performs the searching and killing operations of isolating, deleting the file and the like on the detected halyard software.

It should be further noted that, the above description of the deployment manner of the lux software detection system 200 is taken as an example of a host, and it may also be replaced by other types of endpoint (endpoint) devices, such as a tablet computer, a notebook computer, a local server of an enterprise, a smart phone, and other devices or nodes, which are not particularly limited in the present application.

Based on the foregoing, a detailed description of the specific process of detecting the lux software by the lux software detection system 200 is provided below.

Referring to fig. 5, fig. 5 is a flow chart of a lux software detection method provided in an embodiment of the application, which may include the following steps:

S501, marking the first process as a suspicious process under the condition that the first process calls an API or a system command in a monitoring list.

The first process is one or more processes running on the current operating system, and may be any one or more processes, which are not particularly limited. For the monitoring list, please refer to the previous description, and the description is not repeated here.

It should be noted that, in the case of the host deployment scenario in fig. 3, the current operating system designates the operating system of the host (the specific type of the operating system is not limited), and the first process is a process running on the operating system. If the scenario is the end-cloud co-deployment scenario in fig. 4, the current operating system refers to an operating system corresponding to the simulation environment on the cloud server side, and the first process is a process running on the operating system.

For example, as shown in fig. 6, assuming that a general user or a security operator inputs information of some APIs and/or system commands that the lux software will typically call into a monitoring list through the configuration module 201 in the lux software detection system 200, including APIs and/or system commands for querying a process, service or planning task running on the current operating system, the monitoring module 202 may then monitor call situations of these APIs and/or system commands in the monitoring list based on the monitoring list (i.e. an action labeled (1) in fig. 6).

Assume that the processes currently running on the operating system include process 1, process 2, and process 3, where process 1 and process 2 are normal application (non-malware) processes or system processes and process 3 is a process of some luxury software. Whenever a process (whether a luxo software process or other normal process) has a calling action on any API or system command in the monitoring list, the monitoring module 202 marks it as a suspicious process and sends its information to the action analysis module 203 for further action analysis on the suspicious process.

For example, when process 3 in FIG. 3 triggers a call to any API in the monitoring list (i.e., the action labeled (2) in FIG. 6), the monitoring module 202 marks it as a suspicious process and sends its information to the behavior analysis module 203 (i.e., the action labeled (3) in FIG. 6).

For another example, when a process invokes a system command, it generates a corresponding child process, i.e., the child process created by the process is used to execute the invoked system command, i.e., the parent process of its child process. If a child process of process 3 executes exactly any system command in the monitoring list, the monitoring module 202 marks the parent process of the child process (i.e., process 3) as a suspicious process and sends the suspicious process information to the behavior analysis module 203.

S502, selecting an ending or deleting process, service and/or planning task according to the suspicious process, and judging whether the suspicious process is a process of the luxury software.

In a possible embodiment, in the case that the number of processes, services and/or scheduled tasks belonging to the first blacklist is greater than or equal to the first threshold value, the suspicious process is determined to be a process of the halyard software, among all processes, deleted services and/or scheduled tasks, of which the suspicious process selects to end. The first threshold is a configurable parameter (which may be configured in the configuration module 201), and may be adjusted according to the actual situation. For the first blacklist, please refer to the previous description, and the description is not repeated here.

For example, as shown in fig. 6, it is assumed that the operator inputs information such as a name of a process, a service, or a process that the lux software will normally select to end, in the first blacklist through the configuration module 201 in the lux software detection system 200, and sets the first threshold. When the behavior analysis module 203 receives the information of a suspicious process (such as process 3) sent from the monitoring module 202, the behavior analysis module performs behavior analysis on the suspicious process based on the first blacklist (i.e. the action labeled (4) in fig. 6): assuming that the suspicious process selects to end certain processes, delete certain services and/or plan tasks by calling an API or a system command, the behavior analysis module 203 finds through analysis that, among the processes, deleted services and/or plan tasks that the suspicious process selects to end, the number of processes, services or plan tasks belonging to the first blacklist is greater than or equal to a first threshold, and then determines the suspicious process as a process of the luxury software. The behavior analysis module 203 sends information of the lux software, including the name of the lux software, behavior information (information of selecting an ending process, deleting a service, and/or planning a task), etc., to the disposal module 204 (i.e., an action labeled (5) in fig. 6), so that the disposal module 204 performs a search and kill operation on the lux software. The behavior analysis module 203 may further send information of the lux software to the presentation module 205 (i.e. the action labeled (5) in fig. 6), that is, report the lux software event, and the presentation module 205 may present the lux software event to the user, for example, show information of the operation behavior of the lux software on the process, the service, the planning task, and so on.

It should be noted that, the configuration module 201 may further set a first white list; the behavior analysis module 203 may perform behavior analysis on the suspicious process based on the first blacklist, or may perform behavior analysis on the suspicious process based on the first whitelist. For the first whitelist, please refer to the foregoing description, and the description is omitted here.

In a possible embodiment, the suspicious process is determined to be a process of the luxury software in case the number of processes belonging to the first blacklist among all processes of which the suspicious process selection ends is greater than or equal to the second threshold, the number of services belonging to the first blacklist among all services of which the suspicious process selection deletes is greater than or equal to the third threshold, and/or the number of planned tasks belonging to the first blacklist among all planned tasks of which the suspicious process selection deletes is greater than or equal to the fourth threshold. The second threshold, the third threshold, and the fourth threshold are configurable parameters, and may be set in the configuration module 201 by a security operation and maintenance personnel, and may be adjusted according to actual situations, which is not particularly limited.

In a possible embodiment, if the behavior analysis module 203 finds that the suspicious process calls an API for querying a process, a service or a planned task running on the current operating system, the execution result of the API may be changed, i.e. the fake information is generated according to the first blacklist and/or the first whitelist to replace the real execution result of the API, and the fake information is returned to the suspicious process. For counterfeit information, see the previous relevant description, which is not presented here too.

For example, as shown in FIG. 7, if process 3 triggers a call to an API in the monitoring list for querying a process, service, or planning task running on the system (i.e., the action labeled (2) in FIG. 7), then the monitoring module 202 marks process 3 as a suspicious process and sends the suspicious process information to the behavior analysis module 203 (i.e., the action labeled (3) in FIG. 7). Assuming that the suspicious process specifically calls an API for a process running on the query system, the behavior analysis module 203 may change an execution result of the API, construct a piece of falsification information based on the first blacklist (and may also be based on the first whitelist), replace a real execution result of the API, and return the falsification information to the suspicious process. For the generation of the counterfeit information, please refer to the foregoing description, which is not repeated here.

S503, executing searching and killing operation on the detected lux software.

The searching and killing operation of the le cable software includes one or more of ending the process of the le cable software (i.e. stopping the operation of the le cable software), isolating or deleting the related files of the le cable software, and the like, which is not particularly limited. Related files of the luxury software include data, documents and program files of the luxury software.

For example, as shown in fig. 6, through analysis of the behavior of the suspicious process of the process 3, the behavior analysis module 203 determines it as a process of the lux software, and then the behavior analysis module 203 sends information of the lux software to the disposal module 204. Then, the processing module 204 performs a kill operation on the halyard software: ending the lux software process, and isolating or deleting the file from the lux software.

In a possible embodiment, the processing module 204 may send information about the killing operation (i.e., the action labeled (6) in fig. 6) to the presentation module 205, including the type, time, result, etc. of the killing operation performed by the processing module 204 on the lux software, without specific limitation.

In summary, the frequently called APIs and/or system commands of the luxury software, i.e., those used to query processes, service or planning tasks, end processes, delete services or planning tasks, may be monitored for their calls. For example, they may be placed in a monitoring list, which in turn monitors call to these APIs and/or system commands in the monitoring list. When a process calls any API or system command to be monitored, the process is likely to be a process of the luxury software, the process can be marked as a suspicious process, and further behavior analysis is performed on the suspicious process to finally determine whether the suspicious process is the process of the luxury software.

In embodiments of the present application, behavioral analysis of suspicious processes may be based on processes, services, and/or scheduled tasks whose selection is ended or deleted. Specifically, the process, service and/or scheduled task that the luxury software will generally select to end or delete may be classified (or corresponding identifiers may be allocated) in advance, and then, according to the operation behavior of the suspicious process on the process, service and/or scheduled task under the preset classification, whether the suspicious process accords with the pre-encryption behavior of the luxury software is judged, so as to determine whether the suspicious process is the process of the luxury software. For example, a first blacklist may be set, information of various processes, services and planning tasks belonging to a preset category may be configured in the first blacklist, or information of processes, services and/or planning tasks with higher probability of operating the luxury software in the preset category may be written into the first blacklist, and then behavior analysis may be performed on the suspicious process based on the first blacklist to determine whether the suspicious process is a process of the luxury software, where a specific judgment condition is not limited. After the lux software is determined, corresponding searching and killing operation can be performed on the lux software to ensure the system safety and avoid encryption damage of the lux software, and the lux software event can be presented to an operation and maintenance person to display the behavior information of the lux software for safety analysis.

Referring to fig. 8, fig. 8 is a flowchart of another method for detecting a lux software according to an embodiment of the application, which includes the following steps:

s801, behavior information of a first process is obtained, wherein the behavior information comprises one or more of a process of a preset category, which is selected by the first process to be ended, a service of a preset category, which is selected by the first process to be deleted, and a scheduled task of the preset category, which is selected by the first process to be deleted.

For the first procedure, please refer to the related description in step S501, which is not repeated here.

It should be understood that the behavior information of the first process refers to the operation behavior corresponding to the first process, which operations are specifically performed. The preset categories are preset categories of processes, services and planning tasks which are usually selected to be ended or deleted by the luxury software, can be divided into different categories, and are not particularly limited.

In a possible embodiment, the preset categories may include one or more of a database class, a file editing class, a network communication class, a backup and restore class, a security protection class, and a restart and exit class. For the above-mentioned various preset categories, please refer to the related content in step S102, and the description is not repeated here.

That is, the processes, services, and planning tasks that the luxury software may delete or end may be divided according to a certain standard, and some categories (i.e., preset categories) may be preset, which may specifically include a database class, a file editing class, a network communication class, a backup and restore class, a security protection class, and a restart and exit class. Then, by detecting the operation behaviors of the first process on the processes, the services and the planning tasks under the preset category and analyzing the first process according to the operation behaviors, whether the first process accords with the pre-encryption behavior of the luxury software or not is judged, and therefore effective detection of the luxury software can be achieved.

In a possible embodiment, the behavior information of the first process is obtained in case the first process invokes an API/system command in a monitoring list, wherein the monitoring list comprises one or more of an API and/or a system command for querying a process running on an operating system, querying a running service, querying a set scheduled task, ending a process, deleting a service or deleting a scheduled task.

In this embodiment, a series of APIs and/or system commands that the luxury software will typically call are written into the monitoring list, so that the calling conditions of these APIs and system commands in the monitoring list are monitored. When the first process has calling action on any API and/or system command in the monitoring list, the first process is used as a suspicious process (the first process is possibly a process of the luxury software), and then whether the first process is actually the process of the luxury software is judged by acquiring the action information of the first process. For details of the monitoring list, please refer to the foregoing description, and details thereof are omitted herein.

It should be understood that operations such as deleting a shadow and emptying a recovery station may also occur in the le-su software before the encryption operation, and these actions may also be used to determine whether the first process is a process of the le-su software, and the specific determination manner is not limited. For example, in a case where the number of processes of the preset category, to which the first process selection ends, exceeds a fifth threshold value and the first process performs the delete shadow operation, the first process is determined as a process of the halyard software. For another example, in a case that the number of processes of the preset category, which the first process selection ends, exceeds the sixth threshold value and the first process performs the purge recovery station operation, the first process is determined as a process of the halyard software. For another example, when the number of processes, services and scheduled tasks of the preset category for which the first process selection ends exceeds a seventh threshold, and the first process performs an operation of deleting a shadow and/or clearing a recovery station, the first process is determined as a process of the halyard software.

Thus, in a possible embodiment, the behavior information of the first process may further include one or more of an operation of the first process to delete the curl, and an operation of the first process to empty the recovery station.

S802, determining whether the first process is a process of the luxury software according to the behavior information.

In a possible embodiment, the first process is determined to be a lux software process if one or more of the following conditions are met:

the number of the processes of the preset category, which are selected to be ended by the first process, is larger than or equal to a first threshold value;

or, the number of the processes of the preset category selected to be deleted by the first process is larger than or equal to a second threshold value;

or, the number of the scheduled tasks of the preset category selected to be deleted by the first process is greater than or equal to a third threshold;

or, the sum of the number of processes of the preset category to which the first process selects to end, the number of services of the preset category to which the first process selects to delete, and the number of scheduled tasks of the preset category to which the first process selects to delete is greater than or equal to the fourth threshold.

That is, there are a number of possible ways to determine whether the first process is a process of the lux software. The first threshold, the second threshold, the third threshold, and the fourth threshold are all configurable parameters, and may be appropriately adjusted according to actual situations, and are not particularly limited.

In a possible embodiment, in a case that the first process calls the first API, an execution result of the modified first API is sent to the first process, where the first API includes one or more APIs for querying a process running on the operating system, a running service, or a set scheduled task.

That is, if the first process makes a call to an API for querying a process running on the operating system, a running service, or a set scheduling task, the first process may be a process of the luxury software. To reduce the impact of the luxury software on processes, services, and planning tasks, the execution results of the APIs called by the first process may be altered, i.e., spurious information may be returned thereto. For example, assuming that the first process is a process of the luxury software, when the first process calls an API for querying a process list, an execution result of the API is changed, and a forged process list (not a correct process list) is returned to the first process.

In a possible embodiment, the execution result of the modified first API includes part of information in the execution result of the first API, or the execution result of the modified first API includes part or all of information except the execution result of the first API in a first blacklist, where the first blacklist is an information set of processes, services and planning tasks of a preset category.

That is, only partial changes may be made to the execution result of the first API, i.e., some of the real information is still retained in the information returned to the first process. The execution result of the first API may be completely changed, that is, the information returned to the first process does not include the information of the actual execution result of the first API, and the information returned to the first process may be generated based on the first blacklist. For example, the first blacklist may be preconfigured by the user, information of various processes, services and scheduled tasks belonging to a preset category is configured in the first blacklist, and information except for a real execution result of the first API in the first blacklist may be returned to the first process, that is, the first process obtains the modified execution result of the first API.

It should be noted that, the execution result of the modified first API is sent to the first process, that is, the spurious information is returned to the first process. For specific ways of generating the counterfeit information, please refer to the foregoing description, and details are not repeated here.

In a possible embodiment, after determining that the first process is a process of the luxury software, performing a killing operation on the luxury software corresponding to the first process, where the killing operation includes one or more of ending the process of the luxury software corresponding to the first process, isolating the corresponding luxury software, and deleting the corresponding luxury software.

For details of the searching and killing operation performed on the detected lux software, please refer to the related description of the treatment module 204, which is not repeated herein.

In a possible embodiment, after determining that the first process is a process of the luxury software, the user is prompted that the first process is a process of the luxury software, and behavior information of the first process is presented.

For details of this embodiment, please refer to the related description of the presentation module 205, which is not repeated here.

In summary, the scheme of the application realizes the detection of the lux software based on the preparation behavior of the lux software before encryption. Specifically, by acquiring the behavior information of the first process, especially the process, service and/or planning task under the preset category of the first process selection ending or deleting, whether the first process accords with the preparation behavior of the luxury software before the encryption operation is judged, so that whether the first process is the process of the luxury software can be accurately identified. The scheme of the application can not only identify unknown luxury software, but also can effectively identify the luxury software before the luxury software executes encryption operation. Compared with the method for detecting the encryption behavior of the luxury software, the scheme of the application can discover the potential threat of the luxury software earlier, treat the luxury software in time, prevent the luxury software from encrypting files, and protect the safety of data assets of common users, enterprises and the like.

Referring to fig. 9, fig. 9 is a schematic structural diagram of a lux software detection system 900 according to an embodiment of the present application, where the lux software detection system 900 includes an obtaining module 901 and a determining module 902.

The obtaining module 901 is configured to obtain behavior information of a first process, where the behavior information includes one or more of a process of a preset category to which the first process selects to end, a service of a preset category to which the first process selects to delete, and a scheduled task of a preset category to which the first process selects to delete.

A determining module 902 is configured to determine whether the first process is a process of the lux software according to the behavior information.

In a possible embodiment, the preset categories include one or more of a database category, a file editing category, a network communication category, a backup and restore category, a security protection category, and a restart and exit category.

In a possible embodiment, the determining module 902 is specifically configured to determine that the first process is a process of the le sos software if one or more of the following conditions are satisfied:

In a possible embodiment, the obtaining module 901 is specifically configured to: and under the condition that the first process calls an Application Programming Interface (API)/system command in a monitoring list, acquiring behavior information of the first process, wherein the monitoring list comprises one or more of APIs and/or system commands for inquiring a process running on an operating system, inquiring a running service, inquiring a set planning task, ending the process, deleting the service or deleting the planning task.

In a possible embodiment, the lux software detection system 900 further includes a modification module 903, where the modification module 903 is configured to: and in the case that the first process calls the first API, sending an execution result of the changed first API to the first process, wherein the first API comprises one or more APIs for querying a process running on an operating system, a running service or a set planning task.

In a possible embodiment, the modified execution result of the first API includes part of information in the execution result of the first API, or includes part or all of information in a first blacklist except for the execution result of the first API, where the first blacklist is an information set of processes, services and planning tasks in a preset category.

In a possible embodiment, the above behavior information of the first process further includes one or more of an operation of the first process to delete the curl and an operation of the first process to empty the recovery station.

In a possible embodiment, the lux software detection system 900 further includes a killing module 904, where the killing module 904 is configured to: after the determining module 902 determines that the first process is a process of the le software, a killing operation is performed on the le software corresponding to the first process, where the killing operation includes one or more of ending the process of the corresponding le software, isolating the corresponding le software, and deleting the corresponding le software.

It should be noted that the killing module 904 may correspond to the treatment module 204 in the above-mentioned lux software detection system 200, and is used for executing the corresponding function of the treatment module 204, which is not described herein.

In a possible embodiment, the lux software detection system 900 further includes a prompt module 905, where the prompt module 905 is configured to: after the determining module 902 determines that the first process is a process of the luxury software, the user is prompted that the first process is a process of the luxury software, and behavior information of the first process is presented.

It should be noted that the prompt module 905 may correspond to the presentation module 205 in the above-mentioned lux software detection system 200, and is used for executing the corresponding functions of the presentation module 205, which is not described herein.

The above-mentioned lux software detection system 900 may correspond to the lux software detection system 200 in fig. 2, and may adopt the deployment manner of fig. 3 or fig. 4, which is specifically used to implement any embodiment of the lux software detection method of fig. 5 or fig. 8, please refer to the above description, and the detailed description is omitted herein.

It should be noted that, in the present embodiment of fig. 9, the lux software detection system 900 is only illustrated by the above-mentioned division of the functional modules, and in practical applications, the above-mentioned functional distribution may be performed by different functional modules according to needs, that is, the internal structure of the lux software detection system 900 is divided into other different functional modules to perform all or part of the above-mentioned functions.

Fig. 10 is a schematic structural diagram of another lux software detection device 1000 according to an embodiment of the present application.

The lux software testing device 1000 comprises a processor 1001, a memory 1002 and a communication interface 1003, where the lux software testing device 1000 is specifically configured to implement any of the lux software testing methods of fig. 5 or 8. The processor 1001, the memory 1002, and the communication interface 1003 may be connected to each other via an internal bus 1004, or may communicate via other means such as wireless transmission. In the embodiment of the present application, the bus 1004 is exemplified by a bus 1004, and the bus 1004 may be a peripheral component interconnect standard (peripheral component interconnect, PCI) bus, an extended industry standard architecture (extended industry standard architecture, EISA) bus, a unified bus (Ubus or UB), a computer quick link (compute express link, CXL) bus, a cache coherent interconnect protocol (cache coherent interconnect for accelerators, CCIX) bus, or the like. The bus 1004 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in fig. 10, but not only one bus or one type of bus.

The processor 1001 may be constituted by at least one general purpose processor, such as a central processing unit (central processing unit, CPU), or a combination of a CPU and a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (programmable logic device, PLD), or a combination thereof. The PLD may be a complex programmable logic device (complex programmable logic device, CPLD), a field-programmable gate array (field-programmable gate array, FPGA), general-purpose array logic (generic array logic, GAL), or any combination thereof. The processor 1001 executes various types of digitally stored instructions, such as software or firmware programs stored in the memory 1002, which enable the lux software detection device 1000 to provide a variety of services.

The memory 1002 is used for storing program codes and is controlled to be executed by the processor 1001. The memory 1002 may include volatile memory (RAM), such as random access memory (random access memory); the memory 1002 may also include a non-volatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory (flash memory), a hard disk (HDD), or a Solid State Drive (SSD); the memory 1002 may also include combinations of the above. The memory 1002 may store program codes, and may specifically include program codes for executing any embodiment of the lux software detection method of fig. 5 or fig. 8, which will not be described herein.

The communication interface 1003 may be a wired interface (e.g., an ethernet interface) or a wireless interface (e.g., a cellular network interface or using a wireless local area network interface) and may be an internal interface (e.g., a high-speed serial computer expansion bus (peripheral component interconnect express, PCIe) bus interface). A wired interface or a wireless interface is used to communicate with other devices or modules.

The above-mentioned lux software detection device 1000 may correspond to the lux software detection system 200 in fig. 2 or the lux software detection system 900 in fig. 9, and is specifically configured to perform any embodiment of the lux software detection method in fig. 5 or fig. 8.

It should be noted that, the present embodiment may be implemented by a general physical server, for example, an ARM server or an X86 server, or may be implemented by a virtual machine implemented by combining an NFV technology with a general physical server, where the virtual machine refers to a complete computer system that is simulated by software and has a complete hardware system function and operates in a completely isolated environment, and the present application is not limited in particular. It should be understood that the lux software testing device 1000 shown in fig. 10 may also be a server cluster formed by at least one server, and the present application is not limited in particular. The lux software detection device 1000 may also be a host computer, a notebook computer, a desktop computer, a smart phone, etc., and is not particularly limited.

It should be further noted that fig. 10 is merely one possible implementation of the embodiment of the present application, and in a practical application, the lux software detection device 1000 may further include more or fewer components, and the present application is not limited in particular. For details not shown or described in the embodiments of the present application, reference may be made to the related descriptions in the embodiments of the network modification method of fig. 5 or fig. 8, which are not repeated here.

Embodiments of the present application also provide a computer readable storage medium having instructions stored therein that, when executed on a processor, implement the method of any of the embodiments of fig. 5 or 8.

Embodiments of the present application also provide a computer program product for implementing the method of any of the embodiments of fig. 5 or 8 when the computer program product is run on a processor.

Those skilled in the art will appreciate that the processes implementing all or part of the methods of the above embodiments may be implemented by a computer program for instructing relevant hardware, and the program may be stored in a computer readable storage medium, and the program may include the processes of the embodiments of the methods as above when executed. The storage medium may be a magnetic disk, an optical disk, a ROM, a RAM, or the like.

It should be noted that the above-described embodiments are only some embodiments, but not all embodiments, of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

It is also to be understood that the terminology used in the description of the embodiments of the application is for the purpose of describing particular embodiments only, and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a," "an," "the," and "any" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to any or all possible combinations including one or more of the associated listed items.

Claims

1. A method for detecting lux software, the method comprising:

acquiring behavior information of a first process, wherein the behavior information comprises one or more of a process of a preset category, which is selected to be ended by the first process, a service of the preset category, which is selected to be deleted by the first process, and a scheduled task of the preset category, which is selected to be deleted by the first process;

And determining whether the first process is a process of the luxury software according to the behavior information.

2. The method of claim 1, wherein the preset categories include one or more of a database class, a file editing class, a network communication class, a backup and restore class, a security protection class, a restart and exit class.

3. A method according to claim 1 or 2, wherein said determining whether the first process is a process of luxury software based on the behaviour information comprises:

determining that the first process is a process of the luxo software if one or more of the following conditions are met:

or the number of the processes of the preset category which are selected to be deleted by the first process is larger than or equal to a second threshold value;

or the number of the scheduled tasks of the preset category selected to be deleted by the first process is greater than or equal to a third threshold;

or, the sum of the number of processes of the preset category, which the first process selects to end, the number of services of the preset category, which the first process selects to delete, and the number of scheduled tasks of the preset category, which the first process selects to delete, is greater than or equal to a fourth threshold.

4. A method according to any one of claims 1 to 3, wherein the obtaining the behavior information of the first process comprises:

and acquiring the behavior information of the first process under the condition that the first process calls an Application Programming Interface (API) or a system command in a monitoring list, wherein the monitoring list comprises one or more of APIs and/or system commands for inquiring a process running on an operating system, inquiring a running service, inquiring a set planning task, ending the process, deleting the service or deleting the planning task.

5. The method according to any one of claims 1 to 4, further comprising:

and sending the execution result of the changed first API to the first process under the condition that the first process calls the first API, wherein the first API comprises one or more of APIs for querying a process running on an operating system, a running service or a set planning task.

6. The method of claim 5, wherein the modified execution result of the first API includes part of information in the execution result of the first API, or wherein the modified execution result of the first API includes part or all of information in a first blacklist except the execution result of the first API, wherein the first blacklist is an information set of processes, services and planning tasks of the preset category.

7. The method of any of claims 1 to 6, wherein the behavior information further comprises one or more of an operation of the first process to delete a shadow, an operation of the first process to empty a recycle bin.

8. A method according to any one of claims 3 to 7, wherein after said determining that the first process is a process of the luxo software, the method further comprises:

and executing a searching and killing operation on the corresponding le cable software of the first process, wherein the searching and killing operation comprises one or more of ending the process of the corresponding le cable software, isolating the corresponding le cable software and deleting the corresponding le cable software.

9. A method according to any one of claims 3 to 8, wherein after said determining that the first process is a process of the luxo software, the method further comprises:

and prompting the user that the first process is a process of the luxury software, and presenting the behavior information of the first process.

10. A lux software detection system, the system comprising:

the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring behavior information of a first process, wherein the behavior information comprises one or more of a process of a preset category, which is selected by the first process to be ended, a service of the preset category, which is selected by the first process to be deleted, and a planning task of the preset category, which is selected by the first process to be deleted;

And the determining module is used for determining whether the first process is a process of the luxury software according to the behavior information.

11. The system of claim 10, wherein the preset categories include one or more of a database class, a file editing class, a network communication class, a backup and restore class, a security class, a restart and exit class.

12. The system according to claim 10 or 11, wherein the determining module is specifically configured to:

13. The system according to any one of claims 10 to 12, wherein the acquisition module is specifically configured to:

and acquiring the behavior information of the first process under the condition that the first process calls an Application Programming Interface (API)/system command in a monitoring list, wherein the monitoring list comprises one or more of APIs and/or system commands for inquiring a process running on an operating system, inquiring a running service, inquiring a set planning task, ending the process, deleting the service or deleting the planning task.

14. The system of any one of claims 10 to 13, further comprising a modification module for:

15. The system of claim 14, wherein the modified execution result of the first API includes part of information in the execution result of the first API, or wherein the modified execution result of the first API includes part or all of information in a first blacklist except the execution result of the first API, wherein the first blacklist is an information set of processes, services, and planning tasks of the preset category.

16. The system of any of claims 10 to 15, wherein the behavior information further comprises one or more of an operation of the first process to delete a shadow, an operation of the first process to empty a recycle bin.

17. The system of any one of claims 12 to 16, further comprising a kill module for:

after the determining module determines that the first process is a process of the le cable software, performing a searching and killing operation on the le cable software corresponding to the first process, wherein the searching and killing operation comprises one or more of ending the process of the corresponding le cable software, isolating the corresponding le cable software and deleting the corresponding le cable software.

18. The system of any one of claims 12 to 17, further comprising a hint module for:

after the determining module determines that the first process is the process of the luxury software, prompting the user that the first process is the process of the luxury software, and presenting the behavior information of the first process.

19. A lux software testing device, the device comprising a processor and a memory;

The memory is used for storing a computer program;

the processor is configured to execute a computer program stored in the memory to cause the apparatus to perform the method of any one of claims 1-9.

20. A computer readable storage medium comprising a program or instructions which, when run on a processor, performs the method of any of claims 1-9.