Cleaning Up Risky Traffic, A Mini Series: SMB Signing

This article provides a brief overview of NTLM Relay attacks, explains how to defend against them using SMB Signing, and suggests additional security controls worth looking into. The article also includes tips for setting up an NTLM relay honeypot as a tripwire for attackers.

SMB Signing is a security feature that places a digital signature into each SMB packet, ensuring that the message has not been tampered with during transit. This is an effective way to mitigate the vulnerabilities that exist in NTLM Relay attacks, which can result in an attacker authenticating against the server rather than the actual client. SMB Signing is not enabled by default, even though it was introduced in Windows 2000, and it needs to be enabled at both the client and server level.

Mitre Tactics and CVE’s

The following CVE’s you may have heard of. In all these cases, SMB signing could have helped mitigate the risk of exploitation, as it provides a way to verify the authenticity of SMB packets and prevent malicious actors from tampering with them.

• CVE-2020-0796: This is a critical vulnerability in the Microsoft Server Message Block 3.1.1 (SMBv3) protocol. The vulnerability allows an attacker to execute remote code on a vulnerable system without any user interaction. Microsoft released a patch for this vulnerability in March 2020. \[Mitre Tactics\] \[CVE-2020-0796\]
• CVE-2017-0143: This is a critical vulnerability in the SMBv1 protocol, which could allow an attacker to execute arbitrary code on a remote system. This vulnerability was famously exploited by the WannaCry ransomware attack in May 2017. Microsoft had released a patch for this vulnerability in March 2017, but many systems had not applied the patch in time. \[Mitre Tactics\] \[CVE-2017-0143\]
• CVE-2018-0833: This vulnerability exists in the way that the Windows SMB server handles certain requests. An attacker could exploit this vulnerability to obtain sensitive information from the server. Microsoft released a patch for this vulnerability in March 2018. \[Mitre Tactics\] \[CVE-2018-0833\]
• CVE-2021-31166: This vulnerability exists in the Windows HTTP protocol stack, which could allow an attacker to execute arbitrary code on a vulnerable system. The vulnerability can be exploited through a specially crafted packet sent to a vulnerable server. Microsoft released a patch for this vulnerability in May 2021. \[Mitre Tactics\] \[CVE-2021-31166\]

In all these cases, SMB signing could have helped mitigate the risk of exploitation, as it provides a way to verify the authenticity of SMB packets and prevent malicious actors from tampering with them.

The following MITRE ATT&CK tactics are related to SMB signing:

1. Defense Evasion: Tactic ID TA0005: SMB signing can be used by attackers to evade detection by security tools that do not inspect SMB packets. By using signed SMB packets, attackers can bypass security controls that only look for unsigned or modified packets.
2. Credential Access: Tactic ID TA0006: SMB signing can also be used to steal credentials by tampering with SMB packets in transit. If an attacker can intercept and modify an SMB packet, they could potentially steal the username and password used to authenticate the SMB connection.
3. Discovery: Tactic ID TA0007: SMB signing can be used by defenders to discover potentially malicious activity on a network. By monitoring SMB traffic for unsigned or modified packets, defenders can detect attempts to exploit SMB vulnerabilities or steal credentials.
4. Execution: Tactic ID TA0002: Attackers can use SMB signing to execute arbitrary code on a vulnerable system by exploiting SMB vulnerabilities, as in the case of CVE-2020-0796 and CVE-2017-0143.
5. Collection: Tactic ID TA0009: Attackers can also use SMB signing to collect sensitive information from a target system by intercepting and modifying SMB packets.

A Brief Attack Overview:

So what would these attacks look like? Back in the ’90s Microsoft gave the world NTLM, a challenge – response authentication protocol. The authentication works like this:

1. Client establishes a connection to the server and shares the username in plain text.
2. The server replies to the client with a challenge, asking the client to encrypt a 16 byte random number using a hash of the user’s password.
3. The client dutifully sends this to the server, and the server then sends the username, the original 16 byte challenge, and the encrypted response to a domain controller
4. The domain controller retrieve’s the user’s password from the AD database and uses it to encrypt the challenge and compares the result to the one sent by the client. If they match, disco! Access is granted.

So what if an attacker were able to get in the middle of this exchange? This would put them in a position to intercept this authentication process, relaying the requests and challenges between the client and the server, resulting in the attacker authenticating against the server rather than the actual client. From here, mayhem can ensue.

This is quite an old attack that had some fresh life breathed into it last year thanks to the PetitPotam exploit against Active Directory Certificate Services. But really, this attack vector is present in I dare say the majority of enterprises. The attack scenario is typically this:

1. Launch our old friend Responder in analyze mode to see if there is broadcast (LLMNR or Netbios-NS) traffic.
2. Use a tool such as crackmapexec or an NMAP script to determine if if SMB Signing is enabled. It is off by default – Thanks Microsoft.
3. If you have broadcast traffic and no SMB Signing, it’s time to party. The NTLM Relay script from Impacket is loaded up with a list of our target servers that don’t have SMB Signing enabled. Responder is launched to grab those broadcasts and man in the middle fun happens.

This is the most basic example of the attack. There are a lot of variations on this theme with different attack vectors and different payloads.

So How Do We Defend Against This? SMB Signing places a digital signature into each SMB packet which is used by both SMB clients and servers to validate that a message has not been tampered with in transit. This effectively shuts down the attack scenario I listed above. SMB Signing was introduced in Windows 2000, but it is only enabled by default on Domain Controllers. Enabling it for any other system requires group policy. So yet another default setting that makes an environment very easy to attack, and it has been this way for over two decades now.

SMB Signing needs to be enabled at both the client and server level. You can find the settings under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. Here you will find the following:

SMB Server • Digitally sign communications (always) • Digitally sign communications (if client agrees)

SMB Client • Digitally sign communications (always) • Digitally sign communications (if client agrees)

Configuring both the client and server to always use digital signatures is obviously the best choice here from a security standpoint. Keep in mind that if you set your settings to only digitally sign if the other side agrees, then an attacker in the middle of this exchange can just alter the negotiation to say that one side does not agree. That said, don’t let perfect get in the way of good, Digitally signing communications if agreed can still be a highly effective method of securing your environment.

Any Concerns? A concern is that you may have some client that doesn’t support SMB Signing. In these cases, set your server to digitally sign if the client agrees. Set your clients to digitally sign always. Then bust out some wireshark and sniff your SMB packets on your server and look at the SMB Signature blob in the SMB header if you have any SMB packets with a 0 in that blob, then yup, you got something that isn’t properly supporting SMB signing. If you have to leave your SMB server set to only digitally sign if the client agrees while setting the vast majority of your clients to always require digital signatures, then you’re still in really good shape! And don’t forget those firewalls! Segment off as much as you possibly can your insecure legacy solutions. Remember, a vulnerability is meaningless if there is no avenue to exploit it.

But wait, there’s more… SMB Signing is one control here. It is not a perfect control, but it is low impact and does effectively take care of a very serious attack vector. There are other controls that are very much worth looking into… First, I must point out that Microsoft has been recommending that organizations stop using NTLM since Windows 2000. Kerberos is the recommended protocol as it uses mutual authentication and advanced encryption. Disabling NTLM entirely is a great goal, but requires some serious consideration. I’d fully recommend that orgs start with trying to kill NTLM on their domain controllers. Second, I need to point out that SMB Signing does not encrypt SMB communications. However, SMB Encryption does exist and it both encrypts SMB traffic and signs SMB packets. Definitely worth looking into… Especially if you are playing on the bleeding edge with Server 2022 and Windows 11. Third, I’d heartily recommend reading up on Microsoft’s Extended Protection for Authentication (EPA): https://msrc-blog.microsoft.com/2009/12/08/extended-protection-for-authentication/

Honeypots!! If you have SMB Signing enabled then this low hanging fruit is fairly well thwarted.. So put some of that low hanging fruit back on your network as a tripwire for attackers…

A small domain controller for a new honeypot domain, a small honeypot file server joined to the honeypot domain, and a couple of old laptops or Intel NUCs also domain joined are what you’d need. Ignore everything we’ve done thus far, leave firewalls and SMB Signing off, and leave LLMNR/NBNS enabled on this honeypot domain. Kill any DNS entries for your honeypot file server. Setup some scheduled tasks on your clients that make frequent connection attempts to the honeypot file server. Congratulations, you now have an NTLM relay honeypot. Setup alerting on any network connections to your honeypot servers that do not originate from the static IPs for your honeypot clients. As with my previous suggestions along these lines, there should never be a legitimate connection to these boxesj.

One small thing for this setup… From what I have been able to find, it is not very well documented how LLMNR queries are cached on the client nor how to clear them. In my testing, doing an ipconfig /flushdns followed by a netsh int ip reset after each broadcast does appear to clear out any cache that may exist. The flushdns is probably not required as LLMNR responses do not appear to be in the DNS cache, but it doesn’t hurt. Perhaps others on this sub have a better method / know more about it.

Overall, SMB signing is an important security mechanism that can help prevent attacks and detect malicious activity on a network. However, it is important to keep in mind that SMB signing is not a silver bullet and should be used in conjunction with other security measures to provide comprehensive protection against cyber threats.

For assistance in enabling SMB Signing reach out to professionalservices@tridentstack.com or to see how our fully managed XDR solution can help detect and prevent misconfigurations, and malicious actors email sales@tridentstack.com