This is the second in a series of blogs focusing on a method for identifying samples of Ryuk [1] ransomware using YARA signatures. Ryuk, according to the latest data from the FBI, is the most successful ransomware family with approximately $61.2 million in ransom payments known to have been paid in bitcoin [2]. This ransomware family first appeared in August of 2018, and is a revision or evolution of the Hermes ransomware family. Many of the samples from that timeframe still included some references to Hermes.
Starting from one sample which is identified as Ryuk from dynamic analysis, one specific set of instructions is identified in the code written by the adversary. The purpose of this code is to take the security identifier (SID) [3] for a process found in a Toolhelp snapshot and lookup the account name for that SID. The goal is to determine if the owner of a particular process is NT AUTHORITY by comparing the first three characters of the account name returned by the LookupAccountSidW function call [4]. The code that performs this sequential comparison is shown in Figure 1.
Figure 1: Sequential Comparison Looking for the Letters NTA
Building The Rule
This set of instructions provides a unique and concise set of bytes with which to build a YARA rule. First, let's examine this sequence of bytes:
FF 15 [4] 66 83 3B 4E 75 16 66 83 7B 02 54 75 0F 66 83 7B 06 41 75
The first jump marked in red above is a four byte jump that allows for the location of the LookupAccountSidW import to change as is expected with each sample. The next change needed is to add wildcards for destination registers which may change depending on a specific variant or build of the ransomware.
FF 15 [4] 66 83 ?? 4E 75 ?? 66 83 ?? ?? 54 75 ?? 66 83 ?? ?? 41 75
Armed with this set of bytes, jumps, and wildcards, a basic YARA signature is ready to be deployed to hunt for samples which contain this sequence of instructions. The results of this hunting process in the Titanium Platform is shown in Figure 2.
Figure 2: Results of First Iteration of YARA Rule
The samples which match this rule have first seen dates which stretch all the way back to August of 2018. This rule appears to be effective and does not have false positives. However, there are a multitude of samples which are detected by antivirus scanners as Ryuk or are marked by Titanium Platform’s threat identification also as such.
Process of Elimination
How does one go about finding samples to compare with the results of the hunt seen above? One way to answer this question is to start with the search feature in the Titanium Platform. Using wildcards along with a search keyword, a comprehensive list of files that are marked as Ryuk of different types can be found. The results of this search are seen in Figure 3.
Figure 3: Search Results for Files with Threat Name “Ryuk”
The wildcards shown here allow for 32 and 64 bit files in the results as well as for variation in the malware type name. In the case of Ryuk, this name is often “Trojan” or “Ransomware”.
Now that we have identified a superset of Ryuk samples, we apply the YARA rule from above to this set of files. The files that do not match this rule are the ones to examine more closely. The majority of the files that do not match fall within three general categories: other variants of Ryuk, packed samples, and steganographically hidden samples. Each of these presents a different problem to solve. Starting with the other potential variants, we look to see if the sequential comparisons from above are modified or absent.
A Slight Variation
A sequence of instructions with identical purpose is found in some of the samples identified from the process above. This slightly different sequence is shown in Figure 4.
Figure 4: Different Variant of Sequential Comparisons
This is quite interesting because the end result of comparing the first characters of the result of LookupAccountSidW is exactly the same, but the way that the data is moved around before the comparison is performed is different. This data juggling has the effect of changing the bytes for the instructions immediately before the three comparison instructions. This is the reason why the signature developed above does not match samples with this particular bit of juggling. However, this shows us what is needed for a different YARA rule to detect this variant.
FF 15 [5-21] 0F B7 [2] 83 ?? 4E 75 [2-21] 0F B7 [2] 83 ?? 54 75 [2-21] 0F B7 [2] 83 ?? 41 75
This rule does have some bytes that are unique to this variant in addition to the large jumps shown above in red. As expected, when deploying this new rule in the retrohunting feature of the Titanium Platform, a whole different set of Ryuk samples is found. The results of this hunt are shown in Figure 5.
Figure 5: Results of Second Retrohunt
Boiling Down to One Rule
Having two different rules that match variants of a malware family can be excellent for identification and classification purposes. On the other hand, a different style of rule that condenses both of these down to just the bare essentials provides a more general identification signature. Comparing the two rules side-by-side can show what parts can be changed into jumps and wildcards and which parts must remain.
FF 15 [4] 66 83 ?? 4E 75 ?? 66 83 ?? ?? 54 75 ?? 66 83 ?? ?? 41 75
FF 15 [5-21] 0F B7 [2] 83 ?? 4E 75 [2-21] 0F B7 [2] 83 ?? 54 75 [2-21] 0F B7 [2] 83 ?? 41 75
By keeping the bytes marked in red above which appear in both rules, and replacing the rest of the bytes with appropriate length jumps and wild cards a single rule is formed.
FF 15 [5-26] 83 ?? 4E 75 [2-26] 83 [1-2] 54 75 [2-26] 83 [1-2] 41 75
The full YARA rules for the two variants as well as the generalized rule is provided at the end of this blog and the resulting byte sequence for the generalized rule is shown above. By returning to the A1000 and hunting for files that match this new, generalized rule, a much larger set of Ryuk samples are found. The results of this new hunt are shown in Figure 6.
Figure 6: Hunting Results with Generalized YARA Rule
Cutting Through to the Answer
With the process above repeating, all the variants of that specific code feature can be identified. However, what can be done about the set of samples that don’t appear to match any of these rules, but are still identified as Ryuk, specifically the ones with the sample hidden using steganography? Steganography, by the way, is “the practice of concealing a file, message, image, or video within another file, message, image, or video.” [5] This is distinct from encryption in that the hidden data is simply interwoven in some way with the main image or file in a way where the file is still usable or viewable.
This type of subterfuge can be difficult to spot, but the A1000 slices right through the steganography allowing the hidden file to be extracted and automatically analyzed. After a sample has been uploaded, any files hidden by steganography are marked as such in the list of extracted files. An example of this is shown in Figure 7.
Figure 7: Drilling Down to Files Extracted from Steganography
The YARA rules crafted above are used to scan the file extracted from this process automatically. With the steganography out of the way, we see that this new file has matched the second variant of the sequential comparisons YARA rule. This information can be found under the Classification section of the TitaniumCore results. The matching YARA rules are shown in Figure 8.
Figure 8: YARA Classification
As can be seen above, this hidden Ryuk sample matches with the second variant of the YARA rule developed above.
Conclusion
As we have demonstrated above, the Titanium Platform can be used to refine a large set of files iteratively to classify variants of a malware family based on code features in the samples. This process can be repeated through multiple iterations to develop a complete set of rules for a single feature. An output of this process is a generalized rule which can then be used to hunt for newly found files as they are uploaded and scanned by the Titanium Platform in an ongoing hunting process. Left in place, results from this set of rules will allow an analyst to identify a newly collected file down to a specific variant quickly even when presented with the irritation of steganography.
YARA Rules
private rule WindowsPE
{
condition:
uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550
}
rule Ryuk_SequentialComparisons
{
meta:
author = "Malware Utkonos"
date = "2020-02-29"
description = "Sequential comparison of SID lookup result characters."
strings:
$op1 = { FF 15 [5-26] 83 ?? 4E 75 [2-26] 83 [1-2] 54 75 [2-26] 83 [1-2] 41 75 }
condition:
WindowsPE and all of them
}
rule Ryuk_SequentialComparisons_A
{
meta:
author = "Malware Utkonos"
date = "2020-01-29"
description = "Sequential comparison of SID lookup result characters, variant A."
strings:
$op1 = { FF 15 [4] 66 83 ?? 4E 75 ?? 66 83 ?? ?? 54 75 ?? 66 83 ?? ?? 41 75 }
condition:
WindowsPE and all of them
}
rule Ryuk_SequentialComparisons_B
{
meta:
author = "Malware Utkonos"
date = "2020-02-29"
description = "Sequential comparison of SID lookup result characters, variant B."
strings:
$op1 = { FF 15 [5-21] 0F B7 [2] 83 ?? 4E 75 [2-21] 0F B7 [2] 83 ?? 54 75 [2-21] 0F B7 [2] 83 ?? 41 75 }
condition:
WindowsPE and all of them
}
- Read our previous Ryuk blog:
Hunting for Ransomware: Getting Ahead of Ryuk attacks using YARA rules
[1] https://malpedia.caad.fkie.fraunhofer.de/details/win.ryuk
[2] https://www.bleepingcomputer.com/news/security/fbi-says-140-million-paid-to-ransomware-offers-defense-tips/
[3] https://docs.microsoft.com/en-us/windows/win32/secauthz/security-identifiers
[4] https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-lookupaccountsidw
