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.