Monthly Archives: June 2017

Charles Leaver – Using Ziften And Splunk Easily Detect WannaCry And Respond

Written by Joel Ebrahami and presented by Charles Leaver

 

WannaCry has generated a great deal of media attention. It may not have the huge infection rates that we have actually seen with a lot of the previous worms, but in the current security world the amount of systems it had the ability to contaminate in one day was still rather staggering. The objective of this blog post is NOT to provide an in-depth analysis of the threat, but rather to look how the threat behaves on a technical level with Ziften’s Zenith platform and the combination we have with our technology partner Splunk.

WannaCry Visibility in Ziften Zenith

My very first action was to connect to Ziften Labs risk research study group to see exactly what info they could provide to me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, heads up our research study group and notified me that they had samples of WannaCry presently running in our ‘Red Lab’ to look at the behavior of the danger and perform more analysis. Josh sent me over the information of exactly what he had found when analyzing the WannaCry samples in the Ziften Zenith console. He delivered over those details, which I provide here.

The Red Lab has systems covering all the most common operating systems with various services and setups. There were already systems in the lab that were intentionally vulnerable to the WannaCry threat. Our worldwide threat intelligence feeds used in the Zenith platform are updated in real time, and had no trouble discovering the virus in our lab environment (see Figure 1).

Two lab systems have been recognized running the destructive WannaCry sample. While it is great to see our international risk intelligence feeds upgraded so quickly and identifying the ransomware samples, there were other behaviors that we discovered that would have determined the ransomware risk even if there had actually not been a threat signature.

Zenith agents collect a huge quantity of information on what’s occurring on each host. From this visibility data, we create non signature based detection methods to look at generally malicious or anomalous habits. In Figure 2 shown below, we show the behavioral detection of the WannaCry ransomware.

Examining the Scope of WannaCry Infections

As soon as it has been identified either through signature or behavioral approaches, it is very simple to see which other systems have actually also been contaminated or are exhibiting comparable behaviors.

WannaCry Detections with Ziften and Splunk

After examining this details, 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 currently configured to integrate with Splunk. This permitted me to look at the exact same data inside Splunk. Let me make it clear about the integration we have with Splunk.

We have two Splunk apps for Zenith. The very first is our technology add-on (TA): its function is to consume and index ALL the raw data from the Zenith server that the Ziften agents produce. As this information arrives it is massaged into Splunk’s Common Information Model (CIM) so that it can be normalized and simply searched in addition to utilized by other apps such as the Splunk App for Enterprise Security (Splunk ES). The Ziften TA also consists of Adaptive Response abilities for acting from actions that are rendered in Splunk ES. The second app is a dashboard for showing our info with all the graphs and charts readily available in Splunk to allow digesting the data a lot easier.

Given that I currently had the information on how the WannaCry threat acted in our research lab, I had the advantage of knowing what to look for in Splunk utilizing 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).

Hazard Searching for WannaCry Ransomware in Ziften and Splunk

But I wanted to put on my “event responder hat” and investigate this in Splunk using the Zenith agent information. My very first thought was to browse the systems in my laboratory for ones running SMB, since that was the preliminary vector for the WannaCry attack. The Zenith data is encapsulated in different message types, and I understood that I would most likely find SMB data in the running process message type, nevertheless, I used Splunk’s * regex with the Zenith sourcetype so I might browse 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 searches for common CryptoWare and see if I might get outcomes back. Once again this was really easy to do from the Splunk search panel. I used the same wildcard sourcetype as in the past so I might search throughout 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 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 info inside of Splunk made it really easy to figure out which systems were vulnerable and which systems had actually already been jeopardized.

WannaCry Remediation Using Splunk and Ziften

Among the next steps in any type of breach is to remove the compromise as quick as possible to prevent additional destruction and to act to prevent other systems from being jeopardized. Ziften is among 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 mitigate these dangers through extensions on Zenith.

In the case of WannaCry we actually could have used practically any of the Adaptive Response actions presently offered by Zenith. When aiming to reduce the effect and avoid WannaCry initially, one action that can happen 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 wished to stop the SMB service, therefore preventing the exploit from ever happening and allowing the IT Operations team to get those systems patched prior to beginning the SMB service once again.

Avoiding Ransomware from Spreading out or Exfiltrating Data

Now in the case that we have currently been compromised, it is crucial to prevent additional exploitation and stop the possible exfiltration of delicate information or company intellectual property. There are really three actions we might take. The first two are comparable where we might kill the harmful process by either PID (process ID) or by its hash. This is effective, however given that many times malware will just generate under a brand-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 offered from Ziften’s integration with Splunk ES.

WannaCry is already decreasing, however hopefully this technical blog shows the value of the Ziften and Splunk integration in dealing with ransomware threats against the endpoint.

Charles Leaver – Are You Paranoid About Enterprise Security? This Will Make You.

Written By Charles Leaver Ziften CEO

 

Whatever you do don’t undervalue cyber security criminals. Even the most paranoid “normal” individual would not stress over a source of data breaches being taken qualifications from its heating, ventilation and a/c (HVAC) professional. Yet that’s what occurred at Target in November 2013. Hackers got into Target’s network utilizing qualifications offered to the professional, presumably so they could monitor the heating, ventilation and air conditioning system. (For a good 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 then unload payment card information.

A variety of ridiculous mistakes were made here. Why was the HEATING AND COOLING specialist provided access to the business network? Why wasn’t the HVAC system on a separate, completely separated network? Why wasn’t the POS system on a different network? And so on.

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

Whose job is it to find and repair those vulnerabilities? The security group. The CISO’s office. Security experts aren’t “regular” people. They are hired to be paranoid. Make no mistake, no matter the particular technical vulnerability that was exploited, this was a CISO failure to anticipate the worst and prepare accordingly.

I cannot speak with the Target A/C breach specifically, however there is one overwhelming reason breaches like this occur: A lack of budgetary concern for cyber security. I’m unsure how often companies fail to finance security just since they’re inexpensive and would rather do a share buy-back. Or maybe the CISO is too timid to request for exactly what’s needed, or has been told that she gets a 5% boost, irrespective of the requirement. Maybe the CEO is worried that disclosures of big allocations for security will alarm investors. Maybe the CEO is simply naïve enough to think that the enterprise will not be targeted by hackers. The problem: Every organization is targeted by cyber criminals.

There are substantial competitions over budget plans. The IT department wants to finance upgrades and improvements, and attack the backlog of demand for brand-new and enhanced applications. On the other side, you have operational leaders who see IT jobs as directly assisting the bottom line. They are optimists, and have lots of CEO attention.

By contrast, the security department too often has to defend crumbs. They are seen as a cost center. Security lowers organization danger in a way that matters to the CFO, the CRO (chief risk officer, if there is one), the basic counsel, and other pessimists who care about compliance and track records. These green-eyeshade individuals think of the worst case circumstances. That does not make buddies, and budget plan dollars are allocated reluctantly at too many companies (till the company gets burned).

Call it naivety, call it established hostility, however it’s a genuine difficulty. You can’t have IT given terrific 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 situations where the rightfully paranoid security teams are working with tools that don’t mesh well with their IT counterpart’s tools.

If IT and security tools don’t mesh well, IT might not have the ability to rapidly act to react to risky scenarios that the security groups 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 dangerous or suspicious activity.

One tip: Discover 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 provide some minimal security ability. One budget plan product (take it out of IT, they have more finances), however two workflows, one developed for the IT professional, one for the CISO team. Everybody wins – and next time someone wants to give the A/C contractor access to the network, perhaps security will discover what IT is doing, and head that catastrophe off at the pass.