How to Stop WannaCry Ransomware with CrowdStrike Falcon® Endpoint Protection

Unfortunately for most of us we’re familiar with how ransomware behaves, which is what makes WannaCryptor or WannaCry so noteworthy. Once WannaCry is on a network, it leverages a vulnerability in Windows file sharing protocol, Server Message Block or SMB, in order to spread through an organization. In our first example, we’ll watch as we take a sample of WannaCry, and run it on an unpatched system here on the left. On the right is a second system. This one is on the same network, and also vulnerable to the exploit leveraged by WannaCry.

One of the things that has been so devastating is the speed at which this ransomware propagates through an organization. After detonating the file on the target system, it is only a matter of seconds before files on the second system become encrypted. Quickly thereafter, we see the wallpaper change, and the ransom note appear. CrowdStrike not only protects against the initial infection of WannaCry, but also prevents protected systems in the same organization from being affected by the spread of WannaCry.

In this video, we’ll demonstrate the effectiveness of CrowdStrike in protecting organizations against ransomware using WannaCryptor as an example. To get started, we’ve got this sample in our target system. We’ll simply unzip and run the file. After double-clicking the file to run it, we see that it disappears, and a Windows dialog box is opened to inform us that Windows cannot access the file.

This is because Falcon has identified the file as malicious and quarantined it. In the Falcon UI we see a new alert. Clicking on the alert expands the process tree, and we see that the activity was prevented as machine learning determined it was malicious. On the right side, the execution details pane provides further insight to the event and the file.

When we run this sample again, we’ll modify it using Notepad++. After each detection, Falcon will quarantine a suspicious file, and add it to a blacklist preventing the rest of the organization from running the file. We need to modify this, because the original sample has been quarantined. But this will also illustrate that Falcon has the ability to identify malicious files even if the hash is completely unknown.

For tracking purposes, we’ll change the name, which will be helpful as we run multiple samples. And finally, we’ll disconnect from the network to highlight the protection that Falcon provides even when not connected to the internet. After those changes have been made, we’ll run the sample again. And again, the file is removed, and we get a message indicating the file cannot be located.

Refreshing the UI, we see a second detection. This time we see a similar process tree with the new file name, and it was prevented by our on sensor machine learning engine. Even though we were offline and the sample had been changed, our on sensor machine learning technology is still able to prevent WannaCrypt from infecting its host.

This next time, we’ll change the prevention policy. Up to this point, we’ve been relying on machine learning. So the next scenario, we’ll disable our machine learning both on sensor and in the cloud. On the host we’ll unzip another sample, and this time will make a different change and rename the sample. This time the file doesn’t disappear, and we don’t get the dialog box, but nothing else seems to happen.

Let’s further inspect in Falcon. Refreshing the browser we see the new alert, and expanding the alert we see additional details in the process tree. This time we see the same parent process of explorer.exe, but directly following we see a detection on the file name WannaCry dash 02. However, instead of a prevent icon we see the detection icon, and the CrowdStrike intelligence recognizes actions associated with this file as a malicious indicator.

Directly following the detection from CrowdStrike intelligence, we see a new prevention, only this time the prevention isn’t based on machine learning, but a suspicious process. CrowdStrike can identify processes that are associated with malicious behavior, and our agent immediately prevents any further action. Once again, the user has been protected.

For this next scenario, let’s assume that someone in the organization brings an infected system onto the network. We’ll simulate this by going into our policy preventions, and disabling everything leaving this host completely vulnerable. On the host we’ll get a new sample, and change it again. This change will be slightly different than the last one. Now with protections turned off, there’s nothing in place to keep this unpatched system from being infected, and spreading this to other systems in the network.

To see the changes, we have a folder open on the desktop with some pictures. As we run the sample again, we see files start to be encrypted, the wallpaper has changed, and a ransom note appears. And remember, while we see this on the infected system, the ransomware is also attempting to spread to other systems. In the Falcon UI we have multiple new detections. On our target system we see new detections, but no preventions. We see that the detection details have identified two processes as destructive, and associated with ransomware. Had preventions been enabled, our system would have been protected.

The unique feature of this ransomware was its ability to take advantage of that SMB vulnerability, and propagate itself through the network like a worm. In our alerts we see a prevent icon. Only this time it’s not associated with our first system. It’s associated with another computer on our network, WIN7-ISO2. Inspecting further, we see that ransomware was prevented from executing, and the file associated with it was quarantined. Because this organization was protected by CrowdStrike, this ransomware was unable to spread to other hosts.

For more information, check us out at crowdstrike.com.