<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1525762147722832&amp;ev=PageView&amp;noscript=1">
24.05.2017 | Technical | News | Blog

How To Detect And Protect Yourself From WannaCry

Time to read: 8 min

In light of the WannaCry attack a week ago, and the importance of your management lifecycle, including security, we have developed a solution on how you can detect WannaCry ransomware and protect yourselves, using Operations Management Suite (OMS) from Microsoft.

If OMS is part of your management lifecycle, or you are considering to include it, here’s a free solution from us to you!


Proper protection is essential for making sure your data is safe. There are various tools and services that you can use to achieve protection, but the most important thing is to have defined policies applied and automatically remediated, thus leading to governance. OMS have capabilities that can help you when you are managing servers. This is called Azure Automation Configuration Management.

In the case of WannaCry, disabling SMB v1 (Server Message Block) it is key to prevent or stop the spread. SMB1 is a 30 years old protocol that is enabled on every version of Windows Server (that should not be used by any application or service).

If you still have applications using SMB1 our strong recommendation is to work towards deprecating the use of it in your environment. With Azure Automation, you can disable SMB v1 very easily on your servers. Not only can it be disabled, but Azure Automation will make sure that if someone or something enables it again remediation will be performed.

In the example below I have added my server as a DSC node in Azure automation. For more information click here.


Next step is to add a DSC configuration that will disable SMB v1 on my servers. Example configuration is shown below:

Configuration Security


    Registry DisableSMB1


        Ensure      = "Present" 

        Key         = "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters"

        ValueName   = "SMB1"

        ValueData   = "0"

        ValueType   = "Dword"



The configuration is saved as ps1 file and uploaded to Azure Automation:


After the configuration is uploaded it must be compiled:


After the DSC configuration is compiled a DSC Node configuration is produced, which can be assigned to nodes. Before assigning the configuration to our node we can see that SMB1 registry value is not present.


We then assign the DSC Node Configuration to the DSC Node:


The DSC node will go into pending state awaiting its’ configuration:


After the configuration is received and applied on the server it will report as compliant.


We can then see the configuration applied to the server.


If we go and delete the registry value on the next compliance check the configuration will be automatically remediated as seen in the screenshot below.


Disabling SMB1 can also help you prevent any future threat. If you are unsure of which applications that are using SMB1, Service Map, which is part of OMS can help you with that. Using Service Map, you can find which applications in your environment that are using the SMB protocol. If you disable SMB v1 and if some application is using it with Service Map you will be able to see a failed SMB connection occurring. You can see an example of how that will look in Service Map below:



OMS is also great at detecting security threats. When @WanaDecryptor@.exe is being executed the Security and Audit solution in OMS will detect it as suspicious executable:


What if we just want to perform a quick inventory and check if WannaCry is present on our servers? How can one do that with OMS, even if the Security and Audit solution is not enabled? In such a scenario, we can use the Change Tracking solution. When WannaCry is present on a machine, value ‘wd’ in registry key ‘HKEY_LOCAL_MACHINE\SOFTWARE\WanaCrypt0r’ will be created as described here. By going to the OMS portal -> Settings -> Data -> Windows Registry Tracking we can add the key ‘HKEY_LOCAL_MACHINE\SOFTWARE\WanaCrypt0r’ as shown below:


When registry key is added for the first time the solution will take a snapshot of the values in that key on every server reporting to OMS. After several minutes, we can execute the query below and see which servers that have this registry:

Type=ConfigurationChange (ConfigChangeType=Registry)


This information gives us some details. We can see that the ransomware got on the system by an admin user who probably infected the machine by browsing.

With only a few clicks we could detect which servers that were affected by this ransomware. Of course, with OMS, there are many paths to success. For example, you can use the change tracking solution if SQL related services (sqlwriter.exe or sqlserver.exe) or Exchange services (Microsoft.Exchange.* or MSExchange*) are being stopped as the trojan will try to end these.

Change tracking can also be used to check if SMB v1 is disabled on your servers. Just add the ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters’ registry key as shown here:


After the data is available in Log Analytics, we can then execute a query like the one below to check on the machines where a SMB1 value is present and if it is disabled or enabled:

Type=ConfigurationChange (ConfigChangeType=Registry)  RegistryKey="HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\LanmanServer\\Parameters" ValueName=SMB1 | Extend if(termfreq(ValueData,0),"SMB1 Enabled","SMB 1 Disabled") as Result | Select Computer, Result|display Table


When the SMB1 value is not present that also signals that SMB v1 is enabled. For that scenario, we have another query that will show us computers where SMB v1 enabled:

Type=ConfigurationChange (ConfigChangeType=Registry)  RegistryKey="HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\LanmanServer\\Parameters" Computer NOT IN {Type=ConfigurationChange (ConfigChangeType=Registry)  RegistryKey="HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\LanmanServer\\Parameters" ValueName=SMB1 | measure count() by Computer} | Dedup Computer | Select Computer | display Table


After the initial inventory, you can remove these registry change tracking settings or leave them and monitor for any changes.

I hope you found this useful, and that it gave you some more insight in the capabilities of OMS on how to handle ransomware like WannaCry.

If you need any help with WannaCry or other ransomware attacks, feel free to contact us. It doesn’t matter if you are using OMS or other tools, we will help you anyway!


Stanislav Zhelyazkov

Stanislav is a Principal Consultant at Lumagate and a Microsoft MVP in Cloud and Datacenter Management.

Find me on: