A method of permeation defence and related apparatus

Abstract

The application discloses a penetration defense method and a related device, and can be applied to various scenes such as cloud technology, cloud security, endpoint security, data security, security protection, artificial intelligence, intelligent transportation, and assisted driving. According to the metadata of the authentication request, the abnormal authentication behavior of the attacker is identified and intercepted in real time, the penetration defense is started from the commonness of the domain penetration attack behavior, the diversified domain penetration attack behavior can be targeted, and the security of the terminal device in the network domain is improved. In addition, the penetration defense based on the metadata of the authentication request does not need to obtain the content of the authentication request, and will not affect the penetration defense effect because the authentication request is encrypted, the applicable scene of the penetration defense method is widened, and the penetration defense can be performed in multiple dimensions from the network level and the host behavior level, the identification accuracy of the abnormal authentication behavior is improved, and the security of the terminal device in the network domain is improved in all directions.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a penetration defense method and related apparatus. Background Technology

[0002] In computer networks, domains can be used to uniformly organize and manage security entities such as user accounts and computers. User accounts log in on computers, and domain controllers (DCs) can authenticate user accounts and assign them access permissions to resources within the domain. For example, Windows domains can be used for the unified organization and management of Windows users and computers. Windows domains are typically used in enterprise environments and can be built based on enterprise members.

[0003] Domain penetration is an attack targeting the domain environment within a network, reducing the security of data and resources within the domain. However, the defensive measures against domain penetration in related technologies are limited in effectiveness and cannot meet actual needs. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a penetration defense method and related apparatus that, starting from the commonalities of domain penetration, conducts multi-dimensional penetration defense to improve the security of network domains.

[0005] The embodiments of this application disclose the following technical solutions: On the one hand, embodiments of this application provide a penetration defense method, the method comprising: Obtain authentication requests sent by terminal devices in the network domain; In response to an authentication request sent by a terminal device in the network domain, the metadata of the authentication request is obtained, wherein the metadata includes an account identifier to be identified and an identifier of the process to be identified for initiating the authentication request. The authentication request is validated using the metadata, wherein the validation includes at least one of process validation or account validation. The process validation is used to identify whether the process identifier to be identified meets the process validation conditions, and the account validation is used to identify whether the account identifier to be identified meets the account validation conditions. If the authentication request fails the legitimacy identification, the process to be authenticated will be intercepted.

[0006] On the other hand, embodiments of this application provide a penetration defense device, the device comprising: The authentication request acquisition unit is used to acquire authentication requests sent by terminal devices in the network domain. The metadata acquisition unit is used to acquire the metadata of the authentication request in response to the authentication request sent by the terminal device in the network domain, wherein the metadata includes the identifier of the account to be identified and the identifier of the process to be identified for initiating the authentication request. A legitimacy identification unit is used to identify the legitimacy of the authentication request through the metadata, wherein the legitimacy identification includes at least one of process legitimacy identification or account legitimacy identification, wherein the process legitimacy identification is used to identify whether the process identifier to be identified meets the process legitimacy conditions, and the account legitimacy identification is used to identify whether the account identifier to be identified meets the account legitimacy conditions; The communication interception unit is used to perform communication interception processing on the process to be authenticated if the authentication request fails the legitimacy identification.

[0007] On the other hand, embodiments of this application provide a computer device, the computer device including a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the penetration defense method according to the instructions in the program code.

[0008] On the other hand, embodiments of this application provide a computer-readable storage medium for storing a computer program for executing the aforementioned penetration defense method.

[0009] On the other hand, embodiments of this application provide a computer program product including instructions that, when run on a computer, cause the computer to perform the penetration defense method described above.

[0010] As can be seen from the above technical solution, the authentication request sent by the terminal device in the network domain is obtained. In response to the authentication request, the metadata of the authentication request is obtained. The metadata of the authentication request includes the identifier of the account to be identified and the identifier of the process to be identified used to initiate the authentication request. Since attackers need to authenticate with the domain controller using the terminal device to access the corresponding service, the domain penetration attack initiated by the attacker always starts with the authentication behavior. Therefore, the legitimacy of the authentication request can be identified based on the metadata of the authentication request. When it is determined that the authentication request fails the legitimacy identification, the authentication behavior is considered an abnormal authentication behavior, and the communication interception process can be performed. That is, the abnormal authentication behavior of the attacker can be identified and intercepted in real time based on the metadata of the authentication request. Penetration defense is based on the commonalities of domain penetration attack behaviors, which can target more diverse domain penetration attack behaviors and improve the security of terminal devices in the network domain. In addition, penetration defense based on the metadata of the authentication request does not require obtaining the content of the authentication request and will not be affected by the encryption of the authentication request, thus broadening the applicable scenarios of the penetration defense method.

[0011] Anomaly authentication behaviors require communication via the initiating process at the network layer and rely on account authentication at the terminal device's host behavior level. Therefore, legitimacy recognition can be implemented, including at least one of process legitimacy recognition or account legitimacy recognition. Process legitimacy recognition checks whether the process identifier to be identified meets the process legitimacy criteria, while account legitimacy recognition checks whether the account identifier to be identified meets the account legitimacy criteria. This multi-dimensional penetration defense from both the network and host behavior levels improves the accuracy of anomaly authentication behavior identification and comprehensively enhances the security of terminal devices within the network domain. Specifically, when it is determined that the process identifier to be identified does not meet the process legitimacy criteria, it indicates that the process to be authenticated is not a normally initiated process, and its communication can be intercepted, allowing for real-time identification and interception of domain penetration attacks at the network layer. Similarly, when it is determined that the account identifier to be identified does not meet the account legitimacy criteria, it indicates that the account identifier to be identified is not a commonly used account identifier on the terminal device, and its communication can be intercepted, allowing for real-time identification and interception of domain penetration attacks at the terminal device's host behavior level. 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 or the prior art 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 A schematic diagram of a penetration defense system provided in an embodiment of this application; Figure 2 A flowchart illustrating a penetration defense method provided in this application embodiment; Figure 3 A schematic diagram of an authentication process based on the Kerberos protocol provided for an embodiment of this application; Figure 4 A schematic diagram of an authentication process based on the NTLM protocol provided for an embodiment of this application; Figures 5A-5D A schematic diagram illustrating the legality identification process provided in this application embodiment; Figure 6A and 6B A schematic diagram illustrating another legality identification process provided in this application embodiment; Figure 7 A schematic diagram illustrating another legality identification process provided in this application embodiment; Figure 8 A schematic diagram illustrating another legality identification process provided in this application embodiment; Figure 9 A structural block diagram of a penetration defense system provided in an embodiment of this application; Figure 10 This is a functional diagram of a traffic monitoring module provided in an embodiment of this application; Figure 11 This is a functional diagram of an authentication protocol parsing module provided in an embodiment of this application; Figure 12 A structural block diagram of a penetration defense device provided in an embodiment of this application; Figure 13 A structural diagram of a terminal device provided in an embodiment of this application; Figure 14 This is a structural diagram of a server provided in an embodiment of this application. Detailed Implementation

[0014] This application provides a penetration defense method and related apparatus, which starts from the commonalities of domain penetration, carries out multi-dimensional penetration defense, and improves the security of network domains.

[0015] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “corresponding to,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Domain penetration refers to attacks targeting the domain environment within a network, reducing the security of data and resources within the domain. However, existing defenses against domain penetration have limited effectiveness, only addressing specific attack behaviors and failing to identify or block attacks containing encrypted data in real time, thus failing to meet practical needs. To improve network domain security, this application provides a penetration defense method and related apparatus that addresses the commonalities of domain penetration, implementing multi-dimensional penetration defense to effectively improve network domain security.

[0017] The penetration testing and defense method provided in this application can be implemented using a computer device, which can be a terminal device, including but not limited to mobile phones, computers, smart voice interaction devices, smart home appliances, and vehicle terminals. The terminal device and the server can be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitations on this connection. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing services such as cloud security, endpoint security, data security, security protection, and cloud computing. This application can be applied to various scenarios, including but not limited to cloud technology, cloud security, data security, security protection, artificial intelligence, smart transportation, and assisted driving.

[0018] As disclosed in this application, the penetration defense method or apparatus may include multiple servers forming a blockchain, where the servers are nodes on the blockchain.

[0019] It is understood that in the specific implementation of this application, data related to user accounts is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0020] The embodiments of this application will now be described with reference to the accompanying drawings.

[0021] This application provides a penetration defense method that is applied to... Figure 1 The penetration defense system, as shown in the figure, includes a server 20 and at least one terminal device 10. The client is deployed on the terminal device 10. The server 20 acts as a domain controller in the network domain. The client can run on the terminal device 10 via a browser or as a standalone application (APP). The specific form of the client is not limited here. The penetration defense method can be applied to the terminal device 10 and deployed within security defense products on the terminal device 10, such as zero-trust products, enterprise-level endpoint detection and response (EDR) products, or host antivirus software products.

[0022] In domain penetration attacks, attackers need to authenticate with the domain controller using terminal device 10 before accessing corresponding services. Since an attacker's domain penetration attack always begins with authentication, the legitimacy of the authentication request can be determined based on its metadata. Specifically, the client can obtain the authentication request sent by terminal device 10 in the network domain and acquire its metadata. This metadata includes the identifier of the account to be identified and the identifier of the process to be authenticated that initiated the authentication request.

[0023] When an authentication request fails the legitimacy check, it is considered an abnormal authentication behavior, and the authentication process can be intercepted. This means that abnormal authentication behavior by attackers can be identified and intercepted in real time based on the metadata of the authentication request. By addressing the commonalities of domain penetration attacks, penetration defense can target more diverse domain penetration attack behaviors and improve the security of terminal devices in the network domain. Furthermore, penetration defense based on the metadata of the authentication request does not require obtaining the content of the authentication request and is not affected by the encryption of the authentication request, thus broadening the applicable scenarios of penetration defense methods.

[0024] Abnormal authentication behavior requires communication through the initiating process at the network layer and relies on account authentication at the host behavior level of the terminal device. Therefore, legitimacy recognition can be set up, including at least one of process legitimacy recognition or account legitimacy recognition. Process legitimacy recognition is used to identify whether the process identifier to be identified meets the process legitimacy conditions, and account legitimacy recognition is used to identify whether the account identifier to be identified meets the account legitimacy conditions. This multi-dimensional penetration defense from the network layer and the host behavior layer improves the accuracy of abnormal authentication behavior identification and comprehensively enhances the security of terminal devices in the network domain.

[0025] Specifically, when it is determined that the process identifier to be identified does not meet the process legitimacy conditions, it means that the process to be identified is not a normally initiated process, and communication interception processing can be performed on the process to be authenticated, so as to identify and intercept domain penetration attack behavior in real time at the network level; when it is determined that the account identifier to be identified does not meet the account legitimacy conditions, it means that the account identifier to be identified is not a commonly used account identifier of terminal device 10, and communication interception processing can be performed on the process to be authenticated, so as to identify and intercept domain penetration attack behavior in real time at the host behavior level of terminal device 10.

[0026] Based on the above introduction, the penetration defense method in this application will be described below. (See also...) Figure 2 The flowchart below illustrates a penetration defense method provided in an embodiment of this application. The method includes: S101, Obtain authentication requests sent by terminal devices in the network domain.

[0027] S102, in response to an authentication request sent by a terminal device in the network domain, obtain the metadata of the authentication request.

[0028] S103, verify the legitimacy of the authentication request through metadata, including at least one of process legitimacy verification or account legitimacy verification.

[0029] S104: If the authentication request fails the legitimacy verification, the process that initiated the authentication request will be intercepted.

[0030] In computer networks, user accounts and computers, as security entities, can be uniformly organized and managed in the form of domains (also known as network domains). User accounts log in on computers, and the domain controller, as a server within the domain, can authenticate user accounts and assign them access permissions to resources within the domain. For example, Windows domains can be used for the unified organization and management of Windows users and computers. Windows domains are typically used in enterprise environments and can be built based on the enterprise's members.

[0031] Taking a Windows domain as an example, the domain controller, also known as a domain manager, is the most important server within a Windows domain. It stores the hash values ​​of passwords for user accounts and computers within the domain and runs various services that support the normal operation of Windows Active Directory (AD), such as Kerberos, Lightweight Directory Access Protocol (LDAP), Domain Name System (DNS), Network Time Protocol (NTP), and various Remote Procedure Call Protocol (RPC) services. Windows Active Directory is a directory service used for unified management of users and computers in a Windows domain. It provides various services required by the Windows domain environment, such as centralized enterprise-level user account and computer configuration management, software management, unified identity authentication, and permission granting functions.

[0032] Domain penetration refers to attacks targeting the domain environment within a network. Lateral movement is a crucial element of domain penetration attacks. Lateral movement refers to the attacker's actions of gaining access to one terminal device and then attempting to acquire privileges on other hosts within the network environment to further escalate privileges, expand the attack's reach, and reduce the security of data and resources within the domain. However, existing defenses against domain penetration attacks have limited effectiveness and fail to meet practical needs.

[0033] As an attack defense technology, network traffic analysis-based attack defense technology mainly detects attacks at the network communication level. It can capture and analyze network traffic, and use attack traffic identification technology to determine whether the traffic is attack traffic. Once attack traffic is identified, it will issue an alarm or block it. However, this method often requires preset rules or setting up traffic identification models. Preset rules require human resources to maintain and can only target specific attack behaviors corresponding to the preset rules. They cannot effectively identify other attack behaviors. If multiple attack behaviors need to be identified, a large number of preset rules need to be set. In addition, this attack traffic identification technology has limited ability to identify encrypted traffic.

[0034] As another attack defense technology, host behavior detection-based attack defense involves dynamic behavior detection on the user's host. It detects and defends against attacks by identifying malicious behavior, primarily detecting command execution, file access, process access, registry operations, and pipe operations by host processes. It determines whether an operation is malicious by identifying the initiator and the target of the operation. Host behavior can include user-level and kernel-level behavior. User-level behavior can be detected through API hooking, while kernel-level behavior can be detected through API hooking, registering kernel callbacks, and Intel-VT hardware virtualization technology (VT). However, host behavior detection technology requires pre-defined malicious behavior rules, consuming significant manpower for rule maintenance. It is only effective against specific attack methods and cannot effectively identify other attack behaviors. If multiple attack behaviors need to be identified, a large number of malicious behavior rules need to be set. Furthermore, it offers no defense against attack methods that do not generate relevant host behavior.

[0035] As another attack defense technology, attack defense technology based on host log analysis can be divided into attack defense technology based on terminal log analysis and attack defense technology based on domain controller log analysis, depending on the location of log collection. However, in attack defense technology based on log analysis, since the attack behavior is usually executed when the log is generated, this method cannot be intercepted in real time, but can only perform alerts and post-event analysis.

[0036] In some attack scenarios, attackers can implant network proxies on the victim's host to forward malicious attack traffic. All network authentication requests and attack traffic are initiated by the proxy. In this scenario, the victim's host does not exhibit abnormal host behavior, and most network requests are encrypted. Therefore, attack defense technologies based on host behavior detection are difficult to detect. In other attack scenarios, attackers run custom malware on the victim's host to construct network authentication requests. These constructed network requests are also mostly encrypted, making them difficult to detect using attack traffic identification technologies and attack defense technologies based on host behavior detection. In yet another attack scenario, attackers can use system APIs for network authentication. Attackers can implant Trojan programs on the victim's host and use these Trojan programs to call system APIs. For example, using obtained high-privilege user credentials, they can authenticate as a high-privilege user, create user sessions, execute commands, or import high-privilege user credentials into the current session, thus initiating or completing authentication using system processes. In this attack scenario, network authentication requests are initiated by system processes, making it difficult to distinguish from authentication traffic initiated by normal system processes based on the content of the authentication traffic. Detection of this type of attack is quite difficult.

[0037] The inventors discovered through research that, despite the variety of attack methods in domain penetration attacks, attackers in all these methods need to authenticate with the domain controller using their terminal devices to access the corresponding services. In other words, every domain penetration attack begins with authentication. Therefore, the legitimacy of authentication requests can be assessed, and whether a request is abnormal can be determined. If so, an attack may be imminent. This application's embodiments address penetration defense by focusing on the commonalities of domain penetration attack behaviors. This approach can defend against a wider range of domain penetration attack behaviors, and to some extent, defend against unknown domain penetration attacks, improving the security of terminal devices within the network domain. It also solves the problems of maintaining numerous rules based on rule-based detection, and the difficulty in developing corresponding rules for some attack methods.

[0038] In this embodiment, authentication requests sent by terminal devices in a network domain can be obtained. Based on these requests, metadata is acquired, and the validity of the authentication requests is assessed using this metadata. The metadata describes the authentication request and includes an account identifier to be identified and an identifier for the process to be identified that initiated the authentication request. The account identifier may include at least one of the following: the account name, the terminal device name, or the Active Directory domain name. The process identifier may include at least one of the following: the executable file name, the process signature, or a hash value. Penetration defense based on the metadata of the authentication request does not require obtaining the content of the authentication request and is not affected by the encryption of the authentication request, thus broadening the applicable scenarios of the penetration defense method and solving the problem of encrypted attack traffic being difficult to detect.

[0039] When an authentication request fails the legitimacy check, it is identified as an abnormal authentication behavior. Communication interception of the authentication process can then be implemented, meaning that abnormal authentication behavior by attackers can be identified and blocked in real time based on the authentication request's metadata. Abnormal authentication behavior requires communication through the initiating process at the network layer and relies on account authentication at the terminal device's host behavior level. Therefore, legitimacy checks can be configured to include at least one of process legitimacy checks or account legitimacy checks. Process legitimacy checks assess whether the process identifier meets the process legitimacy criteria, while account legitimacy checks assess whether the account identifier meets the account legitimacy criteria. This multi-dimensional penetration defense from both the network and host behavior levels improves the accuracy of abnormal authentication behavior identification and comprehensively enhances the security of terminal devices within the network domain.

[0040] Specifically, when it is determined that the process identifier to be identified does not meet the process legitimacy conditions, it indicates that the process to be authenticated is not a normally initiated process, but a process established by an attacker using the terminal device. The sending of this authentication request is an abnormal authentication behavior. Therefore, communication interception processing can be performed on the process to be authenticated, and domain penetration attack behavior can be identified and intercepted in real time at the network level, ensuring the security of terminal devices in the network domain. When it is determined that the account identifier to be identified does not meet the account legitimacy conditions, it indicates that the account identifier to be identified is not a normally used account identifier of the terminal device, but an other account identifier used by an attacker using the terminal device. The sending of this authentication request is an abnormal authentication behavior. Therefore, communication interception processing can be performed on the process to be authenticated, and domain penetration attack behavior can be identified and intercepted in real time at the host behavior level of the terminal device, ensuring the security of terminal devices in the network domain.

[0041] In S101, authentication requests sent by terminal devices within the network domain can be retrieved. Specifically, the authentication protocol used in the authentication request can be of type 1, such as Kerberos; or it can be of type 2, such as New Technology LAN Manager (NTLM). NTLM is a query / response authentication protocol, an embedded authentication protocol. NTLM messages are embedded in the communication traffic of other protocols, such as Server Message Block (SMB), MS-RPC, Hypertext Transfer Protocol (HTTP), LDAP, DCOM, WMI, NBSS, and Windows Remote Management (WinRM). In practical applications, most domain penetration attacks rely on either Kerberos or NTLM protocols.

[0042] Kerberos, proposed by MIT, is a two-way authentication protocol suitable for distributed network environments. It relies on symmetric encryption, allowing clients and servers to simultaneously prove their identity to each other. It also provides clients with unified authentication functionality, requiring only one password to authenticate with all services in the current domain. Microsoft added some features to the MIT implementation of Kerberos and uses it as the default authentication protocol in Windows domain environments.

[0043] The Kerberos protocol communication process involves three entities: the client, the application server, and the key distribution center (KDC). See [link to relevant documentation]. Figure 3 This diagram illustrates an authentication process based on the Kerberos protocol, as provided in this application embodiment. The KDC includes two key services: Authentication Server (AS) and Ticket Granting Server (TGS). In the Windows implementation, the domain controller acts as the KDC, with both the AS and TGS services residing on the domain controller, serving as the AS server and TGS server, respectively.

[0044] See Figure 3The authentication process based on the Kerberos protocol can include three stages: AS request (REQ) / AS response (REP), TGS request (REQ) / TGS response (REP), and Application Service (AP) request (REQ) / AP response (REP). In the AS-REQ / AS-REP stage, the client communicates with the AS server. The client uses its user key to encrypt a timestamp and sends the encrypted data to the AS server via an AS-REQ message. The KDC, acting as the AS server, also stores the user key and uses it to decrypt the encrypted data in the AS-REQ to verify the user's identity. After successful authentication, the user logs in successfully, and the AS server generates a Ticket Granting Ticket (TGT) and returns it to the client via an AS-REP message. Both the AS-REQ and AS-REP messages contain the identifier of the account to be identified and the identifier of the domain to be identified. For example, the identifier of the account to be identified is the account name, represented as a CNAME, which could be "Administrator". During the TGS-REQ / TGS-REP phase, after successful user authentication, if the client needs to access services on the server, it must use its existing TGT to request a Service Ticket (ST) from the TGS server via TGS-REQ. The TGS server then sends the ST to the client via TGS-REP. Both the TGS-REQ and TGS-REP messages contain the identifier of the service to be authenticated. During the AP-REQ / AP-REP phase, after receiving the ST, the client can submit it to the server via AP-REQ. The server verifies the validity of the ST; if the ticket is valid, it returns an AP-REP, allowing the client to successfully authenticate and access services on the server.

[0045] Services in a Windows domain environment can be represented by an identifier called the Service Principal Name (SPN). An SPN is essentially a unique string bound to a service account, usually consisting of the service name and the hostname. For example, the SPN of the SMB service on a host named dc.xlab.sec is cifs / dc.xlab.sec.

[0046] Kerberos-based attack methods can include AS-REP Roasting attacks, Kerberoasting attacks, Kerberos delegation attacks, Kerberos certificate authentication attacks, ticket delivery attacks, and golden ticket attacks. When the authentication protocol type is Kerberos, the authentication request type can be at least one of AS-REQ or TGS-REQ, meaning it can retrieve either an AS-REQ sent by an end device in the network domain or a TGS-REQ sent by an end device in the network domain.

[0047] NTLM is an early authentication protocol for Windows, which was retained for compatibility reasons. It also supports unified identity authentication within Windows domains and is one of the important authentication protocols supported by default in Windows domains. The NTLM protocol is based on the challenge / response authentication model. The authentication process is mainly divided into three phases: the negotiation phase by sending the NTLM_NEGOTIATE (also known as the NTLM Type 1 Message) message, the challenge phase by sending the NTLM_CHALLENGE (also known as the NTLM Type 2 Message) message, and the authentication phase by sending the NTLM_AUTH (also known as the NTLM Type 3 Message) message.

[0048] See Figure 4 This diagram illustrates an NTLM-based authentication process according to an embodiment of this application. During the negotiation phase, the client sends an NTLM_NEGOTIATE negotiation message to the server, informing the server of the NTLM options supported by the client, such as message signatures and encryption algorithms. During the challenge phase, after receiving the client's request, the server sends an NTLM_CHALLENGE message to the client. This message contains a random number representing the NTLM options supported by the server; this random number is the server challenge and can be an 8-byte random number. During the authentication phase, after receiving the server challenge, the client uses the hash value of the password claim to encrypt the challenge, generates response data, and sends the response data to the server via NTLM_AUTH. After receiving the response data, the server submits it to the domain controller via the NETLOGON protocol. The domain controller verifies the response; if correct, the user successfully logs in.

[0049] Attacks based on the NTLM protocol can include hash pass-through attacks, CVE-2021-42278, CVE-2021-42287, etc. When the authentication protocol type is NTLM, the authentication request type can be NTLM Type3Message, which can obtain the NTLM Type3 Message sent by the terminal device in the network domain.

[0050] Authentication protocols can be sent through the port of the terminal device, and authentication requests can be obtained through the target port of the terminal device. The target port can be the port corresponding to the authentication protocol. In practice, authentication requests sent through that port can be obtained by detecting the port, i.e., port traffic monitoring of the terminal device. Port traffic monitoring can be implemented using Windows Filter Platform (WFP) network driver filtering technology. The program required by this technology can run at the kernel level. Of course, traffic monitoring can also be implemented through Transport Driver Interface (TDI) technology or user layer hook technology. When the authentication protocols include Kerberos and NTLM protocols, in order to detect the traffic of Kerberos and NTLM protocols, traffic monitoring can be performed on the ports corresponding to these two protocols. See Table 1 for examples of ports for traffic monitoring.

[0051] Table 1 shows the ports used for traffic monitoring.

[0052] Traffic monitoring using WFP can be specifically achieved by setting four filter points and a custom callout function. The four filter points can be FWPM_LAYER_STREAM_V4, FWPM_LAYER_STREAM_V6, FWPM_LAYER_DATAGRAM_DATA_V4, and FWPM_LAYER_DATAGRAM_DATA_V6. FWPM_LAYER_STREAM_V4 and FWPM_LAYER_STREAM_V6 are used to monitor IPv4 / IPv6 TCP communication, while FWPM_LAYER_DATAGRAM_DATA_V4 and FWPM_LAYER_DATAGRAM_DATA_V6 are used to monitor IPv4 / IPv6 UDP communication. In this way, traffic from ports not belonging to the monitored traffic is allowed to pass directly, while information about traffic from ports belonging to the monitored traffic is obtained by the custom callout function.

[0053] In S102, the metadata of the authentication request can be obtained based on the authentication request. The metadata is data used to describe the authentication request, which may include the account identifier to be identified, the process identifier to be identified (PID), etc. In addition, the metadata may also include the protocol type, source address, destination address, source port, and destination port of the authentication protocol.

[0054] For example, when the authentication protocol of the authentication request is the Kerberos protocol, the metadata may include the communication protocol type (e.g., TCP / UDP), the request protocol type (e.g., AS-REQ / TGS-REQ), the source address, the destination address, the source port, the destination port, the identifier of the process to be identified, the command line of the process to be identified, the identifier of the account to be identified, the identifier of the domain to be identified, and the identifier of the service to be identified. The protocol type of the authentication protocol can be determined based on the request protocol type. The identifier of the account to be identified and the identifier of the domain to be identified can be obtained from AS-REQ, and the identifier of the service to be identified can be obtained from TGS-REQ.

[0055] When the authentication protocol of the authentication request is the NTLM protocol, the authentication request can be obtained from the data of other protocols that embed the NTLM protocol. Other protocols include MS-RPC, DCOM, WMI, SMB, NBSS, WinRM, etc. The metadata can include the communication protocol type (e.g., TCP / UDP), sub-protocol type (e.g., MS-RPC / DCOM / WMI / SMB / NBSS / WinRM / LDAP), source address, destination address, source port, destination port, identifier of the process to be identified, command line of the process to be identified, identifier of the account to be identified, identifier of the domain name to be identified, identifier of the service to be identified, etc. The protocol type of the authentication protocol can be determined based on the sub-protocol type.

[0056] Authentication requests include encrypted data packets. Since the legitimacy of authentication requests depends on the metadata of the authentication requests, which contains a large amount of plaintext data, the accuracy of legitimacy identification is not affected even if the authentication request includes encrypted data packets.

[0057] The metadata of an authentication request can be obtained by parsing the authentication request. Parsing can be performed according to protocol parsing control rules, which define the protocols that need to be parsed. If the authentication request uses a protocol that requires parsing, its metadata is retrieved. If the protocol used in the authentication request is determined by the protocol parsing control rules to be a protocol that does not require parsing, then metadata retrieval is not necessary. Protocol parsing control rules can be centrally managed by the enterprise administrator, and terminal devices can look them up as needed. Configuration by the terminal devices themselves is not allowed to ensure the security of protocol parsing. When parsing an authentication request, if the metadata does not contain a certain field, that field can be left empty when retrieving the metadata. Other protocols embedding the NTLM protocol may contain encrypted fields; these encrypted fields do not need to be decrypted when retrieving metadata.

[0058] In S103, the legitimacy of authentication requests can be identified through metadata. The legitimacy identification of authentication requests includes at least one of process legitimacy identification or account legitimacy identification. Process legitimacy identification is used to identify whether the process identifier to be identified meets the process legitimacy conditions, thereby determining whether the process to be authenticated is a forged process, effectively identifying authentication requests made by network proxy program creation processes and authentication requests made by custom malicious program creation processes. Account legitimacy identification is used to identify whether the account identifier to be identified meets the account legitimacy conditions, thereby determining whether the account identifier to be identified is a legitimate account, effectively identifying Trojan programs calling system APIs to perform identity authentication as high-privilege users, etc. The process legitimacy conditions are determined according to the protocol type of the authentication protocol used in the authentication request, and the account legitimacy conditions are determined according to the terminal device.

[0059] Specifically, the authentication protocol type can be determined based on the authentication protocol, and the process legitimacy conditions can be determined based on the authentication protocol type. The authentication protocol type can be a first type, such as the Kerberos protocol, or a second type, such as the NTLM protocol. Similarly, account legitimacy conditions can be determined based on the terminal device's account information. For example, the terminal device's account information could be a legitimate account identifier bound to the terminal account; therefore, the account legitimacy conditions could include the legitimate account identifier bound to the terminal device.

[0060] In some possible implementations, the identification of the legitimacy of authentication requests includes process legitimacy identification, see [link to relevant documentation]. Figure 5AThis is a schematic diagram of a legitimacy identification method provided in an embodiment of this application. The metadata of the authentication request may also include the authentication protocol used by the authentication request. The legitimacy identification of the authentication request through the metadata may specifically be as follows: determine the protocol type of the authentication protocol according to the authentication protocol, determine the process legitimacy conditions according to the protocol type of the authentication protocol, identify the compliance of the process identifier to be identified with the process legitimacy conditions based on the process legitimacy conditions, determine that the authentication request has failed the legitimacy identification when the process identifier to be identified does not meet the process legitimacy conditions, and determine that the authentication request has passed the legitimacy identification when the process identifier to be identified meets the process legitimacy conditions.

[0061] In some other possible implementations, the verification of the authentication request's legitimacy includes account legitimacy verification, see [link to relevant documentation]. Figure 5B This is a schematic diagram of another legitimacy identification provided by an embodiment of this application. In this case, legitimacy identification of the authentication request is performed through metadata. Specifically, the account legitimacy conditions are determined based on the account information of the terminal device. Based on the account legitimacy conditions, the compliance of the account identifier to be identified with the account legitimacy conditions is identified. When the compliance condition is that the account identifier to be identified does not meet the account legitimacy conditions, it is determined that the authentication request has failed the legitimacy identification. When the compliance condition is that the account identifier to be identified meets the account legitimacy conditions, it is determined that the authentication request has passed the legitimacy identification.

[0062] In some other possible implementations, the verification of the authentication request's legitimacy includes process legitimacy verification and account legitimacy verification; see [link to relevant documentation]. Figure 5C This diagram illustrates another method of legitimacy identification provided in this application. The metadata of the authentication request may also include the authentication protocol used by the authentication request. Specifically, legitimacy identification of the authentication request through metadata can involve first identifying the process legitimacy, and then identifying the account legitimacy. Specifically, the protocol type of the authentication protocol can be determined based on the protocol type, and the process legitimacy conditions can be determined based on the protocol type. Based on the process legitimacy conditions, the compliance of the process identifier to be identified with the process legitimacy conditions is identified. When the compliance condition is that the process identifier to be identified meets the process legitimacy conditions, the account legitimacy conditions are determined based on the account information of the terminal device. Based on the account legitimacy conditions, the compliance of the account identifier to be identified with the account legitimacy conditions is identified. When the compliance condition is that the account identifier to be identified does not meet the account legitimacy conditions, it is determined that the authentication request has failed legitimacy identification. Of course, if it is determined that the process identifier to be identified does not meet the process legitimacy conditions, and the authentication request has failed legitimacy identification, then account legitimacy identification may not be performed; if it is determined that the account identifier to be identified meets the account legitimacy conditions, then the authentication request has passed legitimacy identification.

[0063] In some other possible implementations, the verification of the authentication request's legitimacy includes process legitimacy verification and account legitimacy verification; see [link to relevant documentation]. Figure 5D This diagram illustrates another method of legitimacy identification provided in this application. The metadata of the authentication request may also include the authentication protocol used by the authentication request. Specifically, legitimacy identification of the authentication request through metadata can involve first identifying the account legitimacy, and then identifying the process legitimacy. Specifically, account legitimacy conditions can be determined based on the account information of the terminal device. Based on these conditions, the compliance of the account identifier to be identified with the account legitimacy conditions is identified. When the compliance is that the account identifier to be identified meets the account legitimacy conditions, the protocol type of the authentication protocol is determined according to the authentication protocol, and the process legitimacy conditions are determined based on the protocol type. Based on these conditions, the compliance of the process identifier to be identified with the process legitimacy conditions is identified. When the compliance is that the process identifier to be identified does not meet the process legitimacy conditions, the authentication request is determined to have failed legitimacy identification. Of course, if the authentication request fails legitimacy identification when the account identifier to be identified does not meet the account legitimacy conditions, process legitimacy identification may not be performed; if the authentication request meets the process legitimacy conditions, the authentication request is determined to have passed legitimacy identification.

[0064] Process legitimacy identification is used to determine whether the process identifier to be identified meets the process legitimacy conditions, thereby determining whether the process to be authenticated is a forged process. Process legitimacy identification can be implemented in different ways depending on the type of authentication protocol.

[0065] Specifically, identifying the compliance of the process identifier to be identified with the process validity conditions can be achieved by: when the authentication protocol type is determined to be Type 1, determining the process category indicated by the process identifier and the process validity conditions. The process validity conditions can include the process category corresponding to Type 1. The compliance of the process category with the process validity conditions is then assessed. If the process category does not comply with the process validity conditions, the process identifier is determined to be invalid. For example, if the authentication protocol is Kerberos, which belongs to Type 1, and the corresponding process category is Local Security Authority Service (LSASS), then if the process category is not LSASS, the process identifier is determined to be invalid. Specifically, the process identifier in the metadata can be compared with the process ID (PID) of the LSASS process to determine if the process category is LSASS. The LSASS process ID is obtained when the terminal device starts.

[0066] In practice, when determining that the process category to be identified meets the process legitimacy criteria, the process identifier to be identified can be directly determined to meet the process legitimacy criteria. Furthermore, when determining that the process category to be identified meets the process legitimacy criteria, it can also be determined whether the process signature of the process to be authenticated is a valid signature. If not, the process identifier to be identified is determined to not meet the process legitimacy criteria; if so, the process identifier to be identified is determined to meet the process legitimacy criteria. For example, after determining that the process category to be identified is the LSASS process category, the process signature and hash value of the process to be authenticated can be verified based on the LSASS process's process signature to prevent attackers from forging processes with the same name.

[0067] Specifically, identifying the compliance of the process identifier with the process validity conditions based on process validity conditions can be achieved as follows: When the authentication protocol type is determined to be Type II, the signature of the process to be identified, as indicated by the process identifier, and the process validity conditions are determined. The process validity conditions include the valid signature of the process to be authenticated under the authentication protocol. The compliance of the process signature with the process validity conditions is then identified. If the signature does not comply with the process validity conditions, the process identifier is determined to be invalid. Conversely, if the signature complies with the process validity conditions, the process identifier is determined to be valid. For example, if the authentication protocol is NTLM (Type II), the process to be authenticated under NTLM has a valid signature. If the process to be authenticated does not have a signature, or the signature differs from the valid signature, then the signature of the process to be identified is determined to be invalid.

[0068] By identifying account legitimacy conditions, privilege escalation attempts on terminal devices can be detected. Privilege escalation refers to an attacker attempting to gain permissions at the same level as or alter the level of another account. Specifically, based on account legitimacy conditions, the compliance of the account to be identified with these conditions can be determined. This includes identifying the legitimate account identifier bound to the terminal device, and then assessing the compliance of the account to be identified with these conditions. In practice, if the account to be identified and the legitimate account identifier do not match, the account to be identified is deemed not to meet the account legitimacy conditions; if they match, the account to be identified is considered to meet the account legitimacy conditions.

[0069] This can be achieved by initializing the terminal device within the network domain, obtaining the legitimate account identifier bound to the terminal device. This legitimate account identifier can be a domain-specific account identifier or the terminal device's own account identifier. The legitimate account identifier is obtained and stored during the initial initialization, for example, in the registry, and can be retrieved when needed. In other words, if the account indicated by the pending account identifier does not match the legitimate account identifier, it indicates that the pending account identifier is not a commonly used account identifier for that terminal device. This often suggests that an attacker is using a planted Trojan program to call system APIs and authenticate using a different account, thus confirming that the pending account identifier does not meet the account legitimacy requirements.

[0070] The following explanation uses the example of legitimacy identification, which includes process legitimacy identification and account legitimacy identification, with process legitimacy identification performed first and then account legitimacy identification.

[0071] See Figure 6A This is a schematic diagram of another legitimacy identification process provided in this application embodiment. When the protocol type of the authentication protocol is determined to be the first type based on the metadata of the authentication request, for example, the protocol type of the authentication protocol is determined to be the Kerberos protocol based on the metadata of AS-REQ or TGS-REQ, process legitimacy identification is first performed. The process legitimacy conditions are determined according to the authentication protocol, including the process category corresponding to the first type, such as the LSASS process category. Process legitimacy identification can specifically be to determine whether the process category of the process to be authenticated is the process category corresponding to the first type, such as whether it is an LSASS category process. If not, it is determined that the process identifier to be identified does not meet the process legitimacy conditions, and the authentication request fails the legitimacy identification. If yes, it is determined that the authentication request passes the process legitimacy identification, and account legitimacy identification can be performed. In account legitimacy verification, the account legitimacy conditions can be determined based on the account information of the terminal. The account legitimacy conditions may include the legitimate account identifier bound to the terminal. Specifically, account legitimacy verification can be determined by judging whether the account identifier to be identified is a legitimate account identifier bound to the terminal device. If not, it is determined that the account identifier to be identified does not meet the account legitimacy conditions, and the authentication request fails the legitimacy verification. If yes, it is determined that the account identifier to be identified meets the account legitimacy conditions, and the authentication request passes the legitimacy verification.

[0072] See Figure 6BThis is a schematic diagram of another legitimacy identification process provided in this application embodiment. When the type of the authentication protocol is determined to be the second type based on the metadata of the authentication request, for example, when the protocol type is determined to be NTLM based on the metadata of NTLM Type3 Message (NTLM_AUTH), process legitimacy identification is first performed. The process legitimacy conditions determined according to the authentication protocol include whether the process signature is a valid signature. Specifically, process legitimacy identification can be performed by determining whether the process signature of the process to be authenticated is a valid signature. If not, it is determined that the process identifier to be identified does not meet the process legitimacy conditions, and the authentication request fails legitimacy identification. If yes, it is determined that the authentication request passes process legitimacy identification, and account legitimacy identification can proceed. In account legitimacy identification, account legitimacy conditions can be determined based on the terminal's account information. Account legitimacy conditions can include a valid account identifier bound to the terminal. Specifically, it can be performed by determining whether the account identifier to be identified is a valid account identifier bound to the terminal device. If not, it is determined that the account identifier to be identified does not meet the account legitimacy conditions, and the authentication request fails legitimacy identification. If yes, it is determined that the account identifier to be identified meets the account legitimacy conditions, and the authentication request passes legitimacy identification.

[0073] In this embodiment, when it is determined that the authentication request fails the process legitimacy identification, it can be determined whether the process identifier to be identified is in the secure process list. If so, the process indicated by the process identifier is determined to be a secure process, and communication of the process to be authenticated can be allowed, or the account legitimacy identification can continue. If not, the process indicated by the process identifier is determined to be an insecure process. Combined with the fact that the authentication request failed the legitimacy identification, the authentication request is considered an abnormal authentication behavior, and it can be determined that the authentication request failed the legitimacy identification. Whether the process identifier to be identified is in the secure processes can be determined by comparing process hash values. The secure process list can be centrally managed by the enterprise administrator, and terminal devices can search for it when needed. The secure process list can be modified by users of the terminal devices through the terminal devices, and the modification information of the secure process list through the terminal devices is recorded.

[0074] In this embodiment, the metadata may also include a service identifier to be identified. When the authentication protocol type is determined to be the first type, it can be determined whether the service identifier to be identified is a service identifier in the service list to be authenticated. If so, it is determined that the service identifier to be identified corresponds to the service to be detected, and the service has high security requirements, so account legitimacy identification can continue. If not, it is determined that the service identifier to be identified does not correspond to the service to be detected, and the service has low security requirements, so account legitimacy identification can be omitted and communication of the authentication process can be allowed. The service list to be authenticated provides fine-grained defense functions for services and can be centrally managed by enterprise administrators. Terminal devices can search for it when needed. Terminal devices cannot modify the service list to be authenticated to ensure the accuracy of domain penetration attack detection.

[0075] Similarly, when the metadata includes a service identifier to be identified, after the authentication protocol's protocol type is set to Type 1, it can be determined whether the service identifier to be identified belongs to the security service list. If it does, it indicates that the service identifier corresponds to a high-security service, and communication of the authentication process can be allowed without account legitimacy verification. If not, it indicates that the service identifier corresponds to a low-security service, and account legitimacy verification can then be performed. The security service list provides fine-grained defense capabilities for services and can be centrally managed by enterprise administrators. End devices can search for the list when needed, and end devices cannot modify the security service list to ensure the accuracy of domain penetration attack detection.

[0076] In this embodiment of the application, when the protocol type of the authentication protocol is determined to be the second type, it can be determined whether the account identifier to be identified is empty. If the account identifier to be identified is an anonymous account, it is set to empty. If so, it is determined that the account indicated by the account identifier to be identified is an anonymous account, and the communication of the authentication process can be allowed without account legitimacy identification. If not, account legitimacy identification can be performed.

[0077] In this embodiment, a response message to the authentication request can also be obtained to determine whether the authentication result in the response message is successful. For example, when the authentication request is an AS-REQ message, the response message is an AS-REP message; when the authentication request is a TGS-REQ message, the response message is a TGS-REP message; and when the authentication request is an NTLM Type3 Message (NTLM_AUTH) message, the response message is a corresponding login success response. If the authentication result in the response message is determined to be unsuccessful, it is determined that the account indicated by the account identifier to be identified will not obtain subsequent services, and therefore communication of the authentication process can be allowed. If the authentication result in the response message is determined to be successful, it is necessary to continue to verify the legitimacy of the authentication request, for example, by verifying the legitimacy of the account in the authentication request.

[0078] In this embodiment, it can also be determined whether the account identifier to be identified is an account identifier in the secure account list. If so, it is determined that the account identifier to be identified corresponds to a high-security account, and communication of the authentication process can be allowed without account legitimacy verification. If not, it is determined that the account identifier to be identified corresponds to a low-security account, and account legitimacy verification can be performed. The secure account list can be centrally managed by the enterprise administrator, and terminal devices can search for it when needed. The secure account list can be modified by users of the terminal devices through the terminal devices, and the modification information of the secure account list through the terminal devices is recorded.

[0079] The steps described above, such as determining whether the process identifier to be identified is in the list of secure processes, determining whether the service identifier to be identified is a service identifier in the list of services to be authenticated, determining whether the account identifier to be identified is empty, determining whether the authentication result in the response message is successful, and determining whether the account identifier to be identified is an account identifier in the list of secure accounts, can all be performed before account legitimacy identification. In scenarios where multiple steps in these determination steps are performed, the order of the steps can be arbitrarily set.

[0080] The following explanation uses the example of performing multiple of the above-mentioned determination steps.

[0081] See Figure 7This is a schematic diagram of another legitimacy identification process provided in this application embodiment. When the protocol type of the authentication protocol is determined to be the first type based on the metadata of the authentication request, for example, the protocol type of the authentication protocol is determined to be the Kerberos protocol based on the metadata of AS-REQ or TGS-REQ, process legitimacy identification is first performed. The process legitimacy conditions are determined according to the authentication protocol, including the process category corresponding to the first type, such as the LSASS process category. The process legitimacy identification can be specifically determined by judging whether the process category of the process to be authenticated is the process category corresponding to the first type, such as whether it is an LSASS category process. If the process category of the process to be authenticated is not the process category corresponding to the first type, it is determined that the process identifier to be identified does not meet the process legitimacy conditions. It can be further determined whether the process identifier to be identified is in the list of secure processes. If it is, further determination is performed. If not, it is determined that the authentication request has not passed the legitimacy identification.

[0082] If the process category of the process to be authenticated is determined to be the process category corresponding to the first type through the aforementioned identification, or if the process identifier to be identified is in the secure process list, then it can be determined whether the authentication result in the AS-REP or TGS-REP response message for AS-REQ or TGS-REQ is successful. If not, communication of the process to be authenticated is allowed; if yes, further determination is performed. If it is determined that the authentication result in the AS-REP or TGS-REP response message is successful, then it can be further determined whether the account identifier to be identified is an account identifier in the secure account list. If yes, communication of the process to be authenticated is allowed; if not, further determination is performed. If it is determined that the account identifier to be identified is not an account identifier in the secure account list, then it can be further determined whether the service identifier to be identified is a service identifier in the service list to be authenticated. If not, communication of the process to be authenticated is allowed; if yes, further determination is performed. If the service identifier to be identified is determined to be a service identifier in the list of services to be authenticated, then account legitimacy identification is performed. The account legitimacy conditions are determined based on the terminal's account information. The account legitimacy conditions may include a legitimate account identifier bound to the terminal. Specifically, account legitimacy identification can be determined to determine whether the account identifier to be identified is a legitimate account identifier bound to the terminal device. If not, the account identifier to be identified is determined to not meet the account legitimacy conditions, and the authentication request fails the legitimacy identification. If yes, the account identifier to be identified is determined to meet the account legitimacy conditions, and the authentication request passes the legitimacy identification, allowing communication of the authentication process.

[0083] See Figure 8This is a schematic diagram of another legitimacy identification process provided in this application embodiment. When the protocol type of the authentication protocol is determined to be the second type based on the metadata of the authentication request, for example, when the protocol type of the authentication protocol is determined to be the NTLM protocol based on the metadata of the NTLM Type3 Message (NTLM_AUTH), process legitimacy identification is first performed. The process legitimacy conditions are determined according to the authentication protocol, including that the process signature is a valid signature. Process legitimacy identification can specifically be to determine whether the process signature of the process to be authenticated is a valid signature corresponding to the authentication protocol. If not, it is determined that the process identifier to be identified does not meet the process legitimacy conditions. Then it can be further determined whether the process to be authenticated is in the list of secure processes. If yes, further determination is performed. If no, it is determined that the authentication request has not passed the legitimacy identification.

[0084] If the process signature of the process to be authenticated is determined to be a valid signature corresponding to the authentication protocol, or if the process identifier to be authenticated is in the secure process list, then it can be determined whether the authentication result in the response message for NTLM_AUTH is successful. If not, communication of the process to be authenticated is allowed; if yes, further determination is required. If the authentication result in the response message is successful, it can be further determined whether the account identifier to be authenticated is empty. If yes, communication of the process to be authenticated is allowed; if not, further determination is required. If the account identifier to be authenticated is not empty, it can be further determined whether the account identifier to be authenticated is an account identifier in the secure account list. If yes, communication of the process to be authenticated is allowed; if not, further determination is required. If it is determined that the account identifier to be identified is not an account identifier in the list of secure accounts, account legitimacy identification can be performed. The account legitimacy conditions are determined based on the account information of the terminal. The account legitimacy conditions may include a legitimate account identifier bound to the terminal. Specifically, account legitimacy identification can be performed to determine whether the account identifier to be identified is a legitimate account identifier bound to the terminal device. If not, it is determined that the account identifier to be identified does not meet the account legitimacy conditions, and the authentication request fails the legitimacy identification. If it does, it is determined that the account identifier to be identified meets the account legitimacy conditions, and the authentication request passes the legitimacy identification, allowing communication of the authentication process.

[0085] In S104, if an authentication request fails the legitimacy check, it is determined to be an abnormal authentication behavior. Communication interception can be performed on the process initiating the authentication request. See [link to relevant documentation]. Figure 7 and Figure 8 This allows for timely detection and rapid response to abnormal authentication behavior, intercepting attackers' attacks on the terminal device and preventing attackers from using the terminal device as a springboard to attack the network domain environment. This prevents attackers from further harming other terminal devices in the network domain environment or elevating the privileges of the terminal device, thereby improving the security of terminal devices in the network domain.

[0086] After intercepting communication during the authentication process, anomaly alerts can be displayed on the terminal device based on the compliance status obtained from the legitimacy identification. See [link to relevant documentation]. Figure 7 and Figure 8 Anomaly alerts can include metadata about abnormal behavior and authentication requests, enabling end-device users to promptly analyze and handle malicious processes and identify attacker intent. Furthermore, anomaly alerts can be sent to management devices for unified display, processing, and notification to enterprise administrators. Management devices can be servers or end-devices logged into accounts with administrator privileges.

[0087] In this embodiment, the functional modules implementing penetration defense functionality in the terminal device constitute a penetration defense system. (See [link]). Figure 9 This is a structural block diagram of a penetration defense system provided in an embodiment of this application. The penetration defense system includes an attack defense module and a management module. The attack defense module is further divided into a traffic monitoring module, an authentication protocol parsing module, an NTLM attack defense module, and a Kerberos attack defense module. The traffic monitoring module monitors Kerberos traffic and NTLM authentication traffic carried in common intra-domain communication protocols to obtain authentication requests. The authentication protocol parsing module parses the protocol content according to protocol parsing control rules to obtain authentication-related metadata. The NTLM attack defense module defends against NTLM authentication protocol-related attacks initiated from the host by identifying the legitimacy of authentication requests. The Kerberos attack defense module defends against Kerberos protocol-related attacks initiated from the host by identifying the legitimacy of authentication requests.

[0088] The management module is primarily used to manage lists, rules, and anomaly alert information, and to synchronize data with the unified management platform (which can be the aforementioned management device). This module is divided into a rule management module and an anomaly alert module. The rule management module is mainly used to synchronize rules or lists issued by the unified management platform, as well as user-defined rules or lists for the management host. The anomaly alert module is mainly used to report alert information generated by the attack defense module to the unified management platform.

[0089] See Figure 10This is a functional diagram of a traffic monitoring module provided in an embodiment of this application. The traffic monitoring module is mainly used to monitor TCP and UDP traffic sent out by the host. If the authentication request uses a protocol that requires parsing, the module obtains the metadata of the authentication request. If the protocol of the authentication request is determined to be a protocol that does not require parsing according to the protocol parsing control rules, then the metadata is not obtained, and the obtained metadata and communication data packet content are handed over to the authentication protocol parsing module for parsing. The parsing result of the authentication protocol parsing module is handed over to the NTLM attack defense module and the Kerberos attack defense module. Based on the identification results of the defense modules, the traffic monitoring module decides whether to allow the traffic to pass or to block the traffic.

[0090] See Figure 11 This is a functional diagram of an authentication protocol parsing module provided in an embodiment of this application. The authentication protocol parsing module is mainly used to parse Kerberos authentication protocol traffic detected by the traffic monitoring module, as well as other communication traffic using NTLM authentication. Because the Kerberos protocol uses a separate TCP / UDP connection, while the NTLM protocol is an embedded authentication protocol whose authentication process is embedded in other communication protocols, the protocol parsing module is mainly divided into two parts: one part is used to parse Kerberos traffic, and the other part is used to process NTLM authentication traffic embedded in other protocols. Kerberos traffic parsing mainly parses three types of traffic: AS-REQ, TGS-REQ, and TGS-REP. This traffic includes authentication requests AS-REQ and TGS-REQ, as well as response messages TGS-REP. The module parses the ridge protocol field of the traffic to obtain Kerberos authentication metadata, and then sends this metadata to the Kerberos attack defense module. NTLM authentication traffic is embedded in other protocols. In this module, we only need to focus on the MS-RPC, DCOM, WMI, SMB, NBSS, and WinRM protocols. These protocols have corresponding parsing modules, which are used to parse these traffic. The main parsing modules are NTLM Type1 Message, NTLM Type2 Message, and NTLM Type3 Message traffic. The protocol fields of the traffic are parsed to obtain NTLM authentication metadata, and this metadata is sent to the NTLM attack defense module.

[0091] Based on the aforementioned method embodiments Figure 12 This application provides a structural diagram of a penetration defense device 1100, which includes: The authentication request acquisition unit 1301 is used to acquire authentication requests sent by terminal devices in the network domain; Metadata acquisition unit 1302 is used to acquire metadata of the authentication request in response to an authentication request sent by a terminal device in the network domain, wherein the metadata includes an account identifier to be identified and an identification process identifier to initiate the authentication request; The legitimacy identification unit 1303 is used to identify the legitimacy of the authentication request through the metadata, wherein the legitimacy identification includes at least one of process legitimacy identification or account legitimacy identification, the process legitimacy identification is used to identify whether the process identifier to be identified meets the process legitimacy conditions, and the account legitimacy identification is used to identify whether the account identifier to be identified meets the account legitimacy conditions; The communication interception unit 1304 is used to perform communication interception processing on the process to be authenticated if the authentication request fails the legitimacy identification.

[0092] Optionally, the metadata also includes the authentication protocol used by the authentication request. If the legitimacy identification includes process legitimacy identification, the legitimacy identification unit 1303 includes: A process legitimacy condition determination unit is used to determine the protocol type of the authentication protocol and determine the process legitimacy condition based on the protocol type of the authentication protocol. A process legitimacy identification unit is used to identify, based on the process legitimacy conditions, whether the identifier of the process to be identified conforms to the process legitimacy conditions; The process identification result determination unit is used to determine that the authentication request has failed the legality identification when the conformity condition is that the identifier of the process to be identified does not meet the process legality conditions.

[0093] Optionally, if the legitimacy identification includes account legitimacy identification, the legitimacy identification unit 1303 includes: An account legitimacy determination unit is used to determine the account legitimacy conditions based on the account information of the terminal device; An account legitimacy identification unit is used to identify, based on the account legitimacy conditions, whether the identifier of the account to be identified conforms to the account legitimacy conditions; The account identification result determination unit is used to determine that the authentication request has failed the legality identification when the conformity condition is that the identifier of the account to be identified does not meet the account legality conditions.

[0094] Optionally, the metadata also includes the authentication protocol used in the authentication request. If the legitimacy identification includes process legitimacy identification and account legitimacy identification, the legitimacy identification unit 1303 includes: A process legitimacy condition determination unit is used to determine the protocol type of the authentication protocol and determine the process legitimacy condition based on the protocol type of the authentication protocol. A process legitimacy identification unit is used to identify, based on the process legitimacy conditions, whether the identifier of the process to be identified conforms to the process legitimacy conditions; The account legitimacy condition determination unit is used to determine the account legitimacy condition based on the account information of the terminal device when the compliance condition is that the process identifier to be identified meets the process legitimacy condition. An account legitimacy identification unit is used to identify, based on the account legitimacy conditions, whether the identifier of the account to be identified conforms to the account legitimacy conditions; The legitimacy identification result determination unit is used to determine that the authentication request has failed the legitimacy identification when the conformity condition is that the account identifier to be identified does not meet the account legitimacy conditions.

[0095] Optionally, the process legitimacy identification unit includes: The process category determination unit is used to determine the process category indicated by the process identifier to be identified, and the process legality conditions including the process category corresponding to the first type, when the protocol type of the authentication protocol is determined to be a first type. The first compliance identification unit is used to identify the compliance status of the process category to be identified with respect to the process legality conditions based on the process legality conditions; The process legitimacy identification subunit is used to determine that the process identifier to be identified does not meet the process legitimacy conditions when the conformity condition is that the process category to be identified does not meet the process legitimacy conditions.

[0096] Optionally, the process legitimacy identification unit includes: The process signature determination unit is used to determine, when the protocol type of the authentication protocol is determined to be the second type, the signature of the process to be identified indicated by the process identifier to be identified, and the process legitimacy conditions including the legitimate signature of the process to be authenticated under the authentication protocol. The second conformity identification unit is used to identify the conformity of the signature of the process to be identified with the process legality conditions based on the process legality conditions. The process legitimacy identification subunit is used to determine that the process identifier to be identified does not meet the process legitimacy conditions when the compliance condition is that the signature of the process to be identified does not meet the process legitimacy conditions.

[0097] Optionally, the account legitimacy identification unit is specifically used for: Determine the account legitimacy conditions, including the legitimate account identifier bound to the terminal device; Based on the account legitimacy criteria, identify whether the account identifier to be identified conforms to the account legitimacy criteria.

[0098] Optionally, the device further includes: The legitimate account identifier acquisition unit is used to acquire the legitimate account identifier bound to the terminal device through the initialization of the terminal device in the network domain.

[0099] Optionally, the metadata may also include a service identifier to be identified, and the device may further include: The communication unit is configured to, when determining that the protocol type of the authentication protocol is a first type, allow communication of the process to be authenticated if it is determined that the service identifier to be identified is not a service identifier in the list of services to be authenticated; The triggering unit is used to trigger the account legitimacy identification unit if it is determined that the service identifier to be identified is a service identifier in the service list to be authenticated.

[0100] Optionally, the device further includes: A communication permission unit is configured to, when determining that the protocol type of the authentication protocol is the second type, allow communication of the authentication process if the identifier of the account to be identified is determined to be empty; the identifier of the account to be identified is set to empty when the account to be identified is an anonymous account; The triggering unit is used to trigger the account legitimacy identification unit if it is determined that the account identifier to be identified is not empty.

[0101] Optionally, the device further includes: The response message acquisition unit is used to acquire the response message for the authentication request; A communication unit is allowed to allow communication of the process to be authenticated if the authentication result in the response message is determined to be a failure. The triggering unit is used to trigger the account legitimacy identification unit if it is determined that the authentication result in the response message is successful.

[0102] Optionally, the device further includes: A communication permission unit is configured to allow communication of the authentication process if it is determined that the account identifier to be identified is an account identifier in the list of secure accounts. The triggering unit is used to trigger the account legitimacy identification unit if it is determined that the account identifier to be identified is not an account identifier in the list of secure accounts.

[0103] Optionally, the device further includes: The communication unit is configured to, when it is determined that the authentication request has failed the legitimacy identification based on the conformity criteria, allow the communication of the process to be authenticated if it is determined that the process identifier to be identified is a process identifier in the list of secure processes; An interception triggering unit is configured to, when it is determined that the authentication request has failed the legitimacy identification based on the compliance condition, trigger the communication interception unit if it is determined that the process identifier to be identified is not a process identifier in the secure process list.

[0104] Optionally, the authentication request acquisition unit is specifically used for: The authentication request is obtained through the target port of the terminal device, where the target port is the port corresponding to the authentication protocol.

[0105] Optionally, the authentication request may include encrypted data packets.

[0106] As can be seen from the above technical solution, based on the authentication request sent by the terminal device in the network domain, the metadata of the authentication request is obtained. The metadata of the authentication request includes the identifier of the account to be identified and the identifier of the process to be identified used to initiate the authentication request. Since attackers need to authenticate with the domain controller using the terminal device in order to access the corresponding services through the terminal device, that is, the domain penetration attack initiated by the attacker always starts with the authentication behavior. Therefore, the legitimacy of the authentication request can be identified based on the metadata of the authentication request. When it is determined that the authentication request fails the legitimacy identification, the authentication behavior is considered to be an abnormal authentication behavior, and the communication interception process can be carried out. That is, the abnormal authentication behavior of the attacker can be identified and intercepted in real time based on the metadata of the authentication request. Penetration defense starts from the commonality of domain penetration attack behavior, which can target more diverse domain penetration attack behaviors and improve the security of terminal devices in the network domain. In addition, penetration defense based on the metadata of the authentication request does not require obtaining the content of the authentication request, and the encryption of the authentication request will not affect the penetration defense effect, thus broadening the applicable scenarios of the penetration defense method.

[0107] Anomaly authentication behavior requires initiating a process at the network layer and relying on account authentication at the terminal device's host behavior level. Therefore, legitimacy recognition can be configured, including at least one of process legitimacy recognition or account legitimacy recognition. Process legitimacy recognition identifies whether the process identifier to be identified meets the process legitimacy conditions, while account legitimacy recognition identifies whether the account identifier to be identified meets the account legitimacy conditions. This multi-dimensional penetration defense from both the network and host behavior levels improves the accuracy of anomaly authentication behavior identification and comprehensively enhances the security of terminal devices within the network domain. Specifically, when it is determined that the process identifier to be identified does not meet the process legitimacy conditions, it indicates that the process to be identified is not a normally initiated process, and communication interception can be performed on the authentication process, identifying and intercepting domain penetration attacks in real time at the network layer. Similarly, when it is determined that the account identifier to be identified does not meet the account legitimacy conditions, it indicates that the account identifier to be identified is not a commonly used account identifier on the terminal device, and communication interception can be performed on the authentication process, identifying and intercepting domain penetration attacks in real time at the terminal device's host behavior level.

[0108] This application also provides a computer device, which is the computer device described above, and may include a terminal device. The aforementioned penetration defense device may be configured in this computer device. The computer device will now be described in conjunction with the accompanying drawings.

[0109] If the computer device is a terminal device, please refer to Figure 13 As shown, this application provides a terminal device, taking a mobile phone as an example: Figure 13 This diagram illustrates a partial structural representation of a mobile phone related to the terminal device provided in this embodiment. (Reference) Figure 13 The mobile phone includes components such as a radio frequency (RF) circuit 1410, a memory 1420, an input unit 1430, a display unit 1440, a sensor 1450, an audio circuit 1460, a Wi-Fi module 1470, a processor 1480, and a power supply 1490. Those skilled in the art will understand that... Figure 13 The mobile phone structure shown does not constitute a limitation on the mobile phone and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0110] The following is combined Figure 13 A detailed introduction to each component of a mobile phone: The RF circuit 1410 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 1480; in addition, it transmits uplink data to the base station.

[0111] The memory 1420 can be used to store software programs and modules. The processor 1480 executes various mobile phone functions and data processing by running the software programs and modules stored in the memory 1420. The memory 1420 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 1420 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0112] The input unit 1430 can be used to receive input numeric or character information, and to generate key signal inputs related to user settings and function control of the mobile phone. Specifically, the input unit 1430 may include a touch panel 1431 and other input devices 1432.

[0113] The display unit 1440 can be used to display information input by the user or information provided to the user, as well as various menus of the mobile phone. The display unit 1440 may include a display panel 1441.

[0114] The mobile phone may also include at least one sensor 1450, such as a light sensor, a motion sensor, and other sensors.

[0115] Audio circuitry 1460, speaker 1461, and microphone 1462 provide an audio interface between the user and the mobile phone.

[0116] WiFi is a short-range wireless transmission technology. Through the WiFi module 1470, mobile phones can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access.

[0117] The processor 1480 is the control center of the mobile phone. It connects to various parts of the mobile phone through various interfaces and lines. It performs various functions of the mobile phone and processes data by running or executing software programs and / or modules stored in the memory 1420 and calling data stored in the memory 1420.

[0118] The phone also includes a power supply 1490 (such as a battery) that powers the various components.

[0119] In this embodiment, the processor 1480 included in the terminal device also has the following functions: Obtain authentication requests sent by terminal devices in the network domain; In response to an authentication request sent by a terminal device in the network domain, the metadata of the authentication request is obtained, wherein the metadata includes an account identifier to be identified and an identifier of the process to be identified for initiating the authentication request. The authentication request is validated using the metadata, wherein the validation includes at least one of process validation or account validation. The process validation is used to identify whether the process identifier to be identified meets the process validation conditions, and the account validation is used to identify whether the account identifier to be identified meets the account validation conditions. If the authentication request fails the legitimacy identification, the process to be authenticated will be intercepted.

[0120] This application also provides a server; please refer to [link to relevant documentation]. Figure 14 As shown, Figure 14 The diagram illustrates the structure of a server 1500 provided in this embodiment. The server 1500 can vary significantly due to different configurations or performance characteristics. It may include one or more central processing units (CPUs) 1522 (e.g., one or more processors) and a memory 1532, and one or more storage media 1530 (e.g., one or more mass storage devices) for storing application programs 1542 or data 1544. The memory 1532 and storage media 1530 may be temporary or persistent storage. The program stored in the storage media 1530 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 1522 may be configured to communicate with the storage media 1530 and execute the series of instruction operations stored in the storage media 1530 on the server 1500.

[0121] Server 1500 may also include one or more power supplies 1526, one or more wired or wireless network interfaces 1550, one or more input / output interfaces 1558, and / or one or more operating systems 1541, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0122] The steps performed by the server in the above embodiments can be based on Figure 14 The server structure shown.

[0123] In addition, this application embodiment also provides a storage medium for storing a computer program for executing the method provided in the above embodiment.

[0124] This application also provides a computer program product including instructions that, when run on a computer, cause the computer to perform the methods provided in the above embodiments.

[0125] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium can be at least one of the following media: read-only memory (ROM), RAM, magnetic disk or optical disk, and other media that can store program code.

[0126] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and system 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 can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0127] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Moreover, based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A penetration defense method, characterized in that, The method includes: Obtain authentication requests sent by terminal devices in the network domain; In response to an authentication request sent by a terminal device in the network domain, the metadata of the authentication request is obtained, wherein the metadata includes an account identifier to be identified and an identifier of the process to be identified for initiating the authentication request. The authentication request is validated using the metadata, including process validation and account validation. Process validation is used to determine whether the process identifier to be validated meets the process validation criteria, and account validation is used to determine whether the account identifier to be validated meets the account validation criteria. If the authentication request fails the validation, the process to be validated is intercepted. The step of verifying the legitimacy of the authentication request through the metadata includes: The authentication protocol type is determined according to the authentication protocol, and the process legitimacy conditions are determined according to the authentication protocol type. Based on the process legitimacy conditions, the compliance of the process identifier to be identified with the process legitimacy conditions is identified. When the compliance condition is that the process identifier to be identified meets the process legitimacy conditions, the account legitimacy conditions are determined according to the account information of the terminal device. Based on the account legitimacy conditions, the compliance of the account identifier to be identified with the account legitimacy conditions is identified. When the compliance condition is that the account identifier to be identified does not meet the account legitimacy conditions, it is determined that the authentication request has failed the legitimacy identification. or, The account legitimacy conditions are determined based on the account information of the terminal device; based on the account legitimacy conditions, the compliance of the account identifier to be identified with the account legitimacy conditions is identified; when the compliance is that the account identifier to be identified meets the account legitimacy conditions, the protocol type of the authentication protocol is determined according to the authentication protocol, and the process legitimacy conditions are determined according to the protocol type of the authentication protocol; based on the process legitimacy conditions, the compliance of the process identifier to be identified with the process legitimacy conditions is identified; when the compliance is that the process identifier to be identified does not meet the process legitimacy conditions, it is determined that the authentication request has failed the legitimacy identification.

2. The method according to claim 1, characterized in that, The step of identifying whether the process identifier to be identified meets the process legitimacy conditions based on the process legitimacy conditions includes: When the protocol type of the authentication protocol is determined to be the first type, the process category indicated by the process identifier to be identified is determined, as well as the process legality conditions including the process category corresponding to the first type; Based on the process legitimacy conditions, identify whether the category of the process to be identified meets the process legitimacy conditions; When the condition is that the category of the process to be identified does not meet the process legality conditions, it is determined that the identifier of the process to be identified does not meet the process legality conditions.

3. The method according to claim 1, characterized in that, The step of identifying whether the process identifier to be identified meets the process legitimacy conditions based on the process legitimacy conditions includes: When the protocol type of the authentication protocol is determined to be the second type, the signature of the process to be identified indicated by the process identifier to be identified, and the process legitimacy conditions including the legitimate signature of the process to be authenticated under the authentication protocol are determined. Based on the process legitimacy conditions, identify whether the signature of the process to be identified conforms to the process legitimacy conditions; When the condition is that the signature of the process to be identified does not meet the process legality conditions, it is determined that the identifier of the process to be identified does not meet the process legality conditions.

4. The method according to claim 1, characterized in that, The step of identifying whether the account identifier to be identified meets the account legitimacy conditions based on the account legitimacy conditions includes: Determine the account legitimacy conditions, including the legitimate account identifier bound to the terminal device; Based on the account legitimacy criteria, identify whether the account identifier to be identified conforms to the account legitimacy criteria.

5. The method according to claim 4, characterized in that, The method further includes: By initializing the terminal device in the network domain, a legitimate account identifier bound to the terminal device is obtained.

6. The method according to claim 1, characterized in that, The metadata also includes a service identifier to be identified, and the method further includes: When the protocol type of the authentication protocol is determined to be the first type, if it is determined that the service identifier to be identified is not a service identifier in the list of services to be authenticated, communication of the process to be authenticated is allowed; If the service identifier to be identified is determined to be a service identifier in the list of services to be authenticated, the process of identifying whether the account identifier to be identified meets the account legitimacy conditions is performed based on the account legitimacy conditions.

7. The method according to claim 1, characterized in that, The method further includes: When the authentication protocol is determined to be of the second type, if the identifier of the account to be identified is determined to be empty, communication of the authentication process is allowed; the identifier of the account to be identified is set to empty when the account indicated by the identifier of the account to be identified is an anonymous account; If it is determined that the account identifier to be identified is not empty, the process of identifying whether the account identifier to be identified meets the account validity conditions is performed based on the account validity conditions.

8. The method according to claim 1, characterized in that, The method further includes: Obtain the response message for the authentication request; If the authentication result in the response message is determined to be a failure, communication of the process to be authenticated is permitted. If the authentication result in the response message is determined to be successful, the process of identifying the account identifier to be identified in accordance with the account legitimacy conditions is executed.

9. The method according to claim 1, characterized in that, The method further includes: If the account identifier to be identified is determined to be an account identifier in the list of secure accounts, then communication of the authentication process is permitted; If it is determined that the account identifier to be identified is not an account identifier in the list of secure accounts, the process of identifying whether the account identifier to be identified meets the account legitimacy conditions is performed based on the account legitimacy conditions.

10. The method according to claim 1, characterized in that, When it is determined that the authentication request has failed the legitimacy identification based on the compliance criteria, the method further includes: If the process identifier to be identified is determined to be a process identifier in the list of secure processes, communication of the process to be authenticated is permitted; If it is determined that the process identifier to be identified is not a process identifier in the list of secure processes, the communication interception process for the process to be authenticated is executed.

11. The method according to claim 1 or 10, characterized in that, The step of obtaining authentication requests sent by terminal devices in the network domain includes: The authentication request is obtained through the target port of the terminal device, where the target port is the port corresponding to the authentication protocol.

12. The method according to claim 1 or 10, characterized in that, The authentication request includes encrypted data packets.

13. A penetration defense device, characterized in that, The device includes: The authentication request acquisition unit is used to acquire authentication requests sent by terminal devices in the network domain. The metadata acquisition unit is used to acquire the metadata of the authentication request in response to the authentication request sent by the terminal device in the network domain, wherein the metadata includes the identifier of the account to be identified and the identifier of the process to be identified for initiating the authentication request. A legitimacy identification unit is used to identify the legitimacy of the authentication request through the metadata. The legitimacy identification includes process legitimacy identification and account legitimacy identification. The process legitimacy identification is used to identify whether the process identifier to be identified meets the process legitimacy conditions, and the account legitimacy identification is used to identify whether the account identifier to be identified meets the account legitimacy conditions. A communication interception unit is used to intercept the authentication process when the authentication request fails the legitimacy identification. The legality identification unit is specifically used for: The authentication protocol type is determined according to the authentication protocol, and the process legitimacy conditions are determined according to the authentication protocol type. Based on the process legitimacy conditions, the compliance of the process identifier to be identified with the process legitimacy conditions is identified. When the compliance condition is that the process identifier to be identified meets the process legitimacy conditions, the account legitimacy conditions are determined according to the account information of the terminal device. Based on the account legitimacy conditions, the compliance of the account identifier to be identified with the account legitimacy conditions is identified. When the compliance condition is that the account identifier to be identified does not meet the account legitimacy conditions, it is determined that the authentication request has failed the legitimacy identification. or, The account legitimacy conditions are determined based on the account information of the terminal device; based on the account legitimacy conditions, the compliance of the account identifier to be identified with the account legitimacy conditions is identified; when the compliance is that the account identifier to be identified meets the account legitimacy conditions, the protocol type of the authentication protocol is determined according to the authentication protocol, and the process legitimacy conditions are determined according to the protocol type of the authentication protocol; based on the process legitimacy conditions, the compliance of the process identifier to be identified with the process legitimacy conditions is identified; when the compliance is that the process identifier to be identified does not meet the process legitimacy conditions, it is determined that the authentication request has failed the legitimacy identification.

14. The apparatus according to claim 13, characterized in that, The metadata also includes a service identifier to be identified, and the device further includes: The communication unit is configured to, when determining that the protocol type of the authentication protocol is a first type, allow communication of the process to be authenticated if it is determined that the service identifier to be identified is not a service identifier in the list of services to be authenticated; The triggering unit is configured to, if it is determined that the service identifier to be identified is a service identifier in the list of services to be authenticated, execute the step of identifying the compliance of the account identifier to be identified with the account legitimacy conditions based on the account legitimacy conditions.

15. The apparatus according to claim 13, characterized in that, The device further includes: A communication unit is configured to allow communication of the authentication process if, when the authentication protocol is determined to be of the second type, the identifier of the account to be identified is determined to be empty; the identifier of the account to be identified is set to empty when the account indicated by the identifier of the account to be identified is an anonymous account. The triggering unit is used to, if it is determined that the account identifier to be identified is not empty, execute the step of identifying the account identifier to be identified in accordance with the account validity conditions.

16. The apparatus according to claim 13, characterized in that, The device further includes: The response message acquisition unit is used to acquire the response message for the authentication request; A communication unit is allowed to allow communication of the process to be authenticated if the authentication result in the response message is determined to be a failure. The triggering unit is configured to, if it is determined that the authentication result in the response message is successful, execute the step of identifying the account identifier to be identified in accordance with the account legitimacy conditions.

17. A computer device, characterized in that, The computer device includes a processor and memory: The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the penetration defense method according to any one of claims 1-12 according to the instructions in the program code.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the penetration defense method according to any one of claims 1-12.

19. A computer program product comprising instructions that, when run on a computer, cause the computer to perform the penetration defense method according to any one of claims 1-12.

Images