I work as a system administrator for a large financial organization and we first heard about WannaCrypt (also called WannaCry) late last week via the news, as well as our internal security department. We knew we had to scrutinize the situation to determine the best course of action.

One of the elements behind the success of WannaCrypt is the fact it can spread using Microsoft Windows Server Message Block (SMB), which is a way to share files in Windows. This means the phishing email doesn’t have to even reach a system for it to become compromised. As a result, some security officers and upper management are now panic-stricken like stranded characters in “The Walking Dead,” listening to the walkers (zombies) banging on the doors as they huddle trapped inside a bunker.

SEE: How to defend yourself against the WannaCrypt global ransomware attack (ZDNet)

We talk a lot about ideal toolkits on TechRepublic, but there are also many useful interpersonal or “soft” skills which come in handy when relating to others. Diplomacy and common sense are among the greatest of such skills. When the security team or execs are pushing for everyone to drop everything now and patch all systems across the board, it’s important to keep perspective and develop a logical plan everyone can agree on which serves the needs of the users, administrators and overall organization.

In this article, I’ll speak from first-hand perspective on how a threat of this magnitude should be approached from a system administrator perspective.

Assess your needs

Contrary to raw hysteria which might report “all company systems are potentially vulnerable,” that figure may, realistically, be far less. Not all systems are the same. Windows 10 is not impacted in this case, nor are mobile devices or the Linux and Mac operating systems. So, out of the starting gate we knew the scope we had to focus on: Windows systems (other than version 10) in the organization, both workstations and servers.

I can’t stress enough that you need to use technology to manage technology. Two of the most essential tools when managing and addressing vulnerabilities are security scans and automated patching mechanisms. In my case we use Qualys to assess our environment and report on vulnerable systems, and Microsoft’s System Center Configuration Manager (SCCM) to deploy patches to Windows machines.

In preparation to face WannaCrypt head-on, we conducted a security scan to get a list of systems we needed to patch and ran an SCCM report to examine the current status of the patch Microsoft released in March to determine where it was installed.

What we found gave us no small measure of comfort. All user-operated systems were protected, meaning anyone who inadvertently clicked a link in a phishing email would not be impacted by WannaCrypt. However, we found over a hundred test and development Windows 7 systems which had not received the patch, and even though these are on a different subnet inaccessible by many user systems, these vulnerable boxes nevertheless required our attention.

With this list in hand, we proceeded to the next step.

Research and test

Why didn’t these systems get the patch from March? Being test and development boxes, they weren’t set up in SCCM since they are routinely recloned from a master image using VMWare vRealize. However, since the vRealize process had some problems we hadn’t recloned these systems for a few months pending resolution of the issue.

Patching is not the only option in many cases. Microsoft also includes workarounds at this link to disable Server Message Block for Windows 8.1 or Windows Server 2012 R2 and later; these involve turning specific SMB settings off via the Control Panel or Server Manager. Customers running Windows Vista, Windows 7, Windows Server 2008/2008 R2 should see Microsoft Knowledge Base Article 2696547 which provides Powershell commands and registry changes to achieve the same result. Keep in mind this may produce unwanted or unintended effects when it comes to sharing files between systems, however.

We had a decision to make: risk recloning the systems and failing, implement the workaround, or push the patch out manually. We opted for the latter choice as the safest bet.

Rather than blindly rolling out a patch to a hundred systems (even though we had already done so to a larger amount of user workstations), we downloaded the Windows 7 patch manually (you can obtain patches for versions of Windows from Vista workstation to Server 2016 here). I applied it to several systems with good results.

Create and agree upon a plan

Adding 100 or more test systems to SCCM on a temporary basis would have been slower and more tedious than pushing the patch to them directly.

Usually it’s a good idea to prioritize which systems to patch first (user-controlled or public-facing systems are often the biggest targets), but these virtual machines were all largely the same so we could skip that step and apply the patch manually.

There are many different ways to do things in the technology realm, but when it comes to remotely executing commands on a bulk of Windows systems I have found Windows Sysinternals commands to be an awesome collection of tools. Powershell is versatile and robust as well, but not as quick and easy in all cases, and while Group Policy also offers excellent functionality I wanted a quick and simple solution.

Psexec is one such command which can easily run commands on systems using a simple FOR loop in a batch file. It relies upon the use of an administrator account which can access these systems and write files or run commands. I created a batch file with this content:

FOR /F "tokens=1" %%i in (computers.txt) do xcopy patch.msu \\%%i\c$\logs /D

FOR /F "tokens=1" %%i in (computers.txt) do psexec -s -d \\%%i c:\windows\system32\wusa c:\logs\patch.msu /quiet


The first line assesses a text file named “computers.txt” – in which I put the host names of all vulnerable systems and from which it assigns the “%%i” variable to match each host name – and copies the patch file (obviously named “patch.msu”) to the C:\logs folder on all machines.

The second/third lines execute the command via psexec, using the -s switch (to run as a System account) as well as the -d switch (to run in non-interactive fashion whereby it does not wait for each process to finish but fires the command out to each computer).

Note that “pause” at the end of the batch file. That keeps the command window open so you can assess the results and look for failures such as access problems, hard drives out of space, etc.

SEE: Why patching Windows XP forever won’t stop the next WannaCrypt
SEE: Ransomware: The smart person’s guide

Execute the plan

After researching, testing and building the plan the execution is the easiest part. I ran the batch file and it cycled through the system list, deploying the patch to most systems which then rebooted the machines for me.

Confirm success

Running another Qualys scan is the best way to confirm the vulnerability has been patched, but I also spot-checked a few Windows systems to ensure KB4012212 had been installed. I found a few machines which failed to receive the patch since they were out of disk space so I corrected the problem and deployed it to them successfully.

You can go to Control Panel / Programs and Features / View installed updates to see if a particular patch is present:

However, it’s easier to use the “wmic qfe get” command to display installed updates from a command window:

Even better, I ran wmic qfe | find “KB4012212” to look for this particular patch (replace “KB4012212” with the patch you’re looking for if addressing another issue, of course):

The systems I checked were all clean, and the subsequent Qualys scan confirmed as such. All told, the process took about a day and our environment is now fully secured from WannaCrypt. Any new systems we spin up will be patched before put into use and will thus be protected as well. The security department was satisfied and user impact was minimal.

In closing, I’d like to point out that you should never pay a ransom for either personal or business data which becomes seized by the bad guys; it will only ensure episodes of this nature keep happening. Never have one copy of data. Ensure your backups are working reliably. And review those patching reports to make sure things are running smoothly in the background!

Also see: