Detection Of WannaCry And Response To It Through Ziften And Splunk – Charles Leaver

Written by Joel Ebrahami and presented by Charles Leaver


WannaCry has created a lot of media attention. It might not have the huge infection rates that we have actually seen with much of the older worms, but in the current security world the amount of systems it was able to infect in a single day was still rather incredible. The objective of this blog is NOT to supply an in-depth analysis of the threat, however rather to look how the exploit acts on a technical level with Ziften’s Zenith platform and the combination we have with our innovation partner Splunk.

WannaCry Visibility in Ziften Zenith

My first action was to reach out to Ziften Labs hazard research study team to see exactly what details they could provide to me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, heads up our research team and notified me that they had samples of WannaCry presently running in our ‘Red Laboratory’ to take a look at the habits of the danger and perform more analysis. Josh sent me over the information of what he had actually discovered when analyzing the WannaCry samples in the Ziften Zenith console. He sent over those information, which I provide herein.

The Red Laboratory has systems covering all the most popular common os with various services and setups. There were already systems in the laboratory that were deliberately susceptible to the WannaCry exploit. Our international danger intelligence feeds utilized in the Zenith platform are upgraded in real-time, and had no trouble spotting the virus in our lab environment (see Figure 1).


2 lab systems have been determined running the harmful WannaCry sample. While it is terrific to see our global hazard intelligence feeds upgraded so quickly and recognizing the ransomware samples, there were other behaviors that we identified that would have recognized the ransomware threat even if there had actually not been a danger signature.

Zenith agents gather a vast quantity of information on what’s occurring on each host. From this visibility information, we create non-signature based detection methods to take a look at generally harmful or anomalous behaviors. In Figure 2 below, we reveal the behavioral detection of the WannaCry infection.


Investigating the Breadth of WannaCry Infections

Once detected either through signature or behavioral methods, it is very simple to see which other systems have likewise been contaminated or are exhibiting comparable behaviors.


Detecting WannaCry with Ziften and Splunk

After reviewing this information, I decided to run the WannaCry sample in my own environment on a susceptible system. I had one susceptible system running the Zenith agent, and in this example my Zenith server was currently set up to integrate with Splunk. This permitted me to take a look at the very same data inside Splunk. Let me make it clear about the integration we 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 data from the Zenith server that the Ziften agents create. As this information comes in it is massaged into Splunk’s Common Info Model (CIM) so that it can be stabilized and easily browsed as well as utilized 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 2nd app is a control panel for showing our information with all the graphs and charts offered in Splunk to allow absorbing the data a lot easier.

Since I currently had the details on how the WannaCry exploit acted in our research laboratory, I had the advantage of knowing exactly what to find in Splunk using 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).


Risk Hunting for WannaCry Ransomware in Ziften and Splunk

But I wanted to wear my “incident responder hat” and investigate this in Splunk utilizing the Zenith agent information. My first idea 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 various message types, and I understood that I would most likely find SMB data in the running procedure 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 got one result back for the system that was running SMB (see Figure 5).


My next action was to utilize the same behavioral search we have in Zenith that tries to find normal CryptoWare and see if I might get results back. Once again this was really 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 results, displayed in Figure 6, that revealed me in detail the process that was developed and the complete command line that was executed.


Having all this detail within Splunk made it extremely simple to identify which systems were susceptible and which systems had actually currently been jeopardized.

WannaCry Remediation Using Splunk and Ziften

Among the next steps in any type of breach is to remediate the compromise as fast as possible to prevent further destruction and to take action to prevent other systems from being jeopardized. Ziften is one of the Splunk founding Adaptive Response members and there are a variety of actions (see Figure 7) that can be taken through Spunk’s Adaptive Response to reduce these dangers through extensions on Zenith.


In the case of WannaCry we actually might have utilized practically any of the Adaptive Response actions currently readily available by Zenith. When attempting to reduce the effect and avoid 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 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 wanted to stop the SMB service, thus avoiding the exploit from ever taking place and permitting the IT Operations team to get those systems patched prior to beginning the SMB service once again.

Preventing Ransomware from Spreading or Exfiltrating Data

Now in the case that we have already been jeopardized, it is critical to prevent more exploitation and stop the possible exfiltration of delicate information or company intellectual property. There are really three actions we might take. The very first 2 are similar where we might eliminate the malicious process by either PID (process ID) or by its hash. This works, but considering that often times malware will just spawn under a new process, or be polymorphic and have a different hash, we can use an action that is guaranteed to prevent any incoming or outgoing traffic from those contaminated systems: network quarantine. This is another example of an Adaptive Response action readily available from Ziften’s integration with Splunk ES.

WannaCry is currently reducing, however hopefully this technical blog post reveals the worth of the Ziften and Splunk integration in handling ransomware hazards against the endpoint.

Learn From This HVAC Breach And Become Security Paranoid – Charles Leaver

Written By Charles Leaver Ziften CEO


Whatever you do not ignore cybersecurity criminals. Even the most paranoid “regular” person wouldn’t fret about a source of data breaches being taken credentials from its heating, ventilation and a/c (HVAC) contractor. Yet that’s what happened at Target in November 2013. Hackers broke into Target’s network using qualifications given to the contractor, most likely so they could track the heating, ventilation and air conditioning system. (For a great analysis, see Krebs on Security). And after that hackers had the ability to take advantage of the breach to spread malware into point-of-sale (POS) systems, then offload payment card details.

A variety of ludicrous errors were made here. Why was the HVAC professional provided access to the enterprise network? Why wasn’t the HVAC system on a separate, totally isolated network? Why wasn’t the POS system on a separate network? And so on.

The point here is that in a really complicated network, there are uncounted potential vulnerabilities that could be made use of through negligence, unpatched software applications, default passwords, social engineering, spear phishing, or insider actions. You understand.

Whose job is it to find and fix those vulnerabilities? The security group. The CISO’s team. Security specialists aren’t “typical” people. They are paid to be paranoid. Make no mistake, no matter the particular technical vulnerability that was made use of, this was a CISO failure to anticipate the worst and prepare accordingly.

I cannot speak to the Target A/C breach specifically, however there is one frustrating reason why breaches like this happen: A lack of monetary priority for cyber security. I’m not exactly sure how often businesses fail to finance 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 what’s required, or has actually been told that she gets a 5% increase, no matter the requirement. Maybe the CEO is worried that disclosures of big allowances for security will startle investors. Maybe the CEO is merely 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 big competitions over spending plans. The IT department wants to finance upgrades and improvements, and attack the backlog of demand for new and improved applications. On the other side, you have operational managers who see IT jobs as directly assisting the bottom line. They are optimists, and have lots of CEO attention.

By contrast, the security department frequently has to fight for crumbs. They are viewed as an expense center. Security decreases company threat in a manner that matters to the CFO, the CRO (chief risk officer, if there is one), the general counsel, and other pessimists who care about compliance and track records. These green-eyeshade individuals consider the worst case situations. That doesn’t make friends, and budget dollars are designated reluctantly at a lot of companies (till the company gets burned).

Call it naivety, call it established hostility, but it’s a genuine challenge. You cannot have IT provided fantastic tools to drive the enterprise forward, while security is starved and using second best.

Worse, you don’t want to end up in situations where the rightfully paranoid security groups are working 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 be able to rapidly act to react to dangerous circumstances that the security teams are keeping an eye on or are worried about – things like reports from threat intelligence, discoveries of unpatched vulnerabilities, nasty zero-day exploits, or user habits that suggest risky or suspicious activity.

One idea: Discover tools for both departments that are developed with both IT and security in mind, right from the start, instead of IT tools that are patched to provide some minimal security capability. One budget plan item (take it out of IT, they have more money), but 2 workflows, one created for the IT professional, one for the CISO team. Everybody wins – and next time somebody wants to offer the HVAC specialist access to the network, maybe security will observe exactly what IT is doing, and head that disaster off at the pass.