Ransom behavior detection method and device, electronic equipment, storage medium and product

Abstract

This disclosure provides a ransomware detection method, apparatus, electronic device, storage medium, and product. The ransomware detection method includes: responding to a first system call in response to an application retrieving directory entries of a target directory, returning a list of directory entries for the target directory to the application, the list including virtual directory entries for a decoy file; responding to a second system call in response to the application opening the decoy file based on the virtual directory entries, creating and returning an anonymous file object mapped from the decoy file; and, if the file flags of the anonymous file object satisfy a first condition, determining whether the application exhibits ransomware behavior based on the application's file access operations on the anonymous file object, the first condition including file flags indicating that the open mode requires write permissions and / or the addition of a write flag. This disclosure enables accurate and real-time ransomware detection with zero disk overhead and low deployment costs.

Description

Technical Field

[0001] This disclosure relates to the field of computer science, and more specifically, to a method, apparatus, electronic device, storage medium, and product for detecting ransomware. Background Technology

[0002] Ransomware is malicious software that demands ransom from users by encrypting their files. A typical attack process includes file system scanning, bulk file encryption, and destruction of the original files. This file-targeting attack can cause significant damage. Traditional ransomware detection methods primarily rely on signature detection and behavioral analysis. However, given the ever-evolving attack methods of ransomware, these technologies have limitations and / or shortcomings in areas such as resource consumption and detection timeliness. Summary of the Invention

[0003] Various embodiments of this disclosure provide a ransomware detection method, apparatus, electronic device, storage medium, and product, thereby effectively detecting ransomware while ensuring the security of genuine documents.

[0004] Other aspects will be set forth in part in the description which follows, and in part will be apparent from the description or may be learned by practice of the embodiments presented.

[0005] According to a first aspect of the embodiments of this disclosure, a ransomware detection method is provided, the ransomware detection method comprising: responding to a first system call in which an application obtains directory entries of a target directory, returning a list of directory entries of the target directory to the application, wherein the list of directory entries includes virtual directory entries of a decoy file; responding to a second system call in which the application opens the decoy file based on the virtual directory entries, creating and returning an anonymous file object mapped according to the decoy file; and, if the file flag of the anonymous file object satisfies the first condition, determining whether the application has ransomware behavior based on the file access operation of the application on the anonymous file object, wherein the first condition includes the file flag indicating that the open mode requires write permission and / or the addition of a write flag bit.

[0006] Optionally, if the file identifier of the anonymous file object satisfies the first condition, the step of determining whether the application has ransomware behavior based on the application's file access operations on the anonymous file object includes: if the file identifier satisfies the first condition, monitoring the application's file access operations on the anonymous file object; if the monitored file access operations satisfy a second condition, determining that the application has ransomware behavior, wherein the second condition includes at least one of the application performing a write operation, a memory mapping operation, a truncation operation, and a file space allocation operation on the anonymous file object.

[0007] Optionally, the virtual directory entry is generated through the following steps: determining the decoy file characteristics of the virtual decoy file, the decoy file characteristics including the decoy file name; generating the virtual directory entry based on the decoy file characteristics, wherein the decoy file name is a file name that conforms to the characteristics of a real file through encryption, and the file name decrypted from the decoy file name is used to identify the file as the virtual decoy file when the file is opened.

[0008] Optionally, the decoy file features further include at least one of the following: file size determined based on the size distribution of real files in the real directory entries included in the directory entry list; file type determined based on the type of the real files; and file injection density determined based on at least one of the importance of the real directory entries and the number of the real files.

[0009] Optionally, the ransomware detection method further includes: marking the inode number of the decoy file, wherein the marked inode number is used to indicate that the file is the decoy file when the application opens the file.

[0010] Optionally, the ransomware detection method further includes: returning random data or simulated data based on a real file to the application when the application performs a read operation on the anonymous file object, and / or cleaning up the resources of the anonymous file object when the application performs a file close operation on the anonymous file object.

[0011] Optionally, the ransomware detection method further includes: performing a warning operation when the file flag of the anonymous file object satisfies a first condition, wherein the warning operation includes at least one of the following operations: recording a warning log including process information, file open information and / or flag change information; sending a warning event indicating that the application has a risk of ransomware behavior to user space; marking the current process of the application as a suspicious process; freezing the current process until it is unfrozen; and recording a directory snapshot.

[0012] Optionally, the ransomware detection method further includes: upon determining that the application exhibits ransomware behavior, performing protective operations, wherein the protective operations include at least one of the following operations: recording a confirmation log including process information, file operation types, and / or call stacks; sending a confirmation event confirming that the application exhibits ransomware behavior to user space; terminating the current process and its child processes of the application; isolating the current process and restricting its resource usage, access permissions, and / or file operations; and recording a memory snapshot, file system state snapshot, system call sequence, and / or malicious code sample of the process.

[0013] Optionally, at least one step in the ransomware detection method is implemented by modifying the kernel source code, hijacking system calls of kernel modules, extending the Berkeley package filter, kernel probes, and / or userspace file systems.

[0014] According to a second aspect of the embodiments of this disclosure, a ransomware detection device is provided, the ransomware detection device comprising: a directory entry acquisition unit configured to, in response to a first system call by an application to acquire directory entries of a target directory, return a list of directory entries of the target directory to the application, wherein the list of directory entries includes virtual directory entries of a decoy file; a file opening unit configured to, in response to a second system call by the application to open the decoy file based on the virtual directory entries, create and return an anonymous file object mapped according to the decoy file; and a detection unit configured to, if the file flag of the anonymous file object satisfies a first condition, determine whether the application has engaged in ransomware behavior based on the file access operation of the application on the anonymous file object.

[0015] Optionally, the detection unit is configured to determine whether the application is engaging in ransomware behavior based on the application's file access operations on the anonymous file object if the file flag of the anonymous file object satisfies a first condition: if the file flag satisfies the first condition, monitor the application's file access operations on the anonymous file object; if the monitored file access operations satisfy a second condition, determine that the application is engaging in ransomware behavior, wherein the second condition includes at least one of the application performing a write operation, a memory mapping operation, a truncation operation, and a file space allocation operation on the anonymous file object.

[0016] Optionally, the virtual directory entry is generated through the following steps: determining the decoy file characteristics of the virtual decoy file, the decoy file characteristics including the decoy file name; generating the virtual directory entry based on the decoy file characteristics, wherein the decoy file name is a file name that conforms to the characteristics of a real file through encryption, and the file name decrypted from the decoy file name is used to identify the file as the virtual decoy file when the file is opened.

[0017] Optionally, the decoy file features further include at least one of the following: file size determined based on the size distribution of real files in the real directory entries included in the directory entry list; file type determined based on the type of the real files; and file injection density determined based on at least one of the importance of the real directory entries and the number of the real files.

[0018] Optionally, the ransomware detection device further includes an inode marking unit, which is configured to mark the inode number of the decoy file, wherein the marked inode number is used to indicate that the file is the decoy file when the application opens the file.

[0019] Optionally, the ransomware detection device further includes a file operation execution unit, which is configured to: return random data or simulated data based on a real file to the application when the application performs a read operation on the anonymous file object, and / or clean up the resources of the anonymous file object when the application performs a file close operation on the anonymous file object.

[0020] Optionally, the ransomware detection device further includes an alert unit configured to: perform an alert operation when the file flag of the anonymous file object satisfies a first condition, wherein the alert operation includes at least one of the following operations: recording an alert log including process information, file open information, and / or flag change information; sending an alert event indicating that the application has a risk of ransomware behavior to user space; marking the current process of the application as a suspicious process; freezing the current process until it is unfrozen; and recording a directory snapshot.

[0021] Optionally, the ransomware detection device further includes a protection unit configured to: upon determining that the application exhibits ransomware behavior, perform protection operations, wherein the protection operations include at least one of the following operations: recording a confirmation log including process information, file operation types, and / or call stacks; sending a confirmation event confirming that the application exhibits ransomware behavior to user space; terminating the application's current process and its child processes; isolating the current process and restricting its resource usage, access permissions, and / or file operations; and recording a memory snapshot, file system state snapshot, system call sequence, and / or malicious code sample of the process.

[0022] Optionally, at least one operation in the ransomware detection device is implemented by modifying the kernel source code, hijacking system calls of kernel modules, extending the Berkeley packet filter, kernel probes, and / or userspace file systems.

[0023] According to a third aspect of the embodiments of the present disclosure, an electronic device is provided, the electronic device comprising: at least one processor; at least one memory storing computer-executable instructions, wherein the computer-executable instructions, when executed by the at least one processor, cause the at least one processor to perform the ransomware detection method as described above.

[0024] According to a fourth aspect of the embodiments of the present disclosure, a computer-readable storage medium is provided, wherein instructions in the computer-readable storage medium, when executed by at least one processor, cause the at least one processor to perform the ransomware detection method as described above.

[0025] According to a fifth aspect of the embodiments of the present disclosure, a computer program product is provided, including computer-executable instructions, wherein the computer-executable instructions, when executed by at least one processor, implement the ransomware detection method as described above.

[0026] Ransomware detection methods, apparatuses, electronic devices, computer-readable storage media, and computer program products according to various embodiments of this disclosure can return a list of directory entries, including virtual directory entries, to an application in response to a system call for an application to retrieve directory entries. When the application opens a virtual decoy file based on a virtual directory entry, an anonymous file object mapped to the virtual decoy file is created instead of a physical file. If the file flag of the anonymous file object meets specific conditions, the application's file access operation on the anonymous file object is further used to determine whether the application has ransomware behavior. The deployment of virtual directory entries instead of real files for virtual decoy files can have low deployment costs. The use of anonymous file objects mapped from virtual decoy files can avoid occupying external storage space. Furthermore, the determination based on both file flags and file access operations can quickly and accurately detect ransomware behavior. Therefore, various embodiments of this disclosure can achieve accurate and real-time ransomware detection with zero disk overhead and / or low deployment costs.

[0027] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0028] The above and other aspects, features and advantages of various embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings.

[0029] Figure 1 This is a flowchart illustrating a ransomware detection method according to an embodiment of the present disclosure.

[0030] Figure 2 This is a flowchart illustrating the process of obtaining catalog entries according to an embodiment of the present disclosure.

[0031] Figure 3 This is a flowchart illustrating the process of opening a file according to an embodiment of the present disclosure.

[0032] Figure 4 This is a flowchart illustrating the processing in alert mode according to an embodiment of the present disclosure.

[0033] Figure 5 This is a flowchart illustrating the processing in the confirmation mode according to an embodiment of the present disclosure.

[0034] Figure 6 This is a block diagram illustrating a ransomware detection device according to an embodiment of the present disclosure. Detailed Implementation

[0035] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0036] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of methods and apparatus consistent with some aspects of this disclosure as detailed in the claims.

[0037] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. Another example is "performing at least one of step one and step two", which means the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0038] As described in the background section, the technologies used for ransomware detection have numerous limitations and / or shortcomings. For example, these technologies mainly include traditional decoy file techniques and user-mode behavior detection techniques. For instance, traditional decoy file techniques typically involve pre-deploying real decoy files in the file system and detecting ransomware by monitoring access behavior to these decoy files. However, traditional decoy file techniques have at least the following drawbacks: high resource overhead, as traditional decoy files consume a large amount of disk space and inode resources, resulting in high maintenance costs due to the need for regular updates; high identifiability, as decoy files stored on disk have fixed inode numbers, creation times, modification times, and other metadata, allowing ransomware to identify them by analyzing file attributes such as concentrated creation times, regular file sizes, and consecutive inode numbers. This allows ransomware to learn the content patterns of decoy files and bypass ransomware attacks; limited coverage, as the limited number of decoy files cannot cover all directories, allowing ransomware to selectively skip decoy files and attack other files; and poor detection timeliness, due to the delay in detection by user-space monitoring tools (such as inotify or fanotify) monitoring the file system, there is a time window between when a decoy file is modified and when abnormal behavior is detected, during which time ransomware may have already encrypted a large number of files. For example, user-space behavior detection techniques typically identify abnormal batch file operation patterns by monitoring the file access behavior of processes. However, user-space behavior detection technology has at least the following drawbacks: high detection lag, as it relies on the accumulation and analysis of historical data, and there is a time window between the occurrence of abnormal behavior and its detection, meaning that many files may already be encrypted by the time abnormal behavior is detected; high false positive and / or false negative rates, as it detects batch file operations, normal batch file operations such as backups or synchronizations may be misjudged as ransomware, and ransomware may bypass detection by reducing the frequency of file operations or simulating normal behavior, making this rule-based monitoring difficult to cope with unknown attack patterns; high performance overhead, as system call tracing introduces significant performance overhead, and real-time calculation and analysis of behavioral characteristics consume a lot of computing resources, thus affecting the overall performance of the system; and lack of kernel-level control, as user-space detection cannot prevent malicious operations at the kernel level. Even if a threat is detected, the process needs to be terminated through user-space tools, resulting in a response delay to the detection and an inability to precisely control the underlying operations of the file system.

[0039] Therefore, related technologies suffer from problems in at least several aspects, including resource overhead, real-time detection, identifiability of decoy files, and / or directory coverage. To at least address some of the aforementioned deficiencies and / or problems, various embodiments of this disclosure propose ransomware detection methods, apparatuses, electronic devices, computer-readable storage media, and computer program products. These methods can deploy virtual decoy files at the Linux operating system kernel level and achieve real-time detection of ransomware's extortionate behavior based on these files. This allows for decoy file deployment without consuming disk space resources, rapid coverage of decoy files across all directories without pre-deployment, deployment of decoy files that are difficult for ransomware to identify, preventing ransomware from bypassing the decoy files, and / or real-time capture of ransomware behavior at the kernel level, thereby reducing latency. The various embodiments according to this disclosure are described in detail below with reference to the accompanying drawings.

[0040] Before describing the various embodiments of this disclosure, some of the terms used in the embodiments will be explained first.

[0041] A honeypot file is a trap file used to detect malicious behavior of ransomware.

[0042] Anonymous File object: A memory file object that is not associated with a disk file.

[0043] Inode: A data structure in a file system that stores file metadata.

[0044] Directory Entry: A data structure in the file system that describes the mapping relationship between file names and inodes.

[0045] Figure 1 This is a flowchart illustrating a ransomware detection method according to an embodiment of the present disclosure.

[0046] As an example, the ransomware detection method according to embodiments of the present disclosure may be executed by a ransomware detection device, electronic device and / or at least one processor or any other electronic device or system according to embodiments of the present disclosure.

[0047] Reference Figure 1 In step S100, in response to the first system call for the application to obtain the directory entries of the target directory, a list of directory entries of the target directory is returned to the application, wherein the list of directory entries includes the virtual directory entries of the virtual decoy file.

[0048] For example, in a Linux system, an application retrieves directory contents using the function getdents64, a first system call used to obtain directory entries for the target directory. For example, the application can include ransomware or non-ransomware applications; that is, this disclosure does not limit the application herein, and the application can be any application.

[0049] According to embodiments of this disclosure, by hijacking the return path of the first system call of an application and inserting virtual directory entries into the list of directory entries returned to the application as real directory entries, a list of directory entries including virtual directory entries is returned to the application, allowing the application to open virtual decoy files corresponding to the virtual directory entries. As an example, the list of directory entries can be a list consisting of multiple directory entries of the target directory. In this disclosure, the process of hijacking the return path can be referred to as directory traversal hijacking, and the process of inserting virtual directory entries can be referred to as virtual directory entry injection. See below for further details. Figure 2 Step S100 is described in detail.

[0050] Figure 2 This is a flowchart illustrating the process of obtaining catalog entries according to an embodiment of the present disclosure.

[0051] Reference Figure 2 In step S210, in response to the first system call of the application to retrieve directory entries, the first system call is executed to traverse the target directory and retrieve the directory entries of the target directory.

[0052] As an example, in response to an application (such as ransomware or a non-ransomware application) performing a first system call to retrieve directory entries by invoking the function getdents64, the kernel can execute the logic of the original function getdents64: that is, traversing the target directory pointed to by the function getdents64 to retrieve directory entries and populating the retrieved directory entries into a user-space buffer. For example, the target directory pointed to can be determined based on the fd parameter representing the directory file descriptor in the function getdents64. Here, the target directory traversed (i.e., the target directory to which directory entries are to be retrieved) can include, but is not limited to, the target directory pointed to; for example, the target directory traversed can also include the target directory pointed to and its subdirectories.

[0053] In step S220, it is determined whether the retrieval of the directory entry was successful. As an example, the return value of the first system call described above may indicate the number of bytes actually read, such as the total number of bytes in the directory entry structure. If the return value of the first system call is greater than 0, it is determined that the retrieval of the directory entry was successful and step S230 is executed; otherwise, it is determined that the retrieval of the directory entry failed.

[0054] If it is determined that obtaining a directory entry fails, in step S260, it is determined that the directory is empty or that there is an error in obtaining a directory entry, and the virtual directory entry injection is skipped.

[0055] When it is determined that the directory entry was successfully obtained, in step S230, it is determined whether to inject the virtual directory entry of the virtual decoy file.

[0056] As an example, whether to inject a virtual directory entry is determined based on whether the user-space policy and / or the directory entry list includes a virtual directory entry. For instance, when a user-space policy indicates that a specific type of process or a specific range of directories requires a decoy file, it is determined that a decoy file is needed based on the fact that the current process belongs to that specific type of process or the traversed directory belongs to that specific range of directories, and it is determined that a virtual directory entry needs to be injected based on the need for a decoy file. As another example, when the directory entry of the target directory has already been obtained through a first system call, and the directory entry list in the user-space buffer already includes the injected virtual directory entry, it is determined that no further injection of a virtual directory entry is necessary. However, this is merely an example, and embodiments of this disclosure can determine whether to inject a virtual directory entry using various conditions and policies, and are not limited to these.

[0057] Furthermore, although it is shown here that virtual directory entries are not injected if they already exist, this disclosure is not limited to this. Virtual directory entries may be injected during each first system call to retrieve directory entries, regardless of whether they are already included, in order to continuously update the list of directory entries and thus improve the stealth of the decoy file.

[0058] When a virtual directory entry is determined to be injected, in step S240, a virtual directory entry is generated based on the obtained directory entry.

[0059] As an example, based on the file characteristics of the real file corresponding to the obtained directory entry, the decoy file characteristics of the virtual decoy file are determined, and a virtual directory entry for the virtual decoy file is generated based on the decoy file characteristics, wherein the file characteristics of the virtual decoy file conform to the real file characteristics. As an example, the real file may include an actual existing entity file; that is, in this disclosure, the real file may be a file other than the virtual decoy file. In other words, to improve the concealment of the decoy file, a virtual directory entry for the virtual decoy file with file characteristics similar to or identical to those of the real file may be generated. In this disclosure, the file characteristics of the real file may be referred to as real file characteristics, and the file characteristics of the decoy file may be referred to as decoy file characteristics.

[0060] As an example, the file characteristics of real files and virtual decoy files may each include at least one of the following: file name, file size, file type, and file injection density.

[0061] As an example, based on the naming pattern of the real files in the target directory (such as the file name extension, prefix, and / or file name length distribution), decoy file names that conform to the naming pattern are determined, such as decoy file names whose extension, prefix, and / or length distribution is the same as or similar to the real file's extension, prefix, and / or length distribution.

[0062] As an example, the decoy file name can be a file name generated through encryption that conforms to the characteristics of a real file, such as a garbled or random number format. Furthermore, the file name decrypted from the decoy file name through decryption can be a file name with a specific decoy naming pattern. This specific decoy naming pattern can be such that a user or system can identify the file as a virtual decoy file when the file is opened. For example, the specific decoy naming pattern can be a naming pattern identified by specific text or characters, such that when a file is opened, the file name decrypted from that file can identify it as a virtual decoy file. In other words, the decoy file name of a virtual decoy file can have a fixed name label that identifies the decoy file category before encryption, and a name label that is not easily recognized as a decoy file category by ransomware after encryption. For example, in a target directory containing files with the extension ".docx", the decoy file name before or after encryption can have a fixed prefix "report". In this case, the decoy file name before or after encryption can be, for example, "report_2024.docx", and the corresponding file can be identified as a decoy file based on this name. For example, the encrypted decoy file name "report_2024.docx" may appear as gibberish to the user, but it is a normal file name to the ransomware, making the decoy file difficult for the ransomware to recognize, thus reducing its identifiability. In this disclosure, file categories can be divided into decoy files and non-decoy files, that is, corresponding to virtual decoy files and real files, respectively.

[0063] Therefore, according to embodiments of this disclosure, the decoy file name is a file name that conforms to the characteristics of a real file and is generated by encryption, and the file name decrypted from the decoy file name is used to identify the file as a virtual decoy file when the file is opened.

[0064] As an example, the encryption method for the file name can be a symmetric encryption algorithm, and correspondingly, the decryption method can be a symmetric decryption algorithm corresponding to the symmetric encryption algorithm. However, the encryption and decryption methods of the embodiments of this disclosure are not limited thereto, and any encryption and decryption method can be used to implement the embodiments of this disclosure.

[0065] According to embodiments of this disclosure, a virtual directory entry is generated through the following steps: determining the decoy file characteristics of a virtual decoy file, the decoy file characteristics including the decoy file name; and generating a virtual directory entry based on the decoy file characteristics. For example, the generated virtual directory entry may include a filename field determined based on the virtual decoy file name.

[0066] According to embodiments of this disclosure, in addition to generating virtual directory entries based on decoy file features including the decoy file name, virtual directory entries can also be generated based on decoy file features including at least one of file size, file type, and file injection density, and the decoy file name. For example, the generated virtual directory entry may include a file name field determined based on the virtual decoy file name, and the inode pointed to by the virtual directory entry includes information about at least one of file size, file type, and file injection density.

[0067] As an example, the size distribution of real files in the target directory can be statistically analyzed, and virtual decoy files can be assigned sizes that conform to this statistical distribution. This avoids the use of fixed-size decoy files, which are easily identified by ransomware. For example, the size of at least one virtual decoy file among multiple virtual decoy files can be determined as the average size of real files in a directory; the size of at least one virtual decoy file among multiple virtual decoy files can be determined as the maximum or minimum size of real files in a directory; or the size of at least one virtual decoy file among multiple virtual decoy files can be determined as the size of the most frequently occurring real file in a directory. This disclosure does not impose any limitations on this.

[0068] As an example, the types of real files in the target directory can be statistically analyzed, and the decoy files can be assigned a type that conforms to the statistical distribution. For example, the decoy files can be identified as having one or more file types with the largest number of occurrences. File types can include, but are not limited to, regular or ordinary files, directories, symbolic links, etc. For instance, the file type of the decoy file can be set to a regular file type using a format such as DT_REG, making the decoy file indistinguishable from real files of regular file types at the directory entry level, thereby improving the decoy file's stealth.

[0069] As an example, the file injection density for injecting virtual decoy files into a directory can be dynamically adjusted based on the importance of the directory and the number of real files counted from real files. Here, the file injection density can represent the number of virtual directory entries of virtual decoy files injected into a single directory or all directories including a single directory and its subdirectories.

[0070] For example, the importance of directories can be set and the file injection density determined based on user policies. For instance, the user's home directory and / or document directory can be set as high-importance directories, and a higher file injection density can be determined for the user's home directory and / or document directory, such as injecting 5 to 10 virtual directory entries of virtual decoy files into the directory each time it is traversed. On the other hand, the system directory and / or temporary directory can be set as low-importance directories, and a lower file injection density can be determined for the system directory and / or temporary directory, such as injecting 1 to 2 virtual directory entries of virtual decoy files into the directory each time it is traversed.

[0071] For example, the file injection density can be determined based on the number of real files in a single directory or in all directories including the single directory and its subdirectories. For instance, a higher file injection density is determined when the number of real files is greater than or equal to a predetermined threshold, such as injecting 5 to 10 virtual directory entries of decoy files into a directory each time it is traversed. Conversely, a lower file injection density is determined when the number of real files is less than a specific file number threshold, such as injecting 1 to 2 virtual directory entries of decoy files into a directory each time it is traversed. However, the description herein is merely illustrative. For example, the importance of directories can be categorized in any way, the file injection density can be set to any value within any directory range, or the number of decoy files used as the file injection density can be determined based on a value that is reduced or increased by a specific factor based on the number of real files. This disclosure does not limit this.

[0072] According to embodiments of this disclosure, the decoy file features further include at least one of the following: file size determined based on the size distribution of real files in the real directory entries included in the directory entry list; file type determined based on the type of real files; and file injection density determined based on at least one of the importance of real directory entries and the number of real files.

[0073] Furthermore, according to embodiments of this disclosure, the virtual decoy file may also have an inode number (i.e., an inode number) corresponding to the virtual decoy file. That is, one inode number corresponds to one virtual decoy file as its identifier.

[0074] According to embodiments of this disclosure, the inode number of a virtual decoy file is marked, wherein the marked inode number is used to indicate that the file is the virtual decoy file when an application opens the file. As an example, the inode number assigned to the decoy file may be marked, or an inode number with a specific identifier may be assigned to the decoy file, such that when the file is opened, the file can be identified as a decoy file based on its inode number. As an example, the inode number corresponding to the virtual decoy file may be included in the virtual directory entry corresponding to the virtual decoy file for pointing to the inode.

[0075] As an example, a file corresponding to an inode number can be marked as a decoy file by setting the highest bit of the inode number to a specific value (such as 1). For instance, user space can open a file based on the decoy file name in a virtual directory entry; in this case, the file can be identified as a decoy file based on the filename decrypted from the decoy file name. However, user space does not necessarily always open files based on the decoy file name. When a file is not opened by the decoy file name, it can be identified as a virtual decoy file based on the highest bit of the inode number corresponding to the file being set to a specific value.

[0076] Although this disclosure describes the use of either the filename or the inode number alone to identify whether a file is a decoy file, this disclosure is not limited thereto. Both can also be used in turn to determine whether a file is a decoy file. For example, if the filename does not identify the file as a decoy file, the inode number can be used to further identify whether the file is a decoy file.

[0077] As an example, the step of generating a virtual directory entry based on the decoy file characteristics of a virtual decoy file may include, for example, generating a data structure in the process context for mapping the encrypted decoy file name to the corresponding inode, wherein the inode may include metadata of the virtual decoy file, such as file size, file type, etc., in the decoy file characteristics. However, this disclosure is not limited thereto, and the virtual directory entry and its inode may also include other content or information.

[0078] In step S250, the directory entry list is updated by inserting the generated virtual directory entries into the directory entry list that includes the acquired directory entries.

[0079] As an example, when filling the user-space buffer with the obtained directory entries or obtaining the return value of the first system call, a pointer to the user-space buffer can be obtained. Based on the address pointed to by the user-space buffer pointer, virtual directory entries can be injected into the directory entry list by appending the generated virtual directory entries to the end of the user-space buffer. Furthermore, the directory entry list returned to the application is updated by updating the return value of the first system call based on the original return value of the first system call and the size of the injected virtual directory entries. For example, the size of a virtual directory entry could be the size of the string occupied by the virtual directory entry, etc., and this disclosure does not limit this.

[0080] As an example, when updating the list of directory entries, the decision to inject virtual directory entries can also be based on the remaining space in the user-space buffer. For instance, the remaining space in the user-space buffer can be determined when filling the user-space buffer with retrieved directory entries or obtaining the return value of a system call. If the remaining space is greater than or equal to the size of the virtual directory entry to be injected or a specific size threshold, the virtual directory entry is injected; otherwise, the injection is skipped.

[0081] In step S270, when the directory entry list is updated or the injection of virtual directory entries is skipped, the current directory entry list is provided to the application as the return result of the first system call. For example, the return result could be the number of bytes filled in the user space buffer, etc., and this disclosure does not limit this.

[0082] Therefore, the term "virtual" in the virtual decoy file according to embodiments of this disclosure can be understood as the decoy file having only directory entries and / or inodes associated with the decoy file, but not having the characteristics of a file actually stored in non-volatile memory (such as a disk). Thus, a virtual decoy file can be a file of an entity that does not actually have persistent storage.

[0083] The dynamic virtual directory entry injection according to embodiments of this disclosure can inject virtual directory entries without physical files into the returned directory entry list, and can inject virtual directory entries based on actual needs, such as deploying decoy files based on specified target directories or automatically deploying decoy files when newly created directories according to user policy configuration, and can even easily achieve full directory coverage without pre-deployment, thereby expanding the detection coverage of ransomware behavior detection while reducing disk overhead and deployment costs.

[0084] Furthermore, the virtual decoy files according to embodiments of this disclosure are substantially identical to real files in user space and possess dynamically adjusted file characteristics (rather than the fixed pattern of traditional decoy files), making them difficult to identify through file attributes. This prevents attackers from identifying or bypassing the decoy files by pre-scanning directory entries. In particular, the encrypted decoy file names enable the virtual decoy files to meet the low identifiability requirement of being "difficult for viruses to identify and easy for this program to identify," thereby further enhancing the decoy files' stealth. Therefore, in the ransomware detection method according to embodiments of this disclosure, the deployed virtual decoy files possess high decoy file stealth from the application through their encrypted file names, and are easily identifiable from the execution end of the ransomware detection method through the file names and inode numbers used to identify file categories, thereby improving the accuracy and real-time performance of ransomware detection based on virtual decoy files.

[0085] When a virtual directory entry for a virtual decoy file is deployed via step S100, ransomware activity can be detected in the application based on file operations performed after the application opens the virtual decoy file during subsequent file openings.

[0086] return Figure 1 In step S200, in response to the second system call from the application to open the virtual decoy file based on the virtual directory entry, an anonymous file object mapped according to the virtual decoy file is created and returned.

[0087] For example, in a Linux system, an application (such as a ransomware or non-ransomware application) opens a file by calling the `open` or `Openat` system call (i.e., the second system call) to open the file based on a directory file descriptor. The kernel then performs the file open operation by calling the `do_filp_open` function and returns the file descriptor. According to embodiments of this disclosure, the opened file is identified as a decoy file by hijacking the `do_filp_open` function. A corresponding anonymous file object is created based on the file open operation against the decoy file. The decoy file is mapped to this anonymous file object, and the file descriptor of the anonymous file object is returned as the file descriptor of the decoy file. Here, mapping the decoy file to the anonymous file object indicates that the anonymous file object is used as the actual operable file of the decoy file, and all operations performed by the application against the decoy file are directly mapped to operations performed by the application against the anonymous file object. This makes it appear from the application's perspective that the application is performing operations against the decoy file; however, in reality, the application is performing operations against the anonymous file object mapped from the decoy file. In this disclosure, the process of hijacking the file open function can be referred to as file open hijacking, and the process of creating, mapping (or configuring), and returning an anonymous file object can be referred to as anonymous file mapping. See below. Figure 3 Step S200 is described in detail.

[0088] Figure 3 This is a flowchart illustrating the process of opening a file according to an embodiment of the present disclosure.

[0089] Reference Figure 3 In step S310, in response to the second system call to open the file, the function used for opening the file is hijacked. For example, the second system call to open the file may include calling the do_filp_open function. Hijacking the do_filp_open function may include suspending the result return behavior of the do_filp_open function under normal call conditions and obtaining the parameter information contained in the do_filp_open function, such as directory entry, file name, inode number, etc.

[0090] In step S320, it is determined whether the file to be opened is a decoy file (i.e., a virtual decoy file).

[0091] As an example, the file pathname of the file to be opened can be obtained from the directory entry or directory file descriptor in the directory entry list. Based on the file pathname, the filename of the file to be opened can be obtained. The filename decrypted from the obtained filename can then be used to identify whether the file is a decoy file. For example, if decryption from the obtained filename is successful and the decrypted filename is as shown above... Figure 2 A file with a specific decoy naming pattern is identified as a decoy file. For example, the inode number of the file to be opened can be obtained from a directory entry or directory file descriptor, and the file can be identified as a decoy file based on whether the inode number is a marked inode number; for example, an inode number with a specific value marked in its highest bit indicates that the file is a decoy file. Alternatively, the file can be identified as a decoy file based on other file characteristics of the file to be opened; this disclosure does not limit this approach.

[0092] When it is determined that the file to be opened is a decoy file, in step S330, process information is recorded. As an example, the recorded process information may include, but is not limited to, at least one of the following: process identifier (PID), process name, executable file path, and open flag, and may be used for subsequent process-related processing.

[0093] Although it is shown here that process information is recorded when a file is opened, the embodiments of this disclosure are not limited thereto, and process information may not be recorded when a file is opened.

[0094] In step S340, a memory-based anonymous file object is created corresponding to the virtual decoy file to be opened. As an example, the anonymous file object can be created using the function anon_inode_getfile for creating anonymous files.

[0095] In this disclosure, a memory-based anonymous file object can indicate that the anonymous file object is always stored in memory, for example, in a specific memory region of memory that is the main memory or internal memory of the Linux system, and is not stored in non-volatile memory (such as disk) that is the external memory of the Linux system. In other words, the anonymous file object is not a real disk file.

[0096] In step S350, the created anonymous file object is configured to map the virtual decoy file to the created anonymous file object. In other words, since the virtual decoy file corresponding to the virtual directory entry injected in step S100 does not have a real entity file, when the application attempts to open the virtual decoy file, an anonymous file object is created and configured to map the file operations of the virtual decoy file to the anonymous file object. This allows the application to perform file operations on the virtual decoy file, which originally did not exist as a real entity. That is, all input / output (I / O) operations on the virtual decoy file can be performed normally without the application recognizing that the current file is not a real file.

[0097] As an example, configuring the created anonymous file object can include mapping file operations performed by the application on the decoy file to corresponding file operations performed by the application on the anonymous file object, so that the decoy file is mapped to the anonymous file object. In other words, all file operations performed by the application on the decoy file are performed on the anonymous file object to which it is mapped, and the various file operations performed on the anonymous file object are implemented in a custom way.

[0098] For example, Table 1 shows a custom file operation interface for anonymous file objects according to an embodiment of this disclosure.

[0099] Table 1

[0100] However, Table 1 is only shown as an example, and different or other file operations may be defined for anonymous file objects for file operations on virtual decoy files, and this disclosure does not limit this.

[0101] As an example, configuring the created anonymous file object may include allocating shared memory regions for multiple decoy files, such as allocating different segments of the same shared memory region for different decoy files. For example, in mmap During file operations, a shared memory region is allocated for anonymous file objects without occupying additional memory regions. In other words, regardless of how many decoy files are opened, the corresponding anonymous file objects will not occupy excessive memory regions, thereby reducing memory usage and achieving shared memory optimization.

[0102] Therefore, according to embodiments of this disclosure, file operations on virtual decoy files are mapped to file operations defined for anonymous file objects, wherein the file operations defined for anonymous file objects include at least one of the following operations: for read operations, returning random data or simulated data based on real files; for file close operations, cleaning up resources of anonymous file objects; for memory mapping operations, allocating a shared memory region in memory for multiple virtual decoy files and / or determining that the application has ransomware behavior; for write operations, truncation operations, and / or file space allocation operations, determining that the application has ransomware behavior.

[0103] As an example, configuring a created anonymous file object may include initializing private file data. For instance, initializing private file data may include, but is not limited to, recording the file open time, recording the file open flag, initializing the alert status flag (alert_sent), and / or the confirmed status flag (confirmed). The open flag, alert status flag, and confirmed status flag will be described later and will not be detailed here.

[0104] Therefore, according to embodiments of this disclosure, when an application performs a read operation on an anonymous file object, random data or simulated data based on a real file is returned to the application, and / or when an application performs a file close operation on an anonymous file object, the resources of the anonymous file object are cleaned up.

[0105] In step S360, the file descriptor of the anonymous file object is returned as the result of the second system call. In other words, the anonymous file object is returned to the application for subsequent file operations after the file is opened.

[0106] When it is determined that the file to be opened is not a decoy file, in step S370, the file is determined to be a real entity file, and the system call or function used to open the file continues to be executed, such as normally opening the corresponding file stored in non-volatile memory (such as a disk).

[0107] Based on the second system call that the application normally opens the real file, in step S380, the file descriptor of the real file object of the corresponding file is returned to the application.

[0108] In step S390, the application can obtain the file descriptor of the anonymous file object or the real file object as a return result and can continue to perform file operations based on the return result.

[0109] According to embodiments of this disclosure, when an application aims to open a decoy file, an anonymous file object is created and mapped without a real file. The anonymous file object according to embodiments of this disclosure may have the following characteristics: memory-based, not associated with any disk inode; supports standard file operations, allowing reading, writing, etc., just like a normal real file; its lifecycle is bound to a file descriptor, such as automatically releasing the anonymous file when the file descriptor is closed; and it shares a memory region. Therefore, this disclosure, using anonymous file objects, can reflect all I / O operations on the decoy file only in memory without creating a real disk file, without persisting the file content or data to disk. This avoids occupying extra disk space, the creation and maintenance of real files, and saves significant storage resources through shared memory.

[0110] Furthermore, the anonymous file object according to embodiments of this disclosure supports standard file operation interfaces, is transparent to the application, and does not require modification of the application or introduce additional performance overhead.

[0111] return Figure 1 In step S300, if the file flag of the anonymous file object satisfies the first condition, it is determined whether the application has ransomware behavior based on the application's file access operation on the anonymous file object.

[0112] As an example, in a Linux system, as described above, in response to an application calling the open or Openat system call, the kernel calls... do_filp_open The function. Then, in response to kernel calls. do_filp_open The function determines that the opened file is a decoy file and identifies an open event that occurred on the virtual decoy file (i.e., an anonymous file object). In this paper, since any file operation on the virtual decoy file is actually performed on the corresponding anonymous file object, the processing based on the virtual decoy file is directly described as processing based on the corresponding anonymous file object.

[0113] According to embodiments of this disclosure, firstly, it is determined whether the decoy file might be modified based on the file flag of the opened anonymous file object; that is, it is determined whether the file flag satisfies a first condition. According to embodiments of this disclosure, the first condition includes the file flag indicating that the open mode requires write permissions and / or the addition of a write flag. If it is determined that the decoy file might be modified, an alert mode indicating a risk of ransomware behavior is entered, an alert operation is performed, and file access operations targeting the anonymous file object are continuously monitored to determine whether the application has modified the decoy file; that is, it is determined whether the file access operation satisfies a second condition. According to embodiments of this disclosure, the second condition includes the application performing at least one of a write operation, a memory mapping operation, a truncation operation, and a file space allocation operation on the anonymous file object.

[0114] In this disclosure, the alert mode can indicate that ransomware may occur, but has not yet occurred; it may also be referred to as an alert state or alert phase. If it is determined that the application has modified the decoy file, ransomware is determined to have occurred, and based on this determination, the system enters confirmation mode. In this disclosure, confirmation mode can indicate that ransomware has been confirmed to have occurred; it may also be referred to as a confirmation state or confirmation phase.

[0115] In other words, embodiments of this disclosure first determine whether a file may be modified by an application. If it may be modified by an application, the application's operations on the file are monitored, such as notifying relevant security programs to enter alert mode (e.g., notifying the user, temporarily freezing the process that triggered the alert mode, etc.). When the monitored access operations to the file include operations that modify the file content, the application is immediately confirmed to be engaging in ransomware behavior, and relevant security programs are notified to enter confirmation mode (e.g., implementing actual protective measures, etc.). Therefore, in this disclosure, the process of detecting ransomware behavior is also referred to as decoy file write detection or two-stage detection.

[0116] Therefore, according to embodiments of this disclosure, if the file identifier satisfies a first condition, the application's file access operation against the anonymous file object is monitored; if the monitored file access operation satisfies a second condition, it is determined that the application is engaging in ransomware behavior.

[0117] The following reference Figure 4 The relevant processing for the file flag satisfying the first condition in step S300 is described, and reference is made to... Figure 5 The relevant processing for the file operation in step S300 that satisfies the second condition is described.

[0118] Figure 4 This is a flowchart illustrating the processing in alert mode according to an embodiment of the present disclosure. Figure 5 This is a flowchart illustrating the processing in the confirmation mode according to an embodiment of the present disclosure.

[0119] Reference Figure 4 In step S410, when the anonymous file object is opened by the application, the file flag of the anonymous file object is obtained, such as an open flag indicating the open mode.

[0120] In step S420, it is determined whether the open mode indicated by the file flag requires write permission, for example, by detecting whether there is an open flag indicating that the open mode requires or includes write permission.

[0121] As an example, open flags indicating that write permissions are required for the open mode may include, but are not limited to, at least one of O_WRONLY (indicating write-only mode), O_RDWR (indicating read-write mode), O_APPEND (indicating append mode), and O_TRUNC (indicating stage mode). Furthermore, the file open flags recorded when creating the anonymous file object mentioned above can be the open flags used here to determine the open mode.

[0122] When it is determined that write permission is required, in step S430, enter alert mode and perform alert operations in alert mode.

[0123] As an example, embodiments of this disclosure may use the alert status flag `alert_sent` to indicate whether the current process of an application is in alert mode. For instance, the alert status flag initialized when the anonymous file object is created as described above may be empty or false (i.e., `alert_sent=false`), set to true (i.e., `alert_sent=true`) when entering alert mode, and set to false when de-alert mode is de-activated. However, embodiments of this disclosure are not limited thereto, and any other means may be used to indicate or represent alert mode.

[0124] As an example, in alert mode (alert_sent=true), alert operations may include, but are not limited to, logging alert logs, notifying alert events, marking processes, freezing processes, and recording snapshots, at least one of these operations.

[0125] As an example, the alert log may include: basic process information, including but not limited to at least one of PID, Thread Group Identifier (TGID), process name (comm), executable file path, and parent process PID; file open information, including but not limited to at least one of open flags, file open time, and current status; and optional flag change information (such as flag changes), including but not limited to at least one of the original flags, the new flags after the change, and the modified timestamp. For example, the open flag may include at least one of O_WRONLY, O_RDWR, O_APPEND, and O_TRUNC; the file open time may include the open timestamp; and the current status may include alert mode and normal mode. However, this disclosure is not limited to this, and arbitrary alert log content may be set based on user policies.

[0126] As an example, the steps for notifying a warning event may include: notifying the user space of the warning event and sending a warning log. For example, the warning event may be notified to a security program or protection program in user space and a warning log may be sent.

[0127] As an example, the process tagging step may include: marking the application's current process as a suspicious process that may be launched by ransomware.

[0128] As an example, freezing a process may involve freezing the application's current process until it is unfrozen based on specific conditions. For instance, when the current process is frozen, it may be added to an unscheduled wait queue until the user decides to unfreeze it. For example, the process may be unfrozen if it belongs to a specific type of process set by the user.

[0129] As an example, the steps of taking a snapshot may include: taking a snapshot of the current directory for possible subsequent file recovery.

[0130] When it is determined in step S420 that write permissions are not required, in step S470, the application opens the anonymous file object in read-only mode. In this case, since write permissions are not available, the file will not be modified in read-only mode, and therefore, it is not necessary to enter alert mode. In this disclosure, the normal mode that does not enter alert mode may be referred to as normal mode or low-risk mode.

[0131] In step S440, the flag bits of the anonymous file object are monitored. As an example, the system call to the fcntl function, used to control the file descriptors of open files, can be monitored.

[0132] In step S450, it is determined whether a write flag has been added. For example, when a system call to the `fcntl` function is detected, the `fcntl` system call is hijacked, and the `F_SETFL` command used to modify the state of a file descriptor is detected. Based on the detection of the `F_SETFL` command, the original flag and the modified flag are compared to determine whether a write flag has been added. Based on this step, if write permissions are not required when opening a file, but the ransomware adds a write flag to modify the file during subsequent file openings, then alert mode is entered.

[0133] When it is determined that a new write flag has been added, in step S460, the system enters alert mode and performs the alert operation in alert mode. Furthermore, the alert operation in step S460 may be the same as or similar to the alert operation in step S430, and will not be described again here. Additionally, if it is determined that no new write flag has been added (No in step S450), step S480, described below, is executed.

[0134] As an example, if the alert mode has already been entered and the alert operation performed in step S430, step S460 can be skipped. Alternatively, if the alert mode has already been entered and the alert operation performed in step S430, step S460 can be skipped and the alert operation performed again. The embodiments of this disclosure do not limit this.

[0135] Furthermore, according to embodiments of this disclosure, when a file flag satisfies a first condition, an alert operation is performed, wherein the alert operation includes at least one of the following operations: recording an alert log including process information, file open information, and / or flag change information; sending an alert event indicating that the application has a risk of ransomware behavior to user space; marking the application's current process as a suspicious process; freezing the current process until it is unfrozen; and recording a directory snapshot.

[0136] In step S480, file operations, such as file access operations, are monitored to further determine whether ransomware has occurred. Here, although... Figure 4 The step S480 of monitoring file operations is shown in both alert mode and when the file is opened in read-only mode; however, embodiments of this disclosure are not limited thereto.

[0137] As an example, file access operations of the application are monitored only when the file flag meets the first condition. In other words, the alert mode when the file flag meets the first condition only indicates that ransomware may be occurring, but monitoring of file access operations is still needed to confirm whether the application is actually engaging in ransomware. By monitoring file access operations only when the file flag meets the first condition, continuously monitoring files that are opened in read-only mode and will not be modified can be avoided, thus further saving performance overhead.

[0138] Reference Figure 5 In step S510, the application's file operations on the anonymous file object, such as file access operations, are monitored to further determine whether ransomware has occurred.

[0139] As an example, in step S510, file access operations against any opened anonymous file object can be monitored, regardless of whether the anonymous file object is in alert mode. In this case, the details of step S480 can be applied to step S510. Based on this, ransomware behavior can be determined as long as any anonymous file object performs a file access operation that meets the predetermined second condition, thereby improving the accuracy of ransomware behavior detection while reducing the false negative rate.

[0140] As an example, in step S510, only file access operations of the application targeting anonymous file objects in alert mode can be monitored. That is, only file access operations of anonymous file objects whose file flags meet the first condition (i.e., have write permissions or have added a write flag) can be monitored. Based on this, only anonymous file objects that may be subject to ransomware attacks can be monitored, such as detecting anonymous file objects whose file content may be modified, without monitoring all open anonymous file objects. This improves the accuracy of ransomware attack detection while reducing performance overhead.

[0141] In step S520, it is determined whether an event of modifying file content has occurred, that is, whether the file access operation for the anonymous file object includes a file operation that modifies the file content, that is, whether the second condition is met.

[0142] According to embodiments of this disclosure, the second condition includes performing a write operation, a memory mapping operation, a truncate operation, and / or a file space allocation operation on the anonymous file object. That is, when any one of the above file operations is performed on the anonymous file object, it is determined that the file operation satisfies the second condition, i.e., an event of modifying the file content has occurred.

[0143] When it is determined that an event has occurred that modifies the file content, or when it is determined that a file operation includes an operation that modifies the file content, in step S530, it is immediately determined that the application has ransomware behavior without waiting for the file to be closed.

[0144] In step S540, based on the determination that ransomware has occurred, the system immediately enters the confirmation mode and performs the protection operation in the confirmation mode without waiting for the file to close.

[0145] As an example, embodiments of this disclosure may use the confirmed status flag to indicate whether the current process is in confirmed mode. For instance, the confirmed status flag initialized when creating the anonymous file object as described above may be empty or false (i.e., confirmed=false), and when entering confirmed mode, the confirmed status flag is set to true (i.e., confirmed=true). Optionally, when exiting confirmed mode, the confirmed status flag is set to false.

[0146] As an example, based on the determination that ransomware has occurred, the operation type is recorded. For instance, for a write operation, the operation type is recorded as OP_WRITE; for a memory mapping operation, the operation type is recorded as OP_MMAP_WRITE; for a truncation operation, the operation type is recorded as OP_TRUNCATE; and for a file space allocation operation, the operation type is recorded as OP_FALLOCATE.

[0147] As an example, in confirmed mode (confirmed=true), protective actions may include, but are not limited to, logging confirmation logs, notifying confirmation events, terminating processes, isolating and restricting processes, and logging snapshots, at least one of these actions.

[0148] As an example, the confirmation log may include: process details, including but not limited to at least one of PID, TGID, user identifier (UID), process name (comm), executable file path, parent process PID, and process tree information; operation type information, including but not limited to at least one of operation type, operation parameters, and file operation timestamp; time series information, including but not limited to at least one of file open event, confirmation time of ransomware behavior, and time interval from file opening to confirmation time; and behavioral characteristic information, including but not limited to at least one of the following: number of files opened simultaneously, file access mode, write data entropy value, and historical behavior records of the process. For example, the operation type may include at least one of write, mmap, truncate, and fallocate; the operation parameters may include at least one of write size, mmap address range, and truncation length; the confirmation time of ransomware behavior may be the time when the file operation occurred; the file access mode may include random access or sequential access; and the write data entropy value, for example, if higher than a certain threshold, may be used to indicate that the data is encrypted. However, this disclosure is not limited to these, and arbitrary confirmation log content may be set based on user policies.

[0149] As an example, the steps of notifying a confirmation event may include: notifying the user space (such as a security program) of the confirmation event and sending a confirmation log, wherein the confirmation log may include complete process information and operation type, or may be the confirmation log described above.

[0150] As an example, the steps to terminate a process may include: terminating the current process and its child processes to prevent further file corruption and to record complete process information and call stack.

[0151] As an example, the steps of isolating and restricting a process may include: moving the current process into an isolated control group (cgroup), restricting the current process's use of resources (such as the use of central processing unit (CPU), memory and I / O resources), restricting the current process's access to the file system, and redirecting the current process's file operations to the isolated environment to prevent further file corruption.

[0152] As an example, the steps of recording a snapshot may include: saving a memory snapshot of the process (such as / proc / [pid] / mem), recording the process's system call sequence, collecting malicious code samples for analysis, and saving a snapshot of the file system state.

[0153] As an example, protective actions may also include file protection actions that protect real files.

[0154] Therefore, according to embodiments of this disclosure, based on the determination that an application is engaging in ransomware behavior, protective operations are performed, wherein the protective operations include at least one of the following operations: recording a confirmation log including process information, file operation types, and / or call stacks; sending a confirmation event confirming that the application is engaging in ransomware behavior to user space; terminating the current process of the application and its child processes; isolating the current process of the application and restricting the current process's resource usage, access permissions, and / or file operations; and recording a memory snapshot, file system state snapshot, system call sequence, and / or malicious code sample of the process.

[0155] The two-stage detection method according to embodiments of this disclosure can immediately identify and respond to ransomware attacks when the file content is modified, thereby improving the real-time performance of ransomware detection. In particular, by preparing in advance to deal with ransomware attacks through operation in alert mode, the real-time performance of detection is further improved and performance costs are saved.

[0156] If no event occurs that modifies the file content, or if it is determined that file operations do not include modifying the file content, in step S550, the opened anonymous file object is closed without being modified by the application. In other words, the application's modification operations on the anonymous file object are continuously monitored until the application closes the file.

[0157] In step S560, it is determined whether the system is in alert mode. For example, this is determined based on whether the alert status flag alert_sent is true. If it is determined that the system is not in alert mode (step S560 is no), step S590, described below, is executed.

[0158] When in alert mode, in step S570, exit alert mode and perform a de-alert operation. For example, based on the alert status flag alert_sent being true (alert mode has been triggered) and the confirmation status flag confirmed being false (ransomware not confirmed), it can be determined that only the file was opened but not modified. Alert mode can be exited by setting the alert status flag alert_sent to false.

[0159] As an example, a de-alert operation may include operations corresponding to an alert operation, such as, but not limited to, notifying user space of a de-alert event, canceling or clearing a process's flag as a suspicious process, and removing a process's frozen state. For example, a security program or protection program in user space may be notified of a de-alert event, cancel or clear a process's flag as a suspicious process, or remove a process's frozen state.

[0160] Based on the exit alert mode, in step S580, false alarm information is recorded for detection and optimization. For example, the reputation score of the current process can be updated based on the recorded false alarm information.

[0161] As an example, the alert log in alert mode can be logged as false alarm information. However, this disclosure is not limited to this and other false alarm information that can be used to detect optimizations can also be logged.

[0162] In step S590, it is determined that no ransomware extortion has occurred, and the normal execution of the process is resumed.

[0163] The above steps are merely illustrative examples. According to embodiments of this disclosure, one or more steps may be omitted, one or more steps may be performed in a different order, or one or more other steps may be added.

[0164] According to embodiments of this disclosure, at least one operation of the ransomware detection method described above can be implemented by modifying the kernel source code, hijacking system calls of kernel modules, using an extended Berkeley Packet Filter (eBPF), a kernel probe (kprobe), and / or a filesystem in userspace (FUSE).

[0165] As an example, directly modifying the kernel source code can achieve directory traversal hijacking and virtual directory entry injection by modifying the function getdents64 in fs / readdir.c and injecting a virtual decoy directory entry after iterate_dir, and / or file access control can be implemented through the Linux Security Module (LSM). This method has superior performance, complete functionality, and can implement complex logic, making it suitable for customized systems.

[0166] As an example, an eBPF program can achieve directory traversal hijacking and virtual directory entry injection by mounting to the getdents64 system call exit point (tracepoint) and modifying the user-space buffer before returning. eBPF programs have the advantage of dynamic loading and unloading, and security is ensured by a verifier, requiring no modification to the kernel source code, making them suitable for production environments.

[0167] As an example, hijacking kernel module system calls can achieve directory traversal hijacking and virtual directory entry injection by replacing the function pointer of the function getdents64 in the system call table. Kernel module system call hijacking can be dynamically loaded and unloaded, accessing more kernel application programming interfaces (APIs) without modifying the kernel source code, making it suitable for research and testing environments.

[0168] As an example, the kprobe probe can use the return probe kretprobe to insert hooks before the function getdents64 returns to modify the return value and buffer. Kprobe has relatively high security, can be dynamically loaded and unloaded, and does not require modification of the kernel source code, making it suitable for production environments.

[0169] As an example, FUSE can implement a ransomware detection method according to embodiments of this disclosure in user space. FUSE has the advantage of being simple to implement and requires no kernel programming.

[0170] The ransomware detection method according to various embodiments of this disclosure can return a list of directory entries, including virtual directory entries, to an application in response to a system call for an application to retrieve directory entries. When the application opens a virtual decoy file based on a virtual directory entry, an anonymous file object mapped to the virtual decoy file is created instead of an actual file. Furthermore, if the file flag of the anonymous file object meets specific conditions, the method can further determine whether the application has ransomware behavior based on the application's file access operations on the anonymous file object, thereby achieving accurate and real-time ransomware detection with zero disk overhead and / or low deployment costs.

[0171] Figure 6 This is a block diagram illustrating a ransomware detection device according to an embodiment of the present disclosure.

[0172] Reference Figure 6 The ransomware detection device 600 according to embodiments of the present disclosure may include: a directory entry acquisition unit 610, configured to return a list of directory entries of the target directory to the application in response to a first system call by an application to acquire directory entries of the target directory, wherein the list of directory entries includes virtual directory entries of a decoy file; a file opening unit 620, configured to create and return an anonymous file object mapped according to the decoy file in response to a second system call by an application to open the decoy file based on the virtual directory entries; and a detection unit 630, configured to determine whether the application has ransomware behavior based on the application's file access operation on the anonymous file object if the file flag of the anonymous file object satisfies a first condition, wherein the first condition includes the file flag indicating that the open mode requires write permission and / or the addition of a write flag bit.

[0173] In other words, the ransomware detection device 600 can be configured to perform at least the ransomware detection method according to the embodiments of the present disclosure as described above, wherein the directory entry acquisition unit 610 can be configured to perform at least step S100, the file opening unit 620 can be configured to perform at least step S200, and the detection unit 630 can be configured to perform at least step S300. Therefore, the details of the ransomware detection method described above can be applied to the ransomware detection device 600, and some details will not be described again here.

[0174] According to embodiments of this disclosure, the detection unit 630 can be configured to determine whether an application has ransomware behavior based on the application's file access operations on the anonymous file object when the file flag of the anonymous file object meets a first condition: when the file flag meets the first condition, monitor the application's file access operations on the anonymous file object; when the monitored file access operations meet a second condition, determine that the application has ransomware behavior.

[0175] According to embodiments of this disclosure, the second condition may include at least one of the following: an application performing a write operation, a memory mapping operation, a truncation operation, or a file space allocation operation on an anonymous file object.

[0176] According to embodiments of this disclosure, a virtual directory entry can be generated through the following steps: determining the decoy file characteristics of a virtual decoy file, the decoy file characteristics including the decoy file name; generating a virtual directory entry based on the decoy file characteristics, wherein the decoy file name is a file name that conforms to the characteristics of a real file through encryption, and the file name decrypted from the decoy file name is used to identify the file as a virtual decoy file when the file is opened.

[0177] According to embodiments of this disclosure, the decoy file features may further include at least one of the following: file size determined based on the size distribution of real files in the real directory entries included in the directory entry list; file type determined based on the type of real files; and file injection density determined based on at least one of the importance of real directory entries and the number of real files.

[0178] According to embodiments of this disclosure, the ransomware detection device 600 may further include an inode marking unit, which may be configured to mark the inode number of a decoy file, wherein the marked inode number is used to indicate that the file is a decoy file when the application opens the file.

[0179] According to embodiments of this disclosure, the ransomware detection device 600 may further include a file operation execution unit, which may be configured to: return random data or simulated data based on a real file to the application when the application performs a read operation on the anonymous file object, and / or clean up the resources of the anonymous file object when the application performs a file close operation on the anonymous file object.

[0180] According to embodiments of this disclosure, the ransomware detection device 600 may further include a warning unit, which may be configured to: perform a warning operation when the file flag of an anonymous file object satisfies a first condition, wherein the warning operation may include at least one of the following operations: recording a warning log including process information, file open information and / or flag change information; sending a warning event indicating that the application has a risk of ransomware behavior to user space; marking the current process of the application as a suspicious process; freezing the current process until it is unfrozen; and recording a directory snapshot.

[0181] According to embodiments of this disclosure, the ransomware detection device 600 may further include a protection unit, which may be configured to perform protection operations when it is determined that an application is engaging in ransomware behavior. The protection operations may include at least one of the following: recording a confirmation log including process information, file operation types, and / or call stacks; sending a confirmation event confirming that the application is engaging in ransomware behavior to user space; terminating the application's current process and its child processes; isolating the current process and restricting its resource usage, access permissions, and / or file operations; and recording a memory snapshot, file system state snapshot, system call sequence, and / or malicious code sample of the process.

[0182] According to embodiments of this disclosure, at least one operation in the ransomware detection device 600 is implemented by modifying kernel source code, hijacking system calls of kernel modules, extending Berkeley packet filters, kernel probes, and / or userspace file systems.

[0183] The specific methods by which each unit in the ransomware detection device 600 performs its operations have been described in detail in the embodiments of the relevant methods, and will not be elaborated here.

[0184] Furthermore, it should be understood that the various units in the ransomware detection apparatus 600 according to exemplary embodiments of this disclosure may be implemented as hardware components and / or software components. Those skilled in the art, based on the processes performed by the defined various units, may implement the various units, for example, using a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).

[0185] Furthermore, according to embodiments of this disclosure, an electronic device is also provided.

[0186] An electronic device according to an embodiment of the present disclosure may include at least one processor and at least one memory storing computer-executable instructions, wherein the computer-executable instructions, when executed by at least one processor, cause at least one processor to perform the ransomware detection method according to an embodiment of the present disclosure as described above.

[0187] As an example, an electronic device can be a personal computer (PC), a tablet device, a personal digital assistant, a smartphone, or other device capable of executing the aforementioned set of instructions. Here, the electronic device is not necessarily a single electronic device, but can be any collection of devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. The electronic device can also be part of an integrated control system or system manager, or can be configured to interconnect locally or remotely (e.g., via wireless transmission) through an interface.

[0188] In electronic devices, at least one processor may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, and / or a microprocessor. By way of example and not limitation, at least one processor may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, and / or network processors, etc.

[0189] At least one processor can execute instructions or code stored in at least one memory, wherein the at least one memory can also store data. Instructions and data can also be sent and received over a network via a network interface device, wherein the network interface device can employ any known transport protocol.

[0190] At least one memory may be integrated with at least one processor, for example, by arranging RAM or flash memory within an integrated circuit microprocessor. Alternatively, at least one memory may comprise a separate device, such as an external disk drive, storage array, or other storage device that can be used by any database system. At least one memory and at least one processor may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., enabling at least one processor to read files stored in at least one memory.

[0191] In addition, electronic devices may include video displays (such as liquid crystal displays) and user interaction interfaces (such as keyboards, mice, touch input devices, etc.). All components of the electronic device may be interconnected via buses and / or networks.

[0192] According to embodiments of the present disclosure, a computer-readable storage medium is also provided, wherein instructions in the computer-readable storage medium, when executed by at least one processor, cause at least one processor to perform the ransomware detection method as described above.

[0193] As examples, computer-readable storage media may include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, as an example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0194] According to exemplary embodiments of the present disclosure, a computer program product (or computer software) including computer-executable instructions is also provided, wherein the computer-executable instructions, when executed by at least one processor, implement the ransomware detection method as described above.

[0195] Furthermore, according to embodiments of this disclosure, the memory may be the system's main storage device or main memory, and may include volatile memory for temporarily storing computational data in the CPU, as well as data exchanged with external non-volatile memory such as a hard disk. However, embodiments of this disclosure are not limited thereto, and the memory may optionally or additionally include non-volatile memory.

[0196] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0197] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the claims.

Claims

1. A ransomware detection method, characterized by, include: In response to a first system call from an application to retrieve directory entries of a target directory, a list of directory entries for the target directory is returned to the application, wherein the list of directory entries includes virtual directory entries for the decoy file; In response to a second system call by the application to open the virtual decoy file based on the virtual directory entry, an anonymous file object mapped according to the virtual decoy file is created and returned; If the file identifier of the anonymous file object satisfies the first condition, based on the application's file access operations on the anonymous file object, it is determined whether the application is engaging in ransomware behavior. The first condition includes the file flag indicating that the open mode requires write permission and / or the addition of a write flag.

2. The ransomware detection method of claim 1, wherein, If the file identifier of the anonymous file object satisfies the first condition, the steps for determining whether the application has engaged in ransomware behavior based on the application's file access operations on the anonymous file object include: If the file flag satisfies the first condition, monitor the application's file access operation on the anonymous file object; If the monitored file access operations meet the second condition, it is determined that the application is engaging in ransomware behavior. The second condition includes the application performing at least one of the following operations on the anonymous file object: a write operation, a memory mapping operation, a truncation operation, and a file space allocation operation.

3. The ransomware detection method of claim 1, wherein, The virtual directory entry is generated through the following steps: Determine the decoy file characteristics of the virtual decoy file, wherein the decoy file characteristics include the decoy file name; The virtual directory entry is generated based on the characteristics of the decoy file. The decoy file name is a file name generated by encryption that conforms to the characteristics of a real file, and the file name decrypted from the decoy file name is used to identify the file as the virtual decoy file when the file is opened.

4. The ransomware detection method according to claim 3, characterized in that, The decoy file features also include at least one of the following: The file size is determined based on the size distribution of real files in the real directory entries included in the directory entry list; The file type is determined based on the type of the actual file; The file injection density is determined based on at least one of the importance of the real directory entries and the number of real files.

5. The ransomware detection method according to claim 1, characterized in that, The ransomware detection method further includes: The inode number of the virtual decoy file is marked, wherein the marked inode number is used to indicate that the file is the virtual decoy file when the application opens the file.

6. The ransomware detection method according to claim 1, characterized in that, The ransomware detection method further includes: When the application performs a read operation on the anonymous file object, return random data or simulated data based on the real file to the application, and / or When the application performs a file close operation on the anonymous file object, it cleans up the resources of the anonymous file object.

7. The ransomware detection method according to claim 1, characterized in that, The ransomware detection method also includes: If the file flag of the anonymous file object satisfies a first condition, a vigilance operation is performed, wherein the vigilance operation includes at least one of the following operations: Record alert logs that include process information, file open information, and / or flag change information; Send a warning event to user space indicating that the application is at risk of ransomware behavior; Mark the current process of the application as a suspicious process; Freeze the current process until it is unfrozen; Record a snapshot of the directory.

8. The ransomware detection method according to claim 1, characterized in that, The ransomware detection method also includes: If it is determined that the application is engaging in ransomware behavior, protective measures are performed, wherein the protective measures include at least one of the following: The log includes confirmation information such as process information, file operation types, and / or call stack. Send a confirmation event to user space confirming that the application is engaging in ransomware behavior; Terminate the current process of the application and its child processes; Isolate the current process and restrict its resource usage, access permissions, and / or file operations; Record process memory snapshots, file system state snapshots, system call sequences, and / or malicious code samples.

9. The ransomware detection method according to claim 1, characterized in that, At least one step in the ransomware detection method is implemented by modifying the kernel source code, hijacking system calls of kernel modules, extending the Berkeley package filter, kernel probes, and / or userspace file systems.

10. A ransomware detection device, characterized in that, include: The directory entry acquisition unit is configured to return a list of directory entries of the target directory to the application in response to a first system call from an application to acquire directory entries of the target directory, wherein the list of directory entries includes virtual directory entries of the virtual decoy file; The file opening unit is configured to create and return an anonymous file object mapped according to the virtual decoy file in response to a second system call by the application to open the virtual decoy file based on the virtual directory entry. The detection unit is configured to determine whether the application is engaging in ransomware behavior based on the application's file access operations on the anonymous file object, provided that the file flag of the anonymous file object satisfies a first condition. The first condition includes the file flag indicating that the open mode requires write permission and / or the addition of a write flag.

11. An electronic device, characterized in that, include: At least one processor; At least one memory that stores computer-executable instructions. Wherein, when the computer-executable instructions are executed by the at least one processor, they cause the at least one processor to execute the ransomware detection method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the at least one processor to perform the ransomware detection method as described in any one of claims 1 to 9.

13. A computer program product comprising computer-executable instructions, wherein, The computer-executable instructions, when executed by at least one processor, implement the ransomware detection method as described in any one of claims 1 to 9.

Images