Disable SMBv1 in your environments with Configuration Manager Compliance Settings

First published on TECHNET on May 22, 2017

Authored by Cameron Cox

NOTE: I have updated this blog to remove SMB1 LanmanServer from 2012/8+.

There has been lots of buzz over the recent attacks. One of the mitigations to keep the attack from spreading is disabling SMBv1 on all your Windows workstation and servers. One of the easy ways to deploy this out, while also having reports to confirm the settings are set correctly, is the use of Configuration Managers Compliance Settings, also known as Desired (DCM). Using compliance settings makes rolling out this change a breeze and allows you to update your security teams with reports to show the progress of the roll out. Below are the detailed instructions on how setup, configure and deploy these settings.

First, all the documentation on how to disable SMBv1 can be found here .

You can also do this with , keep in mind, does not have a reporting system built into it. The instructions, along with some really good information on the attack can be found here .

You can also do this with Desired State Configuration (DSC). A friend of mine in the consulting side of services, Ralph Kyttle, put together instructions for DSC, leveraging a DSC tool he help build, called the Desired State Configuration Environment Analyzer (DSCEA). The instructions can be found here . The DSCEA tool can be found here .

Let's begin!

First, we need to create the detection and remediation for both LanmanServer and LanmanWorkstation.

For LanmanServer pre-2012/8 is straight forward as we only need to find a single registry key. For 2012/8+ we need to gather the 1 feature for windows.

## LANMANSERVER
## Detection
$SMBv1Compliance = 1
$SMBServer = Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters"
$Win10 = (Get-WmiObject -Class Win32_OperatingSystem).Caption | Where-Object {$_ -like "Microsoft Windows 10 *"}
$Win2016 = (Get-WmiObject -Class Win32_OperatingSystem).Caption | Where-Object {$_ -like "Microsoft Windows Server 2016 *"}
IF ($Win10) { $Win10SMB1 = (Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol).State.ToString() }
IF ($Win2016) { $Win2016SMB1 = (Get-WindowsFeature -Name FS-SMB1).InstallState } 
IF ( (($Win10SMB1 -like "Enabled") -or ($Win2016SMB1 -like "Installed")) -or $SMBServer.SMB1 -eq 1 ) 
{
$SMBv1Compliance
}
ELSE
{
$SMBv1Compliance = 0
$SMBv1Compliance
}

For remediation, pre-2012/8 we will need to just set the registry value to 0, for 2012+ we need to actually remove the feature. Once we restart the service we will operating without SMB1. Note: You will have a pending reboot for 2012/8+ server and client.

## Remediation 
$WinVersion = (Get-WmiObject -Class Win32_OperatingSystem).Version
Switch -Wildcard ($WinVersion)
{
"10.*"
{
Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol -Norestart
}
"8.*"
{
Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol -Norestart
}
"6.*"
{
Set-ItemProperty -Path “HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters” SMB1 -Value 0 –Force
}
}
Restart-Service -Name LanmanServer -Force

For LanmanWorkstation this scenario is not as straight forward as we have REG_MULTI_STRING we need to evaluate and ensure the value for SMBv1 is not present. We also need to ensure the SMBv1 service is not running. This means we need to add some logic to the detection script.

## LanmanWorkstation
## Detection
$SMBClient = Get-ItemProperty -Path “HKLM:SYSTEMCurrentControlSetServicesLanmanWorkstation" 
$SMBv1Status = $(Get-Service -Name mrxsmb10 -ErrorAction SilentlyContinue).Status
IF (($SMBClient.DependOnService -contains "MRxSmb10") -or ($SMBv1Status -eq "Running")) {$false} ELSE {$true}

This reads the value of the DependOnService property and verifies MRxSmb10 is not in the list. MRxSmb10 is the SMBv1 service found in Windows where SMBv1 is still on by default. In this case I am using reverse logic, I am checking for the state that I don't want the services to be in. If we find the services are in their default state, we return a Boolean $false, which will represent a non-compliant machine and will be the trigger for running the remediation script.

For remediation, we will configure the services to no longer depend on SMBv1 and disabled the SMBv1 service. We will then restart the services and stop the SMBv1 service. This will ensure the changes will take effect immediately.

## Remediation
Invoke-Command {cmd /c sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi}
Invoke-Command {cmd /c sc.exe config mrxsmb10 start= disabled}
Restart-Service -Name LanmanWorkstation -Force
Stop-Service -Name mrxsmb10 -Force

Now to take the and plug them into Compliance Settings.

We need to create a new configuration item, and give it a name that aligns with a naming convention and can easily be identified.

We need to remove the operating systems that we know this will break. In my lab, I am removing All Windows XP, and Server 2003 variants. In your environment, you might want to disable on these versions, just keep in mind, anything prior to Vista only has SMBv1, meaning it will break SMB functionality on those machines.

We need to setup the first setting for LanmanServer, be sure to set the Setting Type to Script and Data Type to Integer

Copy in the detection script

Copy in the remediation script

Setup the compliance rule to equal Zero (0) , turn on remediation and report non-compliance if setting instance is not found .

Now to setup the setting for LanmanWorkstation, be sure to set the Setting Type to Script and Data Type to Boolean .

Copy in the detection script

Copy in the remediation script

Setup the compliance rule to equal true and turn on remediation and report noncompliance if this settings instance is not found .


Finish out the wizard.

Now we need to create the baseline, and add the CI

Create the collection for deployment

Deploy the Baseline.

I recommend manually running some of the on a few machines and drop in a few machines that are not compliant before turning remediation on, in the deployment. This will allow you to test the logic. Once you are comfortable with your testing, start rolling out this slowly to machines and/or servers. Remember just because the OS can communicate over S
MBv2/3 doesn't mean your applications are programmed to allow the OS to handle the communication. Some applications may have SMBv1 hardcoded, so be sure to test this in your environment.

Hope this helps!

Cameron

Disclaimer: The information on this site is provided “AS IS” with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use

 

This article was originally published by Microsoft's Core Infrastructure and Security Blog. You can find the original article here.