(See part one of TAU’s Hakbit Ransomware analysis here.)

Many blue team defenders out there will attest to the fact that ransomware is on the rise, and that ransomware doesn’t appear to be going away any time soon. Ransomware is only one of the numerous types of commodity-based emerging threats which the TAU (Threat Analysis Unit) team actively monitors and responds to. Due to the fast-paced nature of commodity based threats such as ransomware, there is a natural priority and sense of urgency to react quickly to new ransomware families, campaigns, and variants in order to provide prevention and detection capabilities. During a recent investigation into Hakbit ransomware, TAU decided to hit the “pause” button and take some time out to investigate this particular ransomware variant. The research methodology and findings are discussed within this report.

Initial Triage

Starting with a recent Hakbit ransomware variant, the first phase was to perform a combination of static and dynamic analysis of the binary for the purpose of triage. The sample analyzed (SHA256 d187292551fce9f4751a8fab00b9f33088c7a38b7454825e35390b524ba969bd) is covered in greater detail in this blog post writeup. A full list of Indicators of Compromise (IOCs) and Tactics, Techniques and Procedures (TTPs) can be found at the end of this report. 

Pivoting off of the import hash in VirusTotal returned over half a million samples. Using the import hash can often be useful when tracking threat actors and groups behind different malware families and campaigns. In this instance, the import hash is too broad and will retrieve far too many false positive samples for analysis. Upon closer inspection of our original binary, there were a couple of noteworthy artifacts. The first observation was that the binary was using the SmartAssembly .NET obfuscator by RedGate (specifically version 7.0.7.2439). Taken from the RedGate web site: 

“SmartAssembly is an obfuscator that helps protect your application against reverse-engineering or modification, by making it difficult for a third-party to access your source code”. 

In other words, although file obfuscation is often used for legitimate purposes such as to protect source code and intellectual property, malware authors also use such obfuscators in an attempt to hide their malicious source code. Obfuscation can ultimately make malware analysis more challenging as well as time consuming. This can be problematic when responding to malware outbreaks that have a high severity, impact, and infection rate. 

The second interesting artifact from the Hakbit sample found was the following code snippet shown, which is explained below.

Figure 1: Hakbit code snippet

Walking through this code shows a network call attempted to a legitimate service icanhazip[.]com in order to retrieve the infected client’s IP address. This, along with the date of encryption, the unique client identifier key, and either the number of files encrypted or possible affected files are posted to a free, legitimate hosting service at a FTP address hosted on 000webhost[.]com. This would appear to be an attempt to notify the ransomware operator(s) of infected systems, so that they can keep track of their victims. It is worth noting that ransomware that leaks data publicly is also on the rise, and this may be another intention of this code snippet. Incidentally and per our observations, despite detonating this sample multiple times, no such call out was made to either of the two addresses. Upon further code review, it was found that the above function expected a string variable to be of a particular value. As the string value was globally set, and no other function used this variable, this entire function was bypassed. It is worth noting that performing full static analysis will often be the only way to confirm the full or partial functionality of malware.  

As the import hash mentioned earlier was too broad, the next step was to construct a simple YARA rule to search for similar samples, thereby returning a more realistic sized set of samples that were associated with these two artifacts. The YARA rule is shown below. 

Figure 2: YARA rule

The results yielded 25 samples from VirusTotal which required further analysis. As part of the processing of these additional samples, each sample was briefly statically and dynamically analyzed in order to produce the resulting output data to work with. The dynamic analysis processing consisted of using our purpose built MalwareLambda platform, as well as some 3rd party static analysis tools such as de4dot and monodis. These tools were used primarily to deobfuscate the SmartAssembly obfuscated binaries, as well as to disassemble and extract interesting artifacts such as strings, functions, classes and base64 encoded strings from the .NET/C# assemblies. The high level data pipeline is shown below. 

Figure 3: Research pipeline

The resulting 25 samples can be cross referenced by their compile date and the number of submitters, which is shown in the below diagram. 

Figure 4: Samples submitted to VirusTotal by compile date

Results

The first observation made was the spread of ransomware samples across primarily three different versions of SmartAssembly. 

Figure 5: Smart Assembly versions

The three different versions of SmartAssembly shown are interesting because they may help to understand if either an individual, group of actors or certain campaigns are using a particular obfuscator version or type.

Our next step is to understand and review the encrypted file extension types found in the 25 samples so far. Although we might have expected all 25 samples to use the same Hakbit file extension “.crypted” for encrypting files on disk, the data shows us that this is not actually the case. In fact there are 5 additional file extensions found in our pool of samples.  

Figure 6: Samples by encrypted file extension

Another interesting feature of reviewing the ransom note messages is that we can get an idea as to the different families, campaigns or variants, and their associated ransom demands. As shown in the following diagram, Hakbit ransomware typically includes ransom demands for between 0.3 and 3 Bitcoins. Interestingly although only one sample of Hentai Onichan ransomware was analyzed, it demands a payment of 30 BTC or approximately $267,000 at the time of writing this report. This could infer that this ransomware may be used as part of a targeted attack due to the way in which the demand is so much higher than other ransomwares in our sample set. The data shown in the diagram is drawn using a logarithmic scale to highlight the differences in ransom amounts. 

Figure 7: Ransom Demand (BTC) by Ransomware

Further studying of the BitCoin wallet addresses indicate two things. Firstly, there are some wallet addresses that are used across the same ransomware family. For example, five out of the 25 samples feature the same wallet address for Hakbit ransomware. Secondly, this shows us wallet addresses featured in other ransomware families. One wallet address in particular is featured across four different ransomware families. This can also be cross-referenced by the file extension types shown above. 

Figure 8: Ransomware by BTC wallet address

Without needing to do a deep and thorough dive, and using the data that we have collected, it is already clear that we are looking at non-Hakbit ransomware families which appear to be related to our initial Hakbit sample. Pivoting off of the contact email addresses contained within the ransom note messages, and performing some high-level OSINT, shines a further light on four additional ransomware families. Shown below is a graph visualization of the ransomware family names (represented by the red nodes), the contact email address found from within the ransom notes (represented by the green nodes), and the edges (represented by the lines) which highlight the connectedness and relationships of each.

Figure 9: Related ransomware families by contact email address

Taking things a step further, and using the country submitter information, we can also work out the relationships between the email contact addresses featured in the ransom note messages. We can then look to see whether or not there are any trends in terms of whether a specific actor or group is targeting specific countries. Although the sample set is small, we can make some high level inferences about the graph visualization below. One example might be the email contact address used for Ravack ransomware. Ravack was featured in two samples submitted from Malaysia to VirusTotal, which may suggest that the contact address featured may be for a particular campaign or particular threat actor that is specifically targeting a country or region. This doesn’t directly suggest that Ravack is only targeting Malaysia, however further collection and processing of Ravack ransomware samples at scale may help to confirm or deny that theory, particularly with more targeted attacks.  

Figure 10: Relationship between country submitter and ransom email contact

Other artifacts that can also be included are the non-generic PE file icon resource types. Shown below are the icon resources. These can potentially be used to further pivot and uncover related variants and campaigns. 

Figure 11: Non-generic icon resources for related Hakbit samples

One other trend that can be used to track variants of a ransomware family or campaign, or even a group of ransomware families that are related, as in the case of Hakbit, are the AV detection rates. From this data one might infer whether certain features that were introduced by the ransomware authors are more successful at evading traditional AV over their development and release cycle. 

Figure 12: AV detections by submitted date

Another method might be to look at the network calls and DNS lookups made during sample detonation, which can be used to build a picture as to any malicious IP’s or domain names in use. While actors may not typically reuse or share the same domain names or IP addresses in general, further analysis of the network artifacts could show whether or not certain calls are made to any interesting domains or IP addresses, which leads us on to our next section. 

Modules/Add-ons Identification

Modules and add-ons are typical of Ransomware as a Service (RaaS) and standalone ransomware. Featuring modular functionality at a cost, ultimately gives the cyber criminal a competitive edge over other competing ransomwares while being able to generate more money by enticing their customer base with new features in their code. With the gradual rise of RaaS and with the increased sophistication and aggressive release cycle by the ransomware authors and cyber criminals, reviewing samples for similarity may expose certain levels of code reuse which may tie in to features or services paid for by affiliates or customers of ransomware. Another method would be to statically analyze the code, and look for new features, modules or add-ons which may suggest a different feature set is available, or if a certain actor is using a fully featured RaaS. In the case of Hakbit, the SharpExec tool was discovered. Taken from the SharpExec page hosted on Github: 

“SharpExec is an offensive security C# tool designed to aid with lateral movement”

Only by iterating through the research methodology were we able to uncover one sample which attempted to download the ProcessHide tool. Taken from their page also hosted on Github:

“Hide any process from any monitoring tool that uses NtQuerySystemInformation”

The graph below shows the number of samples out of the 25 samples analyzed which contained either SharpExec or ProcessHide. 

Figure 13: SharpExec and ProcessHide usage

These types of tools can be further correlated with submitter country, email contact address and so on. Other types of features may include evasion techniques that bypass operating system protections, fully undetectable (FUD) to evade AV, IP tracking and so on. 

Conclusion

From a single sample, and using some of the extracted metadata contained in this sample, we were able to pivot across some of those data points in order to uncover a total of 10 related ransomware families. This was discovered through the combination of static and dynamic analysis. This example can be helpful in expanding our understanding behind not only the code reuse amongst cyber criminals, but also the relationships between other ransomware families, campaigns and variants. 

Collecting and tracking metadata specific to ransomware aid in mapping out a clearer picture of related different actors, campaigns, and variants from a single sample. Such information includes obfuscator details, email contact addresses, wallet addresses, and other generic executable file metadata indicators like file hash types and mutexes. Using these techniques along with other TTPs, such as those featured in the MITRE ATT&CK Framework, can aid with detection, prevention, hunting, incident response, forensic investigations, and help build out your cyber threat intelligence knowledge and expertise.   

Indicators of Compromise