Malicious file detection method and device, electronic equipment and storage medium

Abstract

The invention relates to a malicious file detection method and device, electronic equipment and a storage medium, and the method comprises the steps: reading fixed N-byte data at the head of a to-be-detected file, calculating a Hash value for the N-byte data through employing a Hash algorithm, and generating a head fingerprint, N being an integer greater than 1; a local cache is inquired according to the head fingerprints, the local cache is used for storing local head sample fingerprints and corresponding judgment results, and the judgment results are used for indicating malicious fingerprints or benign fingerprints; if the local cache does not hit the head fingerprint, a cloud cache is inquired according to the head fingerprint, and the cloud cache is used for storing a global head sample fingerprint and a corresponding judgment result; if the cloud cache does not hit the head fingerprint, a malicious rule set of the cloud is called to perform feature scanning on the to-be-detected file, and the malicious rule set is used for identifying whether the to-be-detected file has malicious properties or not. The malicious file detection efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a method, device, electronic device, and storage medium for detecting malicious files. Background Art

[0002] In the field of network security, the rapid and accurate identification of malicious samples is a key link in protecting computer systems and networks from attacks. In order to effectively defend against the increasingly complex and numerous malware threats, traditional detection methods such as signature-based scanning (such as the full scan of traditional antivirus engines) have shown certain effects in specific application scenarios. This method requires that the files to be detected be compared one by one with a huge signature database to determine whether there are known threats. However, with the increasing number of malware types, the size of the signature library has expanded rapidly, resulting in a sharp decline in query performance. Each detection requires traversing a large amount of signature data, resulting in inefficient query performance, which greatly slows down the speed of the entire detection process. Especially when faced with large-scale concurrent detection needs, this inefficiency problem is more prominent, making real-time protection difficult to achieve. Summary of the Invention

[0003] The present application provides a method, device, electronic device and storage medium for detecting malicious files to solve the problem of low efficiency in malicious file detection.

[0004] In a first aspect, the present application provides a method for detecting malicious files, the method comprising:

[0005] After reading the fixed N bytes of data at the head of the file to be detected, a hash value is calculated for the N bytes of data using a hash algorithm to generate a head fingerprint, where N is an integer greater than 1;

[0006] querying a local cache based on the head fingerprint, wherein the local cache is used to store local head sample fingerprints and corresponding determination results, and the determination results are used to indicate malicious fingerprints or benign fingerprints;

[0007] If the local cache does not hit the head fingerprint, query the cloud cache according to the head fingerprint, wherein the cloud cache is used to store the global head sample fingerprint and its corresponding determination result;

[0008] If the cloud cache does not hit the head fingerprint, the malicious rule set in the cloud is called to perform feature scanning on the file to be detected, wherein the malicious rule set is used to identify whether the file to be detected is malicious.

[0009] Optionally, after querying the local cache according to the head fingerprint, the method further includes:

[0010] If the local cache matches the head fingerprint, obtaining a first determination result in the local cache;

[0011] If the first determination result includes the local malicious fingerprint label, the sample threat level, and the malicious family information, the file to be detected is isolated, cleared, and an alarm is issued;

[0012] If the first determination result includes a benign fingerprint label, the file to be detected is released.

[0013] Optionally, after querying the cloud cache according to the head fingerprint, the method further includes:

[0014] If the cloud cache hits the head fingerprint, receiving a second determination result returned by the cloud, wherein the second determination result includes a global malicious fingerprint label, a sample threat level, and information about the malicious family to which it belongs, or the second determination result includes a global benign fingerprint label;

[0015] The head fingerprint and the second determination result are synchronously updated to the local cache according to a preset strategy, wherein the preset strategy is the cache validity period in the second determination result, or the local least recently used strategy or least frequently used strategy.

[0016] Optionally, if the cloud cache does not hit the head fingerprint, calling the malicious rule set in the cloud to perform feature scanning on the file to be detected includes:

[0017] If the cloud cache does not hit the head fingerprint, then call the local risk assessment strategy to evaluate the file to be detected;

[0018] If the assessment result is a risky file, mark the rule set call tag, and send the rule set call tag and the file to be detected to the cloud;

[0019] The cloud calls the tag according to the rule set to load the corresponding malicious rule set, and performs feature matching on the file to be detected according to the malicious rule set to generate a scanning result.

[0020] Optionally, after generating the scanning result, the method further includes:

[0021] Obtaining the scan results returned by the cloud;

[0022] If the scanning result determines that the file to be detected is a malicious sample, the head fingerprint of the malicious sample and the third judgment result are fed back to the back-end complete sample knowledge base, so that the back-end complete sample knowledge base evaluates the head fingerprint as a high-risk threat fingerprint or a new fingerprint, and then updates the head fingerprint to the cloud cache, wherein the third judgment result includes the malicious sample label and the family information to which it belongs.

[0023] Optionally, after obtaining the scanning result returned by the cloud, the method further includes:

[0024] If the scanning result indicates that the file to be detected is a benign sample, the file to be detected is marked as benign and released.

[0025] Optionally, after invoking a local risk assessment strategy to assess the file to be detected, the method further includes:

[0026] If the evaluation result is a non-risk file, the file to be detected will be marked as an unknown file or a benign file, and the process will be terminated or the file to be detected will be released after recording the log. The non-risk file is used to indicate that the source of the file to be detected is credible or the risk factor is lower than a preset threshold.

[0027] In a second aspect, the present application provides a malicious file detection device, the device comprising:

[0028] A generation module is configured to read N bytes of fixed data from the header of a file to be detected, calculate a hash value for the N bytes of data using a hash algorithm, and generate a header fingerprint, where N is an integer greater than 1;

[0029] A first query module is configured to query a local cache based on the head fingerprint, wherein the local cache is configured to store local head sample fingerprints and corresponding determination results, wherein the determination results are configured to indicate malicious fingerprints or benign fingerprints;

[0030] A second query module is configured to query a cloud cache based on the head fingerprint if the local cache does not hit the head fingerprint, wherein the cloud cache is used to store global head sample fingerprints and their corresponding determination results;

[0031] The scanning module is used to call the malicious rule set in the cloud to perform feature scanning on the file to be detected if the cloud cache does not hit the head fingerprint, wherein the malicious rule set is used to identify whether the file to be detected is malicious.

[0032] In a third aspect, the present application provides an electronic device comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus.

[0033] In a fourth aspect, the present application further provides a computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the malicious file detection method described in any one of the above items of the present application.

[0034] The above technical solution provided by the embodiment of the present application has the following advantages compared with the existing technology: it adopts a phased and hierarchical matching strategy, first completing the rapid filtering of the vast majority of files through ultra-lightweight fixed-length header sampling and hash calculation; then utilizing the intelligent multi-level cache architecture composed of the client local cache and the cloud cache to achieve rapid identification of common known header fingerprints, reducing the access pressure on the back-end system; only for a few files that are not hit in the rapid initial screening and cache query, the cloud-based malicious rule set is triggered as a supplementary verification mechanism, ensuring a high detection rate for new, unknown or complex variant malicious samples. This layered filtering adopts detection methods of different costs for samples of different universality, thereby improving the detection efficiency of malicious files. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0036] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0037] One or more embodiments are exemplarily illustrated by pictures in the corresponding drawings. These exemplifications do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0038] Figure 1 Schematic diagram of a malicious file detection system provided in an embodiment of the present application;

[0039] Figure 2 A flowchart of a method for detecting malicious files provided in an embodiment of the present application;

[0040] Figure 3A schematic diagram of the structure of a malicious file detection device provided in an embodiment of the present application;

[0041] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0042] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0043] The disclosure below provides many different embodiments or examples for implementing different structures of the present application. In order to simplify the disclosure of the present application, the components and settings of specific examples are described below. Of course, these are merely examples and are not intended to limit the present application. In addition, the present application may repeat reference numbers and / or letters in different examples. Such repetition is for the purpose of simplicity and clarity and does not in itself indicate the relationship between the various embodiments and / or settings discussed.

[0044] Application scenarios of the embodiments of this application include but are not limited to:

[0045] Terminal security protection: Real-time detection of malware on terminal devices such as personal computers and servers to prevent system infection.

[0046] Email gateway security: Automatically scan email attachments, block malicious emails, and protect corporate email systems.

[0047] Network intrusion detection or prevention system: Detects malicious files transmitted through the network at the network boundary or key nodes.

[0048] Cloud storage service security: Scan files uploaded by users to cloud storage to prevent the spread of malicious files.

[0049] Malicious Sample Analysis Platform: Serves as a fast track for initial sample screening and classification, alleviating the pressure of subsequent in-depth analysis.

[0050] Rapid filtering before sandbox execution: Before submitting samples to the resource-intensive sandbox for dynamic behavior analysis, rapid identification is performed to filter out known samples.

[0051] Optionally, in an embodiment of the present application, the above-mentioned malicious file detection method can be applied to Figure 1The hardware environment shown is composed of the client 101, the cloud server 103, and the cloud scanning module 105. Figure 1 As shown, the client 101 first reads the first N bytes of the header of the file to be detected locally, and then performs hash calculation on the N bytes of data to generate a header fingerprint, and preferentially matches the header fingerprint in the client's local cache; if there is no hit, the cache of the cloud server 103 is queried. If there is no hit, the cloud scanning module 105 can be triggered to perform a deeper feature matching, and the cloud scanning module 105 will feed back the scanning results to the client 101.

[0052] The following will be combined with specific implementation methods to provide a detailed description of a malicious file detection method provided by the embodiment of the present application, taking application to the client as an example. Figure 2 The specific steps are as follows:

[0053] Step 201: After reading the fixed N bytes of data at the head of the file to be detected, a hash value is calculated for the N bytes of data using a hash algorithm to generate a head fingerprint, where N is an integer greater than 1;

[0054] Step 202: querying a local cache based on the head fingerprint, wherein the local cache is used to store local head sample fingerprints and their corresponding determination results, and the determination results are used to indicate malicious fingerprints or benign fingerprints;

[0055] Step 203: If the local cache does not hit the head fingerprint, query the cloud cache based on the head fingerprint, where the cloud cache is used to store the global head sample fingerprint and its corresponding determination result;

[0056] Step 204: If the cloud cache does not hit the head fingerprint, the malicious rule set in the cloud is called to perform feature scanning on the file to be detected, wherein the malicious rule set is used to identify whether the file to be detected is malicious.

[0057] The embodiments of this application first explain the terms involved, including the following content.

[0058] Header fingerprint: A short and unique identifier obtained by hashing the first N bytes of data in the file to be detected, used to quickly match and identify malicious samples.

[0059] Local cache: A small cache stored on the client device that contains recently or frequently accessed header fingerprints and their corresponding verdicts (malicious or benign).

[0060] Cloud cache: A high-performance Redis database deployed in the cloud, used to store global hot spots or recently frequently accessed head fingerprints and their associated information, providing efficient and low-latency query services.

[0061] Malicious rule set: A set of predefined YARA rules used to perform deep scanning of files based on characteristics such as text patterns and binary patterns to identify complex malicious behaviors.

[0062] In step 201, the system first reads the first N bytes of the file header (N is usually 100-512 bytes, for example, the first 200 bytes). It then uses a fast hash algorithm (such as a truncated value of MD5, SHA1, or SHA256) to calculate a hash value for these N bytes of data to generate a fingerprint for the file header.

[0063] If the file to be detected does not have enough N bytes (i.e. the file is too small), the entire content is directly used to generate the hash value. This strategy ensures that even small files can be effectively identified and avoids matching failures due to insufficient file size.

[0064] The key identifying information or volatile parts of many malicious samples (especially variants of specific families) are often concentrated in file headers (such as the header of PE files and the beginning of script files). By hashing only the data with a fixed length (such as 200 bytes) at the beginning of the file, we can reduce the amount of data read and the amount of computation required for initial analysis while maintaining a high degree of discrimination. This allows us to complete the initial filtering of large numbers of files in a very short time. Compared to full-file hashing, this method also reduces I / O and CPU consumption, avoiding the high I / O and CPU computational overhead.

[0065] In step 202, the client (such as a terminal device or an edge gateway server) maintains a small high-speed cache. The cache can manage limited cache space based on cache elimination strategies such as LRU (Least Recently Used) and LFU (Least Frequently Used). The cache capacity can be set according to the client characteristics, such as 500 entries for the terminal and 10,000 entries for the gateway. The local cache stores the client's recent or high-frequency head fingerprints and their associated judgment results, such as malicious fingerprints or benign fingerprints.

[0066] After generating the head fingerprint, the system searches the client's local cache for matching records. If a match is found, the system can directly use the judgment results in the cache to decide how to handle the file without further querying the cloud or other complex analysis. This mechanism makes full use of the client's own computing and storage resources to achieve instant matching of local hot samples, avoids unnecessary network transmission and cloud queries, improves the recognition speed of common samples, and reduces the load on the back-end system. The main function of the local cache is to accelerate the instant recognition of duplicate samples for a specific client and reduce unnecessary network transmission and cloud query load.

[0067] In step 203, the cloud cache stores the frequently accessed header fingerprints from the entire network and their detailed judgment results. If the local cache fails to hit the target header fingerprint, the system will turn to the high-performance cache in the cloud for query, such as Redis cache. Redis is an open source, BSD-licensed, in-memory data structure storage system that can be used as a database, cache, and message middleware. Its key-value pair storage model and operations mainly based on RAM, Redis's memory-based operating characteristics can provide extremely low access latency (sub-millisecond level) and high throughput (hundreds of thousands of operations per second), which allows cloud queries to be completed very quickly. In this way, the system can not only accelerate the recognition of common samples, but also effectively alleviate the pressure on the complete fingerprint library on the back end, and improve the response speed of the overall system.

[0068] The key role of cloud caching is to leverage Redis's low latency and high throughput based on in-memory operations to provide fast, scalable cloud-based fingerprint query services for massive clients. This addresses the performance bottlenecks of traditional centralized database queries and significantly improves the recognition speed of common samples.

[0069] The client-side local cache and cloud-based Redis cache form an intelligent multi-level cache architecture. The local cache solves the problems of repeated query delay and network overhead for specific clients, while the cloud-based Redis cache greatly accelerates the query speed of global hotspot fingerprints. Its performance far exceeds that of traditional disk-based databases or more complex distributed file systems for such high-frequency, low-latency query scenarios, effectively solving the problems of cloud-based query performance bottlenecks and insufficient cache efficiency.

[0070] In step 204, if both the local cache and the cloud cache fail to match the target header fingerprint, it indicates that the sample may be unknown, new, or its malicious features are not contained in the fixed sampling area of ​​the header. At this time, the system will trigger the malicious rule set in the cloud to perform a more in-depth feature scan of the entire file.

[0071] The malicious rule set consists of a series of predefined, regularly updated YARA rules. Users can create YARA rules based on descriptions of text or binary patterns. YARA is a tool designed to help malware researchers identify and classify malware samples, with identification rules at its core. These rules can scan all or specified portions of a file to be tested, identifying complex malicious behaviors or family characteristics defined by text patterns, binary patterns, or other heuristic features within the file to be tested, helping to discover hidden malicious behaviors or variants.

[0072] The YARA rule set serves as an adaptive fallback mechanism and an effective supplement and verification method for fast header fingerprint matching. It compensates for potential missed detections that can occur when relying solely on fixed-length header fingerprints. For example, situations where the malicious payload is located in the middle or back of the file body, the file header is deliberately forged, or the file resembles a benign file but is actually a different sample or variant. By selectively triggering the relatively computationally expensive YARA scan on demand, it effectively combines rapid screening with in-depth analysis and optimizes the allocation of computing resources. This improves the detection coverage and accuracy of new, unknown, or complex variants of malicious samples, and addresses the issues of a single and inflexible detection mechanism.

[0073] For example, employee A receives an email with an attachment. The system performs the following operations on the email.

[0074] 1. Generate header fingerprint: The client reads the first 200 bytes of the attachment and calculates its hash value using the MD5 algorithm to generate a header fingerprint.

[0075] 2. Query the local cache: The client searches the local cache for the header fingerprint. If a match is found and marked as benign, the attachment is released. If no match is found, the client proceeds to the next step.

[0076] 3. Query the cloud cache: The client sends a query request to the cloud-based Redis cache over a secure connection. If a match is found in the cloud and marked as malicious, the appropriate isolation measures are immediately implemented, and the local cache may be updated for faster identification next time. If no match is found, the process proceeds to the next step.

[0077] 4. Invoke the malicious rule set: If the header fingerprint does not match the local or cloud version, the client will invoke the YARA rule set to perform a comprehensive scan of the attachment. If the scan results indicate that the attachment contains ransomware characteristics, immediate isolation and alert measures will be taken, and relevant information will be fed back to the client.

[0078] This application adopts a phased and hierarchical matching strategy. First, it completes the rapid filtering of the vast majority of files through ultra-lightweight fixed-length header sampling and hash calculation; then it uses the intelligent multi-level cache architecture composed of client local cache and cloud cache to quickly identify common known header fingerprints, reducing the access pressure on the back-end system; only for a few files that are not hit in the rapid initial screening and cache query, the cloud malicious rule set is triggered as a supplementary verification mechanism, ensuring a high detection rate for new, unknown or complex variant malicious samples. This layered filtering uses different cost detection methods for samples of different universality, thereby improving the detection efficiency of malicious files.

[0079] As an optional implementation, after querying the local cache based on the header fingerprint, the method further includes:

[0080] Step S11: If the local cache matches the head fingerprint, obtain the first determination result in the local cache;

[0081] Step S12: If the first determination result includes the local malicious fingerprint tag, the sample threat level, and the malicious family information, the detected file is isolated, cleared, and an alarm is issued;

[0082] Step S13: If the first determination result includes a benign fingerprint label, the file to be inspected is released.

[0083] In step S11, if the header fingerprint of the file to be detected is successfully matched in the client's local cache, it means that the file has been processed before and its relevant characteristics (such as whether it is malware, threat level, malware family, etc.) have been recorded. At this time, the system will directly obtain the first judgment result corresponding to the header fingerprint from the local cache.

[0084] In step S12, if the first judgment result in the local cache shows that the file to be detected contains a malicious fingerprint tag (i.e., it is marked as a malicious sample), the system will take corresponding measures based on further detailed information. These detailed information usually include the sample threat level (such as low, medium, and high risk) and the malicious family to which it belongs (such as the ransomware family, the Trojan family, etc.). Based on this information, the system will implement a series of security measures, such as isolating and clearing the file, and issuing an alarm notification to the administrator or user. This process ensures that even the most common malicious samples can be quickly identified and processed, thereby effectively preventing them from causing harm to the system.

[0085] In step S13, if the first determination result in the local cache indicates that the file to be tested contains a benign fingerprint tag, the file has been confirmed to be safe, and the system will directly release it. This means that the file can continue to operate or be used normally without triggering any additional security checks or operations. In this way, the system can quickly screen out a large number of harmless files, reduce false positives, and improve the user experience.

[0086] Whether a sample is malicious or benign, the system can take appropriate action based on the detailed identification results. For malicious samples, the system can quickly identify their threat level and family, and implement measures such as isolation, removal, and alerting. For benign samples, the system directly releases them, reducing unnecessary delays and false positives. Leveraging a local caching mechanism, the system can instantly identify known samples within milliseconds, improving processing speed while avoiding unnecessary network transmissions and cloud queries, reducing the burden on backend systems and overall resource consumption.

[0087] As an optional implementation, after querying the cloud cache based on the head fingerprint, the method further includes:

[0088] Step S21: If the cloud cache matches the head fingerprint, a second determination result returned by the cloud is received, wherein the second determination result includes a global malicious fingerprint label, a sample threat level, and information about the malicious family to which it belongs, or the second determination result includes a global benign fingerprint label;

[0089] Step S22: Synchronously updating the head fingerprint and the second determination result to the local cache according to a preset strategy, wherein the preset strategy is the cache validity period in the second determination result, or the local least recently used strategy or least frequently used strategy.

[0090] In step S21, when the system fails to find a matching head fingerprint in the local cache of the client, it will turn to the high-performance Redis cache in the cloud for query. If the cloud cache hits the head fingerprint, the system will obtain the corresponding second judgment result from the cloud. This judgment result contains rich information, such as whether it is malware (global malicious fingerprint label), the sample threat level (such as low, medium, high risk) and the malicious family it belongs to (such as ransomware family, Trojan family, etc.), or confirm that it is a benign file (global benign fingerprint label). Through these detailed information, the system can quickly make accurate judgments, and take corresponding security measures or directly release harmless files.

[0091] In step S22, the cloud updates the head fingerprint and its corresponding determination result to the local cache of the client according to the preset strategy. There are two main strategies for this update mechanism.

[0092] Cache expiration policy: Based on the cache expiration period (TTL) in the second judgment result returned by the cloud, the system will set a corresponding expiration time in the local cache. This ensures that the data in the local cache remains up to date and avoids misjudgments caused by long periods of inactivity.

[0093] Least Recently Used (LRU) or Least Frequently Used (LFU): If the data returned from the cloud doesn't have a clear cache expiration date, the system uses the local cache management strategy to determine how to handle the new data. For example, with the LRU strategy, the system prioritizes the most recently accessed data, while with the LFU strategy, it prioritizes the most frequently accessed data. This approach helps optimize local cache space utilization and ensures that frequently used data is always available.

[0094] In this application, by leveraging a high-performance cloud-based Redis cache, the system can complete queries for unknown head fingerprints and obtain detailed judgment results in a very short time. This low latency and high throughput enable the system to maintain efficient operation even in the face of massive concurrent requests. By synchronizing cloud-based judgment results to the local cache, the client can improve the recognition speed of common samples and reduce unnecessary network transmission and cloud-based query operations. This dynamic update mechanism ensures that the data in the local cache is always up to date, avoiding misjudgments caused by outdated data. By combining cache expiration policies with local cache eviction policies, the local cache space can be effectively managed to ensure that frequently used data is always available. Whether the sample is malicious or benign, the system can take appropriate measures based on the detailed judgment results. For malicious samples, the system can quickly identify their threat level and family, and take measures such as isolation, removal, and alerting. For benign samples, the system directly releases them, reducing unnecessary delays and false positives. This flexible and accurate classification mechanism greatly enhances the security and adaptability of the system.

[0095] As an optional implementation, in step 204, if the cloud cache does not match the head fingerprint, calling the cloud malicious rule set to perform feature scanning on the file to be detected includes:

[0096] Step S31: If the cloud cache does not match the head fingerprint, the local risk assessment strategy is called to evaluate the file to be detected;

[0097] Step S32: If the assessment result is a non-risk file, the file to be detected is marked as an unknown file or a benign file, and the process is terminated or the file to be detected is released after recording a log. The non-risk file is used to indicate that the source of the file to be detected is credible or the risk factor is lower than a preset threshold.

[0098] Step S33: If the assessment result is a risky file, mark the rule set call tag, and send the rule set call tag and the file to be detected to the cloud;

[0099] Step S34: The cloud calls the tag to load the corresponding malicious rule set according to the rule set, and performs feature matching on the file to be detected according to the malicious rule set to generate a scanning result.

[0100] In step S31, when the system fails to find a matching head fingerprint in the cloud cache, it indicates that the file may be an unknown or complex sample. At this point, the system will first call the local risk assessment strategy to perform a preliminary assessment of the file to be detected. This assessment is usually based on multiple factors, such as the source of the file (whether it comes from a trusted source), the file type (such as executable files, documents, pictures, etc.), file metadata (such as digital signatures, creation time, etc.), and historical behavior records. By integrating this information, the system can quickly determine whether the file has potential security risks.

[0101] In step S32, if the local risk assessment strategy indicates that the file to be tested is non-risky (i.e., the source is trustworthy or the risk factor is below a preset threshold), the system will directly mark it as an unknown file or a benign file and terminate further detection. In this case, the system can choose to log the file for subsequent audits or directly release the file, allowing it to run or be used normally. This approach not only improves the system's processing efficiency, but also reduces the possibility of false positives and enhances the user experience.

[0102] In step S33, if the local risk assessment strategy indicates that the file to be detected is high-risk (i.e., it contains a potential threat), the system will mark it with a rule set call tag and send the tag along with the file to the cloud. This tag indicates the specific malicious rule set that needs to be loaded to perform a deeper feature match on the file. In this way, the system can select the appropriate YARA rule set for scanning in a targeted manner, avoiding unnecessary waste of resources.

[0103] In step S34, once the cloud receives a file to be detected with a rule set call tag, it loads the corresponding malicious rule set based on the tag and performs a comprehensive feature match on the file using that rule set. The YARA rule set contains a series of predefined rules that can identify specific strings, hexadecimal sequences, or other heuristic features within a file, helping to uncover hidden malicious behavior or variants. This deep scanning allows the system to accurately identify new or complex malicious samples and generate detailed scan results.

[0104] In this application, we leveraged local risk assessment strategies to perform preliminary file screening before triggering a deep scan. This approach reduced unnecessary YARA rule scanning and improved the overall efficiency and responsiveness of the system. By invoking a tag mechanism with rule sets, the system intelligently scheduled YARA rule matching only for files that truly required a deep scan, avoiding unnecessary resource waste.

[0105] As an optional implementation, after generating the scanning result, the method further includes:

[0106] Step S41: Obtain the scanning results returned by the cloud;

[0107] Step S42: If the scanning result determines that the file to be detected is a malicious sample, the head fingerprint of the malicious sample and the third judgment result are fed back to the back-end complete sample knowledge base, so that the back-end complete sample knowledge base evaluates the head fingerprint as a high-risk threat fingerprint or a new fingerprint, and then updates the head fingerprint to the cloud cache, where the third judgment result includes the malicious sample label and the family information to which it belongs.

[0108] Step S43: If the scanning result indicates that the file to be detected is a benign sample, the file to be detected is marked as benign and released.

[0109] In step S41, after the system completes deep feature matching for high-risk files, the cloud performs a comprehensive scan of the file based on a malicious rule set (such as YARA rules) and generates a final scan result. This scan result typically includes clear information such as whether the file is a malicious sample, the malware family it belongs to, and the threat level. The system obtains this result from the cloud via a secure communication channel, which serves as an important basis for subsequent processing decisions.

[0110] In step S42, if the scanning result returned by the cloud shows that the file to be detected is judged to be a malicious sample, the system will extract the header fingerprint of the file and the third judgment result returned by the cloud (including malicious labels, family, threat level, etc.), and feed this information back to the system's back-end complete sample knowledge base.

[0111] After receiving this information, the backend knowledge base will further evaluate the header fingerprint to determine whether it is a high-risk threat fingerprint (i.e., a known malicious fingerprint with high harmfulness or spread) or a new fingerprint (i.e., a new variant that has just appeared and has not yet been widely disseminated). Once the fingerprint is confirmed to have potential value, the system will automatically add it to the cloud cache for other clients to quickly query and use during future detection processes.

[0112] In step S43, if the scan result returned by the cloud indicates that the file to be tested is a benign sample, the system will mark the file as benign and allow it to run or be transmitted normally. At the same time, the system may record relevant logs for auditing or behavioral analysis purposes. This processing method not only improves system efficiency but also avoids the accidental interception of harmless files, improving user experience and business continuity.

[0113] In this application, after the malicious sample's header fingerprint and judgment results are fed back to the backend knowledge base, the system can automatically identify high-risk or new malicious fingerprints and share them globally by updating the cloud cache. This closed-loop feedback mechanism makes the system adaptive and continuously evolving, significantly improving the cache hit rate of subsequent similar samples and reducing the number of repeated calls to the YARA rule set.

[0114] This application provides a data flow process for malicious file detection, including the following contents.

[0115] 1. File Arrival and Sampling: When the monitoring component of a client or edge node captures a file to be detected (e.g., a file download, an email attachment, a file system write, etc.), the file preprocessing and sampling module reads a fixed N bytes of data from the file header.

[0116] 2. Header fingerprint generation: The head hash calculation module generates a fast hash fingerprint (such as MD5 value) for the sampled N bytes of data.

[0117] 3. Local cache query: Use the generated header fingerprint to query the client's local cache.

[0118] Hit: Directly obtain the judgment result (such as malicious or benign, threat level, family information, etc.). The process can be directly terminated or enter the corresponding disposal process (such as isolation, removal, alarm, release, etc.).

[0119] Miss: Continue to the next step.

[0120] 4. Cloud Redis cache query (if the local cache misses): The client accesses the module through the cloud cache and sends the header fingerprint to the cloud Redis cache module through a secure connection for query.

[0121] Hit: The cloud-based Redis cache returns the judgment result. The client receives the result and, based on a pre-defined policy (e.g., based on the TTL information in the returned result, or using a local LRU or LFU policy), updates (adds or refreshes) the header fingerprint and its result to the client's local cache, enabling faster access to the same sample later. The process ends or proceeds to disposition.

[0122] Miss: Continue to the next step.

[0123] 5. YARA scan trigger decision (if the cloud Redis cache still misses): This indicates that the sample could not be quickly identified using the header fingerprint. The client's YARA trigger decision and request module evaluates whether a deeper YARA scan is necessary based on pre-set policies.

[0124] Do not trigger YARA scanning: If the policy determines that scanning is not required (for example, the file source is trusted and the type is low-risk), it can be judged as "Unknown (based on header fingerprint and cache)" or "Suspected Benign" and released after the process ends or is recorded.

[0125] Triggering a YARA scan: If the policy determines that a scan is required, the client sends the original file (or its secure reference / path to ensure that the cloud service can access the file) and possible scan parameters (such as specific rule set tags) to the cloud-based YARA scanning service module.

[0126] 6. YARA rule scanning: After receiving the request, the cloud-based YARA scanning service module loads the corresponding YARA rule set and performs comprehensive YARA rule matching on the file content.

[0127] 7. YARA result return and processing: The cloud-based YARA scanning service module returns the scanning results (e.g., the names of specific YARA rules that were hit, metadata tags such as malicious families, or any key malicious rules that were not hit) to the requesting client.

[0128] If a YARA malicious rule is hit, the client records the malicious determination and executes the appropriate action. (Optional) Consider feeding the newly confirmed malicious sample's header fingerprint and YARA matching information (or at least its malicious determination and family classification) back to the backend's complete sample knowledge base. Based on policy, the backend system may decide to add this header fingerprint to the cloud-based Redis cache (especially for new or high-risk threats) to accelerate subsequent identification of such new samples.

[0129] Missing a YARA malicious rule (or only hitting a benign or informational rule): The client determines that the file is not known to be malicious based on current detection methods. The process ends and the file is either processed as a normal file or submitted to other analysis systems. If necessary, the header fingerprint and file metadata of this "YARA miss" status can be recorded in the backend knowledge base for subsequent analysis, rule optimization, or manual judgment.

[0130] The core concept of this invention is a layered filtering and intelligent scheduling mechanism combining "rapid initial screening + efficient cache acceleration + precise supplementary verification." The first layer of ultra-fast filtering is achieved through ultra-lightweight fixed-length header sampling and hash calculations. An intelligent multi-level cache architecture, comprised of client-side local cache and cloud-based Redis cache, significantly improves the recognition speed of common known samples and reduces the pressure on the backend's complete analysis system. For potentially unknown or complex samples that fail to pass the first two stages of rapid identification, a more detailed and flexible YARA rule-based scanning mechanism is used as an adaptive fallback mechanism for supplementary verification, ensuring comprehensive and in-depth detection.

[0131] The core innovations of this application include the following.

[0132] 1. Ultra-lightweight initial screening: Using a fixed sampling of N bytes in the file header combined with a fast hash algorithm (such as MD5) forms the system's first efficient and low-cost filtering barrier. This method can handle the vast majority of file identification requests entering the system with extremely low resource consumption (microsecond processing time), quickly filtering out a large number of samples that can be identified by header features.

[0133] 2. Two-tier high-speed cache acceleration: "Client-side local cache" utilizes endpoint resources to reduce unnecessary network communication and cloud load, achieving personalized and instant acceleration for individuals; "Cloud Redis cache" leverages Redis's memory storage characteristics and high concurrency processing capabilities to provide millisecond-level response capabilities for global hotspot fingerprint queries. It is the key to improving the efficiency of large-scale concurrent matching in the cloud and is superior to traditional disk-based database caching solutions.

[0134] 3. Targeted Deep Verification: YARA scanning, a flexible and powerful feature matching tool, cleverly serves as an adaptive fallback mechanism when all header fingerprint cache misses occur. This "on-demand" approach, rather than "constant execution," avoids the need for heavy-duty YARA scanning of all files. This ensures detection rates for unknown and complex samples while keeping overall system performance overhead within reasonable limits.

[0135] 4. Collaborative Optimization Mechanism: These three core innovations do not exist in isolation; rather, they work together to form an optimized solution that balances cost control, efficiency, and coverage. Header sampling provides lightweight keys for caching, and multi-level caching significantly reduces the number of samples requiring YARA scanning. YARA scanning complements the shortcomings of the previous two, forming an efficient and intelligent process for rapid fingerprint matching of malicious samples.

[0136] The system architecture of the embodiment of the present application is shown below.

[0137] 1. Client or edge node: usually deployed on terminal devices (PC, server), email gateways, network security devices or cloud application portals.

[0138] 1. File preprocessing and sampling module: responsible for receiving or intercepting the file to be detected and accurately reading the preset fixed N bytes of data in the file header.

[0139] 2. Header hash calculation module: For the N-byte header data obtained by sampling, a preset fast hash algorithm (such as MD5) is used to calculate and generate the head fingerprint.

[0140] 3. Local cache management module: Maintains a local header fingerprint cache (e.g., based on a LRU strategy). Responsible for querying the local cache; if the cloud query hits, updates the local cache according to the strategy.

[0141] 4. Cloud cache access module: When the local cache misses, it constructs a query request (including the header fingerprint), sends it to the cloud Redis cache module through a secure network connection, and receives the return result.

[0142] 5. YARA Trigger Decision and Request Module: When a header fingerprint does not match a match in either the local or cloud-based Redis cache, this module decides whether to initiate a YARA scan based on pre-defined trigger policies (such as file type, source reputation, or a default trigger). If a trigger is determined, it sends the original file (or its secure reference / path, and possibly contextual information) to the cloud-based YARA scanning service module and requests a scan.

[0143] 2. Cloud Service: Deployed in a cloud server cluster, it provides scalable and highly available services.

[0144] 1. Cloud-based Redis Cache Module: Deploy and maintain one or more high-performance Redis instances. Store global hotspots or recently frequently accessed header fingerprints and their associated information (such as maliciousness determination, malicious family labels, credibility scores, and related YARA rule prompts). Provide an efficient, low-latency header fingerprint query interface. Responsible for loading, updating (which can be from the backend database), and retiring cached data.

[0145] 2. YARA Scanning Service Module: This module receives files (or references to them) and YARA scan requests from clients. It loads a predefined and regularly updated set of YARA rules, performs a YARA scan on the file contents, and returns matching results (such as matching rule names, rule tags, malicious family determinations, or no matching rules) to the requesting client. This module is typically designed as a horizontally scalable cluster of worker nodes.

[0146] 3. Back-end complete sample knowledge base and rule management system.

[0147] This module is the knowledge base and data source for the entire system. Although it does not directly participate in high-frequency real-time query processes, it is crucial to the continued effectiveness of the system. It is used to store the full amount of malicious sample information (including but not limited to complete file hashes, header fingerprints, sample metadata, behavioral analysis reports, etc.), a complete header fingerprint library (as the data source and update basis for the cloud-based Redis cache, such as loading new or high-frequency fingerprints into Redis for preheating or replacement through regular batch imports or streaming update mechanisms to ensure the timeliness and hotness of the data in Redis), and the creation, testing, deployment, version control, and performance monitoring of the YARA rule library. Newly discovered malicious sample features (including their header fingerprints and applicable YARA rules) will be updated to this library, which in turn affects the content of the Redis cache and the rule set used by the YARA scanning service.

[0148] Two embodiments are used below to illustrate the contents of this application.

[0149] Example 1: Real-time file protection for enterprise terminals.

[0150] 1. Business Scenario: When employees perform daily operations on their computer terminals (such as opening files, downloading attachments, and running programs), terminal security software needs to detect malware in real time to prevent threats such as ransomware, Trojans, and spyware. This requires fast detection speed and low resource usage to minimize user experience while maintaining a high detection rate.

[0151] 2. System module participation and deployment.

[0152] 2.1 Client module: as a core component, it is embedded in the terminal security software deployed by the enterprise.

[0153] File preprocessing and sampling module, header hash calculation module, local cache management module (for example, using LRU strategy, the cache capacity is set to 500 header fingerprint records), cloud cache access module, YARA trigger decision and request module.

[0154] 2.2 Cloud services: Deployed in an enterprise private cloud or a trusted public cloud environment.

[0155] Cloud-based Redis cache module: For example, use an enterprise-level Redis cluster service (such as AWS ElastiCache for Redis, Azure Cache for Redis, or a self-built high-availability Redis cluster), configure it as a memory-optimized instance, and design the cache capacity to support at least 10 million global hotspot header fingerprints. Set the average TTL (Time-To-Live) to 24 hours, and use an LFU or LRU-like eviction strategy to retain frequently accessed items.

[0156] 2.3 YARA scanning service module: It consists of a group of containerized worker nodes that can automatically scale according to the load. Each node is loaded with enterprise-customized YARA rule sets (which may include private rules for specific industry threats) and high-quality public YARA rule sets (for example, from community contributions such as VirusTotal and MalwareBazaar, which have been screened and optimized). The total number of rules may be between 5,000 and 20,000.

[0157] 2.4 Back-end knowledge base and management system: Maintained by the enterprise security operation center, used for sample analysis, fingerprint extraction, YARA rule writing, testing and deployment, and responsible for regular or real-time updates of the cloud Redis cache and YARA rule set.

[0158] 3. Operation steps, conditions, parameters and results.

[0159] 3.1 File Operation Triggering, Header Sampling, and Hash Calculation: When a user creates a file, downloads it, attempts to open it, or executes it on the terminal, the file monitoring component (driver or application layer hook) of the endpoint security software captures the file event and its path. The file sampling module immediately reads the first 200 bytes of the file's header. The header hash calculation module uses the MD5 algorithm to calculate a hash value for this 200-byte data, generating a header fingerprint.

[0160] Parameters: sampling length N = 200 bytes, hash algorithm = MD5.

[0161] Conditions: The file is readable and the file size is greater than or equal to 200 bytes (if it is less than 200 bytes, the entire file is sampled).

[0162] Technical Principle: Leveraging the fact that file headers often contain key identifying information, this method uses fixed-length sampling and fast hashing to achieve ultra-lightweight fingerprint extraction, laying the foundation for subsequent fast matching. This step is estimated to take less than 0.5ms.

[0163] 3.2 Local cache query: The generated MD5 header fingerprint is queried in the client's local LRU cache (the capacity is set to 500 fingerprint records).

[0164] Parameters: Local cache strategy = LRU, capacity = 500.

[0165] Technical Principle: Leveraging the client's local resources, this method enables instant matching of frequently encountered or recently encountered samples on the endpoint, reducing network requests and representing the first level of multi-level caching. This step is expected to take <0.1ms.

[0166] Result 1 (Hit): If a match is found, for example, if the fingerprint is associated with "Malware Trojan.Generic.XYZ, Action: Quarantine," the endpoint security software directly executes the preset quarantine action and may issue a warning to the user. The process ends. The total time (from file capture to action decision) is approximately <1ms.

[0167] Result 2 (miss): If miss, proceed to the next step.

[0168] 3.3 Cloud Redis Cache Query: If the local cache does not hit the result, the terminal's cloud cache access module sends the header MD5 fingerprint to the cloud-deployed Redis cache service via an encrypted HTTPS request. The cloud Redis cache is queried.

[0169] Parameters: The number of fingerprints in the cloud Redis cache is > 10M, and the elimination strategy is LFU or LRU.

[0170] Technical Principle: This approach leverages the high-speed query capabilities of the cloud-based Redis in-memory database to rapidly match fingerprints of globally popular malicious samples. This serves as the second-level core of the multi-level cache. Assuming an average round-trip time (RTT) of 20ms between the terminal and the cloud service, and a Redis query time of <1ms, the average response time for this step (including network latency) is 20-25ms.

[0171] Result 1 (Hit): If Redis finds a hit, for example, returning the verdict "Malware Adware.Win32.Popuper, Action: Intercept and Log," the endpoint security software executes the corresponding action and updates the result (header fingerprint and verdict) to the local cache (refreshing its LRU position). The process ends. The total time is approximately 20-26ms.

[0172] Result 2 (miss): If Redis still does not hit, it indicates that the sample header fingerprint is not a currently known common hot sample, and proceed to the next step.

[0173] 3.4 YARA Scan Triggering and Execution: The endpoint's YARA trigger decision module, based on pre-set policies (e.g., defaulting to triggering for all cache misses, or further checking file metadata such as digital signatures and source Zone.Identifiers, triggering if a valid signature is missing or the file originates from an untrusted zone), decides to upload the original file (or, for large files, perhaps sending the file metadata and headers first, with the cloud-based YARA service returning the requested complete file as needed) via an encrypted channel to the cloud-based YARA scanning service module. The cloud-based YARA scanning service module selects an appropriate rule subset (possibly based on a preliminary determination of the file type) to scan the file contents.

[0174] Parameters: Number of YARA rules = 5k-20k, trigger condition = cache miss and matching the specified policy.

[0175] Technical Principle: As an adaptive fallback mechanism, YARA scanning performs deep content feature matching on samples that cannot be identified by quick fingerprinting, improving detection rates and compensating for the limitations of head fingerprinting. File upload (assuming an average file size of 1MB, upload time on an intranet or good broadband connection is approximately 50-200ms, depending on bandwidth and server distance). The YARA scanning service performs the scan (assuming moderate rule complexity, average scan time for a 1MB file is 100-500ms).

[0176] Result 1 (YARA hits malicious rule): For example, if the rule "Ransomware.WannaCry.Gen" is hit, it is determined to be ransomware. The endpoint security software immediately executes the highest priority disposal action (such as terminating the process, isolating the file, and blocking related network connections). The header fingerprint and YARA matching information of this newly discovered sample can be submitted to the backend knowledge base, and after evaluation, its header fingerprint and malicious judgment may be quickly updated to the cloud-based Redis cache. The total time (this path, from file capture to disposal decision) can range from 170ms to 725ms (mainly affected by upload and scanning time).

[0177] Result 2 (YARA misses or only hits benign or informational rules): The sample is considered unidentified based on the current rule set. This can be recorded as "Unknown but passed the YARA scan" or treated as a low-risk file and released. Endpoint security software may monitor the behavior of such files for an extended period of time.

[0178] 4. Expected Results: The majority (e.g., an estimated 85-98%, depending on the enterprise threat landscape and cache quality) of known malware can be quickly identified and processed (within 1-26ms) in a local or cloud-based Redis cache using header fingerprinting, reducing endpoint CPU and I / O load with minimal impact on the user experience. For the small number of samples (2-15%) that require YARA scanning, while each scan takes longer, the low frequency of YARA triggering keeps the overall system processing time low (e.g., potentially under 50ms), while ensuring detection depth and coverage of unknown, new, and complex variant threats.

[0179] Example 2: Real-time scanning of email gateway attachments.

[0180] 1. Business Scenario: When receiving external email, an enterprise email gateway must perform real-time malware scanning on all inbound email attachments to prevent malicious attachments (such as Office documents carrying macro viruses, malicious scripts, and executable programs) from entering the internal network. Daily email processing can reach hundreds of thousands to millions of emails, with a massive amount of attachments, requiring high throughput and low latency.

[0181] 2. System module participation and deployment.

[0182] 2.1 Edge Node (Mail Gateway Server): Integrates the client module logic of the present invention. As a server node, it has more processing power and memory resources than the terminal.

[0183] File preprocessing and sampling module, header hash calculation module, local cache management module (for example, using the LFU strategy, the cache capacity is set to 10,000 to 50,000 header fingerprint records to adapt to server-level processing volume), cloud cache access module, YARA trigger decision and request module (the trigger strategy can be more aggressive, such as triggering YARA for all executable files, scripts, documents with macros, etc. after a cache miss).

[0184] 2.2 Cloud Service: Same as Example 1, but it may be necessary to configure a higher-specification and larger-scale cloud Redis cache cluster and YARA scanning service cluster based on the concurrency and total processing capacity of the mail gateway to ensure SLA.

[0185] 2.3 Backend knowledge base and management system: Similar to Example 1, it may focus more on extracting fingerprints and YARA rules from email threat intelligence.

[0186] 3. Operation steps, conditions, parameters and results.

[0187] 3.1 Email Arrival and Attachment Extraction: The email gateway receives the incoming email, parses the email content, and extracts all attachments. The following process is performed for each attachment.

[0188] 3.2 Header sampling and hash calculation: Sample the first 200 bytes of the attachment file and calculate the MD5 hash.

[0189] Parameters: N = 200 bytes, Hash = MD5. Very low latency (sub-millisecond).

[0190] 3.3 Gateway local cache query: query the large capacity LFU cache maintained locally by the mail gateway server.

[0191] Parameters: Local cache capacity 10k-50k, policy = LFU. Very low latency (sub-millisecond).

[0192] Result 1 (Hit): If it is a hit (such as being determined to be known malicious), the email gateway directly processes the email according to the preset strategy (such as quarantining the email, deleting attachments and notifying the recipient, marking it as spam, etc.).

[0193] Result 2 (miss): Go to the next step.

[0194] 3.4 Cloud Redis cache query: If there is no local hit, the attachment header fingerprint is queried in the cloud Redis cache.

[0195] Technical Principle: Leverages Redis to handle large-scale concurrent queries. Estimated query execution time (including network latency between the gateway and the cloud) is 5-15ms (assuming a high-quality connection between the gateway and the cloud service).

[0196] Result 1 (hit): The processing method is similar to the local cache hit, and the result is updated to the gateway local cache.

[0197] Result 2 (miss): Go to the next step.

[0198] 3.5 YARA scan triggering and execution: If both levels of cache miss, the YARA trigger decision module (for example, all high-risk attachments such as executable files, Office documents, PDFs, and scripts are triggered by default, and low-risk attachments such as ordinary images and text files can be triggered or not) submits the attachment to the cloud-based YARA scanning service.

[0199] Technical Principle: Targeted, in-depth inspection of potentially high-risk attachments that have cache misses. The total time it takes to transfer an attachment to the YARA service and scan it (assuming an average attachment size of 1MB, a YARA scan time of 100-500ms, and a network transfer time of 50ms) is 150-550ms.

[0200] Result 1 (YARA hits a malicious rule): The email gateway processes the email based on the YARA result. The relevant information is fed back to the backend and may update the Redis cache.

[0201] Result 2 (YARA miss): The attachment is considered to have no known malicious features in this round of detection, and the email can be delivered normally or undergo other standard content filtering.

[0202] 4. Expected Results: By combining header fingerprinting with a two-level cache, the vast majority (e.g., 90-99%) of common malicious attachments can be identified and processed in a very short time (from milliseconds to tens of milliseconds), improving the processing throughput of the email gateway. YARA scanning, as an on-demand deep detection method, ensures the ability to detect malicious attachments used in new, complex, or targeted attacks, while its call frequency is effectively controlled to avoid becoming an overall performance bottleneck. The system as a whole is able to meet the email gateway's requirements for high concurrency and low latency processing while maintaining a high detection rate.

[0203] Based on the same technical concept, this application provides a malicious file detection device, such as Figure 3 As shown, the device includes:

[0204] A generation module 301 is configured to read N bytes of fixed data from the header of a file to be detected, calculate a hash value for the N bytes of data using a hash algorithm, and generate a header fingerprint, where N is an integer greater than 1;

[0205] A first query module 302 is configured to query a local cache based on the head fingerprint, wherein the local cache is configured to store local head sample fingerprints and corresponding determination results, wherein the determination results are configured to indicate malicious fingerprints or benign fingerprints;

[0206] The second query module 303 is configured to query the cloud cache based on the head fingerprint if the local cache does not match the head fingerprint, wherein the cloud cache is used to store the global head sample fingerprint and its corresponding determination result;

[0207] The scanning module 304 is used to call the malicious rule set in the cloud to perform feature scanning on the file to be detected if the cloud cache does not hit the head fingerprint, wherein the malicious rule set is used to identify whether the file to be detected has malicious properties.

[0208] Optionally, the device is further used to:

[0209] If the local cache matches the head fingerprint, the first determination result in the local cache is obtained;

[0210] If the first judgment result contains the local malicious fingerprint label, the sample threat level, and the malicious family information, the detected file will be isolated, cleared, and an alarm will be issued;

[0211] If the first determination result includes a benign fingerprint label, the file to be inspected is released.

[0212] Optionally, the device is further used to:

[0213] If the cloud cache hits the head fingerprint, receiving the second determination result returned by the cloud, wherein the second determination result includes a global malicious fingerprint label, a sample threat level, and information about the malicious family to which it belongs, or the second determination result includes a global benign fingerprint label;

[0214] The head fingerprint and the second determination result are synchronously updated to the local cache according to a preset strategy, wherein the preset strategy is the cache validity period in the second determination result, or the local least recently used strategy or least frequently used strategy.

[0215] Optionally, the scanning module 304 is configured to:

[0216] If the cloud cache does not match the head fingerprint, the malicious rule set in the cloud is called to perform feature scanning on the file to be detected, including:

[0217] If the cloud cache does not match the head fingerprint, the local risk assessment strategy is called to evaluate the file to be detected;

[0218] If the assessment result is a risky file, the rule set call tag is marked and the rule set call tag and the file to be tested are sent to the cloud;

[0219] The cloud calls the label according to the rule set to load the corresponding malicious rule set, and performs feature matching on the files to be detected according to the malicious rule set to generate the scanning results.

[0220] Optionally, the device is further used to:

[0221] Get the scan results returned from the cloud;

[0222] If the scanning result determines that the file to be detected is a malicious sample, the head fingerprint of the malicious sample and the third judgment result will be fed back to the back-end complete sample knowledge base, so that the back-end complete sample knowledge base will evaluate the head fingerprint as a high-risk threat fingerprint or a new fingerprint, and then update the head fingerprint to the cloud cache. Among them, the third judgment result includes the malicious sample label and the family information to which it belongs.

[0223] Optionally, the device is further used to:

[0224] If the scan result indicates that the file to be tested is a benign sample, the file to be tested is marked as benign and released.

[0225] Optionally, the device is further used to:

[0226] If the assessment result is a non-risk file, the file to be tested will be marked as an unknown file or a benign file, and the process will be terminated or the file to be tested will be released after recording the log. Among them, the non-risk file is used to indicate that the source of the file to be tested is credible or the risk factor is lower than the preset threshold.

[0227] like Figure 4As shown, an embodiment of the present application provides an electronic device, including a processor 401, a communication interface 402, a memory 403 and a communication bus 404, wherein the processor 401, the communication interface 402, and the memory 403 communicate with each other through the communication bus 404.

[0228] The memory 403 is used to store computer programs.

[0229] In one embodiment of the present application, the processor 401 is configured to implement the malicious file detection method provided by any one of the aforementioned method embodiments when executing a program stored in the memory 403 .

[0230] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the malicious file detection method provided in any of the aforementioned method embodiments are implemented.

[0231] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0232] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, or of course, by hardware. Based on this understanding, the above technical solution, in essence, or the part that contributes to the relevant technology, can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or certain parts of the embodiment.

[0233] It should be understood that the terms used herein are for the purpose of describing specific example embodiments only and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "comprise", "include", "contain" and "have" are inclusive and therefore specify the presence of stated features, steps, operations, elements and / or parts, but do not exclude the presence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring them to be performed in the specific order described or illustrated, unless the order of execution is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0234] The foregoing is merely a list of specific embodiments of the present application, intended to enable those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the broadest scope consistent with the principles and novel features of the present application.

Claims

1. A method for detecting malicious files, characterized in that: The method comprises: After reading the fixed N bytes of data at the head of the file to be detected, a hash value is calculated for the N bytes of data using a hash algorithm to generate a head fingerprint, where N is an integer greater than 1; querying a local cache based on the head fingerprint, wherein the local cache is used to store local head sample fingerprints and corresponding determination results, and the determination results are used to indicate malicious fingerprints or benign fingerprints; If the local cache does not hit the head fingerprint, query the cloud cache according to the head fingerprint, wherein the cloud cache is used to store the global head sample fingerprint and its corresponding determination result; If the cloud cache does not hit the head fingerprint, the malicious rule set in the cloud is called to perform feature scanning on the file to be detected, wherein the malicious rule set is used to identify whether the file to be detected is malicious.

2. The method according to claim 1, characterized in that After querying the local cache according to the head fingerprint, the method further includes: If the local cache matches the head fingerprint, obtaining a first determination result in the local cache; If the first determination result includes the local malicious fingerprint label, the sample threat level, and the malicious family information, the file to be detected is isolated, cleared, and an alarm is issued; If the first determination result includes a benign fingerprint label, the file to be detected is released.

3. The method according to claim 1, characterized in that After querying the cloud cache according to the head fingerprint, the method further includes: If the cloud cache hits the head fingerprint, receiving a second determination result returned by the cloud, wherein the second determination result includes a global malicious fingerprint label, a sample threat level, and information about the malicious family to which it belongs, or the second determination result includes a global benign fingerprint label; The head fingerprint and the second determination result are synchronously updated to the local cache according to a preset strategy, wherein the preset strategy is the cache validity period in the second determination result, or the local least recently used strategy or least frequently used strategy.

4. The method according to claim 1, wherein If the cloud cache does not match the header fingerprint, calling the malicious rule set in the cloud to perform feature scanning on the file to be detected includes: If the cloud cache does not hit the head fingerprint, then call the local risk assessment strategy to evaluate the file to be detected; If the assessment result is a risky file, mark the rule set call tag, and send the rule set call tag and the file to be detected to the cloud; The cloud calls the tag according to the rule set to load the corresponding malicious rule set, and performs feature matching on the file to be detected according to the malicious rule set to generate a scanning result.

5. The method according to claim 4, characterized in that After generating the scan result, the method further includes: Obtaining the scan results returned by the cloud; If the scanning result determines that the file to be detected is a malicious sample, the head fingerprint of the malicious sample and the third judgment result are fed back to the back-end complete sample knowledge base, so that the back-end complete sample knowledge base evaluates the head fingerprint as a high-risk threat fingerprint or a new fingerprint, and then updates the head fingerprint to the cloud cache, wherein the third judgment result includes the malicious sample label and the family information to which it belongs.

6. The method according to claim 5, characterized in that After obtaining the scan results returned by the cloud, the method further includes: If the scanning result indicates that the file to be detected is a benign sample, the file to be detected is marked as benign and released.

7. The method according to claim 4, characterized in that After invoking a local risk assessment strategy to assess the file to be detected, the method further includes: If the evaluation result is a non-risk file, the file to be detected will be marked as an unknown file or a benign file, and the process will be terminated or the file to be detected will be released after recording the log. The non-risk file is used to indicate that the source of the file to be detected is credible or the risk factor is lower than a preset threshold.

8. A malicious file detection device, characterized in that: The device comprises: A generation module is configured to read N bytes of fixed data from the header of a file to be detected, calculate a hash value for the N bytes of data using a hash algorithm, and generate a header fingerprint, where N is an integer greater than 1; A first query module is configured to query a local cache based on the head fingerprint, wherein the local cache is configured to store local head sample fingerprints and corresponding determination results, wherein the determination results are configured to indicate malicious fingerprints or benign fingerprints; A second query module is configured to query a cloud cache based on the head fingerprint if the local cache does not hit the head fingerprint, wherein the cloud cache is used to store global head sample fingerprints and their corresponding determination results; The scanning module is used to call the malicious rule set in the cloud to perform feature scanning on the file to be detected if the cloud cache does not hit the head fingerprint, wherein the malicious rule set is used to identify whether the file to be detected is malicious.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; Memory for storing computer programs; A processor, configured to implement the method according to any one of claims 1 to 7 when executing a program stored in a memory.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images