Archive for June, 2017

Chuck Leaver – Detect And Respond To WannaCry With Ziften And Splunk

Written by Joel Ebrahami and presented by Chuck Leaver

WannaCry has actually produced a great deal of media attention. It may not have the huge infection rates that we have seen with many of the previous worms, however in the current security world the quantity of systems it was able to infect in one day was still somewhat 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 integration 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 group to see exactly what details they could provide to me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, heads up our research group and notified me that they had samples of WannaCry currently running in our ‘Red Laboratory’ to look at the behavior of the risk and carry out more analysis. Josh sent me over the information of what he had found when examining 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 operating systems with various services and setups. There were currently systems in the lab that were purposefully vulnerable to the WannaCry threat. Our international risk intelligence feeds utilized in the Zenith platform are upgraded in real-time, and had no trouble spotting the infection in our laboratory environment (see Figure 1).

2 lab systems have been recognized running the harmful WannaCry sample. While it is terrific to see our international risk intelligence feeds updated so rapidly and recognizing the ransomware samples, there were other behaviors that we detected that would have determined the ransomware danger even if there had not been a risk signature.

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

Investigating the Scope of WannaCry Infections

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

Detecting WannaCry 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 currently set up to integrate with Splunk. This permitted me to take a look at the exact same info inside Splunk. Let me explain about the integration we have with Splunk.

We have two 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 info populates it is massaged into Splunk’s Common Information Model (CIM) so that it can be normalized and simply searched along with utilized by other apps such as the Splunk App for Enterprise Security (Splunk ES). The Ziften TA also consists of Adaptive Response capabilities for acting from events that are rendered in Splunk ES. The 2nd app is a dashboard for displaying our information with all the charts and graphs available in Splunk to make absorbing the data much easier.

Because I currently had the details on how the WannaCry threat acted in our research laboratory, I had the advantage of understanding exactly what to find in Splunk using the Zenith data. In this case I had the ability to see a signature alert by using the VirusTotal integration with our Splunk app (see Figure 4).

Danger Hunting for WannaCry Ransomware in Ziften and Splunk

But I wanted to put on my “event responder hat” and investigate this in Splunk utilizing the Zenith agent information. My first thought 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 most likely find SMB data in the running process message type, however, I used Splunk’s * regex with the Zenith sourcetype so I might 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 looks for typical CryptoWare and see if I could get outcomes back. Once again this was extremely easy to do from the Splunk search panel. I utilized the same wildcard sourcetype as in the past so I could search throughout all Zenith data and this time I included the ‘delete shadows’ string search to see if this habit 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 revealed me in detail the procedure that was developed and the complete command line that was performed.

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

WannaCry Removal Utilizing Splunk and Ziften

One of the next steps in any type of breach is to remediate the compromise as fast as possible to prevent further destruction and to act to prevent any other systems from being jeopardized. Ziften is one of 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 reduce these threats through extensions on Zenith.

When it comes to WannaCry we really could have utilized nearly any of the Adaptive Response actions presently readily available by Zenith. When trying to lessen the effect and avoid WannaCry initially, one action that can take place is to shut 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 wanted to stop the SMB service, thus avoiding the exploit from ever happening and allowing the IT Operations group to get those systems patched prior to starting the SMB service again.

Preventing Ransomware from Spreading or Exfiltrating Data

Now in the event that we have already been jeopardized, it is crucial to prevent further exploitation and stop the possible exfiltration of sensitive information or company intellectual property. There are really three actions we could take. The very first 2 are similar where we might kill the harmful process by either PID (process ID) or by its hash. This is effective, however because oftentimes malware will just generate under a brand-new process, or be polymorphic and have a different hash, we can apply an action that is guaranteed to prevent any inbound or outgoing traffic from those contaminated systems: network quarantine. This is another example of an Adaptive Response action offered from Ziften’s integration with Splunk ES.

WannaCry is already diminishing, however ideally this technical blog reveals the worth of the Ziften and Splunk integration in dealing with ransomware hazards against the end point.

 

Chuck Leaver – It’s Time To Get Paranoid About Your Security

Written By Chuck Leaver Ziften CEO

Whatever you do don’t ignore cyber security hackers. Even the most paranoid “normal” person would not stress over a source of data breaches being stolen qualifications from its heating, ventilation and a/c (A/C) professional. Yet that’s exactly what occurred at Target in November 2013. Hackers got into Target’s network using qualifications given to the contractor, probably so they might track the heating, ventilation and a/c system. (For a great analysis, see Krebs on Security). And then hackers had the ability to utilize the breach to spread malware into point-of-sale (POS) systems, then unload payment card details.

A number of ludicrous mistakes were made here. Why was the HEATING AND COOLING contractor provided access to the enterprise network? Why wasn’t the A/C system on a separate, entirely isolated network? Why wasn’t the POS system on a different network? Et cetera, et cetera.

The point here is that in a very intricate network, there are uncounted potential vulnerabilities that could be exploited through carelessness, unpatched software applications, 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 experts aren’t “regular” 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 expect the worst and prepare appropriately.

I cannot speak with the Target A/C breach specifically, however there is one frustrating reason that breaches like this happen: A lack of financial concern for cybersecurity. I’m unsure how frequently businesses cannot fund security merely since they’re inexpensive and would rather do a share buy-back. Or possibly the CISO is too timid to request for exactly what’s required, or has been told that he gets a 5% boost, irrespective of the requirement. Perhaps the CEO is worried that disclosures of big allocations for security will startle investors. Perhaps the CEO is merely naïve enough to believe that the business won’t be targeted by hackers. The problem: Every business is targeted by cyber criminals.

There are substantial competitions over spending plans. The IT department wants to finance upgrades and enhancements, and attack the backlog of demand for new and better applications. On the flip side, you have line-of-business leaders who see IT tasks as directly helping the bottom line. They are optimists, and have great deals of CEO attention.

By contrast, the security department frequently needs to fight for crumbs. They are viewed as an expense center. Security reduces company danger 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 track records. These green-eyeshade individuals think about the worst case scenarios. That does not make good friends, and budget dollars are designated grudgingly at a lot of companies (up until the company gets burned).

Call it naivety, call it established hostility, but 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 wish to wind up in scenarios where the rightfully paranoid security teams are working with tools that do not fit together well with their IT counterpart’s tools.

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

One suggestion: Find tools for both departments that are designed with both IT and security in mind, right from the start, instead of IT tools that are patched to offer some minimal security capability. One spending plan item (take it out of IT, they have more money), but two workflows, one created for the IT professional, one for the CISO team. Everyone wins – and next time someone wants to give the HEATING AND COOLING specialist access to the network, maybe security will observe what IT is doing, and head that catastrophe off at the pass.