YARA BlackCat Payload Example – YARA Post #2

In my first post in this series, Day 1 of the 12 Days of YARA, I shared some resources that can help you to get started with YARA. YARA is a rules based language that allows for pattern matching against a file (or a processes memory). This is a useful tool that can describe a malware sample in a way can match on both a specific sample and (if properly generalized) on similar samples. A generalized rule may continue to match on related samples even if they change slightly from version to version, this is in contrast to cryptographic hash based approaches (SHA1, SHA256, MD5) to detection where minor changes in the malware create an entirely different hash value.

YARA rules are quite simple in terms of structure. The rule typically consists of the strings that will match file contents, and boolean conditions that determine whether the rule is matched or not. There’s a good overview of how to write a YARA rule in the documentation that it is worth reading if you are unfamiliar with how the rules are structured.

When I learn something I like to learn by reading the documentation as well as examples published by others. This helps me get a better sense of the idiomatic use of a language. Luckily there are lots of examples published that you can use to see different approaches people have taken.

In this post I’ll reference one of the YARA rules provided by AT&T Alien Labs in their post about BlackCat ransomware earlier this year:

rule BlackCat : WindowsMalware {
   meta:
      author = "AlienLabs"
      description = "Detects BlackCat payloads."
      SHA256 = "6660d0e87a142ab1bde4521d9c6f5e148490b05a57c71122e28280b35452e896"
    strings:
        $rust = "/rust/" ascii wide
        $a0 = "vssadmin.exe Delete Shadows /all /quietshadow" ascii
        $a1 = "bcdedit /set {default}bcdedit /set {default} recoveryenabled No" ascii wide
        $a2 = "Services\\LanmanServer\\Parameters /v MaxMpxCt /d 65535" ascii wide
        $a3 = ".onion/?access-key=${ACCESS_KEY}" ascii wide
        $b0 = "config_id" ascii
        $b1 = "public_key" ascii
        $b2 = "extension" ascii
        $b3 = "note_file_name" ascii
        $b4 = "enable_esxi_vm_kill" ascii
        $b5 = "enable_esxi_vm_snapshot_kill" ascii
    condition:
        uint16(0) == 0x5A4D and filesize < 5MB and $rust and 2 of ($a*) and 3 of ($b*)

}

Taking a few moments to examine this a few things begin to pop out.

First the meta section provides information about the origin of the rule, in this case information about the authorship, description, and the hash of the Windows BlackCat payload. While the hash in the metadata is not used in the rule itself, it is useful to be able to look up more information about the file on other sources (like VirusTotal).

Second, in the strings section the author has grouped related sets of strings together with the same prefix ($a,$b), when we look in the condition section we can see that YARA allows the use of wildcards to identify these different sets of strings and apply different conditional logic to them.

Third, in the condition section we can see how the author uses both the strings defined earlier, as well as some other conditional statements:

  • uint16(0) == 0x5A4D. The uint16(0) reads the unsigned 16 bit integer at the start of the file (offset 0) and compares it with 0x5A4D which is the magic number indicating this is an executable file on Windows. YARA does include a PE module that allows for fine-grained inspection of attributes of a portable executable files, but looking for specific markers at a known offset (as in this case) may be more efficient from an execution perspective if the rule doesn’t need that level of granularity.
  • filesize < 5MB. Here the authors include a filesize limit, this will help optimise the processing of very large files (above the 5MB specified) so that the scan can concentrate on the right set of files.
  • $rust and 2 of ($a*) and 3 of ($b*). Here the author uses the strings defined earlier. These sets of strings relate to characteristics that are less likely to change over time. For example, commands to delete shadow copies are a common characteristics of ransomware, so detecting strings related to that operation are less likely to change than strings related to non-core aspects of the malware.

Stay tuned for Day 3 tomorrow!