SBN

Retread Ransomware

Retread Ransomware

In March of 2020, MalwareHunterTeam discovered a downloader which installed both a KPot infostealer as well as a second payload which was a ransomware variant that used the string “CoronaVirus”. This sample was leveraging ongoing current events and appears to be some form of cover for or distraction from the infostealer trojan that was installed alongside it. Via code analysis of this “CoronaVirus” sample, it is clear that it reuses a large amount of code from a four year old sample of ransomware detected as “Satana”.

This older malware sample was first seen on June 29, 2016. This old sample and the recent one share two decoding algorithms that are used to hide strings, code, and a little, tiny PE file. This embedded file is run via a modification to the BootExecute registry key. The new file has some changes to the strings that are encoded along with the encoded data hiding the ransom note and the Bitcoin wallet addresses used to collect payment.

These are new addresses with a number of payments made during the same time that the new file was observed in the wild. The ransom amount demanded is quite small: $50. All in all, this is a strange executable. What follows is an examination of the two decoding algorithms and a method for discovering the old samples based on YARA rules that focus on these algorithms.

String Decoding

Many malware families obfuscate the strings that are used during their execution as a way to foil static analysis and detections based on the decoded forms of the strings. In the samples examined here, the string encoding is very simple. It is a substitution cipher which shifts one character then subtracts the position index of the character in the encoded string to reveal the decoded character. This algorithm is highlighted in Figure 1.

Figure 1: String Decoding Algorithm

Figure 1: String Decoding Algorithm

By focusing on the algorithm itself, which can be more stable than surrounding code when reused, one may locate other malware samples that could be related to the sample being analyzed. Figure 2 shows the same algorithm, but in a debugger where the first encoded string that is operated on in the sample can be seen in the dump at the bottom.

Figure 2: First Encoded String in Sample

Figure 2: First Encoded String in Sample

This same algorithm can be easily translated into Python and the strings from the sample decoded without executing the sample. A small Python program for decoding these strings is shown in Figure 3. The first string in the sample, which decodes to “CoronaVirus”, is shown here.

Figure 3: Python Implementation of String Decoder Algorithm

Figure 3: Python Implementation of String Decoder Algorithm

Taking only the bytes of the instructions that comprise this algorithm, a byte string for a YARA rule is identified.

$op1 = { 8A 14 06 2A D1 FE CA 88 14 07 }

By then deploying this YARA rule as a retrohunt in the Titanium Platform, a number of additional samples are found. The results of this retrohunt are shown in Figure 4.

Figure 4: Retrohunt Results

Figure 4: Retrohunt Results

Old Satana Sample

In the results of the retrohunt there are a number of samples from 2016. The sample with the earliest ‘first seen’ date is shown in Figure 5.

Figure 5: Earliest Related Satana Sample from 2016

Figure 5: Earliest Related Satana Sample from 2016

This file is well detected as Satana via the TitaniumCore YARA classification as well as being classified as ransomware by the TitaniumCore Machine Learning classification. Both of these classifications are seen in Figure 6.

Figure 6: Detection and Classification

Figure 6: Detection and Classification

In addition to this first sample, there are nine other samples that have been identified as related to the first based on the ReversingLabs Hash Algorithm (RHA). These other samples are seen in Figure 7.

Figure 7: Cluster of Ten Files Related via RHA

Figure 7: Cluster of Ten Files Related via RHA

The earliest files in the cluster, each of which are also first seen in 2016, are very minor changes to the earliest file. These may be researchers testing or other types of analysis artifacts. One such minor change is highlighted in Figure 8 which shows a side-by-side comparison of the two files using HexFiend.

Figure 8: Side-by-side Comparison of Satana Samples

Figure 8: Side-by-side Comparison of Satana Samples

More recently observed files from this same cluster are clearly analysis artifacts from researchers or analysis tools. Many of them simply have the encoded strings decoded in the sample and no other changes. Knowing that all the files in the cluster are essentially the same file, only the earliest sample (ee937717efe9a2e076b9497498b628beb0c84a8476bd288105a59c5aeea01f3d) is used for comparison with the CoronaVirus sample.

Data Decoding

Another common method used to encode data to avoid detection and identification is the “exclusive or” operation or XOR. The sample analyzed here uses this operation to hide large blobs of data. It specifically encodes the ransom note as well as a very small PE file which is used to display a variation of the ransom note on reboot. The location where this XOR operation is carried out is shown in Figure 9.

Figure 9: XOR Decoding Process

Figure 9: XOR Decoding Process

This is a loop which uses the first byte of the data as the key and then operates using that key on the rest of the bytes in the data. The encoded data before this operation has started is shown in Figure 10. The XOR key is the very first byte, 0x58.

Figure 10: First Byte of Encoded Data is XOR Key

Figure 10: First Byte of Encoded Data is XOR Key

After this decoding process is complete, the embedded PE file begins to appear. This data is still compressed, but the file magic “MZ” and the DOS stub string are clear. The decoded version of the data shown above is seen in Figure 11.

Figure 11: Decoded Data with PE File Starting to Appear

Figure 11: Decoded Data with PE File Starting to Appear

The next step after decoding the data is to decompress it. The instructions that perform this action utilize the library function “RtlDecompressBuffer”. The function name is loaded dynamically by decoding a string using the string decoding capability examined earlier. As puzzling as it sounds, something like a comic book supervillain telling you their next step before doing something evil, the meaning of these instructions is stated clearly by the additional string, “DeCompressor”, which is not encoded or hidden in any way. These instructions as seen in the debugger are shown in Figure 12.

Figure 12: Disassembled Decompression Instructions

Figure 12: Disassembled Decompression Instructions

Aside from the tiny PE file and the ransom note template, the decoded list of Bitcoin wallet addresses is provided. One of these addresses is selected to be used with the ransom note template to generate the note that is dropped by the ransomware. These decoded and decompressed Bitcoin wallet addresses are shown in Figure 13.

Figure 13: Decoded and Decompressed Bitcoin Wallet Addresses

Figure 13: Decoded and Decompressed Bitcoin Wallet Addresses

These addresses are listed in Table 1. The list of wallet addresses in the sample have two duplicates, so the total set of addresses has 22 members each of which is of type Bech32 SegregatedWitness address format.

bc1qc9axh3fq2ypgcd92j582v9khfrn52strql7ztn
bc1qzww0kjteu52w50m3d2ucp72zh5dwchph9vqj6k
bc1q5e8pwyk9rqtq400agngmq5h23cuz42x0wlqw3q
bc1qrkp9cx6svxguxupx9p0z5ss4nmyr4fwhvgkasg
bc1qjl0ufmwct84ww69zwyxe99gext7za6qkyhx200
bc1q6ryyex33jxgr946u3jyre66uey07e2xy3v2cah
bc1qlmu9xk8wdnydnlcvy9uvcepzklcv7kxyhk8ymy
bc1qftwqsaw57v6cstwrdvclmkz63plvf5q3vqvw4k
bc1qegps92ddvgv8t45lfcn02afsjlyf7mynuqvpmm
bc1quwc6yqgdcgm6z2663vpjm9cgtfwf7mhk2n7gtn
bc1q9dd5nkqrxsny93r9u09jwq8agvkf04afxh67jg
bc1qt6ypzfv25hwv70zs8nvrdhjl962jzyymkl7y9d
bc1qgd3nj0486k35ra42a550ntyafdr7s5lmyzjn29
bc1q8r42fm7kwg68dts3w70qah79n5emt5m76rus5u
bc1q3v6far85gtdsrk4zu4fuhphheyqprwmuv62n92
bc1qpvguajy4rxr7743hzuwfmz32krzzfcjl9rf0qx
bc1qe9gj2sj3an73dq37vpe34xflc83yjp4u3pzfgz
bc1qpaksevt2w6cqdeqjvm8dapvz66y3hs3jjy4x66
bc1qt3uf3wx569z5z9wdeanuj4rwq7m06grhxt96v3
bc1qzv6h2zaedjgduc6xmyn86hdsu0skuunt9lhkxn
bc1q2x9h8wlh2cuxjd9rv94v6syz7lpxxk2wwrndmv
bc1qxsjfw0jftfr9n5urdyh7xmz4cspls8qefuyetr


Table 1: Bitcoin Wallet Addresses

The ransom note template has four locations where string replacement is used to generate the final note text that is dropped to the ransom note file. These locations in the template are highlighted in Figure 14.

Figure 14: Ransom Note Template

Figure 14: Ransom Note Template

The email address, coronaVi2022[@]protonmail[.]ch, along with the amount demanded in Bitcoin (BTC), 0.008, are both hard coded. The unique ID is generated by concatenating the drive serial number collected from PhysicalDrive0 and the HwProfileGuid and then generating an MD5 from this string. The Bitcoin wallet address is chosen from the list decoded and decompressed as documented above. These four values just before the call to sprintf can be seen in Figure 15.

Figure 15: String Replacement into Ransom Note Template

Figure 15: String Replacement into Ransom Note Template

The payment demand of 0.008 BTC, interestingly, does not line up with any of the seven payments made to the set of wallet addresses from the binary. Each is a single payment. Some of the payments are larger than the demand and some are smaller than the demand. It is unknown whether these payments are in fact connected with the ransomware.

Old Satana Sample Differences

The majority of the instructions that handle the generation of randomness and moving that random data around in memory are all identical between the Satana and the Coronavirus samples. Library and compiler added code along with these identical functions are shown in Figure 16 as analyzed using Relyze’s binary difference feature.

Figure 16: Binary Difference Showing Identical Functions

Figure 16: Binary Difference Showing Identical Functions

There are a number of functions that have some amount of change according to binary difference, however, most of these instruction changes do not have a significant effect on the malware sample’s behavior. The strings that are operated on are different and one significant location of change is the BTC demand amount which was 0.5 BTC in the older sample and 0.008 BTC in the newest. This change in price in the disassembly is shown in Figure 17.

Figure 17: Difference in Hard-Coded BTC Demand

Figure 17: Difference in Hard-Coded BTC Demand

Conclusion

As can be seen through comparison between the older Satana sample and the new Coronavirus sample, these two are very closely related. This old sample, or the source code for it, has been repurposed and redeployed as “CoronaVirus” ransomware. However, due to the distribution alongside the KPot sample, the very low demand amount of approximately $70, and the payments that are oddly larger or smaller than the demand: this may be a faux ransomware campaign. Totaling all the payments received, the set of wallet addresses only collected 0.10417322 BTC or about $930, a strangely low amount.

YARA Rule
private rule WindowsPE  {      condition:          uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550  }    rule SubstCipher_MinusIndex  {      meta:          author = "Malware Utkonos"          date = "2020-04-13"          exemplar = "ee937717efe9a2e076b9497498b628beb0c84a8476bd288105a59c5aeea01f3d"      strings:          $op1 = { 8A 14 06 2A D1 FE CA 88 14 07 }      condition:          WindowsPE and all of them  }

 


*** This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by Robert Simmons. Read the original post at: https://blog.reversinglabs.com/blog/retread-ransomware