So, now that we have explained how the attacker can get access, it’s time to talk about how to mitigate it. (Please see previous blog post for details on relay authentication attacks)
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:
- Institute a minimum of 15-character password and encourage passphrases
- Implement strong account compromise monitoring measures on your SIEM/equivalent.
- Implement password filtering to exclude the use of organization-associated words in passphrases
- Extend password life to 1 year or possibly longer
- (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
