RM Logo
Technical Rating: 
Support Home PageSupport
Print This PagePrint This Page
Add to 'My Library' Add to 'My Library'

RM advice on disabling SMBv1 on networks
Published Date : 19 May 2017   Last Updated : 05 Jul 2019   Content Ref: TEC5705399  


SMBv1 and Ransomware

The recent Ransomware exploit (refer to NWS5696059 in the Other Useful Articles section below) spread due to a vulnerability in the SMBv1 protocol. The Microsoft advice (repeated in our NWS article) was to patch all affected computers and servers immediately.

A number of customers have asked about disabling SMBv1 across their network, as this is now an outdated technology. This article sets out our reasoning for not releasing an update that does this for all customers.


SMBv1 is used by some legacy devices / applications

Ideally we would like to disable SMBv1, but unfortunately a blanket ban on SMBv1 can cause issues. The number of systems potentially using SMBv1 in a school is so large that a mandate to turn it off, delivered by a patch or CC4 update could cause chaos in some school's systems. CC4 itself has no requirement for SMBv1, but we cannot guarantee the rest of your school's systems, including ones that could be critical to safeguarding, child safety as well as education could make this move.

The advice to respond to MS17-010 - WannaCrypt is to patch - remember the HyperV physical servers, if you have them, as these are often found unpatched or waiting to install a patch from some time ago. 

If you cannot patch a device, then disabling SMBv1 can be used (though resolution of why you cannot patch a device should be high on your to-do list). If you blanket ban SMBv1 on your network, you may cause significant issues.

The problem is that disabling SMBv1 could affect all those other, often forgotten, systems on the network - Signage, Cashless Catering, Visitor Entry Systems, BMS, CCTV, VLE - as well as potentially any older Mac OSX, IOS, Android, BYOD, guests and potentially systems brought into your school by social services / council employees etc. Even older versions of Smoothwall (pre-Inverness release) uses SMBv1 to contact your domain controllers, so user based filtering rules will not work.

There will be other systems not listed - so patch now - and then plan a project to remove SMBv1 later when it can be done in a controlled manner.

The actual disabling of SMBv1 is not hard at all (give us a call about it if you like, we are happy to help) - wrangling your suppliers to make everything work is potentially a far greater challenge.

How does WannaCrypt use the SMBv1 vulnerability

The WannaCrypt malware is a also a worm and uses the SMBv1 vulnerability to worm its way around the network, spreading itself to vulnerable machines.

It is just (!) a bit of Ransomware. If one user clicks on the wrong link, then off it goes encrypting anything the user has access to - standard Ransomware stuff.

To mitigate any Ransomware, we recommend only giving your users the minimum rights they need and do not let grant local administrative rights. This way the impact of this Ransomware is kept to a minimum.

But the problem with WannaCrypt is the worm. It moves around your network looking for other devices to infect, not just encrypting some files on the remote system - like your file server, but it is creating an executable on that system. 

This then runs as whoever is on that system - so your admin PC that you are logged on as a domain admin, or the server you are on is now infected and the worm executes as you in the background then everything can be encrypted on the network. This turns a couple of hours downtime (to restore a home area and maybe the staff shared area) to potentially weeks of downtime as servers are restored or rebuilt and you might have to rebuild every computer. RM has been called in to assist with this sort of issue many times.

Patching the SMBv1 vulnerability prevents the worm from moving around the network. The Ransomware may still be able to run and encrypt the files the user has access to but it cannot spread. So you have one Ransomware infection - not 600 to contend with.


MS17-010 - Response
  • Always have offsite / backups that are not accessible via a share (since if it can see your backups it will encrypt them first).
  • If using cloud storage services such as OneDrive or Google Drive your documents are backed up in version control - though some viruses / Ransomware can make it difficult to restore these / get the original filename back and you may require assistance to recover these.
  • Patch - Patch everything and make sure you got everything (refer to NWS5696059 in the Other Useful Articles section below for a link to a tool to scan your network to identify computers not patched).
  • Have up to date anti-virus - RMVP and now most anti-virus vendors' products are also blocking the SMBv1 manipulation that WannaCrypt is using (you still need to patch but your AV is helping (if it's up to date)).

If you need a hand please do get in touch with RM Support or your normal support provider.

Other Useful Articles

RM advice following the WannaCry & Petya Ransomware outbreaks (NWS5696059)

Did the information in this article help answer your question?
Please add any comments about this article in the box below. If you answered No then it is important you tell us why so that we can change the article if required. We can only respond if you log in to the RM Support website or provide your contact details. Note: If you need help with a technical query, please log a call online or telephone our support team.
Thank you for your feedback, which is sent directly to the RM Knowledge team. We address every message received with the intention of improving our Knowledge Library articles. If you have an unresolved technical issue, please contact RM Support.

If this article has not helped provide a solution then it is also possible to log a call...

Document Keywords: rm, SMBv1, ransomware, wannacrypt, wannacry

Please read - important disclaimer information.
http://www.rm.com/_RMVirtual/Includes/csredirect.asp?cref=&title=Standard Content Disclaimer

Top Of PageTop of page