Written by Joel Ebrahami and presented by Charles Leaver


WannaCry has produced a lot of media attention. It might not have the huge infection rates that we have seen with a number of the previous worms, however in today’s security world the amount of systems it had the ability to infect in one day was still somewhat incredible. The objective of this blog post is NOT to provide an in-depth analysis of the exploit, but rather to look how the threat behaves on a technical level with Ziften’s Zenith platform and the integration we have with our technology partner Splunk.

WannaCry Visibility in Ziften Zenith

My very first action was to reach out to Ziften Labs danger research group to see exactly what info they could provide to me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, directs our research study team and notified me that they had samples of WannaCry presently running in our ‘Red Laboratory’ to look at the behavior of the risk and conduct more analysis. Josh sent me over the details of exactly what he had discovered when analyzing the WannaCry samples in the Ziften Zenith console. He sent over those information, which I provide in this post.

The Red Lab has systems covering all the most popular typical os with different services and configurations. There were already systems in the lab that were deliberately vulnerable to the WannaCry exploit. Our worldwide threat intelligence feeds utilized in the Zenith platform are upgraded in real-time, and had no trouble detecting the virus in our lab environment (see Figure 1).


Two laboratory systems have been determined running the harmful WannaCry sample. While it is great to see our worldwide hazard intelligence feeds updated so quickly and determining the ransomware samples, there were other behaviors that we found that would have identified the ransomware hazard even if there had not been a risk signature.

Zenith agents gather a large quantity of information on what’s happening on each host. From this visibility data, we develop non-signature based detection methods to take a look at generally destructive or anomalous habits. In Figure 2 below, we show the behavioral detection of the WannaCry threat.


Investigating the Scope of WannaCry Infections

Once discovered either through signature or behavioral techniques, it is really easy to see which other systems have actually also been infected or are displaying comparable behaviors.


Detecting WannaCry with Ziften and Splunk

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

We have 2 Splunk apps for Zenith. The first is our technology add-on (TA): its function is to ingest and index ALL the raw information from the Zenith server that the Ziften agents produce. As this information comes in it is massaged into Splunk’s Common Information Model (CIM) so that it can be normalized and simply browsed in addition to used by other apps such as the Splunk App for Enterprise Security (Splunk ES). The Ziften TA likewise includes Adaptive Response capabilities for acting from actions that are rendered in Splunk ES. The 2nd app is a dashboard for displaying our information with all the charts and graphs readily available in Splunk to facilitate digesting the data a lot easier.

Given that I currently had the information on how the WannaCry exploit behaved in our research laboratory, I had the advantage of knowing exactly what to find in Splunk utilizing the Zenith data. In this case I was able to see a signature alert by utilizing the VirusTotal integration with our Splunk app (see Figure 4).


Danger Searching for WannaCry Ransomware in Ziften and Splunk

But I wanted to wear my “event responder hat” and examine this in Splunk using the Zenith agent information. My very first thought was to browse the systems in my laboratory for ones running SMB, because that was the preliminary vector for the WannaCry attack. The Zenith data is encapsulated in various message types, and I knew that I would most likely find SMB data in the running process message type, nevertheless, I utilized Splunk’s * regex with the Zenith sourcetype so I could search all Zenith data. The resulting search appeared like ‘sourcetype= ziften: zenith: * smb’. As I expected I got one result back for the system that was running SMB (see Figure 5).


My next action was to utilize the very same behavioral search we have in Zenith that searches for common CryptoWare and see if I might get outcomes back. Once again this was extremely simple to do from the Splunk search panel. I used the very same wildcard sourcetype as previously so I might browse throughout all Zenith data and this time I included the ‘delete shadows’ string search to see if this behavior was ever released at the command line. My search looked like ‘sourcetype= ziften: zenith: * delete shadows’. This search returned outcomes, displayed in Figure 6, that showed me in detail the procedure that was created and the full command line that was carried out.


Having all this info within Splunk made it really easy to identify which systems were vulnerable and which systems had already been jeopardized.

WannaCry Removal Using Splunk and Ziften

Among the next steps in any type of breach is to remediate the compromise as quick as possible to prevent further damage and to do something about it to prevent other systems from being compromised. Ziften is among 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 hazards through extensions on Zenith.


When it comes to WannaCry we truly might have utilized nearly any of the Adaptive Response actions currently offered by Zenith. When aiming to minimize the effect and prevent WannaCry in the first place, one action that can happen is to close down SMB on any systems running the Zenith agent where the version of SMB running is understood to be susceptible. With a single action Splunk can pass to Zenith the agent ID’s or the IP Address of all the susceptible systems where we wanted to stop the SMB service, hence avoiding the exploit from ever occurring and permitting the IT Operations team to get those systems patched prior to starting the SMB service once again.

Avoiding Ransomware from Spreading or Exfiltrating Data

Now in the event that we have actually currently been compromised, it is vital to prevent more exploitation and stop the possible exfiltration of sensitive details or company intellectual property. There are truly three actions we might take. The very first 2 are similar where we could kill the malicious procedure by either PID (process ID) or by its hash. This is effective, but considering that many times malware will simply spawn under a brand-new process, or be polymorphic and have a various hash, we can apply an action that is guaranteed to prevent any inbound or outbound traffic from those contaminated systems: network quarantine. This is another example of an Adaptive Response action available from Ziften’s integration with Splunk ES.

WannaCry is already decreasing, however ideally this technical blog shows the worth of the Ziften and Splunk integration in handling ransomware hazards against the end point.

Written By Charles Leaver Ziften CEO


Whatever you do don’t ignore cybersecurity criminals. Even the most paranoid “normal” person would not fret about a source of data breaches being taken qualifications from its heating, ventilation and a/c (A/C) specialist. Yet that’s what occurred at Target in November 2013. Hackers got into Target’s network using credentials given to the professional, most likely so they might track the heating, ventilation and a/c system. (For an excellent analysis, see Krebs on Security). And after that hackers had the ability to utilize the breach to spread malware into point of sale (POS) systems, then offload payment card information.

A number of ludicrous errors were made here. Why was the HEATING AND COOLING specialist given access to the business network? Why wasn’t the A/C system on a separate, completely separated network? Why wasn’t the POS system on a different network? And so on.

The point here is that in an extremely intricate network, there are uncounted potential vulnerabilities that could be exploited through negligence, unpatched software applications, default passwords, social engineering, spear phishing, or insider actions. You get the point.

Whose job is it to find and repair those vulnerabilities? The security team. The CISO’s office. Security experts aren’t “typical” individuals. They are paid to be paranoid. Make no mistake, no matter the particular technical vulnerability that was exploited, this was a CISO failure to expect the worst and prepare appropriately.

I cannot speak to the Target HEATING AND COOLING breach specifically, however there is one overwhelming reason breaches like this occur: A lack of budgetary top priority for cybersecurity. I’m not sure how typically businesses cannot fund security merely since they’re inexpensive and would rather do a share buy back. Or maybe the CISO is too shy to ask for what’s needed, or has actually been told that he gets a 5% increase, irrespective of the need. Perhaps the CEO is worried that disclosures of large allotments for security will spook investors. Perhaps the CEO is simply naïve enough to believe that the business will not be targeted by hackers. The problem: Every company is targeted by cyber criminals.

There are huge competitions over budget plans. The IT department wants to fund upgrades and enhancements, and attack the backlog of demand for brand-new and enhanced applications. On the flip side, you have line-of-business managers who see IT projects as directly assisting the bottom line. They are optimists, and have lots of CEO attention.

By contrast, the security department frequently has to defend crumbs. They are viewed as a cost center. Security decreases enterprise risk in such a way that matters to the CFO, the CRO (chief risk officer, if there is one), the basic counsel, and other pessimists who care about compliance and track records. These green-eyeshade people consider the worst case circumstances. That does not make friends, and spending plan dollars are allocated grudgingly at a lot of organizations (till the business gets burned).

Call it naivety, call it established hostility, however it’s a genuine obstacle. You cannot have IT offered great tools to move the enterprise forward, while security is starved and making do with second-best.

Worse, you don’t want to wind up in situations where the rightfully paranoid security groups are dealing with tools that don’t fit together well with their IT equivalent’s tools.

If IT and security tools do not mesh well, IT might not have the ability to quickly act to react to risky circumstances that the security groups are monitoring or are concerned about – things like reports from risk intelligence, discoveries of unpatched vulnerabilities, nasty zero-day exploits, or user behaviors that indicate risky or suspicious activity.

One idea: Discover tools for both departments that are developed with both IT and security in mind, right from the beginning, instead of IT tools that are patched to offer some very little security ability. One spending plan product (take it out of IT, they have more money), however two workflows, one developed for the IT expert, one for the CISO team. Everyone wins – and next time somebody wishes to give the HEATING AND COOLING contractor access to the network, possibly security will see exactly what IT is doing, and head that catastrophe off at the pass.