NTLM Relay Attacks


There are several ways an attacker can persuade a Windows host to connect to a malicious SMB server to intercept credentials; https://www.bordergate.co.uk/smb-credential-interception/

However, intercepting NTLM-SSP credentials in this manner requires an attacker to break the hashed value, which can take some time.

An often quicker route to compromising hosts, is to relay credentials between systems.

SMB to SMB Relaying

Relaying NTLM credentials between hosts using SMB can be prevented using SMB signing, however this isn’t a default setting and rarely seems to be enabled on client systems.

It’s worth noting that since Microsoft’s MS08_068 patch, NTLM credentials cannot be relayed back to the host they originated from. Because of this, the source of the credentials will need to be different than the target.

To begin the attack, start by determining hosts on the network which don’t have SMB signing enabled using crackmapexec and output the list of hosts to a text file:

From the output, we can see SMB signing is enabled on the Windows server host which is a domain controller. Signing is enabled by default on server operating systems.

We can target the client systems which don’t have SMB signing enabled using ntlmrelayx from Impacket (https://github.com/SecureAuthCorp/impacket).

The example below shows the WINDOWS2 host attempting to authenticate to the attackers host. These credentials are relayed to WINDOWS1, and the contents of it’s SAM database are extracted;

The above will work provided the intercepted user account has local administrator privileges over the target host.

Since in most corporate environments vulnerability scanner and asset management systems will attempt to authenticate to any system within internal network ranges it isn’t an unusual scenario for the credentials to be sent to the attacker without having to resort to MITM attacks.

However, this doesn’t directly help us target the domain controller which has signing enabled.

SMB to LDAP Relaying

However, there is a another way to target the domain controller. By relaying an SMB authentication request to the DC’s secure LDAP port, we can create new domain administrator accounts (provided the victim user has these privileges).

To perform this attack, the SMB Message Integrity Code (MIC) needs to be bypassed using CVE-2019-1019 (–remove-mic flag), otherwise authentication will fail.

We can verify the credentials work by using crackmapexec to authenticate to the domain controller:

Bonus Round!

Even if the account intercepted has no special privileges, we can still use this technique as a foothold into a network.

Standard user accounts have the privilege to create computer accounts. The below output shows ntlmrelayx creating a new user account on the domain using a standard user account.

This newly created machine account can then be used with tools such as BloodHound (https://www.bordergate.co.uk/bloodhound-by-example/) to further identify attack paths within the domain.

Closing Notes

If you are trying this in a lab, a certificate will need to be configured for LDAPS to work. The following PowerShell script will generate a certificate that can be used for testing: