Charles Leaver – Ziften And Splunk Are All You Need To Detect And Respond To WannaCry

Written by Joel Ebrahami and presented by Charles Leaver


WannaCry has actually generated a lot of media attention. It might not have the huge infection rates that we have seen with a lot of the previous worms, however in today’s security world the amount of systems it was able to contaminate in a single day was still rather shocking. The objective of this blog is NOT to offer a detailed analysis of the exploit, but rather to look how the threat acts on a technical level with Ziften’s Zenith platform and the combination we have with our innovation partner Splunk.

Visibility of WannaCry in Ziften Zenith

My first action was to connect to Ziften Labs threat research study team to see what details they could supply to me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, directs our research group and notified me that they had samples of WannaCry presently running in our ‘Red Lab’ to look at the habits of the danger and perform further analysis. Josh sent me over the details of exactly what he had actually discovered when examining the WannaCry samples in the Ziften Zenith console. He delivered over those information, which I provide herein.

The Red Laboratory has systems covering all the most typical operating systems with different services and configurations. There were currently systems in the laboratory that were purposefully susceptible to the WannaCry threat. Our international threat intelligence feeds used in the Zenith platform are updated in real time, and had no trouble finding the virus in our lab environment (see Figure 1).

Two lab systems have actually been recognized running the malicious WannaCry sample. While it is great to see our worldwide hazard intelligence feeds upgraded so quickly and determining the ransomware samples, there were other behaviors that we found that would have determined the ransomware danger even if there had actually not been a hazard signature.

Zenith agents gather a large amount of information on what’s happening on each host. From this visibility data, we create non-signature based detection methods to take a look at typically malicious or anomalous habits. In Figure 2 shown below, we show the behavioral detection of the WannaCry infection.

Investigating the Breadth of WannaCry Infections

Once spotted either through signature or behavioral approaches, it is really easy to see which other systems have likewise been infected or are showing similar habits.

Detecting WannaCry with Ziften and Splunk

After examining this information, I decided to run the WannaCry sample in my own environment on a vulnerable 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 allowed me to take a look at the exact same data inside Splunk. Let me explain about the integration that exists with Splunk.

We have two Splunk apps for Zenith. The first is our technology add-on (TA): its function is to consume and index ALL the raw information from the Zenith server that the Ziften agents generate. As this information arrives it is massaged into Splunk’s Common Information Model (CIM) so that it can be stabilized and simply browsed in addition to used by other apps such as the Splunk App for Enterprise Security (Splunk ES). The Ziften TA also includes Adaptive Response abilities for acting from actions that are rendered in Splunk ES. The second app is a dashboard for displaying our info with all the charts and graphs offered in Splunk to facilitate absorbing the data a lot easier.

Given that I already had the details on how the WannaCry exploit acted in our research lab, I had the advantage of knowing exactly what to search for in Splunk utilizing 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).

Threat Hunting for WannaCry Ransomware in Ziften and Splunk

However I wished to put on my “event responder hat” and examine this in Splunk using the Zenith agent data. My first idea 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 different message types, and I knew that I would most likely discover SMB data in the running process message type, nevertheless, I utilized Splunk’s * regex with the Zenith sourcetype so I might search all Zenith data. The resulting search looked like ‘sourcetype= ziften: zenith: * smb’. As I anticipated I received one result back for the system that was running SMB (see Figure 5).

My next step was to use the very same behavioral search we have in Zenith that tries to find common CryptoWare and see if I could get results back. Once again this was extremely easy to do from the Splunk search panel. I used the very same wildcard sourcetype as previously so I might search 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 results, shown in Figure 6, that revealed me in detail the procedure that was developed and the complete command line that was performed.

Having all this information inside of Splunk made it extremely easy to determine which systems were susceptible and which systems had currently been jeopardized.

WannaCry Removal Using Splunk and Ziften

Among the next steps in any kind of breach is to remove the compromise as fast as possible to prevent additional damage and to act to prevent other systems from being compromised. Ziften is among 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 mitigate these risks through extensions on Zenith.

When it comes to WannaCry we actually could have utilized nearly any of the Adaptive Response actions presently readily available by Zenith. When aiming to minimize the effect and avoid WannaCry in the first place, one action that can occur is to close down SMB on any systems running the Zenith agent where the variation 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 susceptible systems where we wished to stop the SMB service, hence avoiding the exploit from ever taking place and enabling 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 case that we have actually already been compromised, it is crucial to prevent more exploitation and stop the possible exfiltration of sensitive information or business intellectual property. There are truly 3 actions we could take. The very first two are similar where we could kill the harmful process by either PID (process ID) or by its hash. This works, but given that often times malware will just spawn under a new procedure, or be polymorphic and have a different hash, we can apply an action that is ensured to prevent any incoming or outbound traffic from those infected 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 value of the Ziften and Splunk integration in dealing with ransomware threats against the endpoint.

Charles Leaver – Now Is The Time For Security Paranoia As HVAC Breach Shows

Written By Charles Leaver Ziften CEO


Whatever you do not ignore cyber security criminals. Even the most paranoid “regular” individual would not worry about a source of data breaches being stolen qualifications from its heating, ventilation and air conditioning (A/C) professional. Yet that’s what occurred at Target in November 2013. Hackers got into Target’s network utilizing qualifications provided to the contractor, probably so they could monitor the heating, ventilation and air conditioning system. (For a great analysis, see Krebs on Security). And after that hackers had the ability to leverage the breach to inject malware into point of sale (POS) systems, and then offload payment card details.

A number of ludicrous errors were made here. Why was the A/C contractor provided access to the business network? Why wasn’t the A/C system on a separate, entirely isolated network? Why wasn’t the POS system on a separate network? And so on.

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

Whose job is it to discover and fix those vulnerabilities? The security team. The CISO’s office. Security experts aren’t “typical” individuals. 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 accordingly.

I can’t talk to the Target HEATING AND COOLING breach particularly, however there is one overwhelming reason that breaches like this happen: A lack of financial priority for cybersecurity. I’m not exactly sure how frequently businesses fail to fund security merely since they’re cheap and would rather do a share buy-back. Or possibly the CISO is too timid to request what’s needed, or has been told that she gets a 5% boost, no matter the need. Perhaps the CEO is worried that disclosures of large allowances for security will alarm shareholders. Perhaps the CEO is simply naïve enough to believe that the enterprise won’t be targeted by hackers. The problem: Every organization is targeted by hackers.

There are big competitions over budget plans. The IT department wishes to fund upgrades and improvements, and attack the stockpile of demand for brand-new and enhanced applications. On the flip side, you have line-of-business leaders who see IT projects as directly helping the bottom line. They are optimists, and have lots of CEO attention.

By contrast, the security department too often needs to defend crumbs. They are seen as a cost center. Security lowers organization risk 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 people consider the worst case circumstances. That doesn’t make pals, and budget plan dollars are designated reluctantly at a lot of companies (until the company gets burned).

Call it naivety, call it established hostility, however it’s a genuine difficulty. You cannot have IT given excellent tools to drive the business forward, while security is starved and using second best.

Worse, you don’t wish to wind up in circumstances 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 fit together well, IT may not be able to quickly act to react to dangerous situations that the security teams are keeping an eye on or are concerned about – things like reports from risk intelligence, discoveries of unpatched vulnerabilities, nasty zero-day exploits, or user habits that indicate dangerous or suspicious activity.

One idea: Find tools for both departments that are created with both IT and security in mind, right from the beginning, rather than IT tools that are patched to offer some very little security capability. One spending plan item (take it out of IT, they have more money), however 2 workflows, one designed for the IT expert, one for the CISO group. Everybody wins – and next time someone wishes to offer the HEATING AND COOLING specialist access to the network, possibly security will observe what IT is doing, and head that disaster off at the pass.