Network-based NT LAN manager (NTLM) relay attack detection and prevention

A method is provided for verifying an authentication request to a computer network. The method may include receiving a network packet and extracting an authentication request from the network packet. The authentication request may be encrypted to store attribute-value pairs, and the method may further include decrypting the authentication request to access the attribute-value pairs. The method may also include extracting a target name and a device name from the attribute-value pairs, wherein the device name indicates an identified target device, and determining whether the target name refers to the identified target device identified by the device name.

BACKGROUND

Computers within computer networks may request access to other computers within the network and/or to a server on the network. For example, a server, such as an application server or a proxy server, or another computing device on the network may provide one or more services (e.g., application services, proxy services). Computers on the network may request access to the server in order to access the provided services.

However, to protect and restrict access to the provided services, access to the services is restricted to users with access permission. Computer networks rely on authentication protocols to verify user identities and enforce access permissions. These authentication protocols may be implemented by a server connected to the network and may process authentication requests prior to permitting access to services.

SUMMARY

The present disclosure presents new and innovative systems and methods for detecting relay attacks within a network. In one embodiment, a method is provided comprising receiving a network packet, extracting an authentication request from the network packet, wherein the authentication request is encrypted to store attribute-value pairs, and decrypting the authentication request to access the attribute-value pair. The method may also comprise extracting a target name and a device name of the authentication request from the attribute-value pairs, wherein the device name indicates an identified target device and determining whether the target name refers to the identified target device identified by the device name.

In another embodiment, the method further comprises determining that the target name does not refer to the identified target device and blocking the authentication request.

In yet another embodiment, the device name contains a unique name of the identified target device.

In a further embodiment, the target name includes an internet protocol (IP) address and determining whether the target name refers to the identified computing device further comprises identifying an assigned target device assigned to the IP address and determining whether the assigned target device matches the identified target device.

In a still further embodiment, the target name includes a service principal name (SPN). In such embodiments, determining whether the target name refers to the identified target device may further comprise mapping the SPN to a mapped target device and determining whether the mapped target device matches the identified target device.

In another embodiment, the authentication request is selected from the group consisting of a NETLOGON request according to a NETLOGON protocol and an authenticate response according to an NT LAN Manager (NTLM) protocol.

In yet another embodiment, the device name is an MsvAvComputerName for an NTLM protocol and the unique name is the NetBIOS computer name of the identified target device.

In a further embodiment, the target name is an MsvAvTargetName for an NTLM protocol.

In a still further embodiment, mapping the SPN to a mapped target device further comprises identifying the SPN in a database of SPN mappings. In such an embodiment, the database of SPN mappings may be created by monitoring traffic on a network.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Centralized authentication protocols, such as Windows® NT LAN Manager (NTLM) are susceptible to relay attacks from compromised servers on the network. For example, if a user attempts to connect to a malicious server compromised by an attacker, the attacker can capture the authentication request provided by the user. The malicious server may use the captured authentication request to connect to another computing device on the network. The captured authentication request can then be used to execute code on the other machine and may enable, e.g., user creation within a captured machine's active directory domain services, forging web requests, accessing databases, and otherwise bypassing the computer network's access permissions. The system and methods disclosed herein provide a way to intercept and prevent such malicious attempts to repurpose authentication requests.

FIG. 1depicts the message flow associated with an exemplary relay attack10for an NTLM authentication protocol.FIG. 1includes a client machine12, a compromised server14, an attacked target16, and a domain controller18. The client machine12may be attempting to connect to a server on a network to access network services, such as network services provided by a server or another computing device on the network. The compromised server14may be compromised by malware or other software to intercept authentication requests from computing devices, such as the client machine12, to gain access to another computing device on the network, such as the attacked target16. The domain controller18may be implemented to perform centralized authentication for services on the network according to the NTLM and NETLOGON protocols. Further, as explained below, other devices on the network (e.g., the client machine12, the compromised server14, the attacked target16) may exchange credentials via requests and responses according to the NTLM protocol and the domain controller18may authenticate the exchanged credentials according to the NETLOGON protocol.

The relay attack10begins with the client machine12transmitting a negotiate request (i.e., an NTLM negotiate request) to the compromised server14(block20). The negotiate request may indicate that the client machine12is attempting to negotiate access to a network (e.g., by logging in with user credentials). In certain attacks, the client machine12may transmit the negotiation request without intervention from the compromised server14(e.g., at the request of a user using the client machine12or a client machine12computing process). In other versions of the attack, the compromised server14may prompt or otherwise cause the client machine12to transmit the negotiate request.

The compromised server14may then relay this negotiate request to the attacked target16(block22). By relaying the negotiate request, the compromised server14may attempt to pass itself off as the client machine12, using the negotiate request from the client machine12to gain access to the attacked target16(e.g., by intercepting and reusing the client machine's12responses under the NTLM protocol). The attacked target16may interpret the received negotiate request as a request from the client machine12to access one or more services provided by the attacked target16.

Per the NTLM authentication protocol, the attacked target16may therefore respond with a challenge response (i.e., an NTLM challenge response) (block24). The challenge response may be a random series of digits for encryption using a hash of a user password, later used by the domain controller18to authenticate provided user credentials. Similar to the negotiate request, the compromised server14may relay the challenge response to the client machine12(block26). Because the client machine12initially transmitted the negotiated request to the compromised server14, the client machine12may incorrectly interpret the received challenge response as coming from the compromised server14.

In response, the client machine12may generate and transmit an authenticate response (i.e., an NTLM authenticate response) to the compromised server14based on the challenge response (block28). According to the NTLM authentication protocol, the client machine12may encrypt the challenge response using a hash of a user credential (e.g., a password) to generate the authenticate response. The compromised server14may then relay the authenticate response to the attacked target16(block30). Similar to the client machine12, because the attacked target16provided the challenge response after receiving a negotiate request from the compromised server14, the attacked target16may incorrectly interpret the authenticate response as being derived from user credentials associated with the compromised server14.

The attacked target16may then generate a NETLOGON request including the authenticate response, challenge response, and other user credentials (e.g., user name) and may transmit the NETLOGON request to the domain controller18(block32). The domain controller18may then compare the authenticate response and the challenge response to authenticate the user credentials. For example, the domain controller18may obtain the password hash associated with the provided user credentials and may use the password hash to encrypt the challenge response. If the encrypted challenge response created by the domain controller18and the authenticate response match, the domain controller18may authenticate the provided user credentials and approve the logon request. If there is no match, the domain controller18may determine that the provided user credentials are inauthentic and reject the logon request. Assuming the credentials provided by the client machine12are authentic, the authenticate response should match the encrypted challenge response generated by the domain controller18, causing the domain controller18to authenticate the logon request even though the credentials did not originate with the compromised server14.

The domain controller18may then generate a NETLOGON response indicating this determination and may transmit the NETLOGON response to the attacked target16(block34). If the domain controller18approves the NETLOGON request, the NETLOGON response may indicate the approval. If the domain controller18rejects the NETLOGON request, the NETLOGON response may indicate the rejection. As described above, under the attack10, the domain controller18will authenticate the NETLOGON request32if the underlying authenticate response was generated using authentic credentials at the client device12. Therefore, the NETLOGON response received by the attacked target16will approve the NETLOGON request. Responsive to this, the attacked target16may then allow the compromised server14to access the attacked target's16services and directories, even though the compromised server14has not actually provided authenticated user credentials. After gaining access, the compromised server14may further undermine the security of the network by, e.g., adding users to the attacked target16active directory domain services, executing code on the attacked target16, and utilizing the attacked target16network services without proper authorization or user credentials.

Also, although the attacked target16and the domain controller18are separate devices inFIG. 1, in certain versions of the attack10, the domain controller18may be the attacked target. In such versions of the attack10, the compromised server14may attempt to access one or more services of the domain controller18with user credentials provided at the client machine12. To do so, the compromised server14may relay the authenticate response to the domain controller18at step30. The domain controller18may then authenticate the authenticate request as discussed above and may grant access to the compromised server14if the relayed user credentials have permission to access the services of the domain controller18.

A system and method for detecting and preventing such attacks is therefore required. Preferably, this system will operate at a central location within the network in conjunction with the network's authentication protocol to detect and reject logon requests and other packets that have been improperly relayed. Such a centralized implementation for relay attack monitoring may enable a system that is able to operate independent of the operating system of the devices generating and processing the negotiate request, challenge response, authenticate response, NETLOGON request, and NETLOGON response.

FIG. 2depicts a system100according to an exemplary embodiment of the present disclosure. As further explained above, the system100may be configured to provide centralized authentication services according to NTLM and NETLOGON protocols, and to detect and prevent relay attacks (e.g., the attack10). The system100includes a target device102and a compromised server104connected to a network112, which may respectively be examples of the attacked target16and the compromised server14. A relay detection device108is also connected to the network112, and a domain controller110is connected to the relay detection device108. The domain controller110may be an example of the domain controller18. The compromised server104generates and transmits network packets115containing an authenticate response117(i.e., an NTLM authenticate response) according to the NTLM protocol. The authenticate response117contains attribute-value pairs120, which contains a target name122and a device name124. The target device102generates and transmits network packets114,116that, for example, contain a NETLOGON request118for authenticating user credentials according to the NETLOGON protocol. The NETLOGON request118contains the attribute-value pairs120, which may include individual attribute value pairs such as the target name122, and the device name124received in the authenticate response117. According to the NTLM and NETLOGON protocols, the target name122may be implemented as the MsvAvTargetName contained within the attribute-value (AV) pairs of an NTLM authenticate response and the device name124may be implemented as the MsvAvNbComputerName contained within the AV pairs of an NTLM authenticate response.

The relay detection device108includes a networking module126containing a service principal name (SPN) translator132and an Internet protocol (IP) address translator134. The relay detection device108also includes a CPU128and a memory130.

The target device102may represent a device that provides one or more services to the network112. The target device102may receive and process requests to authenticate user credentials from a computing device104,106on the network112.

The target device102may interact with the compromised server104according to the NTLM authentication protocol to exchange credentials (e.g., via NTLM negotiate requests, NTLM challenge responses, and NTLM authenticate responses). To verify the credentials provided via these interactions, the target device102may communicate with the domain controller110via the network112using a NETLOGON request118generated according to the NETLOGON protocol. In communicating with the domain controller110, the target device102may generate one or more network packets114,116. For example, in validating an access request (e.g., an authenticate response117) received from the compromised server104, the target device102may generate a network packet114containing the NETLOGON request118for transmission to the domain controller110. According to the NTLM and NETLOGON protocols, the target device102may generate the NETLOGON request118after exchanging NTLM negotiate requests, NTLM challenge responses, and NTLM authenticate responses with the compromised server104, as explained above in connection with the attack10.

As another example, the target device102may generate the NETLOGON request118to include the attribute-value pairs120of the authenticate response117received from the compromised server104. According to such an example, and as depicted, both the authentication response117and the NETLOGON request118include attribute-value pairs120including a target name122and a device name124.

The attribute-value pairs120permit the system to detect malicious relay attacks, such as the attack10. The target names122may include the string provided in the original request (e.g., received in the negotiate request of an NTLM protocol) identifying the compromised server104as the device for which access is being requested by the NETLOGON request118. For example, the target name122may include one or both of an IP address for the computing device to which access is granted or an SPN of a service for which the computing device is requesting access. In certain implementations, the target name122is signed by the user's hash (e.g., a hash based on the user's password). The attribute-value pairs120may also include a device name124. The device name124may indicate a unique identifier (e.g., an IP address, a NetBIOS computer name) of the target device102for which access is requested by the NETLOGON request118.

The relay detection device108may be configured to receive and process network packets114,116received from the target device102. For example, the relay detection device108may be configured to confirm the validity of NETLOGON requests118received within network packets114to ensure that authentication responses117captured and reused by malicious servers on the network112cannot be used to gain access to the target device102without permission. One or more of these functions may be implemented by the networking module126. For example, one or more of these features may be implemented by the SPN translator132and the IP address translator134.

Similarly, the relay detection device108may be configured to receive and process network packets115received from the compromised server104. For example, the relay detection device108may receive a network packet115containing an authenticate response117if the compromised server104is requesting access to one or more network services provided by the domain controller110. The relay detection device108may be configured to confirm the validity of authenticate responses117to ensure that authenticate responses117captured and reused by the compromised server104cannot be used to gain access to the domain controller110without permission. As with NETLOGON request118validation, one or more of the features may be implemented by the networking module126, the SPN translator132, and the IP address translator134.

The SPN translator132may be configured to translate from an SPN (e.g., an SPN included as part of a target name122) to a corresponding computing device. For example, the received SPN may refer to a service implemented by one or more computing devices (e.g., the attacked target102or the compromised server104) of the network112. The SPN translator132may be configured to convert from an SPN identifying a service to the computing device implementing the service identified by the SPN. For example, the SPN translator132may maintain a database that maps SPNs to corresponding computing devices (e.g., the compromised server104and the target device102) on the network112. The SPN translator132may update the entries of the databases based on data gathered from an active directory of the domain controller110and by monitoring traffic on the network112. The SPN translator132may use this data to create new mappings between SPNs and computing devices for the database. The translated SPN may then be provided to the networking module126for subsequent verification of a NETLOGON request118or an authenticate response117, as discussed below.

The IP address translator134may be configured to translate from an IP address (e.g., an IP address included as part of a target name122or a device name124) to an identifier of a computer on the network112. For example, the IP address translator134may translate the IP address using a DNS lookup, a NetBIOS request to the target machine (e.g., the NetBIOS name of the computing device104,106at the provided IP address), or may analyze traffic (e.g., Kerberos traffic) within the network112that includes a device name along with the IP address. The translated IP address, or resulting device name, may be provided to the networking module126for subsequent verification of a NETLOGON request118or an authenticate response117, as discussed below.

In one embodiment, the relay detection device108also includes a CPU128and the memory130, which may be used to implement one or more features of the relay detection device108. For example, the memory130may contain instructions which, when executed by the CPU128, cause the CPU128to perform one or more functions of the relay detection device108, such as the networking module126, the SPN translator132, and the IP address translator134. In certain implementations, the relay detection device108may be implemented as a module (e.g., a software module) of a server on the network112. For example, the relay detection device108may be implemented as a proxy server or a software module for the domain controller110of the network112. As another example, the relay detection device108may be a software module within a server on the network112providing services to authorized computing devices.

The domain controller110may be configured to receive NETLOGON requests118and/or authenticate responses117and to verify the user credentials used to generate the NETLOGON requests118. For example, similar to the above discussion of the attack10and the domain controller18, the domain controller110may authenticate NETLOGON requests118by encrypting a challenge response of the NETLOGON request118with a password hash associated with user credentials of the authentication request and comparing the encrypted challenge response with an authenticate response of the NETLOGON request118. If the encrypted challenge response and the authenticate response match, the domain controller110may determine that the provided user credentials are authentic. The domain controller110may similarly verify authenticate responses117received from a compromised server104.

The network112may be implemented as one or more wired or wireless networks. For example, the network112may be implemented as the Internet or a local area network (LAN). The computing devices102,104,106and the relay detection device108may connect to the network112by wired or wireless means. For example, the client machines102,104,106and the relay detection device108may connect by one or more Ethernet, W-Fi, cellular, and/or Bluetooth connections.

FIG. 3depicts a method200according to an exemplary embodiment of the present disclosure. The method200may be performed to verify the authenticity of a NETLOGON request118provided by a target device102. For example, the method200may be performed by a relay detection device108and/or a networking module126when verifying a NETLOGON request118received via the network112.

The method200may be implemented on a computer system, such as the relay detection device108and/or the domain controller110. For example, the method200may be implemented by the networking module126, the SPN translator132, and the IP address translator134. The method200may also be implemented by a set of instructions stored on a computer readable medium that, when executed by a processor, cause the computer system to perform the method. For example, all or part of the method200may be implemented by the CPU128and the memory130. Although the examples below are described with reference to the flowchart illustrated inFIG. 3, many other methods of performing the acts associated withFIG. 3may be used. For example, the order of some of the blocks may be changed, certain blocks may be combined with other blocks, one or more of the blocks may be repeated, and some of the blocks described may be optional.

The method200may begin with a relay detection device108receiving a network packet114,115,116(block202). For example, the relay detection device108may receive a network packet114,116from an attacked target device102via the network112. The network packet114,116may contain a NETLOGON request118, an attribute value pairs120, a target name122, and a device name124. As another example, the relay detection device108may receive a network packet117from a compromised server104via the network112. The network packet117may contain an authenticate response117containing an attribute value pairs120, a target name122, and a device name124. In certain implementations, the NETLOGON request118and/or the authenticate response117may be encrypted for secure storage and transmission.

The relay detection device108may then extract the NETLOGON request118or the authenticate response117(block204). For example, the networking module126may extract the NETLOGON request118from the network packet114upon receipt of the network packet114. As another example, the networking module126may extract the authenticate response117upon receipt of the network packet115if the compromised server104is requesting access to the domain controller110.

The relay detection device108may then decrypt the NETLOGON request118or the authenticate response117(block206). For example, the networking module126may decrypt the NETLOGON request118using a key retrieved from the domain controller110. As another example, the networking module126may decrypt the authenticate response117using a private key of the compromised server104.

After decrypting, the relay detection device108may then extract the target name122and device name124(block208). For example, the target name122and device name124may be stored within attribute-value pairs120of the NETLOGON request118or the authenticate request117. The relay detection device108and/or the networking module126may then extract the target name122and device name124from the attribute-value pairs120.

The networking module126may then determine whether the target name122refers to the same device identified by the device name124(block210). For example, the networking module126, SPN translator132, or IP address translator134may be used to identify a device on the network112corresponding to the target name122. Similarly, the networking module126, SPN translator132, or IP address translator124may be used to identify the device corresponding to the device name124. The networking module126may then determine whether the target name122refers to the same device identified by the device name124, as explained further below.

FIG. 4depicts a method300according to an exemplary embodiment of the present disclosure. The method300may be used to process a NETLOGON request118after evaluation by the networking module126. For example, the method300may be performed to process a NETLOGON request118after the networking module126evaluates the NETLOGON request118according to the method200. For example, the method300may be performed after block210of the method200, as depicted.

The method300may be implemented on a computer system, such as the relay detection device108and/or the domain controller110. For example, the method300may be implemented by the networking module126. The method300may also be implemented by a set of instructions stored on a computer readable medium that, when executed by a processor, cause the computer system to perform the method. For example, all or part of the method300may be implemented by the CPU128and the memory130. Although the examples below are described with reference to the flowchart illustrated inFIG. 4, many other methods of performing the acts associated withFIG. 4may be used. For example, the order of some of the blocks may be changed, certain blocks may be combined with other blocks, one or more of the blocks may be repeated, and some of the blocks described may be optional.

The networking module126may first analyze whether the target name122refers to the target device102identified by the device name124(block302). For example, block302may be performed responsive to the determination made at the block210of the method200. If the networking module126determines that the target name122refers to the same target device102as the device name124, the networking module126allows the NETLOGON request118or the authenticate response117, depending on which was received (block306).

If instead the networking module126determines that the target name122refers to a target device102different from the target device102identified by the device name124, the networking module126blocks the NETLOGON request118or the authenticate response117, depending on which was received (block304). In implementations where the target name122is cryptographically signed with a user hash, a malicious computing device, such as a malicious server, may be unable to modify the target name122without undermining the cryptographic signature. The device name124may also be transmitted such that it cannot be modified without causing the domain controller110to reject the NETLOGON request118or the authenticate response117. For example, the domain controller110may communicate with the target device102via a secure channel created with a cryptographic key associated with the target device102to receive the NETLOGON request118. Similarly, the domain controller110may communicate with the compromised server104via a similarly-secured channel to receive the authenticate response117. The domain controller110may be further configured to verify that the device name124matches the target device102or compromised server104that established the secure channel and may automatically reject NETLOGON requests118or authenticate responses117for which the device name124does not match. In addition to or instead of blocking the request, the networking module126may request a multi-factor authentication identifier from the user attempting to access the target device102and/or may issue an alert regarding the authenticate response117to, e.g., a network administrator or the user.

Therefore, if the target name122is determined to refer to a different target device102than the device name124, this suggests that one or both of the target name122and the device name124have been modified by a malicious actor (e.g., a compromised server12,104on the network112). Therefore, authentication should not be allowed and the corresponding NETLOGON request118or authenticate response117is blocked.

FIG. 5depicts a method400according to an exemplary embodiment of the present disclosure. The method400may be used to determine whether the target name122refers to the same target device102as the device name124. For example, the networking model126, SPN translator132, and IP address translator134may perform the method400in implementing the block210of the method200. Accordingly, as depicted, the method400may occur after the block208of the method200.

The method400may be implemented on a computer system, such as the relay detection device108and/or the domain controller110. For example, the method400may be implemented by the networking module126, the SPN translator132, and the IP address translator134. The method400may also be implemented by a set of instructions stored on a computer readable medium that, when executed by a processor, cause the computer system to perform the method. For example, all or part of the method400may be implemented by the CPU128and the memory130. Although the examples below are described with reference to the flowchart illustrated inFIG. 5, many other methods of performing the acts associated withFIG. 5may be used. For example, the order of some of the blocks may be changed, certain blocks may be combined with other blocks, one or more of the blocks may be repeated, and some of the blocks described may be optional. As another example, the relative ordering of the blocks402,404may be switched.

The method400begins with the networking module126determining whether the target name122contains an IP address (block402). As discussed above, in certain implementations, the target name122may contain the IP address for a target device102implementing a service for which access is requested. If the networking module126determines that the target name122contains an IP address, the networking module126may identify the target device102assigned to the IP address of the target name122. For example, the IP translator134may translate the IP address of the target name122into an identifier (e.g., NetBIOS name, DNS name, Kerberos identifier) of the target device102assigned to the IP address of the target name122.

The networking module126may then determine whether the assigned target device of the target name122is the same as the target device102identified by the device name124(block410). The device name124may contain a unique identifier of a target device102. The networking module126may determine if the unique identifier of the device name124refers to the assigned target device of the target name122. For example, the IP address translator134may be configured to translate the IP address from the target name122into the same type of identifier as the unique identifier of the device name124. For example, the device name124may contain the NetBIOS name of a target device102. The IP address translator134may therefore be configured to translate the IP address of the target name122into a NetBIOS name. The networking module126at block410may then compare the NetBIOS name from the IP address translator134to the NetBIOS name of the device name124. If the NetBIOS names from the IP address translator134and the device name124match, the networking module126may determine that the target name122and the device name124refer to the same target device102.

If the networking module126determines that the IP address of the target name122refers to the same target device102as the device name124(block412), processing may continue to, e.g., allowing the NETLOGON request118or authenticate response117to proceed (block306). If the networking module126determines that the IP address of the target name does not refer to the same target device102is a device name124(block406), processing may proceed to, e.g., blocking the authentication request the NETLOGON request118or authenticate response117from proceeding (block304).

If the networking module126determines at block402that the target name122does not contain an IP address, the networking module126may then determine if the target name122contains an SPN (block404). If the target name122contains an SPN, the SPN translator132may map the SPN of the target name122to a mapped target device. For example, as discussed above, the SPN translator132may map an SPN of a service for which access is requested by the NETLOGON request118to the associated target device102implementing the service. Similar to the IP address translator134, the SPN translator132may be configured to translate the SPN into a unique identifier (e.g., NetBIOS name, DNS name, Kerberos identifier) of the target device102.

The networking module126may then determine if the mapped target device102of the target name122is the same as the target device102identified by the device name124(block416). Similar to the IP translator134at block410, the SPN translator132may map the SPN into the same type of unique identifier used by the device name124. For example, the SPN translator132may map the SPN into a NetBIOS name if the device name124stores the unique identifier as a NetBIOS name. The networking module126at block416may then compare the NetBIOS name from the SPN translator132to the NetBIOS name of the device name124. If the NetBIOS names match, the networking module126may determine that the target name122and the device name124refer to the same target device102.

If the networking module126determines that the SPN of the target name122refers to the same target device102as the device name124(block412), processing may continue to, e.g., allowing the NETLOGON request118or authenticate response117to proceed (block306). If the networking module126determines that the SPN of the target name122does not refer to the same target device102as a device name124(block406), processing may proceed to, e.g., blocking the NETLOGON request118or authenticate response117from proceeding (block304).

If the networking module126determines at block404that the target name does not contain an SPN or an IP address, the networking module126may determine that detecting a relay attack10is not possible (block420). In such instances, processing may proceed to blocking the NETLOGON request118or authenticate response117in certain implementations (e.g., block304). In other implementations, the networking module126may allow the NETLOGON request118or authenticate response117(e.g., block306). In still further implementations, the networking module126may generate an alert or request a multi-factor authentication identifier from the user.

FIG. 6depicts a method600according to an exemplary embodiment of the present disclosure. The method600may be performed to verify the authenticity of a NETLOGON request118received from a target device102or an authenticate response117received from a compromised server104. For example, the method600may be performed by the system100, including the relay detection device108, networking module126and/or the domain controller110when verifying a NETLOGON request118or an authenticate response117received via the network112.

The method600may also be implemented by a set of instructions stored on a computer readable medium that, when executed by a processor, cause the computer system to perform the method. For example, all or part of the method600may be implemented by the CPU128and the memory130. Although the examples below are described with reference to the flowchart illustrated inFIG. 6, many other methods of performing the acts associated withFIG. 6may be used. For example, the order of some of the blocks may be changed, certain blocks may be combined with other blocks, one or more of the blocks may be repeated, and some of the blocks described may be optional.

The method600includes a computing device602, which may be an implementation of the target device102and/or the compromised server104, and a relay detection device604, which may be an implementation of the relay detection device108. The relay detection device604also includes a networking module606, which may be an implementation of the networking module126, and which includes an SPN translator608and an IP address translator610, which may be implementations of the SPN translator132and the IP address translator134. The method600further includes a domain controller612, which may be an example implementation of the domain controller110and may, in certain implementations, implement one or more of the relay detection device604, the networking module606, the SPN translator608, and the IP address translator610.

The method600begins with the computing device602transmitting a network packet114,115,116(block620). In certain examples, the computing device602(e.g., the target device102) may generate the network packet114to include a NETLOGON request118in response to receiving an authenticate response117from a compromised server104while authenticating user credentials provided by a different computing device requesting access to services provided by the computing device602. In other examples, the computing device602(e.g., the compromised server104) may generate the network packet115to include an authenticate response117while requesting access to services provided by the domain controller612. The relay detection device604may then receive the network packet114,115,116and may send the network packet114,115,116to the networking module606(block622).

The networking module606may then extract the NETLOGON request118or the authenticate response116from the network packet114,115,116(block624). As described above, the networking module606may decrypt the network packet114,115,116prior to extracting the NETLOGON request118or the authenticate response117. The networking module606may then extract a device name124and target name122from the NETLOGON request118or the authenticate response117(e.g., from an attribute-value pairs120of the NETLOGON request118or the authenticate response117) (blocks626,628).

The networking module606may then analyze the target name122to determine whether the target name122contains and IP address or an SPN (block630,634). If the networking module606determines that the target name122contains an IP address, the networking module606may send the target name122to the IP address translator610. The IP address translator610may then translate the IP address (block632). For example, the IP address translator610may identify an assigned device assigned to the IP address of the target name122(e.g., the NetBIOS name of the target device assigned to the IP address). If the networking module606instead determines that the target name122contains an SPN, the networking module606may send the target name122to the SPN translator608. The SPN translator608may then map the SPN (block636). For example, the SPN translator608may map the SPN of the target name122to a mapped device associated with the SPN (e.g., the NetBIOS name of the target device assigned to the SPN).

After processing at either or both of blocks632,636is complete, the SPN translator608and IP address translator610may return the mapped device or assigned device to the networking module606. The networking module606may then determine whether the target name122refers to the same target device as the device name124(block638). For example, the SPN translator608and/or the IP address translator610may be configured to map and/or translate the target name122into the same format used by the device name124(e.g., a NetBIOS name). If the mapped or translated target name122refers to the same device as the device name124, the networking module606may determine that the target name122and the device name124refer to the same computing device602.

If the target name122and the device name124refer to the same computing device602, the networking module606may approve the NETLOGON request118or the authenticate response117(block640) and may forward the NETLOGON request118or the authenticate response117to the domain controller612for further processing (block642). If, instead, the target name122and the device name124do not refer to the same computing device602, the networking module606may block the NETLOGON request118or the authenticate response117(block644) and processing may stop. Similarly, if the NETLOGON request118or the authenticate response117includes neither an IP address nor an SPN, the networking module606may block the NETLOGON request118or the authenticate response117(block644). In certain implementations, rather than blocking the NETLOGON request118or the authenticate response117at block644, the networking module606may request a multi-factor authentication identifier from the user attempting to access the target device102and/or may issue an alert regarding the NETLOGON request118or the authenticate response117to, e.g., a network administrator or the user. In such implementations, the networking module's response at block644may be configurable by, e.g., a user.

All of the disclosed methods and procedures described in this disclosure can be implemented using one or more computer programs or components. These components may be provided as a series of computer instructions on any conventional computer readable medium or machine readable medium, including volatile and non-volatile memory, such as RAM, ROM, flash memory, magnetic or optical disks, optical memory, or other storage media. The instructions may be provided as software or firmware, and may be implemented in whole or in part in hardware components such as ASICs, FPGAs, DSPs, or any other similar devices. The instructions may be configured to be executed by one or more processors, which when executing the series of computer instructions, performs or facilitates the performance of all or part of the disclosed methods and procedures.

It should be understood that various changes and modifications to the examples described here will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.