What if we were to tell you that anyone connected to your network could simply ask other users to sign into their system, then relay that sign-in and assume the privileges of that user?

Further, what if this wasn’t limited to users who had an account, but anyone who could connect to the network?

Unfortunately for a lot of organizations that is the case; especially those using a Microsoft Windows and Active Directory-based infrastructure.

These are called relay authentication attacks and here are some mitigation steps to help mitigate the risk:

Mitigations: Attacker Step 1

In Step 1 on the attacker’s side, they did a stealthy SMB scan to identify vulnerable targets. What they were looking for was:

  • Systems that accept incoming SMB connections that do not require SMB Signing and/or SMB Encryption
  • Systems that accept incoming LDAP or LDAP/S connections that do not require signing.

Our first mitigations are:

  • Disable incoming SMB where possible by creating firewall rules
  • Require SMB Encryption as an ideal or SMB Signing as a secondary option.
      • Keep in mind that it should be required on both the host and the client, which requires four group policy changes under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
      • For the hosts, create a policy and enable Microsoft network server: Digitally sign communications (always) and Microsoft network server: Digitally sign communications (if client agrees). Domain controllers have these settings applied by default, so it is only necessary to apply this policy to an OU containing the rest of your servers.
      • For workstations, create a policy and enable Microsoft network client: Digitally sign communications (always) and Microsoft network client: Digitally sign communications (if server agrees).

Note: You should only use the “if server agrees” options if SMBv1 is still enabled in your environment. However, it is recommended to not use SMBv1 and to disable it when possible.

  • Require LDAP signing

Much in the same way that you want your servers to negotiate signing on SMB traffic, we will do the same thing for LDAP traffic.

Default Domain Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies> Security Options.

In the Network security: LDAP client signing requirements Properties dialog box, select Require signing in the list, and then select OK.

  • Enable LDAP channel binding

As of March 2020, Microsoft offers a group policy for LDAP channel binding: Domain controller: LDAP server channel binding token requirements specifically to address current vulnerabilities. It is recommended that Windows administrators review Microsoft’s posting at https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows and follow the guidance there.

Possible Pitfalls: Step 1 Mitigations

Requiring traffic signing can result in decreased performance when processing that traffic. So, connections over SMB and LDAP could take longer. In more robust environments, this change could be negligible. However, in particularly taxed environments, connections relying on signed traffic might take noticeably longer.

Additionally, it is possible that enabling SMB and/or LDAP signing can interfere with some third-party applications that may not support signed SMB or LDAP traffic, particularly applications that rely on SMBv1.

Mitigations: Attacker Step 2

The attacker’s second step was to trigger an authentication technique by:

  • Abusing multicast name resolution services enabled by default
  • Operating a rogue IPv6 DHCP server on networks that do not have IPv6 enabled

So our mitigations for this section are, with group policy options where applicable:

  • Disable WPAD

This is a DHCP server option and NIC level TCP/IP properties change to disable NetBIOS over TCP/IP

  • Disable LLMNR

Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client

Set “Turn OFF Multicast Name Resolution” to Enabled.

  • Disable mDNSst

Multicast DNS sends traffic over UDP port 5353. Review your firewall rules to make sure UDP 5353 is only allowed from trusted locations that need it.

  • Disable NBT-NS

This should be mitigated by the WPAD NIC changes in step 1. Disable NetBIOS over TCP/IP.

  • Set up IPv6 across the network or block IPv6 DHCP & DNS traffic on your network according to vendor’s instructions.

Possible Pitfalls: Step 2 Mitigations

The primary issues with disabling the protocols listed above are causing problems with applications that rely on them. It is always recommended to check with your applications vendors before making any network wide changes to assess the impact that sweeping changes will have. However, the security benefits far outweigh the losses in most cases. A cursory internet search on each of the protocols above, excepting IPv6 (without additional context), will reveal no shortage of horror stories and attack vectors.

Mitigations: Offline Password Cracking

Offline password cracking is ruthlessly effective, especially but not only for systems with standard 8-character password requirements. Utilizing cloud-based password cracking techniques, an attacker can guess every single possible 8-character password in under 20 minutes.

Our recommendation is the following:

  1. Institute a minimum of 15-character password and encourage passphrases
  2. Implement strong account compromise monitoring measures on your SIEM/equivalent.
  3. Implement password filtering to exclude the use of organization-associated words in passphrases
  4. Extend password life to 1 year or possibly longer
  5. (Optional) Remove password complexity requirements

These techniques also make other attack paths such as password spraying much more difficult. We hope to cover password spraying in an upcoming talk and blog post!

Mitigations Checklist

If you want a checklist for mitigations, here it is:

  • Disable incoming SMB where possible by creating firewall rules
  • Require SMB Encryption as an ideal or SMB Signing as a secondary option.
    • Keep in mind that it should be required on both the host and the client, which requires two separate GPO changes.
  • Require LDAP signing
  • Enable LDAP channel binding
  • Block IPv6 DHCP & DNS traffic OR fully configure IPv6 on the network
  • Disable WPAD
  • Disable LLMNR
  • Disable mDNS
  • Disable NBT-NS