With Ziften And Splunk You Can Detect And Respond To WannCry – Chuck Leaver

Written by Joel Ebrahami and presented by Chuck Leaver


WannaCry has generated a lot of media attention. It might not have the enormous infection rates that we have actually seen with much of the previous worms, but in the current security world the quantity of systems it had the ability to infect in one day was still rather shocking. The goal of this blog is NOT to provide an in-depth analysis of the threat, however rather to look how the exploit behaves on a technical level with Ziften’s Zenith platform and the combination we have with our technology partner Splunk.

Visibility of WannaCry in Ziften Zenith

My very first action was to connect to Ziften Labs threat research team to see what details they might provide to me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, directs our research study group and informed me that they had samples of WannaCry currently running in our ‘Red Lab’ to take a look at the habits of the threat and perform additional analysis. Josh sent me over the details of what he had actually found when examining the WannaCry samples in the Ziften Zenith console. He sent over those details, which I present herein.

The Red Laboratory has systems covering all the most typical os with different services and configurations. There were currently systems in the laboratory that were purposefully vulnerable to the WannaCry exploit. Our international hazard intelligence feeds utilized in the Zenith platform are upgraded in real-time, and had no trouble spotting the infection in our lab environment (see Figure 1).

Two laboratory systems have been determined running the destructive WannaCry sample. While it is great to see our international danger intelligence feeds updated so rapidly and recognizing the ransomware samples, there were other habits that we found that would have identified the ransomware threat even if there had not been a danger signature.

Zenith agents collect a huge amount of data on what’s happening on each host. From this visibility info, we develop non-signature based detection techniques to take a look at generally harmful or anomalous habits. In Figure 2 shown below, we reveal the behavioral detection of the WannaCry threat.

Examining the Breadth of WannaCry Infections

When detected either through signature or behavioral approaches, it is very simple to see which other systems have actually likewise been infected or are displaying similar behaviors.

Detecting WannaCry with Ziften and Splunk

After evaluating this information, I chose 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 already configured to integrate with Splunk. This enabled me to look at the exact same information inside Splunk. Let me elucidate about the integration we have with Splunk.

We have 2 Splunk apps for Zenith. The very first is our technology add on (TA): its role is to consume and index ALL the raw data from the Zenith server that the Ziften agents generate. As this info arrives it is massaged into Splunk’s Common Info Model (CIM) so that it can be stabilized and easily 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 abilities for taking actions from events that are rendered in Splunk ES. The 2nd app is a control panel for displaying our data with all the charts and graphs readily available in Splunk to facilitate digesting the data a lot easier.

Considering that I currently had the information on how the WannaCry exploit behaved in our research lab, I had the advantage of knowing exactly what to search for in Splunk using the Zenith data. In this case I had the ability to see a signature alert by utilizing the VirusTotal integration with our Splunk app (see Figure 4).

Hazard Hunting for WannaCry Ransomware in Ziften and Splunk

But I wanted to wear my “incident responder hat” and examine this in Splunk utilizing the Zenith agent information. My very first thought was to search the systems in my lab for ones running SMB, because that was the initial 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, however, I used Splunk’s * regex with the Zenith sourcetype so I could browse all Zenith data. The resulting search appeared like ‘sourcetype= ziften: zenith: * smb’. As I expected I received 1 result back for the system that was running SMB (see Figure 5).

My next step was to use the exact same behavioral search we have in Zenith that looks for normal 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 same wildcard sourcetype as previously so I could browse throughout all Zenith data and this time I added 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, shown in Figure 6, that revealed me in detail the procedure that was developed and the full command line that was carried out.

Having all this info within Splunk made it very easy to determine which systems were susceptible and which systems had actually currently been jeopardized.

WannaCry Remediation Using Splunk and Ziften

Among the next steps in any kind of breach is to remediate the compromise as quick as possible to prevent more destruction and to take action to prevent any other systems from being compromised. Ziften is one of the Splunk initial Adaptive Response members and there are a variety of actions (see Figure 7) that can be taken through Spunk’s Adaptive Response to alleviate these threats through extensions on Zenith.

In the case of WannaCry we actually might have used nearly any of the Adaptive Response actions presently readily available by Zenith. When aiming to minimize the effect and avoid WannaCry initially, one action that can occur is to shut down SMB on any systems running the Zenith agent where the variation 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 vulnerable systems where we wished to stop the SMB service, hence preventing the threat from ever occurring and allowing the IT Operations group to get those systems patched before beginning the SMB service again.

Preventing Ransomware from Spreading or Exfiltrating Data

Now in the event that we have actually already been compromised, it is vital to prevent further exploitation and stop the possible exfiltration of sensitive info or company intellectual property. There are really 3 actions we might take. The first two are similar where we might eliminate the destructive process by either PID (process ID) or by its hash. This is effective, however since oftentimes malware will just spawn under a brand-new procedure, or be polymorphic and have a various hash, we can apply an action that is ensured to prevent any inbound or outgoing traffic from those infected systems: network quarantine. This is another example of an Adaptive Response action offered from Ziften’s integration with Splunk ES.

WannaCry is already lessening, however ideally this technical blog reveals the worth of the Ziften and Splunk integration in handling ransomware dangers against the end point.

Organizations Need To Increase Their Paranoia Over Security – Chuck Leaver

Written By Chuck Leaver Ziften CEO


Whatever you do don’t ignore cyber security criminals. Even the most paranoid “typical” person would not stress over a source of data breaches being stolen qualifications from its heating, ventilation and a/c (HEATING AND COOLING) specialist. Yet that’s exactly what took place at Target in November 2013. Hackers got into Target’s network utilizing credentials provided to the specialist, probably so they could track the heating, ventilation and air conditioning system. (For a good analysis, see Krebs on Security). And after that hackers were able to leverage the breach to inject malware into point of sale (POS) systems, and then offload payment card information.

A number of ridiculous errors were made here. Why was the HEATING AND COOLING specialist provided access to the enterprise network? Why wasn’t the HEATING AND COOLING system on a different, totally isolated network? Why wasn’t the POS system on a separate network? Et cetera, et cetera.

The point here is that in a very complex network, there are uncounted prospective vulnerabilities that could be exploited through recklessness, unpatched software, default passwords, social engineering, spear phishing, or insider actions. You get the point.

Whose task is it to discover and repair those vulnerabilities? The security team. The CISO’s team. Security specialists aren’t “normal” people. They are hired to be paranoid. Make no mistake, no matter the particular technical vulnerability that was made use of, this was a CISO failure to prepare for the worst and prepare appropriately.

I can’t talk to the Target HEATING AND COOLING breach specifically, but there is one frustrating reason that breaches like this happen: A lack of budgetary top priority for cybersecurity. I’m not sure how frequently companies fail to fund security just due to the fact that they’re inexpensive and would rather do a share buy-back. Or possibly the CISO is too shy to request for what’s required, or has actually been informed that he gets a 5% boost, irrespective of the requirement. Maybe the CEO is worried that disclosures of big allotments for security will startle investors. Maybe the CEO is merely naïve enough to think that the enterprise will not be targeted by cyber criminals. The problem: Every company is targeted by hackers.

There are big competitions over spending plans. The IT department wishes to fund upgrades and enhancements, and attack the stockpile of demand for brand-new and improved applications. On the other side, you have line-of-business leaders who see IT projects as directly assisting the bottom line. They are optimists, and have great deals of CEO attention.

By contrast, the security department frequently needs to defend crumbs. They are viewed as a cost center. Security reduces company risk in a way that matters to the CFO, the CRO (chief risk officer, if there is one), the general counsel, and other pessimists who appreciate compliance and reputation. These green-eyeshade people think of the worst case situations. That doesn’t make good friends, and budget dollars are assigned reluctantly at a lot of companies (up until the business gets burned).

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

Worse, you do not want to wind up in scenarios where the rightfully paranoid security groups are dealing with tools that do not fit together well with their IT counterpart’s tools.

If IT and security tools don’t mesh well, IT may not be able to rapidly act to react to risky situations that the security teams are keeping an eye on or are worried about – things like reports from risk intelligence, discoveries of unpatched vulnerabilities, nasty zero-day exploits, or user habits that suggest risky or suspicious activity.

One idea: Find tools for both departments that are developed with both IT and security in mind, right from the beginning, rather than IT tools that are patched to supply some very little security ability. One budget product (take it out of IT, they have more cash), however 2 workflows, one designed for the IT expert, one for the CISO group. Everyone wins – and next time somebody wants to offer the HVAC specialist access to the network, maybe security will discover what IT is doing, and head that disaster off at the pass.