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.