Attack framework-based large language model terminal threat detection method

Abstract

The application provides a large language model terminal threat detection method based on an attack framework, which comprises the following steps: receiving suspicious logs reported by a terminal after being filtered according to a data cleaning rule; performing threat detection on the suspicious logs based on a threat detection rule to determine threat event logs; using a large language model to analyze the threat event logs based on threat intelligence knowledge base and / or event content corresponding to the threat event logs; and outputting a threat report of the threat event logs in the case that the threat event logs have malicious intent. Through the technical solution of the application, the large language model is used, the ATT&CK knowledge base is combined with the APT organization attack activity analysis report, the automatic maintenance of the detection rule is realized, and the false positive rate is reduced when the APT attack is detected.

Description

Technical Field

[0001] This application relates to the field of cybersecurity, and in particular to a method for terminal threat detection based on a large language model of an attack framework. Background Technology

[0002] An APT (Advanced Persistent Threat) attack is a sophisticated and persistent cyberattack targeting a specific objective, typically launched by highly specialized and well-organized attackers. Current technologies primarily rely on manually written APT attack detection rules, based on which detection is performed. However, this approach is costly to maintain and heavily dependent on the experience of security personnel; insufficient experience can lead to a high false positive rate. Summary of the Invention

[0003] This application provides a large language model-based endpoint threat detection method based on an attack framework, which aims to detect APT attacks, reduce the maintenance cost of manually writing detection rules, and lower the false positive rate.

[0004] Specifically, this application is implemented through the following technical solution: According to a first aspect of the embodiments of this application, a method for detecting terminal threats based on a large language model using an attack framework is provided, comprising: The receiving terminal reports suspicious logs that have been filtered according to data cleaning rules, including rules generated using a large language model based on the ATT&CK knowledge base, which identify logs containing technologies from the ATT&CK knowledge base as suspicious logs. Threat detection is performed on the suspicious logs based on threat detection rules to identify threat event logs. The threat detection rules include rules generated by a large language model based on the ATT&CK knowledge base and the APT group attack activity analysis report, which identify suspicious context logs that match the threat attack path in the APT group attack activity analysis report as threat event logs. The technologies contained in the threat attack path include those in the ATT&CK knowledge base. The suspicious context logs include a specified number of consecutive logs within a specified time range containing the suspicious logs. Using a large language model, the threat event log is analyzed based on the threat intelligence knowledge base and / or the event content corresponding to the threat event log. The event content includes: the threat event corresponding to the threat event log, the source of the threat, the time of the threat attack, and the path of the threat attack. If it is determined that the threat event log has malicious intent, a threat report of the threat event log is output.

[0005] According to a second aspect of the embodiments of this application, a large language model terminal threat detection system based on an attack framework is provided, comprising: The terminal device is used to filter logs according to data cleaning rules and send the filtered suspicious logs to the server device. The data cleaning rules include rules generated by using a large language model based on the ATT&CK knowledge base to identify logs containing the technology in the ATT&CK knowledge base as suspicious logs. A server-side device is used to receive the suspicious logs; perform threat detection on the suspicious logs based on threat detection rules to determine threat event logs. The threat detection rules include rules generated using a large language model based on the ATT&CK knowledge base and the APT group attack activity analysis report, which identify suspicious context logs that match the threat attack path in the APT group attack activity analysis report as threat event logs. The technologies contained in the threat attack path include those in the ATT&CK knowledge base. The suspicious context logs include a specified number or a specified number of consecutive logs containing the suspicious logs within a specified time range. Using a large language model, the threat event logs are analyzed based on the threat intelligence knowledge base and / or the event content corresponding to the threat event logs. The event content includes: the threat event corresponding to the threat event log, the threat source, the threat attack time, and the threat attack path. If it is determined that the threat event log has malicious intent, a threat report for the threat event log is output.

[0006] According to a third aspect of the embodiments of this application, a large language model terminal threat detection device based on an attack framework is provided, comprising: The receiving module is used to receive suspicious logs reported by the terminal after being filtered according to data cleaning rules. The data cleaning rules include rules generated by using a large language model based on the ATT&CK knowledge base to identify logs containing technologies in the ATT&CK knowledge base as suspicious logs. The threat detection module is used to perform threat detection on the suspicious logs based on threat detection rules to identify threat event logs. The threat detection rules include rules generated by using a large language model based on the ATT&CK knowledge base and the APT group attack activity analysis report, which identify suspicious context logs that match the threat attack path in the APT group attack activity analysis report as threat event logs. The technologies contained in the threat attack path include the technologies in the ATT&CK knowledge base. The suspicious context logs include a specified number of continuous logs within a specified time range containing the suspicious logs. The analysis module is used to analyze the threat event log using a large language model, based on the threat intelligence knowledge base and / or the event content corresponding to the threat event log. The event content includes: the threat event corresponding to the threat event log, the source of the threat, the time of the threat attack, and the threat attack path. The report output module is used to output a threat report of the threat event log if it is determined that the threat event log has malicious intent.

[0007] According to a fourth aspect of the embodiments of this application, an electronic device is provided, comprising: a processor and a memory, wherein, Memory, used to store computer programs; The processor, when executing a program stored in memory, implements the method provided in the first aspect.

[0008] According to a fifth aspect of the embodiments of this application, a computer program product is provided, wherein the computer program product stores a computer program, and the computer program, when executed by a processor, implements the method provided in the first aspect.

[0009] According to a sixth aspect of the embodiments of this application, a machine-readable storage medium is provided, the machine-readable storage medium storing machine-executable instructions that can be executed by a processor; wherein the processor is configured to execute the machine-executable instructions to implement the method provided in the first aspect.

[0010] As can be seen from the above technical solutions, in the embodiments of this application, the powerful natural language understanding and code generation capabilities of the large language model are utilized, combined with the ATT&CK knowledge base and APT group attack activity analysis reports, to achieve automated conversion from security domain knowledge described in natural language to detection rules. This reduces the reliance on senior security experts to write rules, lowers the technical threshold, reduces the maintenance costs of manually writing detection rules, and reduces omissions or grammatical errors that may occur due to manual writing, thereby reducing the false alarm rate during the detection stage.

[0011] Furthermore, in this embodiment, data cleaning rules are deployed on the terminal side to filter logs on the terminal, achieving "noise removal" and "purification" at the data source, ensuring that only suspicious logs are reported to the server, significantly reducing the amount of logs uploaded to the server and saving bandwidth and storage costs. The data cleaning rules and threat detection rules used are generated based on the ATT&CK knowledge base, which is a network attack tactics knowledge base based on attack frameworks, improving rule coverage and accuracy. In the threat detection stage, contextual log detection of suspicious logs is performed, and semantic analysis and contextual association are used to improve the accuracy of threat detection. After identifying threat event logs, the threat event logs are further analyzed based on the threat intelligence knowledge base and / or the event content corresponding to the threat event logs, and threat reports are output for those with genuine malicious intent, reducing the false alarm rate. Attached Figure Description

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

[0013] Figure 1 This is a flowchart illustrating a large language model-based terminal threat detection method based on an attack framework according to one embodiment of this application. Figure 2 This is a schematic diagram of the data cleaning rule generation process in one embodiment of this application; Figure 3 This is a schematic diagram of the process of generating threat detection rules in one embodiment of this application; Figure 4 This is a schematic diagram of the threat report generation process in one embodiment of this application; Figure 5 This is a schematic diagram of a threat detection process in one embodiment of this application; Figure 6 This is a schematic diagram of a rule update process based on false alarms in one embodiment of this application; Figure 7 This is a schematic diagram of the structure of a large language model terminal threat detection device based on an attack framework according to one embodiment of this application; Figure 8 This is a schematic diagram of the structure of a large language model terminal threat detection system based on an attack framework according to one embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electronic device according to one embodiment of this application. Detailed Implementation

[0014] To enable those skilled in the art to better understand the technical solutions provided in the embodiments of this application, some terms involved in the embodiments of this application will be briefly explained below.

[0015] 1. ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) Knowledge Base: Developed and maintained by MITRE, this globally accessible cybersecurity knowledge base describes and categorizes the tactics, techniques, and processes employed by cyber attackers throughout the attack lifecycle. The ATT&CK knowledge base is a cyberattack tactics and techniques knowledge base based on an attack framework. This framework systematically organizes and presents various attack behaviors that attackers may use in a matrix format, dividing attack activities into multiple tactical phases such as reconnaissance, resource development, initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, command and control, data infiltration, and impact. Specific attack techniques and their sub-techniques are listed under each tactic. The ATT&CK knowledge base is built based on real threat intelligence and attack cases, providing security practitioners with a standardized language and reference model, and is widely used in threat modeling, attack simulation, security assessment, detection rule development, and defense capability gap analysis.

[0016] 2. APT (Advanced Persistent Threat): APT refers to organized, professional attack teams with clear offensive intentions that carry out long-term, covert, and persistent cyberattacks against specific targets. APT attacks are characterized by clear targeting, complex methods, strong concealment, and long duration, often making them difficult to detect and defend against using traditional security defenses. They are one of the major threats facing the cybersecurity field.

[0017] 3. RAG (Retrieval-Augmented Generation): An artificial intelligence architecture that combines information retrieval techniques with generative models. It enhances the accuracy, timeliness, and interpretability of generated content by retrieving relevant information from external knowledge bases and integrating it into the input context of the generative model. The RAG workflow typically involves: first, retrieving relevant documents or fragments from external knowledge sources based on the user's query; then, inputting the retrieved information and the original query into a large language model, which generates the final answer based on the retrieved external knowledge. This architecture effectively alleviates the inherent problems of knowledge truncation and illusion generation in large language models, enabling them to provide more reliable and verifiable answers in specialized domains.

[0018] 4. Large Language Model (LLM): This refers to a natural language processing model with a massive number of parameters built using deep learning techniques. It typically employs the Transformer architecture and learns the grammatical structure, semantic knowledge, and contextual understanding of a language through self-supervised pre-training on massive text corpora. Large language models can perform various natural language processing tasks such as text generation, question answering, translation, summarization, and code writing, and possess strong semantic understanding and logical reasoning capabilities. In the field of cybersecurity, large language models can be used for applications such as threat intelligence analysis, attack behavior understanding, and automatic security report generation.

[0019] 5. Threat Intelligence Repository: This refers to a database or knowledge base that systematically collects, organizes, and stores various types of cybersecurity threat information. Its content can cover structured or unstructured threat data such as attacker identity information, attack tool characteristics, malware sample characteristics (e.g., hash values, behavioral patterns), attack technical indicators (e.g., IP addresses, domain names, URLs), vulnerability information, and attack tactics and processes. Many cybersecurity organizations' threat intelligence centers provide publicly available threat intelligence repositories. These repositories aggregate threat intelligence from multiple sources and perform correlation analysis, providing data support for security detection, attack attribution, risk warning, and defense decision-making.

[0020] 6. Sigma: An open-source, universal security incident detection rule format designed to describe security detection logic in a way that is independent of specific security information and event management systems. Sigma rules are written in YAML format and describe the characteristic patterns of specific attack behaviors or anomalous activities in log data by defining log sources, detection conditions, and field matching logic. Sigma has become a widely adopted standardized rule description language in network security detection engineering, promoting community collaboration and sharing of detection knowledge.

[0021] To make the above-mentioned objectives, features, and advantages of the embodiments of this application more apparent and understandable, the technical solutions of the embodiments of this application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0022] It should be noted that the sequence numbers of the steps in the embodiments of this application do not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0023] Please see Figure 1 This is a flowchart illustrating a large language model-based terminal threat detection method based on an attack framework, provided in an embodiment of this application. The method can be applied to server-side devices and may include the following steps: Step S100: Receive suspicious logs reported by the terminal after being filtered according to data cleaning rules. The data cleaning rules include rules generated by using a large language model based on the ATT&CK knowledge base to identify logs containing technologies from the ATT&CK knowledge base as suspicious logs.

[0024] Among them, the ATT&CK knowledge base is a network attack tactics and techniques knowledge base based on the attack framework.

[0025] In this embodiment, to achieve "noise removal" and "purification" at the data source, ensuring that only suspicious logs are reported to the server, data cleaning rules are deployed on the terminal side to filter logs from the terminal, thereby significantly reducing the amount of logs uploaded to the server and saving bandwidth and storage costs. Dedicated agent software can be deployed on the terminal device to continuously monitor, collect, and analyze device behavior to identify, detect, and respond to malicious attacks targeting these devices. The data cleaning rules used are generated based on the ATT&CK knowledge base, improving rule coverage and accuracy. To lower the technical barrier and reduce maintenance costs or errors caused by manually writing rules, the data cleaning rules are generated using a large language model. The terminal uses these data cleaning rules to identify logs containing technologies from the ATT&CK knowledge base as suspicious logs and reports them to the server. The server then receives the suspicious logs reported by the terminal, filtered according to the data cleaning rules.

[0026] In some embodiments, data cleaning rules are generated in the following manner: The detection strategies and terminal cleaning rules corresponding to each technology in the ATT&CK knowledge base are used as input to the large language model to generate data cleaning rules in Sigma format. The terminal cleaning rule generation prompts are used to instruct the large language model to output the detection strategies corresponding to each technology in the ATT&CK knowledge base in Sigma format. The data cleaning rules include a set of technology detection files corresponding to all technologies in the ATT&CK knowledge base.

[0027] Accordingly, if the terminal detects that any technology detection file contains the corresponding technology in the log, it identifies the log as a suspicious log, adds the identifier of the detected technology to the log, and then uploads the suspicious log to the server.

[0028] Here, as Figure 2 As shown, the detection strategies and endpoint cleaning rules corresponding to each technology in the ATT&CK knowledge base are used to generate prompts (such as "output the above detection rules in Sigma format"), which are then input into the large language model. The large language model generates rules in Sigma format. The data cleaning rules are generated based on the ATT&CK knowledge base, which improves the rule coverage and accuracy. The data cleaning rules are generated using the large language model, which reduces the maintenance cost or errors caused by manually writing rules. The data cleaning rules adopt the Sigma format, which is widely used in the threat detection field, making the rule format more standardized and the detection more reliable.

[0029] Step S110: Perform threat detection on suspicious logs based on threat detection rules to determine threat event logs. The threat detection rules include rules generated using a large language model based on the ATT&CK knowledge base and APT group attack activity analysis report, which identify suspicious context logs that match the threat attack path in the APT group attack activity analysis report as threat event logs. The technologies contained in the threat attack path include technologies in the ATT&CK knowledge base. Suspicious context logs include a specified number of continuous logs within a specified time range containing the suspicious logs.

[0030] Specifically, after receiving suspicious logs reported by the terminal, the server performs threat detection on the suspicious logs based on threat detection rules. Suspicious context logs that match the threat attack paths in the APT group's attack activity analysis report are identified as threat event logs. Through context association analysis, threat attack chains that cannot be reflected in a single log can be identified, thereby improving the detection accuracy of threat event logs.

[0031] In some embodiments, threat detection rules are generated as follows: The attack phases in the APT group's attack activity analysis report are identified using a large language model, and the corresponding technologies in the ATT&CK knowledge base are determined for each attack phase. The attack phase is then assigned a corresponding technology identifier. Using a large language model, based on the identifiers of the technologies corresponding to the attack stages, the threat attack paths in the APT group's attack activity analysis report, and the attack events corresponding to the threat attack paths, a threat detection file in a specified format is generated. Each threat attack path consists of multiple attack stages in the corresponding attack order, and each threat detection file indicates a threat attack path expressed by the identifiers of multiple technologies in the corresponding attack order, as well as its corresponding attack events. The threat detection rules include the set of all threat detection files.

[0032] Here, threat detection rules are generated based on APT group attack activity analysis reports, specifically based on the threat attack paths in these reports. Each threat attack path consists of multiple attack stages arranged in a corresponding attack sequence. Only multiple attack stages that achieve a certain sequential relationship are identified as attack events, thus improving rule coverage and accuracy. The process involves first using a large language model to identify the attack stages in the APT group attack activity analysis report, assigning each stage an identifier from the corresponding ATT&CK knowledge base. Then, based on the identifiers of the technologies corresponding to the attack stages, the threat attack paths in the APT group attack activity analysis report, and the attack events corresponding to those paths, the large language model generates a threat detection file in a specified format to obtain the threat detection rules. This two-stage large language model identification, compared to directly generating threat detection rules using a single large language model, separates the identification and generation tasks, resulting in more accurate results each time, reducing computational performance pressure, and improving the accuracy of threat detection rules.

[0033] Specifically, such as Figure 3 As shown, the ATT&CK knowledge base can be imported into the RAG knowledge base. By inputting publicly available APT group attack activity analysis reports into the large language model, the large language model combines the RAG knowledge base containing the ATT&CK knowledge base with attack stages to extract prompt words (such as "The above is an APT group attack activity analysis report. Please combine the ATT&CK knowledge base to generate attack stages with corresponding numbers for the technologies"). It extracts the attack stages from the report and maps each stage to a technology in the ATT&CK knowledge base. Then, it combines the attack stages output by the large language model with threat detection rules to generate prompt words (such as "Based on the threat attack paths in the APT group attack activity analysis report, generate attack path rules by combining the extracted attack stages with their numbers, and generate threat detection rules"). The large language model then combines these attack stages with the threat attack paths in the APT group attack activity analysis report to finally generate threat detection rules.

[0034] Accordingly, in some embodiments, step S110 may specifically include: For any suspicious log, determine the suspicious context log corresponding to that suspicious log; Based on the context order of each log in the suspicious context log and the identifier of the technology added to each log, the suspicious context log is identified as a threat event log if it matches any threat detection file in the threat detection rules.

[0035] The threat events and threat attack paths corresponding to the threat event logs are the attack events and threat attack paths indicated in the matching threat detection files. The threat source and threat attack time corresponding to the threat event logs are the time when the terminal that reported the threat event logs reported the threat event logs and the time when the terminal that received the threat event logs reported the threat event logs reported the threat event logs.

[0036] Specifically, for any suspicious log, a specified number or a specified number of consecutive logs containing that suspicious log within a specified time range are identified as suspicious context logs. After identifying a suspicious log, the terminal adds the identifiers of the detected technologies from the ATT&CK knowledge base to the suspicious log. Based on the context order of each log in the suspicious context log, the order of the corresponding multiple technology identifiers can be obtained. Each threat detection file indicates a threat attack path expressed by multiple technology identifiers in a corresponding attack order, and its corresponding attack events. If the order of multiple technology identifiers corresponding to the suspicious context log matches the attack order of multiple technology identifiers in the threat attack path of any threat detection file, then the suspicious context log matches any threat detection file in the threat detection rules, and the suspicious context log is identified as a threat event log. Here, through semantic analysis and context association, benign and malicious behaviors with similar characteristics but different intentions are effectively distinguished, significantly improving the accuracy of detection.

[0037] For example, when identifying suspicious context logs for any suspicious log, a specified time range or a specified number of consecutive logs containing the suspicious log can be selected as suspicious context logs. This specified time range or number can be preset. Selection can be based on the suspicious log as the middle log entry, selecting logs before and after the preset time range or number of logs; or it can be based on the suspicious log as the target number of log entries (e.g., the first, last, or Nth entry), selecting logs before and / or after the preset time range or number of logs. For example, the number of suspicious context logs determined based on this specified time range or number is equal to or greater than the sum of the number of attack stages contained in the threat attack path indicated in each threat detection file.

[0038] For example, a preset time range or a preset number of suspicious context logs can be selected first. If it is determined that the suspicious context logs cannot be successfully detected to match any threat detection file, for example, if the number of suspicious context logs is less than the sum of the number of attack stages in the threat attack path indicated in the threat detection file, a minimum number of logs to be supplemented is determined. This minimum number is the difference between the sum of the number of attack stages in the threat attack path and the number of logs in the current suspicious context logs. Based on the first and / or last logs of the current suspicious context logs, the number of logs to be supplemented is continued to be added forward and / or backward according to the minimum number of logs to be supplemented, so that the number of suspicious context logs after supplementation is equal to or greater than the sum of the number of attack stages in the threat attack path indicated in the threat detection file.

[0039] For example, since the identified suspicious context logs are used for threat detection by checking whether they match threat detection files, the number of logs contained in the suspicious context logs can be determined based on the threat attack paths indicated in the threat detection files, and suspicious context logs can be selected based on this number. Specifically, for any threat detection file, the required number of logs for the suspicious context logs can be determined based on the threat attack paths indicated in that file. For example, the number of logs can be equal to or greater than the sum of the number of attack stages contained in the threat attack paths. Each threat detection file can correspond to a specific number of logs. Then, for any suspicious log, the suspicious context logs corresponding to that suspicious log are determined based on each log number, and then checked for matching with each corresponding threat detection file. Alternatively, based on the threat attack paths indicated in all threat detection files, the sum of the maximum number of attack stages contained in these threat attack paths can be determined as the number of logs. For any suspicious log, the corresponding suspicious context logs are determined based on this number of logs. This ensures that all selected suspicious context logs can be successfully matched with the threat detection rules, avoiding invalid detections caused by the number of suspicious context logs being less than the sum of the number of attack stages contained in any threat attack path. It also avoids the need to select more suspicious context logs after invalid detections occur.

[0040] Step S120: Using a large language model, analyze the threat event log based on the event content corresponding to the threat intelligence knowledge base and / or threat event log. The event content includes: the threat event corresponding to the threat event log, the source of the threat, the time of the threat attack, and the path of the threat attack.

[0041] In this embodiment, to further reduce the false alarm rate, after detecting a threat event log, instead of directly outputting an alarm, it enters the intelligent analysis stage. Utilizing the deep semantic understanding capabilities of a large language model, it further analyzes the threat event log based on the threat intelligence knowledge base and / or the event content corresponding to the threat event log. The threat intelligence knowledge base is a knowledge base that aggregates threat intelligence from multiple sources and contains various types of network security threat information. The event content corresponding to the threat event log includes: the threat event corresponding to the threat event log, the source of the threat, the time of the threat attack, and the threat attack path. This allows for a comprehensive judgment based on these contents to determine whether the threat event log conforms to normal business rules. Thus, it effectively distinguishes between benign and malicious behaviors with similar characteristics but different intentions, outputting threat reports for those with genuine malicious intent, thereby reducing the false alarm rate.

[0042] In some embodiments, when analyzing threat event logs based on a threat intelligence knowledge base, step S120 may specifically include: Identify all threat intelligence matching information contained in the threat event log. Threat intelligence matching information includes one or more of the following: IP address, domain name, and file hash. Using a large language model, if any threat intelligence matching information matches a malicious element in the threat intelligence knowledge base, it can be determined that the threat event log has malicious intent. The malicious element includes one of the following: a malicious IP address, a malicious domain name, or a malicious file hash.

[0043] Accordingly, subsequent threat reports may include malicious tags from the threat intelligence knowledge base.

[0044] Specifically, to further reduce the false alarm rate, after detecting threat event logs, all threat intelligence matching information contained in the logs is extracted. If any threat intelligence matching information matches a malicious element in the threat intelligence knowledge base, the threat event log is determined to have malicious intent. Since the threat intelligence knowledge base centralizes threat intelligence from multiple sources, further analysis of the threat event logs based on this knowledge base can output threat reports for those truly with malicious intent, improving detection reliability. Accordingly, the output threat report can include malicious tags from the threat intelligence knowledge base, such as one or more of the following: malicious IP address, malicious domain name, malicious file hash, malicious type (e.g., remote control Trojan), and malicious family (e.g., Generic Trojan). These malicious tags can be structured or unstructured threat data representing attacker identity information, attack tool characteristics, malware sample characteristics (e.g., hash value, behavioral patterns), attack technical indicators (e.g., IP address, domain name, URL), vulnerability information, attack tactics and processes, etc.

[0045] In some embodiments, when analyzing the threat event log based on the event content corresponding to the threat event log, step S120 may specifically include: By utilizing a large language model and based on the event content corresponding to the threat event log, if the threat event log does not conform to normal business rules, it is determined that the threat event log has malicious intent. The normal business rules include reasonable business behaviors determined through big data, the relationship between the business source and the business time.

[0046] Specifically, to further reduce the false alarm rate, after detecting threat event logs, based on the event content corresponding to the threat event logs, namely the threat event, threat source, threat attack time, and threat attack path, a large language model is further used in conjunction with the analysis of normal business big data (a series of reasonable business behaviors generated by business sources in the corresponding business time collected in advance) to determine whether the threat event logs conform to normal business rules. Threat reports can be output for those with genuine malicious intent, thereby improving detection reliability.

[0047] In some embodiments, the threat event log can be analyzed based on the event content corresponding to the threat intelligence knowledge base and the threat event log. If any analysis result indicates that the threat event log has malicious intent, that is, if any threat intelligence matching information matches a malicious element in the threat intelligence knowledge base, or if the threat event log does not conform to normal business rules, the threat event log is determined to have malicious intent.

[0048] Here, by analyzing the threat event logs based on the threat intelligence knowledge base and the corresponding event content, threat reports can be generated for those with genuine malicious intent, thereby improving detection reliability.

[0049] Step S130: If it is determined that the threat event log has malicious intent, output a threat report of the threat event log.

[0050] Specifically, the threat report may include one or more of the following: the source of the threat, the time of the attack, the attack path, and the corresponding ATT&CK techniques. Furthermore, it can utilize a large language model, combined with a RAG knowledge base containing an ATT&CK knowledge base and a threat intelligence knowledge base, to summarize the attack process and automatically generate a standardized report containing sections such as a summary, attack chain analysis, impact assessment, and remediation recommendations. In one embodiment, the threat report generation process can be seen... Figure 4This approach solves the problems of low efficiency and inconsistent formatting in manual report writing; it transforms discrete suspicious logs and threat alerts into coherent and professional reports through a large language model; it greatly improves report production efficiency, reducing the manual report writing work that originally required several hours to a response time of seconds, enabling immediate detection and reporting of threat events; it ensures report quality and professionalism, with generated reports using standardized terminology, clear logic, and strict adherence to security industry standards, avoiding unclear expressions or omissions of key information that may occur in manual writing; it reduces the time security analysts waste processing a large number of invalid alerts, allowing them to focus on high-value real threats and improving the overall response speed of security operations.

[0051] As can be seen from the above technical solutions, in this embodiment, the powerful natural language understanding and code generation capabilities of the large language model are utilized. Combined with the ATT&CK knowledge base (the ATT&CK knowledge base is a network attack tactics and techniques knowledge base based on attack frameworks) and APT group attack activity analysis reports, the standardized knowledge base of attack frameworks and the publicly available APT group attack activity analysis reports are mapped into structured rules through the large model. The maintenance of automated and standardized rules is achieved, realizing the automated conversion from security domain knowledge described in natural language to detection rules. This reduces the reliance on senior security experts to write rules, lowers the technical threshold, reduces the maintenance cost of manually writing detection rules, and reduces the omissions or grammatical errors that may occur due to manual writing, thereby reducing the false positive rate during the detection stage. Furthermore, data cleaning rules are deployed on the terminal side to filter logs on the terminal, achieving "noise removal" and "purification" at the data source, ensuring that only suspicious logs are reported to the server, significantly reducing the amount of logs uploaded to the server and saving bandwidth and storage costs. The data cleaning rules and threat detection rules used are generated based on the ATT&CK knowledge base, improving rule coverage and accuracy. In the threat detection stage, contextual log detection of suspicious logs is performed, using semantic analysis and contextual association to improve threat detection accuracy. After identifying threat event logs, further analysis is conducted on the threat event logs based on the threat intelligence knowledge base and / or the event content corresponding to the threat event logs, outputting threat reports for those with genuine malicious intent, reducing the false alarm rate.

[0052] In some embodiments, when using a large language model to determine that the threat event log conforms to normal business rules based on the event content corresponding to the threat event log, it can also be determined that there are false alarms in the threat detection of the threat event log, output false alarm alerts and reasons for false alarms, and mark the parts of the threat detection rules related to the threat attack path corresponding to the threat event log. For example, in one embodiment, the overall threat detection process is visible... Figure 5 .

[0053] For example, suppose a threat event log corresponds to a threat attack path that involves sequential access and debugging of several data ports. The source of the threat in this threat event log is a developer's host, and the threat attack time is during the developer's work debugging time. In this case, the threat event log conforms to the business rules of normal developer work debugging data ports. It is determined that there is a false alarm in the threat detection for this threat event log. The false alarm alarm and the reason for the false alarm are output (e.g., it belongs to normal developer debugging of data ports). The part of the threat detection rules related to the threat attack path corresponding to this threat event log (the behavior path of sequential access and debugging of several related data ports) is marked. Here, a large language model is used in conjunction with the analysis of normal business big data to determine whether threat event logs conform to normal business rules. If they conform to normal business rules, false alarms and their reasons are output. This helps security analysts intuitively understand why the behavior was judged as a false alarm. The judgment criteria provided make the alarm handling process transparent, facilitate analyst review, and reduce the time wasted by security analysts in dealing with a large number of invalid alarms. This allows them to focus on high-value real threats and improve the overall response speed of security operations. Marking the parts of the threat detection rules that are related to the threat attack path corresponding to the false alarm threat event logs can help with subsequent false alarm handling and rule updates, reduce the system false alarm rate, and improve operational efficiency.

[0054] In some embodiments, to address the issue of false positives in threat detection from threat event logs, further methods for handling false positives and updating rules are provided, as follows: In cases where false alarms are detected in threat event logs, determine the confidence level of the false alarm alert; When the confidence value is equal to or higher than the confidence threshold, or when a false alarm verification confirmation is received for a false alarm, the false alarm information corresponding to the false alarm will be stored in the false alarm database. The false alarm information includes the threat event log, the part of the threat detection rule related to the threat attack path corresponding to the threat event log, and the false alarm reason corresponding to the threat event log. Using a large language model, based on false positive information, the parts of the threat detection rules related to the threat attack path corresponding to the threat event log and / or the parts of the data cleaning rules related to at least one technology corresponding to the threat event log are updated.

[0055] Specifically, the confidence threshold is manually set in advance. When the large language model determines that there are false positives in threat detection of threat event logs, it analyzes and provides a confidence value for the false alarm. The confidence value represents the probability that the threat detection is a false alarm after combining analysis with normal business big data. In some embodiments, a false alarm verification button can be provided when a false alarm is output, allowing security analysts to verify the false alarm; or, if the confidence value of the false alarm given by the large language model is lower than the confidence threshold, a false alarm verification button can be provided, allowing security analysts to verify the false alarm. When the confidence value is equal to or higher than the confidence threshold, or when false alarm verification confirmation information is received for the false alarm, the false alarm information corresponding to the false alarm is stored in the false alarm database, recording the threat event log corresponding to the false alarm, the part of the threat detection rule related to the threat attack path corresponding to the threat event log, and the reason for the false alarm corresponding to the threat event log. Thus, it can learn from false alarms and continuously optimize, performing self-updating of threat detection rules and / or data cleaning rules. The scope of rule adjustments includes raising detection thresholds or adding whitelist exception rules. For example, if there are a first number (the number exceeds the false alarm threshold A) of identical false alarms, the part of the threat detection rule that detected the false alarm related to the threat attack path corresponding to the false alarm threat event log can be updated. For example, the threat detection file containing the threat attack path corresponding to the false alarm threat event log can be deleted (or the threat attack path and the corresponding threat event can be added to a whitelist, which can be used to analyze the threat event log; if it matches the whitelist, it is determined that the threat event log does not have malicious intent). If there are a second number (the number exceeds the false alarm threshold B) of false alarms, and the threat attack paths corresponding to these false alarm threat event logs all contain at least one technology, the part of the data cleaning rule related to the at least one technology can be updated. For example, the technology detection file corresponding to the at least one technology can be deleted (or the at least one technology can be added to a whitelist), or the detection threshold in the technology detection file of the at least one technology can be increased (for example, originally, 5 detections were considered as executing a scanning technology, and 6 detections were considered as abnormal behavior, but this would lead to false alarms, so the number is increased to 7 to be considered as executing a scanning technology). The adjusted rules can be reviewed by a security analyst before taking effect. Updated rules can be implemented directly or through comparative testing. Specifically, the old and new versions of the rules can be deployed simultaneously, and the false positive rate can be compared after a target testing period (e.g., one week or one month) to verify the effect before replacement. That is, if the false positive rate decreases after the update, the new rule takes effect; if the false positive rate increases after the update, the previous stable version of the rules can be reverted to. In one embodiment, the rule update process based on false positives is as follows: Figure 6Here, by updating threat detection rules and / or data cleaning rules in a timely manner based on false alarm information, the rules are continuously improved, thereby further enhancing the reliability of the rules and the accuracy of threat detection.

[0056] Based on the same concept as the methods described above, this application proposes a large language model-based terminal threat detection device using an attack framework. (See also...) Figure 7 The diagram shown is a structural diagram of the device, which includes: The suspicious log receiving module 701 is used to receive suspicious logs reported by the terminal after being filtered according to data cleaning rules. The data cleaning rules include rules generated by using a large language model based on the ATT&CK knowledge base to identify logs containing technologies from the ATT&CK knowledge base as suspicious logs. Threat detection module 702 is used to perform threat detection on suspicious logs based on threat detection rules to identify threat event logs. The threat detection rules include rules generated by using a large language model based on the ATT&CK knowledge base and APT group attack activity analysis report, which identify suspicious context logs that match the threat attack path in the APT group attack activity analysis report as threat event logs. The technologies contained in the threat attack path include technologies in the ATT&CK knowledge base. Suspicious context logs include a specified number of consecutive logs within a specified time range containing suspicious logs. Analysis module 703 is used to analyze threat event logs using a large language model, based on the event content corresponding to the threat intelligence knowledge base and / or threat event logs. The event content includes: the threat event corresponding to the threat event log, the source of the threat, the time of the threat attack, and the threat attack path. The report output module 704 is used to output a threat report of the threat event log if it is determined that the threat event log has malicious intent.

[0057] In some embodiments, data cleaning rules are generated in the following manner: The detection strategies and terminal cleaning rules corresponding to each technology in the ATT&CK knowledge base are used as input to the large language model to generate data cleaning rules in Sigma format. The terminal cleaning rule generation prompts are used to instruct the large language model to output the detection strategies corresponding to each technology in the ATT&CK knowledge base in Sigma format. The data cleaning rules include the set of technology detection files corresponding to all technologies in the ATT&CK knowledge base. Specifically, if the terminal detects that any technology detection file contains the corresponding technology in the log, it will identify the log as a suspicious log and add the identifier of the detected technology to the log.

[0058] In some embodiments, threat detection rules are generated as follows: The attack phases in the APT group's attack activity analysis report are identified using a large language model, and the corresponding technologies in the ATT&CK knowledge base are determined for each attack phase. The attack phase is then assigned a label with the corresponding technology. Using a large language model, based on the identifiers of the technologies corresponding to the attack stages, the threat attack paths in the APT group's attack activity analysis report, and the attack events corresponding to the threat attack paths, a threat detection file in a specified format is generated. Each threat attack path consists of multiple attack stages in the corresponding attack order, and each threat detection file indicates a threat attack path expressed by the identifiers of multiple technologies in the corresponding attack order, as well as its corresponding attack events. The threat detection rules include the set of all threat detection files.

[0059] In some embodiments, the threat detection module 702 is specifically used for, For any suspicious log, determine the suspicious context log corresponding to that suspicious log; Based on the context order of each log in the suspicious context log and the identifier of the technology added to each log, if the suspicious context log matches any threat detection file in the threat detection rules, the suspicious context log is identified as a threat event log. The threat event and threat attack path corresponding to the threat event log are the attack event and threat attack path indicated in the matched threat detection file. The threat source and threat attack time corresponding to the threat event log are the time when the terminal that reported the threat event log and the time when the terminal that received the threat event log reported the threat event log are respectively.

[0060] In some embodiments, the analysis module 703 is specifically used for, Identify all threat intelligence matching information contained in the threat event log. Threat intelligence matching information includes one or more of the following: IP address, domain name, and file hash. Using a large language model, if any threat intelligence matching information matches a malicious element in the threat intelligence knowledge base, it can be determined that the threat event log has malicious intent. The malicious element includes one of the following: a malicious IP address, a malicious domain name, or a malicious file hash. The threat report includes malicious tags from the threat intelligence knowledge base.

[0061] In some embodiments, the analysis module 703 is specifically used for, By utilizing a large language model and based on the event content corresponding to the threat event log, if the threat event log does not conform to normal business rules, it is determined that the threat event log has malicious intent. The normal business rules include reasonable business behaviors determined through big data, the relationship between the business source and the business time. Analysis module 703 is also used to: utilize a large language model, based on the event content corresponding to the threat event log, determine that there are false alarms in the threat detection of the threat event log if the threat event log conforms to normal business rules, output false alarm alerts and reasons for false alarms, and mark the parts of the threat detection rules related to the threat attack path corresponding to the threat event log.

[0062] In some embodiments, the device further includes an update module for: In cases where false alarms are detected in threat event logs, determine the confidence level of the false alarm alert; When the confidence value is equal to or higher than the confidence threshold, or when a false alarm verification confirmation is received for a false alarm, the false alarm information corresponding to the false alarm will be stored in the false alarm database. The false alarm information includes the threat event log, the part of the threat detection rule related to the threat attack path corresponding to the threat event log, and the false alarm reason corresponding to the threat event log. Using a large language model, based on false positive information, the parts of the threat detection rules related to the threat attack path corresponding to the threat event log and / or the parts of the data cleaning rules related to at least one technology corresponding to the threat event log are updated.

[0063] Based on the same concept as the methods described above, this application proposes a large language model-based endpoint threat detection system using an attack framework. (See [link to relevant documentation]). Figure 8 The diagram shown is a structural diagram of the system, which includes: Terminal device 801 is used to filter logs according to data cleaning rules and send the filtered suspicious logs to the server device. The data cleaning rules include rules generated by using a large language model based on the ATT&CK knowledge base to identify logs containing technologies from the ATT&CK knowledge base as suspicious logs. Server device 802 is used to receive suspicious logs; perform threat detection on the suspicious logs based on threat detection rules to identify threat event logs. The threat detection rules include rules generated using a large language model based on the ATT&CK knowledge base and APT group attack activity analysis reports, which identify suspicious context logs that match the threat attack paths in the APT group attack activity analysis reports as threat event logs. The technologies contained in the threat attack paths include those in the ATT&CK knowledge base. Suspicious context logs include a specified number of consecutive logs containing suspicious logs within a specified time range. Using a large language model, the threat event logs are analyzed based on the threat intelligence knowledge base and / or the event content corresponding to the threat event logs. The event content includes: the threat event corresponding to the threat event log, the threat source, the threat attack time, and the threat attack path. If it is determined that the threat event log has malicious intent, a threat report of the threat event log is output.

[0064] In some embodiments, data cleaning rules are generated in the following manner: The detection strategies and terminal cleaning rules corresponding to each technology in the ATT&CK knowledge base are used as input to the large language model to generate data cleaning rules in Sigma format. The terminal cleaning rule generation prompts are used to instruct the large language model to output the detection strategies corresponding to each technology in the ATT&CK knowledge base in Sigma format. The data cleaning rules include the set of technology detection files corresponding to all technologies in the ATT&CK knowledge base. The terminal device 801 is also used to identify the log as a suspicious log and add the identifier of the detected technology to the log if any technology detection file detects that the log contains the technology corresponding to the technology detection file.

[0065] In some embodiments, threat detection rules are generated as follows: The attack phases in the APT group's attack activity analysis report are identified using a large language model, and the corresponding technologies in the ATT&CK knowledge base are determined for each attack phase. The attack phase is then assigned a label with the corresponding technology. Using a large language model, based on the identifiers of the technologies corresponding to the attack stages, the threat attack paths in the APT group's attack activity analysis report, and the attack events corresponding to the threat attack paths, a threat detection file in a specified format is generated. Each threat attack path consists of multiple attack stages in the corresponding attack order, and each threat detection file indicates a threat attack path expressed by the identifiers of multiple technologies in the corresponding attack order, as well as its corresponding attack events. The threat detection rules include the set of all threat detection files.

[0066] In some embodiments, the server device 802 is specifically used for, For any suspicious log, determine the suspicious context log corresponding to that suspicious log; Based on the context order of each log in the suspicious context log and the identifier of the technology added to each log, if the suspicious context log matches any threat detection file in the threat detection rules, the suspicious context log is identified as a threat event log. The threat event and threat attack path corresponding to the threat event log are the attack event and threat attack path indicated in the matched threat detection file. The threat source and threat attack time corresponding to the threat event log are the time when the terminal that reported the threat event log and the time when the terminal that received the threat event log reported the threat event log are respectively.

[0067] In some embodiments, the server device 802 is specifically used for, Identify all threat intelligence matching information contained in the threat event log. Threat intelligence matching information includes one or more of the following: IP address, domain name, and file hash. Using a large language model, if any threat intelligence matching information matches a malicious element in the threat intelligence knowledge base, it can be determined that the threat event log has malicious intent. The malicious element includes one of the following: a malicious IP address, a malicious domain name, or a malicious file hash. The threat report includes malicious tags from the threat intelligence knowledge base.

[0068] In some embodiments, the server device 802 is specifically used for, By utilizing a large language model and based on the event content corresponding to the threat event log, if the threat event log does not conform to normal business rules, it is determined that the threat event log has malicious intent. The normal business rules include reasonable business behaviors determined through big data, the relationship between the business source and the business time. Using a large language model, based on the event content corresponding to the threat event log, and assuming that the threat event log conforms to normal business rules, it is determined that there are false alarms in the threat detection of the threat event log, outputs false alarm alerts and reasons for false alarms, and marks the parts of the threat detection rules related to the threat attack path corresponding to the threat event log.

[0069] In some embodiments, the server device 802 is further configured to: In cases where false alarms are detected in threat event logs, determine the confidence level of the false alarm alert; When the confidence value is equal to or higher than the confidence threshold, or when a false alarm verification confirmation is received for a false alarm, the false alarm information corresponding to the false alarm will be stored in the false alarm database. The false alarm information includes the threat event log, the part of the threat detection rule related to the threat attack path corresponding to the threat event log, and the false alarm reason corresponding to the threat event log. Using a large language model, based on false positive information, the parts of the threat detection rules related to the threat attack path corresponding to the threat event log and / or the parts of the data cleaning rules related to at least one technology corresponding to the threat event log are updated.

[0070] Based on the same concept as the above method, this application proposes an electronic device, see [link to previous application]. Figure 9 As shown, the electronic device includes a processor 91 and a machine-readable storage medium 92, the machine-readable storage medium 92 storing machine-executable instructions that can be executed by the processor 91; the processor 91 is used to execute the machine-executable instructions to implement the large language model terminal threat detection method based on the attack framework disclosed in the above example of this application.

[0071] Based on the same concept as the above method, this application also provides a machine-readable storage medium storing a plurality of computer instructions. When the computer instructions are executed by a processor, they can implement the large language model terminal threat detection method based on the attack framework disclosed in the above examples of this application.

[0072] The aforementioned machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0073] Based on the same application concept as the above method, this application embodiment provides a computer program product, including a computer program, which, when executed by a processor, implements the above-described large language model terminal threat detection method based on an attack framework.

[0074] Those skilled in the art will understand that the embodiments of this application can be provided as methods, apparatus, systems, electronic devices, machine-readable storage media, or computer program products. For example, the specific implementation flow of the apparatus, system, electronic device, machine-readable storage medium, or computer program product can be found in the relevant descriptions in the above method embodiments, and will not be repeated here. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0075] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for terminal threat detection based on a large language model using an attack framework, characterized in that, include: The receiving terminal reports suspicious logs that have been filtered according to data cleaning rules. The data cleaning rules include rules generated using a large language model based on the ATT&CK knowledge base, which identify logs containing technologies from the ATT&CK knowledge base as suspicious logs. The data cleaning rules include a set of technology detection files corresponding to all technologies in the ATT&CK knowledge base, and the suspicious logs are marked with the identifiers of the detected technologies. Threat detection is performed on the suspicious logs based on threat detection rules to identify threat event logs. The threat detection rules include rules generated using a large language model based on the ATT&CK knowledge base and the APT group attack activity analysis report, which identify suspicious context logs that match the threat attack path in the APT group attack activity analysis report as threat event logs. The technologies contained in the threat attack path include those in the ATT&CK knowledge base. The suspicious context logs include a specified number of consecutive logs within a specified time range containing the suspicious logs. The threat detection rules include a set of all threat detection files. Each threat detection file indicates a threat attack path expressed in the corresponding attack order using multiple technology identifiers, and its corresponding attack event. Using a large language model, the threat event log is analyzed based on the threat intelligence knowledge base and / or the event content corresponding to the threat event log. The event content includes: the threat event corresponding to the threat event log, the source of the threat, the time of the threat attack, and the path of the threat attack. If it is determined that the threat event log has malicious intent, a threat report of the threat event log is output; The method further includes: If there are false positives in the threat detection of the threat event log, the false positive information will be stored in the false positive database. The false positive information includes the threat event log, the part of the threat detection rule related to the threat attack path corresponding to the threat event log, and the reason for the false positive corresponding to the threat event log. Using a large language model, based on the false alarm information, if the threat attack paths corresponding to the false alarm threat event logs that exceed the false alarm quantity threshold all contain at least one technology, the technology detection file corresponding to the at least one technology in the data cleaning rules is updated.

2. The method according to claim 1, characterized in that, The data cleaning rules are generated in the following manner: The detection strategies and terminal cleaning rules corresponding to each technology in the ATT&CK knowledge base are used as input to the large language model to generate data cleaning rules in Sigma format. The terminal cleaning rule generation prompts are used to instruct the large language model to output the detection files of each technology in the ATT&CK knowledge base in Sigma format. If the terminal detects that any of the technology detection files contains the corresponding technology in the log, it identifies the log as a suspicious log and adds the identifier of the detected technology to the log.

3. The method according to claim 1, characterized in that, The threat detection rules are generated in the following manner: The attack phases in the APT group's attack activity analysis report are identified using a large language model, and the corresponding technologies in the ATT&CK knowledge base are determined for each attack phase. The attack phase is then assigned a corresponding technology identifier. Using a large language model, based on the identifier of the technology corresponding to the attack stage, the threat attack path in the APT group's attack activity analysis report, and the attack events corresponding to the threat attack path, a threat detection file in a specified format is generated, wherein any threat attack path consists of multiple attack stages in the corresponding attack order.

4. The method according to claim 3, characterized in that, The threat detection process based on threat detection rules, which identifies threat event logs, includes: For any suspicious log, determine the suspicious context log corresponding to that suspicious log; Based on the context order of each log in the suspicious context log and the identifier of the technology added to each log, if the suspicious context log matches any threat detection file in the threat detection rules, the suspicious context log is determined as a threat event log. The threat event and threat attack path corresponding to the threat event log are the attack event and threat attack path indicated in the matched threat detection file. The threat source and threat attack time corresponding to the threat event log are the time when the terminal that reported the threat event log and the time when the terminal that received the threat event log reported the threat event log were respectively.

5. The method according to claim 1, characterized in that, The analysis of the threat event logs using a large language model based on a threat intelligence knowledge base includes: Identify all threat intelligence matching information contained in the threat event log, wherein the threat intelligence matching information includes one or more of IP address, domain name, and file hash; Using a large language model, if any of the threat intelligence matching information matches a malicious element in the threat intelligence knowledge base, it is determined that the threat event log has malicious intent, wherein the malicious element includes one of a malicious IP address, a malicious domain name, or a malicious file hash; The threat report includes malicious tags from the threat intelligence knowledge base.

6. The method according to claim 1, characterized in that, The step of using a large language model to analyze the threat event log based on the event content corresponding to the threat event log includes: Using a large language model, based on the event content corresponding to the threat event log, if it is determined that the threat event log does not conform to normal business rules, it is determined that the threat event log has malicious intent. The normal business rules include the relationship between reasonable business behavior, business source and business time determined by big data. The method further includes: Using a large language model, based on the event content corresponding to the threat event log, and if it is determined that the threat event log conforms to the normal business rules, it is determined that there are false alarms in the threat detection of the threat event log, and the false alarm alarm and the reason for the false alarm are output. The part of the threat detection rules related to the threat attack path corresponding to the threat event log is marked.

7. The method according to claim 6, characterized in that, The step of storing false alarm information in a false alarm database when there are false alarms in the threat detection of the threat event log includes: In the event that there are false alarms in the threat detection of the threat event log, determine the confidence value of the false alarm alert; If the confidence value is equal to or higher than the confidence threshold, or if a false alarm verification confirmation is received for the false alarm, the false alarm information corresponding to the false alarm will be stored in the false alarm database.

8. A large language model-based endpoint threat detection system based on an attack framework, characterized in that, The system includes: A terminal device is used to filter logs according to data cleaning rules and send the filtered suspicious logs to a server device. The data cleaning rules include rules generated using a large language model based on the ATT&CK knowledge base, which identify logs containing technologies in the ATT&CK knowledge base as suspicious logs. The data cleaning rules include a set of technology detection files corresponding to all technologies in the ATT&CK knowledge base, and the suspicious logs are marked with the identifier of the detected technology. A server-side device is used to receive the suspicious logs; perform threat detection on the suspicious logs based on threat detection rules to determine threat event logs. The threat detection rules include rules generated using a large language model based on the ATT&CK knowledge base and APT group attack activity analysis reports, which identify suspicious context logs matching the threat attack paths in the APT group attack activity analysis reports as threat event logs. The technologies contained in the threat attack paths include those in the ATT&CK knowledge base. The suspicious context logs include a specified number or a specified time range of continuous logs containing the suspicious logs. The threat detection rules include a set of all threat detection files, where each threat detection file indicates a threat attack path expressed in the corresponding attack sequence using multiple technology identifiers, and its corresponding attack events. The server-side device uses a large language model based on the threat intelligence knowledge base and / or the threat event logs... The event content corresponding to the threat event log is analyzed, wherein the event content includes: the threat event corresponding to the threat event log, the source of the threat, the time of the threat attack, and the threat attack path; if it is determined that the threat event log has malicious intent, a threat report of the threat event log is output; if there are false positives in the threat detection of the threat event log, the false positive information is stored in the false positive database, the false positive information includes the threat event log, the part of the threat detection rule related to the threat attack path corresponding to the threat event log, and the reason for the false positive corresponding to the threat event log. Using a large language model, based on the false positive information, if there are multiple false positives exceeding the false positive threshold, and the threat attack paths corresponding to the threat event logs all contain at least one technology, the technology detection file corresponding to the at least one technology in the data cleaning rule is updated.

9. An electronic device, characterized in that, Including processor and memory, among which, Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product contains a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images