Detecting Ransomware: Behind the Scenes of an Attack

Ransomware has been the threat of the year. If you’ve had even a lazy eye on current events in information security, you’ve heard about the WannaCry infection that recently took out endpoints for hundreds of companies. By now you’ve (hopefully) patched all of your vulnerable Windows systems—but don’t relax just yet! There are still plenty of active ransomware campaigns, like SyncCrypt, GlobeImposter, and Locky, to name a few. It goes without saying that many organizations are concerned about detecting ransomware and how to prevent it.

Red Canary recently caught a ransomware campaign in the wild and quickly notified our customer before it spread across their network. This infection appeared similar to Matrix ransomware. Three key observations led us to pick up on the initial infection:

• Portable executable with an .hta file extension
• Lack of signature on the running executable
• File hash shown as malicious on multiple reputation websites.

We are frequently asked how we detect ransomware infections and what is provided to our customer. We’ll use snapshots from the actual threat detection to illustrate the attack timeline and show what happened in the moments following initial infection.

Detecting Ransomware: Threat Detection Timeline

It all started when an executable file named index[1].htm was downloaded using Internet Explorer. The victim downloaded this file during an otherwise normal browsing session. Within seconds, the initial download spawned a randomly named executable that modified almost three thousand files and made over six thousand network connections.

The initial event was identified by the Red Canary Detection Engine. The Red Canary analyst running the investigation immediately jumped to the Carbon Black Response platform to dig deeper. One running instance of the malicious binary immediately stood out as a prime suspect for useful forensic information.

By focusing on this malicious process, we saw every associated encryption of the victim’s files. This specific strain of ransomware encrypted all files in a directory, and then placed a text file in that folder with instructions for paying the ransom and regaining access to the files.

Immediately after encrypting the victim’s files, the ransomware ran cleanup operations. Using vssadmin to delete device backups, the malicious process made quick work of the victim’s only way to restore unencrypted data.

The use of vssadmin by ransomware campaigns is so widespread that some have even suggested disabling vssadmin altogether, and instead using wmic.exe to create device backup files. This technique could help in some cases, but WannaCry also uses wmic, wbadmin, and bcdedit to delete all connected backups and disable recovery mode. Clearly, offline backups will only be more important as ransomware capabilities continue to grow.

Once the victim’s backups were deleted, a text file was created with instructions for paying a bitcoin ransom and restoring the encrypted files.

This detection was sent to the customer immediately, and they were able to isolate and remediate the endpoint before the infection could spread. We haven’t seen any evidence of ransomware on their network since this event. Without endpoint visibility, this could have been a much bigger problem.

It’s a reminder of how important it is to have multiple layers of defense. Obviously you want to prevent as much as you can. But threats will still get through. When they do, it is critical that you have visibility across your environment, you have solutions in place to detect threats, and then have the resources to rapidly respond.

You Might Also Like:

• Webinar: Targeted Measures to Prevent and Mitigate Ransomware
• How to Prevent Ransomware: 5 Practical Techniques and Countermeasures
• The Ransomware Epidemic: an End-to-End Look at the #1 Cyber Threat