Written by Joel Ebrahami and presented by Charles Leaver
WannaCry has created a lot of media attention. It might not have the huge infection rates that we have actually seen with much of the older worms, but in the current security world the amount of systems it was able to infect in a single day was still rather incredible. The objective of this blog is NOT to supply an in-depth analysis of the threat, however rather to look how the exploit acts on a technical level with Ziften’s Zenith platform and the combination we have with our innovation partner Splunk.
WannaCry Visibility in Ziften Zenith
My first action was to reach out to Ziften Labs hazard research study team to see exactly what details they could provide to me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, heads up our research team and notified me that they had samples of WannaCry presently running in our ‘Red Laboratory’ to take a look at the habits of the danger and perform more analysis. Josh sent me over the information of what he had actually discovered when analyzing the WannaCry samples in the Ziften Zenith console. He sent over those information, which I provide herein.
The Red Laboratory has systems covering all the most popular common os with various services and setups. There were already systems in the laboratory that were deliberately susceptible to the WannaCry exploit. Our international danger intelligence feeds utilized in the Zenith platform are upgraded in real-time, and had no trouble spotting the virus in our lab environment (see Figure 1).
2 lab systems have been determined running the harmful WannaCry sample. While it is terrific to see our global hazard intelligence feeds upgraded so quickly and recognizing the ransomware samples, there were other behaviors that we identified that would have recognized the ransomware threat even if there had actually not been a danger signature.
Zenith agents gather a vast quantity of information on what’s occurring on each host. From this visibility information, we create non-signature based detection methods to take a look at generally harmful or anomalous behaviors. In Figure 2 below, we reveal the behavioral detection of the WannaCry infection.
Investigating the Breadth of WannaCry Infections
Once detected either through signature or behavioral methods, it is very simple to see which other systems have likewise been contaminated or are exhibiting comparable behaviors.
Detecting WannaCry with Ziften and Splunk
After reviewing this information, 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 example my Zenith server was currently set up to integrate with Splunk. This permitted me to take a look at the very same data inside Splunk. Let me make it clear about the integration we have 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 data from the Zenith server that the Ziften agents create. As this information comes in it is massaged into Splunk’s Common Info Model (CIM) so that it can be stabilized and easily browsed as well as utilized by other apps such as the Splunk App for Enterprise Security (Splunk ES). The Ziften TA also includes Adaptive Response capabilities for taking actions from events that are rendered in Splunk ES. The 2nd app is a control panel for showing our information with all the graphs and charts offered in Splunk to allow absorbing the data a lot easier.
Since I currently had the details on how the WannaCry exploit acted in our research laboratory, I had the advantage of knowing exactly what to find in Splunk using the Zenith data. In this case I was able to see a signature alert by utilizing the VirusTotal integration with our Splunk app (see Figure 4).
Risk Hunting for WannaCry Ransomware in Ziften and Splunk
But I wanted to wear my “incident responder hat” and investigate this in Splunk utilizing the Zenith agent information. My first idea was to search the systems in my lab for ones running SMB, since 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 procedure message type, however, I used Splunk’s * regex with the Zenith sourcetype so I could search all Zenith data. The resulting search looked 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 same behavioral search we have in Zenith that tries to find normal CryptoWare and see if I might get results back. Once again this was really simple to do from the Splunk search panel. I used the very same wildcard sourcetype as previously so I might browse 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 looked like ‘sourcetype= ziften: zenith: * delete shadows’. This search returned results, displayed in Figure 6, that revealed me in detail the process that was developed and the complete command line that was executed.
Having all this detail within Splunk made it extremely simple to identify which systems were susceptible and which systems had actually currently been jeopardized.
WannaCry Remediation Using Splunk and Ziften
Among the next steps in any type of breach is to remediate the compromise as fast as possible to prevent further destruction and to take action to prevent other systems from being jeopardized. Ziften is one of 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 dangers through extensions on Zenith.
In the case of WannaCry we actually might have utilized practically any of the Adaptive Response actions currently readily available by Zenith. When attempting to reduce the effect and avoid WannaCry in the first place, one action that can take place is to shut down SMB on any systems running the Zenith agent where the version of SMB running is understood to be susceptible. With a single action Splunk can pass to Zenith the agent ID’s or the IP Address of all the vulnerable systems where we wanted to stop the SMB service, thus avoiding the exploit from ever taking place and permitting the IT Operations team to get those systems patched prior to beginning the SMB service once again.
Preventing Ransomware from Spreading or Exfiltrating Data
Now in the case that we have already been jeopardized, it is critical to prevent more exploitation and stop the possible exfiltration of delicate information or company intellectual property. There are really three actions we might take. The very first 2 are similar where we might eliminate the malicious process by either PID (process ID) or by its hash. This works, but considering that often times malware will just spawn under a new process, or be polymorphic and have a different hash, we can use an action that is guaranteed to prevent any incoming or outgoing traffic from those contaminated 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 worth of the Ziften and Splunk integration in handling ransomware hazards against the endpoint.