Monthly Archives: June 2017

Charles Leaver – WannaCry Detection And Response With Ziften And Splunk

Published by:

Written by Joel Ebrahami and presented by Charles Leaver

 

WannaCry has created a great deal of media attention. It may not have the massive infection rates that we have seen with a lot of the previous worms, however in the current security world the amount of systems it had the ability to infect in a single day was still rather incredible. The objective of this blog post is NOT to provide a detailed analysis of the threat, however rather to look how the threat behaves 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 very first action was to reach out to Ziften Labs threat research study group to see exactly what info they might provide to me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, directs our research group and informed me that they had samples of WannaCry currently running in our ‘Red Lab’ to take a look at the behavior of the risk and carry out further analysis. Josh sent me over the details of exactly what he had found when examining the WannaCry samples in the Ziften Zenith console. He sent over those details, which I provide here.

The Red Laboratory has systems covering all the most popular typical os with various services and configurations. There were already systems in the laboratory that were purposefully susceptible to the WannaCry exploit. Our worldwide threat intelligence feeds used in the Zenith platform are upgraded 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 destructive WannaCry sample. While it is excellent to see our global risk intelligence feeds upgraded so quickly and identifying the ransomware samples, there were other habits that we found that would have recognized the ransomware threat even if there had actually not been a danger signature.

Zenith agents collect a huge quantity of data on what’s taking place on each host. From this visibility information, we produce non-signature based detection strategies to take a look at typically malicious or anomalous behaviors. In Figure 2 shown below, we reveal the behavioral detection of the WannaCry ransomware.

Investigating 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 infected or are showing similar behaviors.

WannaCry Detections with Ziften and Splunk

After examining this details, 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 case my Zenith server was already configured to integrate with Splunk. This allowed me to look at the same data inside Splunk. Let me make it clear about the integration that exists with Splunk.

We have two Splunk apps for Zenith. The first is our technology add on (TA): its role is to consume and index ALL the raw information from the Zenith server that the Ziften agents create. As this info populates it is massaged into Splunk’s Common Info Model (CIM) so that it can be stabilized and easily searched as well as utilized by other apps such as the Splunk App for Enterprise Security (Splunk ES). The Ziften TA likewise consists of Adaptive Response capabilities for taking actions from actions that are rendered in Splunk ES. The second app is a dashboard for showing our information with all the charts and graphs available in Splunk to allow digesting the data much easier.

Given that I currently had the details on how the WannaCry exploit 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 was able to see a signature alert by using the VirusTotal integration with our Splunk app (see Figure 4).

Risk Hunting for WannaCry Ransomware in Ziften and Splunk

But I wished to wear my “event responder hat” and investigate this in Splunk using the Zenith agent data. My first thought was to search 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 knew 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 could search all Zenith data. The resulting search appeared like ‘sourcetype= ziften: zenith: * smb’. As I anticipated I received 1 result back for the system that was running SMB (see Figure 5).

My next step was to use the same behavioral search we have in Zenith that tries to find normal 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 very same wildcard sourcetype as previously so I might search 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 appeared like ‘sourcetype= ziften: zenith: * delete shadows’. This search returned outcomes, displayed in Figure 6, that revealed me in detail the process that was produced and the full command line that was performed.

Having all this detail inside of Splunk made it very easy to determine which systems were vulnerable and which systems had actually already been compromised.

WannaCry Removal Utilizing Splunk and Ziften

Among the next steps in any type of breach is to remediate the compromise as quick as possible to prevent further damage and to act to prevent other systems from being jeopardized. Ziften is one of 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 really could have used practically any of the Adaptive Response actions currently readily available by Zenith. When aiming to minimize the impact 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 wanted to stop the SMB service, therefore preventing the threat from ever taking place and enabling the IT Operations team to get those systems patched prior to beginning the SMB service once again.

Avoiding Ransomware from Spreading or Exfiltrating Data

Now in the case that we have already been jeopardized, it is vital to prevent additional exploitation and stop the possible exfiltration of delicate info or company intellectual property. There are really 3 actions we could take. The very first 2 are comparable where we could kill the malicious procedure by either PID (process ID) or by its hash. This works, however given that many times malware will just generate under a brand-new process, or be polymorphic and have a various hash, we can use an action that is guaranteed to prevent any incoming or outbound 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, but hopefully this technical blog post shows the value of the Ziften and Splunk integration in handling ransomware dangers against the end point.

Charles Leaver – A Breach Out Of Nowhere Get Paranoid About Your Company Security

Published by:

Written By Charles Leaver Ziften CEO

 

Whatever you do don’t undervalue cybersecurity hackers. Even the most paranoid “regular” person wouldn’t worry about a source of data breaches being taken qualifications from its heating, ventilation and a/c (A/C) specialist. Yet that’s exactly what took place at Target in November 2013. Hackers got into Target’s network utilizing credentials offered 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 then hackers had the ability to leverage the breach to spread malware into point of sale (POS) systems, then unload payment card details.

A number of ludicrous errors were made here. Why was the A/C contractor given access to the business network? Why wasn’t the HVAC system on a different, completely separated network? Why wasn’t the POS system on a different network? And so on.

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

Whose job is it to discover and fix those vulnerabilities? The security group. The CISO’s office. Security specialists aren’t “normal” people. They are paid to be paranoid. Make no mistake, no matter the particular technical vulnerability that was exploited, this was a CISO failure to prepare for the worst and prepare accordingly.

I cannot talk to the Target HEATING AND COOLING breach particularly, but there is one frustrating reason that breaches like this occur: An absence of financial priority for cybersecurity. I’m not sure how frequently businesses fail to fund security merely since they’re inexpensive and would rather do a share buy-back. Or maybe the CISO is too timid to request for what’s needed, or has been told that he gets a 5% increase, no matter the requirement. Possibly the CEO is worried that disclosures of big allowances for security will scare shareholders. Maybe the CEO is merely naïve enough to believe that the business won’t be targeted by hackers. The problem: Every enterprise is targeted by hackers.

There are substantial competitions over budget plans. The IT department wishes to finance upgrades and improvements, and attack the stockpile of demand for 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 great deals of CEO attention.

By contrast, the security department frequently needs to fight for crumbs. They are viewed as a cost center. Security reduces business danger in a manner 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 people think of the worst case situations. That does not make friends, and budget plan dollars are allocated grudgingly at too many companies (till the company gets burned).

Call it naivety, call it entrenched hostility, but it’s a real difficulty. You cannot have IT given fantastic tools to move the enterprise forward, while security is starved and using second-best.

Worse, you do not wish to end up in situations 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 don’t fit together well, IT may not be able to quickly act to respond to risky situations that the security groups are keeping track of or are worried about – things like reports from hazard intelligence, discoveries of unpatched vulnerabilities, nasty zero-day exploits, or user habits that indicate dangerous or suspicious activity.

One recommendation: 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 ability. One budget plan item (take it out of IT, they have more money), however two workflows, one created for the IT professional, one for the CISO group. Everybody wins – and next time somebody wants to provide the A/C professional access to the network, maybe security will notice what IT is doing, and head that disaster off at the pass.