By Joel Ebrahimi

Using Ziften and Splunk to Detect and Respond to WannaCry / Ransomware

Introduction
Part of my role as Principle Solutions Architect at Ziften is to understand, build, and improve our current integrations with our partner ecosystem. Understanding partner technologies comes from experience in using the technologies and seeing how they behave in a variety of security situations. Naturally when a major exploit campaign occurs it is important for me to know how our products were able to detect these threats and when actions can be taken to prevent or remediate them. I also want to see what value the integrations I have been building can complement or enhance our products to increase each product’s overall value when it comes to defending against these types of threats.

WannaCry has generated a lot of media attention. It may not have the massive infection rates that we have seen with many of the older worms, but in today’s security world the amount of systems it was able to infect in a single day was still somewhat staggering. The goal of this blog is NOT to provide a detailed analysis of the exploit, but rather to look how the exploit behaves on a technical level with Ziften’s Zenith platform and the integration we have with our technology partner Splunk.

Visibility of WannaCry in Ziften Zenith
My first action was to reach out to Ziften Labs threat research team to see what information they could provide me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, heads up our research team and informed me that they had samples of WannaCry currently running in our ‘Red Lab’ to look at the behavior of the threat and conduct further analysis. Josh sent me over the details of what he had found when analyzing the WannaCry samples in the Ziften Zenith console. He sent over those details, which I present herein.

The Red Lab has systems covering all the most common operating systems with different services and configurations. There were already systems in the lab that were intentionally vulnerable to the WannaCry exploit. Our global threat intelligence feeds used in the Zenith platform are updated in real-time, and had no trouble detecting the virus in our lab environment (see Figure 1).

Figure 1: Global threat intelligence signatures detect WannaCry in lab testing.

Two lab systems have been identified running the malicious WannaCry sample. While it is great to see our global threat intelligence feeds updated so quickly and identifying the ransomware samples, there were other behaviors that we detected that would have identified the ransomware threat even if there had not been a threat signature.

Zenith agents collect a vast amount of data on what’s happening on each host. From this visibility data, we create non-signature based detection techniques to look at typically malicious or anomalous behaviors. In Figure 2 below, we show the behavioral detection of the WannaCry ransomware.

Figure 2: Behavioral detection of the WannaCry ransomware in lab testing.

Investigating the Breadth of WannaCry Infections
Once detected either through signature or behavioral methods, it is very easy to see which other systems have also been infected or are exhibiting similar behaviors.

Figure 3: Finding WannaCry infections through historical data investigation.

WannaCry Detections with Ziften and Splunk
After reviewing this information, I decided to run the WannaCry sample in my own environment on a vulnerable system. I had one vulnerable system running the Zenith agent, and in this case my Zenith server was already configured to integrate with Splunk. This allowed me to look at the same data inside Splunk. Let me explain about the integration we have with Splunk.

We have 2 Splunk apps for Zenith. The first is our technology add-on (TA): its role is to ingest and index ALL the raw data from the Zenith server that the Ziften agents generate. As this data comes in it is massaged into Splunk’s Common Information Model (CIM) so that it can be normalized and easily searched as well as used by other apps such as the Splunk App for Enterprise Security (Splunk ES). The Ziften TA also includes Adaptive Response capabilities for taking actions from events that are rendered in Splunk ES. The second app is a dashboard for displaying our data with all the charts and graphs available in Splunk to make digesting the data much easier.

Since I already had the details on how the WannaCry exploit behaved in our research lab, I had the advantage of knowing what to look for in Splunk using the Zenith data. In this case I was able to see a signature alert by using the VirusTotal integration with our Splunk app (see Figure 4).

Figure 4: Finding WannaCry in the Ziften Zenith App for Splunk.

Threat Hunting for WannaCry Ransomware in Ziften and Splunk
But I wanted to put on my “incident responder hat” and investigate this in Splunk using the Zenith agent data. My first thought was to search the systems in my lab for ones running SMB, since that was the initial vector for the WannaCry attack. The Zenith data is encapsulated in different message types, and I knew that I would probably find SMB data in the running process message type, however, I used Splunk’s * regex with the Zenith sourcetype so I could search all Zenith data. The resulting search looked like ‘sourcetype=ziften:zenith:* smb’. As I expected I received 1 result back for the system that was running SMB (see Figure 5).

Figure 5: Searching for systems running SMB using Splunk and Ziften data.

My next step was to use the same behavioral search we have in Zenith that looks for typical CryptoWare and see if I could get results back. Once again this was very easy to do from the Splunk search panel. I used the same wildcard sourcetype as before so I could search across all Zenith data and this time I added the ‘delete shadows’ string search to see if this behavior was ever issued at the command line. My search looked like ‘sourcetype=ziften:zenith:* delete shadows’. This search returned results, shown in Figure 6, that showed me in detail the process that was created and the full command line that was executed.

Figure 6: Searching for the ‘delete shadows’ string with Splunk and Ziften.

Having all this information inside of Splunk made it very easy to determine which systems were vulnerable and which systems had already been compromised.

WannaCry Remediation Using Splunk and Ziften
One of the next steps in any type of breach is to remediate the compromise as fast as possible to prevent further damage and to take action to prevent any other systems from being compromised. Ziften is one of the Splunk founding Adaptive Response members and there are a number of actions (see Figure 7) that can be taken through Spunk’s Adaptive Response to mitigate these threats through extensions on Zenith.

Figure 7: Splunk / Ziften Adaptive Response Actions.

In the case of WannaCry we really could have used almost any of the Adaptive Response actions currently available by Zenith. When trying to minimize the impact and prevent WannaCry in the first place, one action that can take place is to shut down SMB on any systems running the Zenith agent where the version of SMB running is known vulnerable. With a single action Splunk can pass to Zenith the agent ID’s or the IP Address of all the vulnerable systems where we wanted to stop the SMB service, thus preventing the exploit from ever happening and allowing the IT Operations team to get those systems patched before starting the SMB service again.

Preventing Ransomware from Spreading or Exfiltrating Data
Now in the case that we have already been compromised, it is critical to prevent further exploitation and stop the possible exfiltration of sensitive information or company intellectual property. There are really 3 actions we could take. The first 2 are similar where we could kill the malicious process by either PID (process ID) or by its hash. This is effective, but since often times malware will just spawn under a new process, or be polymorphic and have a different hash, we can apply an action that is guaranteed to prevent any inbound or outbound traffic from those infected systems: network quarantine. This is another example of an Adaptive Response action available from Ziften’s integration with Splunk ES.

WannaCry is already diminishing, but hopefully this technical blog shows the value of the Ziften and Splunk integration in dealing with ransomware threats against the endpoint.

Get the General Here