How Stampado Ransomware Analysis Led To Yara Improvements

Some time ago, I was asked by a colleague to develop a set of Yara rules to detect samples of the Stampado ransomware family. (Yara is an open-source tool used by security researchers to spot and categorize malware samples according to a set of defined rules.)

Stampado is a relatively new Ransomware-as-a-Service (RaaS) threat that’s been on our radar recently. I had access to only a few samples at the time, and first tried looking for common strings among them but had no luck. I then went to compare the files structures and realized all of them had an interesting section at the end of the file, like the one starting at offset 0xde000 as follows:

Figure 1. Hexadecimal dump from a Stampado sample

There was an e-mail address at the end of the file, appended to the original file. I asked my colleague if he knew anything about this; he immediately told me that Stampado provides instructions to people who bought the kit, which mentions this:

Figure 2. Instructions for Stampado buyers

I concluded that Stampado developers added a 0x0d byte (Carriage Return on the ASCII table) to the end of each sample and told their buyers to add their e-mail address after the CR byte using a regular text editor (which will show the CR byte as a new line). This usage of CR seems a bit wrong, since the DOS/Windows format for a newline is 0x0d 0x0a (CR and a Line Feed, or LF), while Unix-based OSes uses an LF character only. In any event, the presence of a CR byte at the end of file of each Stampado sample is an interesting characteristic – which can be used in a Yara rule to detect them.

I wanted to make a rule who could catch samples both with and without the e-mail address filled. This meant I couldn’t just write a “last byte of the file is 0x0d” rule because if the buyer adds his email address, the 0x0d byte will be several bytes before the last byte, with the difference depending on the string size of his e-mail address,

When bytes are added after the end of a PE file, what is called an overlay section is created. This section is not listed in the PE sections, so an easy way to check if a PE file has an overlay or not is to find the end of the last section described by the PE section headers and check if there is data after it. If so, something was added to the PE file and we can say it has an overlay.

Using the current Yara version, I achieved this with the following rule:

private rule has_overlay {
     condition:
          filesize > pe.sections[pe.number_of_sections - 1].raw_data_offset + pe.sections[pe.number_of_sections - 1].raw_data_size
}

There’s one problem with this rule, however: if the last section described in section headers is not the last physical section on file, we can’t trust it. I started discussing this issue on Yara’s Github page and users there were kind enough to give me suggestions that allowed me to come up with a pull request for the Yara’s PE module that adds the ability of processing overlays. Soon, rules like the following will be valid and stable Yara rules:

import "pe"

private rule has_overlay {
     condition:
          pe.overlay.offset}

rule big_overlay {
     condition:
          pe.overlay.size > 1024}

rule overlay_bytes {
     strings:
          $bytes = { 90 41 42 50 56 }
     condition:
          bytes at pe.overlay.offset
}

Once version 3.6.0 of Yara is released I’ll be able to replace the last condition of the following rule by something like “uint8(pe.overlay.offset) == 0x0d” and rely on it. I am happy to have Yara as an open source project so small contributions like this are possible. We also help the tool to become better and better overtime and to adapt itself to face new challenges.

rule stampado_overlay
{
meta:
description = "Catches Stampado samples looking for \\r at the beginning of PE overlay section"
reference = ""
author = "Fernando Merces, FTR, Trend Micro"
date = "2016-07"
md5 = "a393b9536a1caa34914636d3da7378b5"
md5 = "dbf3707a9cd090853a11dda9cfa78ff0"
md5 = "dd5686ca7ec28815c3cf3ed3dbebdff2"
md5 = "6337f0938e4a9c0ef44ab99deb0ef466"

condition:
pe.characteristics == 0x122 and
pe.number_of_sections == 5 and
pe.imports("VERSION.dll", "VerQueryValueW") and uint8(pe.sections[4].raw_data_offset + pe.sections[4].raw_data_size) == 0x0d

}

Trend Micro products based on our own internal technology already detect the Stampado samples I analyzed as RANSOM_STAMP.SM. In addition, our decryptor tool also supports this ransomware and may be able to decrypt affected files.

Open-source tools are commonly used by security researchers all over the world. We are happy that we have been able to give back to the community at large; we hope that we will be able to provide give back more frequently moving forward.

Thanks to Stephen Hilt (who sent me these Stampado samples to work on) and Wesley Shields, who helped me with the patch for Yara.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

How Stampado Ransomware Analysis Led To Yara Improvements

Read more: How Stampado Ransomware Analysis Led To Yara Improvements