Monthly Archives: June 2017

Detected WannaCry And Respnded To It Swiftly Through Ziften / Splunk Integration – Charles Leaver

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 much of the previous worms, but in today’s security world the quantity of systems it had the ability to infect in one day was still somewhat shocking. The goal of this blog post is NOT to provide a comprehensive analysis of the threat, however rather to look how the exploit acts 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 risk research team to see exactly what details they might provide to me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, heads up our research study group and informed me that they had samples of WannaCry presently running in our ‘Red Laboratory’ to look at the behavior of the danger and conduct more analysis. Josh sent me over the information of exactly what he had actually discovered when examining the WannaCry samples in the Ziften Zenith console. He delivered over those information, which I present in this post.

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

2 laboratory systems have actually been recognized running the harmful WannaCry sample. While it is terrific to see our global threat intelligence feeds updated so rapidly and determining the ransomware samples, there were other behaviors that we discovered that would have identified the ransomware danger even if there had not been a risk signature.

Zenith agents gather a large quantity of data on what’s happening on each host. From this visibility information, we create non-signature based detection techniques to take a look at usually harmful or anomalous behaviors. In Figure 2 shown below, we show the behavioral detection of the WannaCry threat.

Examining the Scope of WannaCry Infections

As soon as it has been spotted either through signature or behavioral methods, it is very simple to see which other systems have likewise been infected or are displaying similar habits.

WannaCry Detections with Ziften and Splunk

After evaluating this info, 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 already set up to integrate with Splunk. This permitted me to look at the exact same info inside Splunk. Let me elucidate about the integration that exists 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 info from the Zenith server that the Ziften agents generate. As this data comes in it is massaged into Splunk’s Common Info Model (CIM) so that it can be normalized and simply browsed as well as utilized by other apps such as the Splunk App for Enterprise Security (Splunk ES). The Ziften TA likewise includes Adaptive Response capabilities for taking actions from actions that are rendered in Splunk ES. The 2nd app is a control panel for displaying our info with all the graphs and charts available in Splunk to make digesting the data a lot easier.

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

Danger Hunting for WannaCry Ransomware in Ziften and Splunk

However I wished to wear my “event responder hat” and examine this in Splunk using the Zenith agent info. My first idea was to browse the systems in my laboratory 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 understood that I would probably find SMB data in the running process message type, nevertheless, I used 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 use the exact same behavioral search we have in Zenith that searches for typical CryptoWare and see if I could get results back. Once again this was very simple to do from the Splunk search panel. I used the exact same wildcard sourcetype as previously so I might search across all Zenith data and this time I added the ‘delete shadows’ string search to see if this habit was ever provided at the command line. My search appeared like ‘sourcetype= ziften: zenith: * delete shadows’. This search returned results, displayed in Figure 6, that revealed me in detail the procedure that was produced and the complete command line that was executed.

Having all this detail within Splunk made it extremely easy to determine which systems were vulnerable and which systems had currently been jeopardized.

WannaCry Removal Utilizing Splunk and Ziften

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

In the case of WannaCry we really could have utilized nearly any of the Adaptive Response actions currently readily available by Zenith. When attempting to lessen the impact and avoid WannaCry initially, one action that can occur is to close down SMB on any systems running the Zenith agent where the version of SMB running is understood to be 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 wished to stop the SMB service, thus preventing the threat from ever happening and allowing the IT Operations team to get those systems patched prior to beginning the SMB service again.

Preventing Ransomware from Spreading or Exfiltrating Data

Now in the event that we have actually already been jeopardized, it is vital to prevent further exploitation and stop the possible exfiltration of sensitive information or business intellectual property. There are actually 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 considering that often times malware will just generate under a new procedure, or be polymorphic and have a various hash, we can use an action that is ensured to prevent any incoming or outgoing 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 lessening, but ideally this technical blog shows the value of the Ziften and Splunk integration in dealing with ransomware hazards against the end point.

Major Breach Caused By Info Leak. You Must Get Security Paranoid – Charles Leaver

Written By Charles Leaver Ziften CEO


Whatever you do don’t ignore cyber security hackers. Even the most paranoid “typical” individual wouldn’t worry about a source of data breaches being taken credentials from its heating, ventilation and air conditioning (A/C) specialist. Yet that’s what took place at Target in November 2013. Hackers got into Target’s network using qualifications provided to the professional, most likely so they might monitor the heating, ventilation and air conditioning system. (For a great analysis, see Krebs on Security). And after that hackers were able to utilize the breach to inject malware into point-of-sale (POS) systems, and after that offload payment card details.

A number of ludicrous mistakes were made here. Why was the HVAC specialist given access to the business network? Why wasn’t the HVAC system on a different, entirely isolated network? Why wasn’t the POS system on a different network? And so on.

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

Whose task is it to discover and fix those vulnerabilities? The security team. The CISO’s team. Security professionals aren’t “typical” individuals. 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 prepare for the worst and prepare accordingly.

I can’t speak to the Target HVAC breach specifically, however there is one overwhelming reason why breaches like this happen: A lack of budgetary concern for cybersecurity. I’m not sure how typically companies cannot fund security simply since they’re inexpensive and would rather do a share buy-back. Or possibly the CISO is too timid to ask for what’s required, or has actually been told that she gets a 5% boost, irrespective of the need. Possibly the CEO is worried that disclosures of big allocations for security will alarm investors. Possibly the CEO is simply naïve enough to believe that the business will not be targeted by hackers. Bad news: Every business is targeted by cyber criminals.

There are huge competitions over budget plans. The IT department wants to fund upgrades and improvements, and attack the backlog of demand for brand-new and better applications. On the other side, you have line-of-business managers who see IT jobs 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 viewed as an expense center. Security reduces organization threat in such 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 individuals think of the worst case scenarios. That doesn’t make good friends, and budget plan dollars are assigned grudgingly at a lot of companies (up until the company gets burned).

Call it naivety, call it established hostility, however it’s a real challenge. You can’t have IT provided great tools to move the business forward, while security is starved and making do with second best.

Worse, you don’t want to end up in scenarios where the rightfully paranoid security teams are working with tools that do not mesh well with their IT counterpart’s tools.

If IT and security tools do not fit together well, IT may not have the ability to quickly act to react to dangerous scenarios that the security groups are keeping track of or are concerned about – things like reports from danger intelligence, discoveries of unpatched vulnerabilities, nasty zero-day exploits, or user behaviors that indicate dangerous or suspicious activity.

One idea: Discover tools for both departments that are designed with both IT and security in mind, right from the beginning, rather than IT tools that are patched to provide some very little security ability. One budget plan item (take it out of IT, they have more cash), however 2 workflows, one created for the IT professional, one for the CISO group. Everybody wins – and next time somebody wants to give the A/C contractor access to the network, maybe security will observe exactly what IT is doing, and head that disaster off at the pass.