Configuration Manager SQL queries for KBs related to WannaCrypt ransomware.

The simplest and most generally recommended approach is to deploy the latest CU to Windows 10 or Server 2016 systems, and to deploy the latest Monthly Rollup to pre-Windows 10 machines, and use the built-in ConfigMgr Compliance reports to determine overall compliance.

Official Customer Guidance for WannaCrypt attacks: https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/

MS17-010 Security Update: https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Pre-Windows 10 machines:

Windows 8.1 and Server 2012 R2 machines that do not report KB2919355 as installed will be returned by the query. This is because KB2919355 is required for the later KBs to be reported as applicable. So, these systems can be considered at risk and require further investigation.

For Windows Vista, Windows 7, Windows 8.1, Windows Server 2008 R2 SP1, Windows Server 2008 SP2, Windows Server 2012, and Windows Server 2012 R2 query below, the systems returned will be those that do not have either the March, April, or May monthly rollups installed -AND- are reporting the following specific ‘Security Only’ updates as ‘Required’:

Windows Vista and Server 2008 SP2: KB4012598
Windows 7 and Server 2008 R2 SP1: KB4012212
Windows Server 2012: KB4012214
Windows Server 2012 R2 and Windows 8.1: KB4012213

Windows 10 and Server 2016

For the Windows 10 and Server 2016 queries, there are 2 scenarios that may apply depending on an environment’s configuration on the expiry of superseded updates in ConfigMgr. For more information on this, see the Supersedence rules section on TechNet and this.

Scenario 1: Customers with Supersedence rule NOT set to ‘Immediately expire’:

If the superseded updates are not expired and therefore still available in ConfigMgr, you can use the following query to help identify Windows 10 and Windows Server 2016 systems that do not have the March CU or a subsequent CU installed. Please note that for the March CU data to be evaluated, the months to wait before an update is expired value in ConfigMgr must be set to a high enough value such that the March update was not expired. The same consideration applies to the subsequent updates. If this does not apply to your environment, the information in Scenario 2: Customers with Supersedence rule set to ‘Immediately expire’ (or not long enough) can be tried.

For the following Windows 10 and Server 2016, the query below returns systems that do not have any of the following monthly CUs, released in March or later (through the date of this post), installed:

Win10  RTM: KB4012606, KB4019474, KB4015221, KB4016637
Win10 1511: KB4013198, KB4015219, KB4016636, KB4019473
Win10 1607/Server 2016: KB4013429, KB4015217, KB4015438, KB4016635, KB4019472

Scenario 2: Customers with Supersedence rule set to ‘Immediately expire’ (or not long enough):

Since CUs are superseded each month, and expired due to the ConfigMgr Supersedence Rules option being set to ‘Immediately Expire’, compliance data is not available on the expired update – in this scenario, you will, however, have compliance data on the newest CU available, so the simplest path forward would be to deploy the latest CU and report against it.

Alternate Options (for Windows 10 and Server 2016):

Alternative options to the above, that may help determine ‘at risk’ machines, by reporting on the expired CU, are as follows:

A. Extend Hardware Inventory to include Win32_QuickFixEngineering, and use this data to identify ‘at risk’ machines. If any machine has neither March, April or May CU installed, they’re ‘at risk’. NOTE that if you do not have this already enabled and enable it now, you would need to wait for all the clients to report Hardware Inventory.

B. Create a Configuration Item and Baseline which queries the March, April and May CU’s from Win32_QuickFixEngineering and reports Compliance. Here’s a sample PowerShell script written by Umair Khan that can be used in a DCM Baseline: