A user file behavior analysis system, method

Abstract

The application relates to a user file behavior analysis system and method in the field of information security technology, which comprises a bottom file access capturing unit, a high-level user operation semantic capturing unit, an event communication and queue unit and a strategy identifying unit. The bottom file access capturing unit is used for capturing real file access events occurring in a file system. The high-level user operation semantic capturing unit is used for injecting a hook into a controlled application and capturing operation intention events of a user. The event communication and queue unit is used for sending the operation intention events from a kernel state to a user state and receiving real file access events sent by the user state. The strategy identifying unit is used for judging a final user behavior type by comparing the operation intention events and the real file access events, thereby solving the problem of incomplete file behavior monitoring caused by the fact that existing user file operation behaviors are easily recognized and intercepted by security software.

Description

Technical Field

[0001] This invention relates to the field of information security technology, specifically to a user file behavior analysis system and method. Background Technology

[0002] With the increasing frequency of endpoint data breaches, enterprises have an increasingly urgent need for comprehensive and accurate analysis of user file operation behavior. Current user behavior analysis methods, particularly user-mode API hooks, can only intercept some system API calls, such as CreateFileW, WriteFile, and MoveFile. However, some file operations may be completed through kernel-mode interfaces (such as NtCreateFile and NtWriteFile) or memory-mapped files, which do not trigger user-mode APIs and therefore cannot be monitored. Furthermore, file operations may involve multi-step chains, such as downloads and moves that involve cross-process or cross-volume operations; single-point hooks cannot fully trace the entire operation chain.

[0003] Meanwhile, since the Windows kernel Minifilter can only obtain file system-level information such as file path, IRP request and process ID, but cannot obtain user-space network stack data such as URL, HTTP header, download protocol or browser download process, it cannot determine whether a file is generated by network download based solely on file system filtering, resulting in insufficient file source identification capability.

[0004] Furthermore, conventional remote thread injection methods (including CreateRemoteThread, NtCreateThreadEx, etc.) and APC (Asynchronous Procedure Call) injection methods all require writing external code addresses, modifying thread execution paths, or forcibly creating new execution threads within the target process while it is running. These operations directly alter the process's runtime environment, including its memory structure, thread stack, instruction pointers, and other critical runtime states, thus limiting the effectiveness of process injection methods.

[0005] Because these behaviors are highly similar to the operating methods of malware (such as process hijacking, code injection, and remote thread launching of malicious code), their operational characteristics will be regarded as abnormal behavior by security software, anti-malware tools, and system protection mechanisms, thereby triggering interception or causing the target process to execute abnormally. At the same time, this type of injection method depends on the runtime memory state. If the target process is performing a critical task or has a thread synchronization sensitive area, the injection may cause crashes, abnormal exits, or injection failures, resulting in poor stability.

[0006] Therefore, this type of runtime active injection mechanism inherently suffers from problems such as being easily identified and blocked by security software and unstable compatibility. Summary of the Invention

[0007] This invention addresses the shortcomings of existing technologies by providing a user file behavior analysis system and method, which solves the problem of incomplete file behavior monitoring caused by the ease with which existing user file operation behaviors can be identified and blocked by security software.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0009] A user file behavior analysis system includes a low-level file access capture unit, a high-level user operation semantic capture unit, an event communication and queue unit, and a policy identification unit;

[0010] The underlying file access capture unit is used to capture real file access events that occur in the file system;

[0011] The high-level user operation semantic capture unit is used to inject hooks into the controlled application and capture user operation intent events.

[0012] The event communication and queue unit is used to send the operation intention event from the kernel space to the user space, and to receive the actual file access event sent by the user space.

[0013] The policy identification unit is used to perform multi-source comparison of the operation intent event and the actual file access event to determine the type of the end user behavior.

[0014] Optionally, capturing actual file access events occurring in the file system includes the following steps:

[0015] Acquire functional data one, and perform functional event identification based on the functional data one;

[0016] The identified functional events are labeled to obtain real file access identifiers, wherein the real file access identifiers are one or more combinations thereof.

[0017] Optionally, capturing user action intent events includes the following steps:

[0018] Acquire functional data two, and perform functional event identification based on the functional data two;

[0019] The identified functional events are labeled to obtain operation intent labels, wherein the operation intent labels are single labels.

[0020] Optionally, the policy identification unit performs multi-source comparison of the operation intent event and the actual file access event to determine the type of end-user behavior, including the following steps:

[0021] The type of end-user behavior is determined based on process identifier, thread identifier, file path, timestamp, event sequence, and operation characteristics.

[0022] Optionally, the type of end-user behavior can be determined based on process identifier, thread identifier, file path, timestamp, event sequence, and operation characteristics, including:

[0023] When the operation intent flag marked by the high-level user operation semantic capture unit is INJ_CREATE, the target file is determined to be a newly created file;

[0024] When the operation intent flag marked by the high-level user operation semantic capture unit is INJ_OPEN, or the real file access flag marked by the low-level file access capture unit includes DEV_READ or DEV_CREATE_SECTION, the target file is determined to be an open file.

[0025] When the underlying file access capture unit marks the real file access identifier including DEV_WRITE, the target file is determined to be a modified file;

[0026] When the operation intent marked by the high-level user operation semantic capture unit is INJ_COPY, and the source file in the event exists, the target file is determined to be a copied file;

[0027] When the operation intent flagged by the high-level user operation semantic capture unit is INJ_MOVE; and the source file and target file in the event are on the same drive, it is determined to be a file renaming.

[0028] When the operation intent flag marked by the high-level user operation semantic capture unit is INJ_DELETE, the target file is determined to be a file to be deleted.

[0029] Optional, also includes:

[0030] When the operation intent flag marked by the high-level user operation semantic capture unit is INJ_COPY, and the source file in the event does not exist, the target file is determined to be a moved file;

[0031] When the operation intent marked by the high-level user operation semantic capture unit is INJ_MOVE, and the source file and target file in the event are on different drives, then the target file is determined to be a moved file.

[0032] Optional, also includes:

[0033] When the target files are the same object, the operation intent is marked as INJ_UPLOAD, and the actual file access identifier contains DEV_READ. If the complete read length is greater than or equal to the file size, it is determined to be an uploaded file.

[0034] If the target files are the same object, the operation intent identifier is INJ_DOWN, and the actual file access identifier contains INJ_WRITE, then it is determined to be a file download.

[0035] Optionally, when a user creates a new file in File Explorer or an application, the target process performs Minifilter capture on the path, passive injection capture of controlled whitelisted processes, data communication, and policy identification.

[0036] A user file behavior analysis method, applied to the user file behavior analysis system as described above, includes the following steps:

[0037] Capture real file access events that occur in the file system;

[0038] Inject hooks into controlled applications and capture user action intent events;

[0039] Send the operation intent event from kernel mode to user mode, and receive the actual file access event sent by user mode;

[0040] The type of end-user behavior is determined by multi-source comparison of the operation intent event and the actual file access event.

[0041] A computer storage medium storing computer program instructions; when executed by a processor, the computer program instructions implement the user file behavior analysis method described above.

[0042] Compared with the prior art, the technical solution provided by this invention has the following advantages:

[0043] This invention constructs a two-layer collaborative file behavior monitoring system between the kernel Minifilter driver and the passive injection module of the controlled whitelist process. This system achieves accurate identification of all types of file operations, including creating, opening, modifying, copying, moving, renaming, deleting, uploading, and downloading. It overcomes the limitation of traditional Minifilters in recognizing network download behavior, enabling accurate determination of upload and download actions. Compared with existing technologies, this invention significantly improves the comprehensiveness, accuracy, and reliability of file behavior identification, effectively solving problems such as the system's inability to determine the true source of a file from a single dimension, ambiguous operation semantics, and missing behavior chains. It provides high-precision and robust underlying support for file security auditing, data leakage prevention, trusted computing, and behavioral forensics. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is a diagram of a user file behavior analysis system architecture proposed in Embodiment 1. Detailed Implementation

[0046] The present invention will be further described in detail below with reference to the embodiments. The following embodiments are explanations of the present invention, but the present invention is not limited to the following embodiments.

[0047] Example 1

[0048] like Figure 1 As shown, a user file behavior analysis system includes a low-level file access capture unit, a high-level user operation semantic capture unit, an event communication and queuing unit, and a policy identification unit. The low-level file access capture unit (driver layer Minifilter) is used to capture real file access events occurring in the file system, including file creation, reading, writing, attribute changes, and access termination. All events are accompanied by process identifiers, thread identifiers, file paths, and timestamps, forming a low-level event stream.

[0049] The high-level user action semantic capture unit (kernel layer) injects hooks into controlled applications such as editors, browsers, and file explorers to capture user action intent events, such as creating, opening, copying, moving, renaming, downloading, and uploading. The captured action intent events include the application initiating the action, the target path, the action type, and the action source (e.g., URL, UI callback).

[0050] The event communication and queuing unit sends kernel-mode events to user-mode via IOCTL and receives user-mode events via LPC / NtConnectPort. The module employs a queuing mechanism to ensure that events are transmitted in chronological order without loss, providing a complete data link for subsequent behavior recognition.

[0051] The policy identification unit (multi-source event association) performs multi-source comparison on events from kernel space and user space, and determines the final user behavior type based on process identifier, file path, timestamp, and operation sequence association. A cross-validation mechanism avoids false positives, mapping low-level events to unified user behaviors (create, open, modify, copy, move, rename, delete, upload, download).

[0052] Specifically, the underlying file access capture unit logic is shown in Table 1. Through functional events, when file access ends, it captures information including process identifier, thread identifier, target file path, source file path, file size, timestamp, and file type. It also adds related identifiers such as DEV_CREATE, DEV_CREATE_SECTION, DEV_OPEN, DEV_READ, DEV_WRITE, DEV_RENAME, DEV_MOVE, DEV_COPY, and DEV_DELETE. (Note: these identifiers are one or more combinations).

[0053] Table 1

[0054]

[0055] On the other hand, the underlying capture process is as follows: when a file access start event is detected, the process, thread, path, and timestamp are recorded, and the event is placed in a queue; when a file read event is detected, the read length and offset are recorded, and it is determined whether the read is complete; when a file write event is detected, the write length and offset are recorded, and it is determined whether the write mode is continuous; when a file attribute change event is detected, if a deletion flag is included, the file is marked to enter the deletion process; when a file access end event is detected, the current event chain is closed, and preparation is made to associate it with user-mode events.

[0056] The logic of the high-level user operation semantic capture unit is shown in Table 2. Through functional events, corresponding events will record the above information, including process identifier, thread identifier, target file path, source file path, file size, timestamp, file type, etc.; and also add related identifiers such as INJ_CREATE, INJ_OPEN, INJ_READ, INJ_WRITE, INJ_RENAME, INJ_MOVE, INJ_COPY, INJ_DELETE, INJ_DOWN, INJ_UPLOAD, etc. (Note: only one identifier can be added here).

[0057] Table 2

[0058]

[0059] For the event association and policy recognition logic, the event association and policy recognition unit comprehensively analyzes multi-source data from the driver layer (low-level events) and the kernel layer (user intent events), and completes the accurate identification of the user's actual behavior based on process identifier, thread identifier, file path, timestamp, event sequence and operation characteristics. The timestamp can record the time when the event is triggered. When a user operates on a file on the computer, the required interval is more than 500ms. Therefore, after the target file is confirmed to have been acted upon, useless information can be filtered out.

[0060] The logic for behavior recognition is as follows:

[0061] When the operation intent flag of the high-level user operation semantic capture unit is INJ_CREATE, the target file is determined to be a newly created file;

[0062] When the operation intent flag of the high-level user operation semantic capture unit is INJ_OPEN, or the real file access flag of the low-level file access capture unit includes DEV_READ or DEV_CREATE_SECTION, the target file is determined to be an open file.

[0063] When the underlying file access capture unit marks the actual file access identifier as DEV_WRITE, the target file is determined to be a modified file;

[0064] When the operation intent flag of the high-level user operation semantic capture unit is INJ_COPY, and the source file in the event exists, the target file is determined to be a copied file;

[0065] When the operation intent flagged by the high-level user operation semantic capture unit is INJ_MOVE, and the source and target files in the event are on the same drive, it is determined to be a file renaming.

[0066] When the operation intent flag marked by the high-level user operation semantic capture unit is INJ_DELETE, the target file is determined to be a file to be deleted.

[0067] When the operation intent flag of the high-level user operation semantic capture unit is INJ_COPY, and the source file in the event does not exist, the target file is determined to be a moved file;

[0068] When the operation intent flag of the high-level user operation semantic capture unit is INJ_MOVE, and the source file and target file in the event are on different drives, the target file is determined to be a moved file;

[0069] When the target files are the same object, the operation intent is marked as INJ_UPLOAD, and the actual file access identifier contains DEV_READ. If the complete read length is greater than or equal to the file size, it is determined to be an uploaded file.

[0070] If the target files are the same object, the operation intent identifier is INJ_DOWN, and the actual file access identifier contains INJ_WRITE, then it is determined to be a file download.

[0071] Furthermore, when an unidentified behavior occurs—that is, when the user layer receives various file identifiers in the driver layer event, but the kernel layer does not have the target file—the process PID and driver layer event identifier characteristics are recorded. This information is then provided to the user for auditing. After auditing, any behavior based on these characteristics can be identified as such, or the behavior can be determined by a built-in policy. Alternatively, a model can be added to determine these characteristics. For example, a built-in policy could be used for the wps.exe process (derived from the PID), where the driver event identifier characteristics are ordered such that DEV_CREATE takes precedence over DEV_RENAME, thus identifying the behavior as modification.

[0072] On the other hand, when new behavior is identified, that is, when the user executes "right-click to create a new file (e.g., D:\1\1.txt)" in the resource manager or application, the target process will perform a lot of operations on the path. The system's identification mechanism includes: (1) Minifilter capture, collecting process ID, thread ID, target file path, buffer length, operation type (Create, Read...) and timestamp in the callbacks IRP_MJ_CREATE, IRP_MJ_READ, and IRP_MJ_CLEANUP; (2) Passive injection capture of controlled whitelist processes, injecting hooks into target processes such as Notepad, intercepting NtCreateFile, judging whether it is a real new creation through flags such as FILE_CREATE, FILE_OPEN_IF, and FILE_OVERWRITE_IF, and extracting additional information such as file path and file size; (3) Data communication, due to the large amount of data, the driver layer and application layer transmit through IOCTL, and the kernel layer transmits through NtConnectPort. In communication with user space, a queue mechanism is used to ensure that data is not lost; (4) Strategy identification, the comprehensive judgment conditions include the target process being an editing process such as notepad, the driver layer event containing the Create identifier, the user space hook capturing the "creation class" identifier of NtCreateFile, and both having related file behavior. After the conditions are met, the behavior is identified as file creation behavior.

[0073] For file opening behavior recognition, since Notepad generates a typical sequence when opening D:\1\1.txt: create, read, create, read...close, we first perform Minifilter capture to capture events such as Create, Read, and Cleanup, as well as the file path; then we perform process injection capture, injecting hooks to capture NtCreateFile and NtReadFile, and extracting the complete read behavior (the full file length read); finally, we perform policy recognition, judging by whether the process is Notepad (non-system behavior), whether the Create behavior matches the complete read behavior, and whether there is a match between user mode and kernel mode. If these conditions are met, it is recognized as a file opening behavior.

[0074] For modification behavior identification, when modifying a file, repeated create / read operations will occur, but write operations will also be included. Therefore, the key points for identification are whether the Minifilter captures IRP_MJ_WRITE, whether the injection layer captures NtWriteFile, and whether the length and offset of the written data are identified. Based on this, the identification strategy is to determine whether the create + write flags are present at the same time, whether there are write operations in both kernel mode and user mode, and whether the file content is overwritten or appended. If so, it is determined to be a file modification behavior.

[0075] For copy, move, and rename identification, since the system injects the following APIs into the Explorer process: CopyFileW, CopyFile2, CopyFileExW, etc., which are related to copying / moving, what is captured is the source file path, the target file path, and changes in the size of the source / target files. Therefore, the identification strategy is to judge the behavioral conditions: Copy: Is there a copy flag, and the source file still exists? Move: Is there a copy flag, and the source file does not exist (or has been deleted from its original location)? Rename: Is there a move flag, and the source and target are in the same directory?

[0076] For the identification of deletion behavior, when a deletion operation (such as D:\1\1.txt) is performed, the system will capture: (1) Minifilter layer: IRP_MJ_SET_INFORMATION (where FileDispositionInformation means delete), IRP_MJ_CLEANUP; (2) Explorer injection: NtOpenFile parses the files starting with $R (actual files in the recycle bin) and files starting with $I (information files) corresponding to the deleted file. Therefore, the identification strategy is to determine whether the Minifilter layer detects the deletion mark and whether the Explorer injection layer parses the $R and $I files, thereby determining whether the file is a deletion behavior.

[0077] For the identification of upload behavior, when a file (such as D:\1\1.txt) is uploaded by DingTalk or QQ, the following will occur: (1) the Minifilter layer captures Create, Read, and Cleanup, with particular attention to the complete file reading; (2) the passive injection capture of the controlled whitelist process, such as injecting events in qq.exe and dingtalk.exe: paste callback, open file dialog callback, file selection event (OpenWindows). Therefore, the identification strategy is to determine that the upload must meet the following conditions: the driver layer recognizes the complete read behavior, the user mode detects UI events such as paste / open windows, and both point to the same file. Once these conditions are met, it is identified as a file upload behavior.

[0078] For the identification of download behavior, when a user performs a file download operation in a browser or application (e.g., saves a network file to local D:\1\1.txt), Minifilter layer behavior capture will occur. During the file download process, the browser or application will execute the following typical sequence on the target file path: create, write, write, write, ... cleanup; (1) The Minifilter driver captures events at the following callback points: IRP_MJ_CREATE, IRP_MJ_WRITE, IRP_MJ_SET_INFORMATION (may set the final file name), IRP_MJ_CLEANUP, and records the following information: process ID, thread ID, download target file path, write offset, write length (identifies continuous write), operation type, timestamp; (2) Passive injection capture of controlled whitelist processes, injecting hooks in browsers (such as chrome.exe, msedge.exe) or applications (such as qq.exe, dingtalk.exe), monitoring URLDownloadToFileW (IE / system component), WinINet API (InternetReadFile, HttpQueryInfo) User-space hooks can extract the following information: source URL, target save path, file size (calculated from HTTP headers or chunks), and download-triggered UI behavior (e.g., "Save to..." window). This information is used to confirm that the file is generated from the network, rather than being copied or written locally.

[0079] Therefore, when identifying a download, the following conditions must be met: the driver layer recognizes continuous write behavior, the file paths of both are consistent (final save path), the timestamps match, and the link sequence is reasonable. Once these conditions are met, the download behavior is identified as a file download.

[0080] This invention constructs a two-layer collaborative file behavior monitoring system between the kernel Minifilter driver and the passive injection module of the controlled whitelisted processes, achieving accurate identification of all types of file operations, including creating, opening, modifying, copying, moving, renaming, deleting, uploading, and downloading. The system captures key events such as IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_SET_INFORMATION, and IRP_MJ_CLEANUP in real time at the kernel level, obtaining low-level behavioral characteristics such as process ID, thread ID, target path, write offset, length, and timestamp. Simultaneously, in user space, hooks are injected into controlled processes such as Notepad, Explorer, browsers (Chrome / Edge / IE), QQ, and DingTalk to intercept NtCreateFile, NtReadFile, NtWriteFile, CopyFile, URLDownloadToFile, WinINet / URLMonAPI, and UI events such as upload, paste, and file selection, extracting auxiliary information such as file path, source URL, file size, and dialog context. By performing time correlation, path consistency comparison, and operation semantic matching between kernel-mode and user-mode behaviors, this invention can accurately distinguish similar behaviors such as creating, opening, modifying, copying, moving, renaming, and deleting. It also overcomes the limitation of traditional Minifilters in recognizing network download behavior, achieving accurate determination of upload and download actions. Compared with existing technologies, this invention significantly improves the comprehensiveness, accuracy, and reliability of file behavior recognition, effectively solving problems such as the system's inability to determine the true source of a file from a single dimension, ambiguous operation semantics, and missing behavior chains. It provides high-precision and robust underlying support for file security auditing, data leakage prevention, trusted computing, and behavioral forensics.

[0081] Example 2

[0082] A user file behavior analysis method includes the following steps: capturing real file access events occurring in the file system; injecting hooks into a controlled application and capturing user operation intent events; sending the operation intent events from the kernel space to the user space, and receiving real file access events sent by the user space; and performing multi-source comparison of the operation intent events and real file access events to determine the final user behavior type.

[0083] Since the user file behavior analysis method in this embodiment is applied to the user file behavior analysis system shown in Embodiment 1, and the specific analysis method has been disclosed in Embodiment 1, it will not be repeated in this embodiment.

[0084] A computer storage medium storing computer program instructions; when the computer program instructions are executed by a processor, they implement the user file behavior analysis method as described in Embodiment 1.

[0085] More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wire segments, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0086] In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless segments, wire segments, optical cables, RF, etc., or any suitable combination thereof.

[0087] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules, units, or units is merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units, modules, or components may be combined or integrated into another device, or some features may be ignored or not executed.

[0088] The units may or may not be physically separate. The components shown as units can be one or more physical units, meaning they can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0089] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0090] In particular, according to embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit (CPU), it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof.

[0091] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0092] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions within the technical scope disclosed in the present invention should be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0093] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any form or substance. It should be noted that those skilled in the art can make various improvements and additions without departing from the method of the present invention, and these improvements and additions should also be considered within the scope of protection of the present invention. Any modifications, alterations, and equivalent changes made by those skilled in the art based on the above-disclosed technical content without departing from the spirit and scope of the present invention are equivalent embodiments of the present invention. Furthermore, any modifications, alterations, and evolutions made to the above embodiments based on the essential technology of the present invention still fall within the scope of the technical solution of the present invention.

Claims

1. A user file behavior analysis system, characterized in that, It includes a low-level file access capture unit, a high-level user operation semantic capture unit, an event communication and queue unit, and a policy identification unit; The underlying file access capture unit is used to capture real file access events that occur in the file system; The high-level user operation semantic capture unit is used to inject hooks into the controlled application and capture user operation intent events. The event communication and queue unit is used to send the operation intention event from the kernel space to the user space, and to receive the actual file access event sent by the user space. The policy identification unit is used to perform multi-source comparison of the operation intent event and the actual file access event to determine the type of the end user behavior.

2. The user file behavior analysis system according to claim 1, characterized in that, Capturing real file access events occurring in the file system includes the following steps: Acquire functional data one, and perform functional event identification based on the functional data one; The identified functional events are labeled to obtain real file access identifiers, wherein the real file access identifiers are one or more combinations thereof.

3. The user file behavior analysis system according to claim 1, characterized in that, Capturing user action intent events includes the following steps: Acquire functional data two, and perform functional event identification based on the functional data two; The identified functional events are labeled to obtain operation intent labels, wherein the operation intent labels are single labels.

4. A user file behavior analysis system according to any one of claims 1-3, characterized in that, The policy identification unit performs multi-source comparison of the operation intent event and the actual file access event to determine the type of the final user behavior, including the following steps: The type of end-user behavior is determined based on process identifier, thread identifier, file path, timestamp, event sequence, and operation characteristics.

5. A user file behavior analysis system according to claim 4, characterized in that, The type of end-user behavior is determined based on process identifier, thread identifier, file path, timestamp, event sequence, and operation characteristics, including: When the operation intent flag marked by the high-level user operation semantic capture unit is INJ_CREATE, the target file is determined to be a newly created file; When the operation intent flag marked by the high-level user operation semantic capture unit is INJ_OPEN, or the real file access flag marked by the low-level file access capture unit includes DEV_READ or DEV_CREATE_SECTION, the target file is determined to be an open file. When the underlying file access capture unit marks the real file access identifier including DEV_WRITE, the target file is determined to be a modified file; When the operation intent marked by the high-level user operation semantic capture unit is INJ_COPY, and the source file in the event exists, the target file is determined to be a copied file; When the operation intent flagged by the high-level user operation semantic capture unit is INJ_MOVE; and the source file and target file in the event are on the same drive, it is determined to be a file renaming. When the operation intent flag marked by the high-level user operation semantic capture unit is INJ_DELETE, the target file is determined to be a file to be deleted.

6. A user file behavior analysis system according to claim 5, characterized in that, Also includes: When the operation intent flag marked by the high-level user operation semantic capture unit is INJ_COPY, and the source file in the event does not exist, the target file is determined to be a moved file; When the operation intent marked by the high-level user operation semantic capture unit is INJ_MOVE, and the source file and target file in the event are on different drives, then the target file is determined to be a moved file.

7. A user file behavior analysis system according to claim 6, characterized in that, Also includes: When the target files are the same object, the operation intent is marked as INJ_UPLOAD, and the actual file access identifier contains DEV_READ. If the complete read length is greater than or equal to the file size, it is determined to be an uploaded file. If the target files are the same object, the operation intent identifier is INJ_DOWN, and the actual file access identifier contains INJ_WRITE, then it is determined to be a file download.

8. A user file behavior analysis system according to claim 1, characterized in that, When a user creates a new file in File Explorer or an application, the target process performs Minifilter capture on the path, passive injection capture of controlled whitelisted processes, data communication, and policy identification.

9. A method for analyzing user file behavior, characterized in that, The user file behavior analysis method, applied to the user file behavior analysis system as described in any one of claims 1-8, includes the following steps: Capture real file access events that occur in the file system; Inject hooks into controlled applications and capture user action intent events; Send the operation intent event from kernel mode to user mode, and receive the actual file access event sent by user mode; The type of end-user behavior is determined by multi-source comparison of the operation intent event and the actual file access event.

10. A computer storage medium, characterized in that, The computer storage medium stores computer program instructions; when the computer program instructions are executed by the processor, they implement the user file behavior analysis method as described in claim 9.

Images