Written by Joel Ebrahami and presented by Chuck Leaver
WannaCry has created a great deal of media attention. It may not have the enormous infection rates that we have actually seen with a number of the older worms, but in the current security world the quantity of systems it was able to infect in a single day was still somewhat shocking. The objective of this blog post is NOT to offer a detailed analysis of the exploit, however rather to look how the threat behaves on a technical level with Ziften’s Zenith platform and the integration 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 team to see what info they could supply to me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, heads up our research study team and informed me that they had samples of WannaCry presently running in our ‘Red Lab’ to take a look at the habits of the threat and conduct additional analysis. Josh sent me over the information of exactly what he had actually found when analyzing the WannaCry samples in the Ziften Zenith console. He sent over those details, which I present here.
The Red Lab has systems covering all the most popular common operating systems with different services and configurations. There were already systems in the lab that were deliberately susceptible to the WannaCry exploit. Our international hazard intelligence feeds utilized in the Zenith platform are updated in real-time, and had no trouble identifying the infection in our lab environment (see Figure 1).
2 laboratory systems have actually been recognized running the harmful WannaCry sample. While it is fantastic to see our global danger intelligence feeds upgraded so quickly and recognizing the ransomware samples, there were other behaviors that we spotted that would have determined the ransomware danger even if there had actually not been a hazard signature.
Zenith agents gather a huge amount of information on what’s taking place on each host. From this visibility info, we create non-signature based detection techniques to look at normally malicious or anomalous behaviors. In Figure 2 shown below, we show the behavioral detection of the WannaCry infection.
Examining the Breadth of WannaCry Infections
When identified either through signature or behavioral methods, it is very simple to see which other systems have likewise been contaminated or are displaying similar behaviors.
WannaCry Detections with Ziften and Splunk
After reviewing this details, I chose to run the WannaCry sample in my own environment on a vulnerable system. I had one vulnerable system running the Zenith agent, and in this example my Zenith server was currently set up to integrate with Splunk. This allowed me to look at the same information inside Splunk. Let me make it clear about the integration we have 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 generate. As this information populates it is massaged into Splunk’s Common Info Model (CIM) so that it can be stabilized and simply searched as well as used by other apps such as the Splunk App for Enterprise Security (Splunk ES). The Ziften TA likewise includes Adaptive Response capabilities for acting from events that are rendered in Splunk ES. The 2nd app is a dashboard for displaying our info with all the graphs and charts available in Splunk to facilitate absorbing the data much easier.
Because I already had the details on how the WannaCry threat behaved in our research laboratory, I had the advantage of knowing exactly what to find in Splunk utilizing the Zenith data. In this case I had the ability 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
But I wished to put on my “event responder hat” and investigate this in Splunk utilizing the Zenith agent information. My very first thought was to browse the systems in my laboratory for ones running SMB, since that was the initial vector for the WannaCry attack. The Zenith data is encapsulated in different message types, and I knew that I would probably find SMB data in the running process message type, however, 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 received one result back for the system that was running SMB (see Figure 5).
My next step was to utilize the exact same behavioral search we have in Zenith that tries to find typical CryptoWare and see if I might get outcomes back. Once again this was extremely simple to do from the Splunk search panel. I used the same wildcard sourcetype as before so I might browse throughout all Zenith data and this time I included the ‘delete shadows’ string search to see if this habit was ever issued at the command line. My search appeared like ‘sourcetype= ziften: zenith: * delete shadows’. This search returned outcomes, shown in Figure 6, that revealed me in detail the process that was produced and the full command line that was executed.
Having all this detail inside of Splunk made it extremely simple to figure out which systems were susceptible and which systems had actually already been compromised.
WannaCry Removal Using Splunk and Ziften
One of the next steps in any type of breach is to remove the compromise as fast as possible to prevent further damage and to take action to prevent other systems from being compromised. Ziften is among the Splunk initial 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 risks through extensions on Zenith.
When it comes to WannaCry we really could have utilized almost any of the Adaptive Response actions currently offered by Zenith. When attempting to decrease the impact and prevent WannaCry in the first place, one action that can take place is to close down SMB on any systems running the Zenith agent where the variation 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 susceptible systems where we wished to stop the SMB service, hence preventing the exploit from ever happening and allowing the IT Operations group to get those systems patched before starting the SMB service again.
Preventing Ransomware from Spreading or Exfiltrating Data
Now in the event that we have actually already been compromised, it is important to prevent more exploitation and stop the possible exfiltration of sensitive info or company intellectual property. There are really three actions we could take. The very first two are similar where we might eliminate the malicious procedure by either PID (process ID) or by its hash. This works, however considering that oftentimes malware will simply spawn under a brand-new process, or be polymorphic and have a different hash, we can apply an action that is ensured to prevent any inbound or outbound traffic from those infected systems: network quarantine. This is another example of an Adaptive Response action readily available from Ziften’s integration with Splunk ES.
WannaCry is already decreasing, however ideally this technical blog post reveals the worth of the Ziften and Splunk integration in handling ransomware risks against the end point.