This is the second in a series looking at part of the Revil malware. The first post covered a triage and unpacking of the first stage. The post will look at the high-level flow and look in-depth at the configuration embedded in the sample and some options. Revil Process Diagram Looking at the flow diagram (shown above), there is a pretty straightforward flow to the sample. It initially sets itself up by resolving the import table, reading the embedded configuration data, and command-line arguments.
This is the first in a series looking at part of the REvil malware. I will start off by showing a brief triage overview of the sample and then dive into the initial details of the stage 1 unpacker. Let us get into it! Initial Triage The Revil (aka Sodinokibi) malware is ransomware that encrypts files on a victim’s disk and leaves a note to head to a Tor link to send payment to decrypt your files.
Below are the slides my presentation at the Maine ISC(2) chapter meetup on June 10, 2020.
This post is a sequel to the post covering the sample “Bank Statement.bat.” I had received this message before the Bank Statement message, but I found the sample in the previous post was less obfuscated and easier to reverse engineer. In this post, I will cover the different ways that this sample hid the decoding routes and how I was able to gather the data to run the same decoding script I used before to extract the payload from the PNG data within this sample.
When looking through my Spam folder, I have run across a few messages with “.bat” files attached to them. Most messages have had different content in the message to entice a victim to open the attachment. I started to investigate each of the attachments and found they were Windows Binaries, and at least two had PNG files in the resources. After doing this initial triage, I wanted to see if the payload of these pieces of malware is encoded in this PNG data and how it was encoded.
Summary In this post, I will reverse and analyze a Ryuk malware sample. Ryuk is pretty well-known ransomware that encrypts the contents of a victim’s hard drive. The sample uses two executable stages, one that determines if the system is a 32bit or a 64bit system, then extracts out the appropriate second stage executable onto the file system and executes the second stage. The second stage then attempts to gain persistence through creating a registry key and then finally injects an encryption process into another process and starts to encrypt the file systems leaving behind a Ransom note for the user to find.