Malware authors use encryption to hide valuable content from analysts and automated detection tools. That’s why Nozomi Networks researchers are constantly monitoring malware samples collected by our Internet of Things (IoT) honeypots to detect new or modified malware samples. The majority of the botnet-derived samples we receive can be placed into two distinct groups: Mirai-based and Gafgyt-based. We recently published a blog about the modifications found in Gafgyt-based samples, so in this blog we will focus on the Mirai-based samples.
During a recent analysis of collected samples, we discovered one Mirai-based variant using a new decryption function called xor_init. When malware authors introduce encryption to hide valuable content from analysts and automated tools, the exclusive OR (XOR) operation is the most used bitwise operation by malware creators. Because this new function does not re-encrypt potential indicators, it remains in clear-text even well after an attack. While this is considered a downgrade compared to normal stealthy malware this, in turn, makes it easier for network defenders and responders to trace an attack.
In this blog, we discuss Mirai’s new encryption routine, the three different encryption variants, and how these modifications actually benefit network defenders and responders. Let’s take a look at it in greater detail.
Mirai’s New Encryption Routine
Mirai has its own encryption/decryption system that is initialized in the table_init function, so we first have to check if it’s the same function but renamed. After checking its code, we see that it is very different.
Old method: Mirai’s table_init code populates the memory with encrypted strings that will later decrypt on demand and re-encrypt after being used. This reduces the time during which the strings remain in cleartext in memory, which makes it harder for analysts to extract all the encrypted strings. This is a simple, yet efficient, method to keep secrets safe.
New method: Now, let’s check what new method xor_init is adding to the already existing functionality. The function allocates a block of memory, decrypts all the information in a single go, and does not re-encrypt later. In other words, one of the first functions executed is decryption of all hidden strings, making decryption for researchers much easier. This is a significant and unnecessary downgrade from the original Mirai functionality.
The malware authors who modified the Mirai (or another variant) source code probably designed their own protection function because it made it easier for them to add new strings. Most of the time we find that the encrypted strings aren’t necessary for protection, as they are not unique enough to identify the samples as suspicious. In many cases, we see exploit code and data that is useful in identifying suspicious samples in the non-encrypted form. Moreover, the exploit code may contain non-encrypted command and control (C&C) domains and other indicators that can immediately be used to create detections.
Mirai Decryption Variations
As we encountered multiple samples similar to this one, we started tracking them and quickly noticed that there are several similar groups involving different sets of modifications. First, we discovered that some variants are using table_init and xor_init functions at the same time to process different strings. There is no constant pattern of strings that are stored in this new XOR-encryption set: sometimes, but not often, we see the C&C server information stored there, but most of the times we only see some file paths that are not critical for detection. It seems that the creators of this variant wanted to add some new code but most of the times it does not adequately protect the most important strings. For example, strings related to the exploitation of vulnerabilities used during the propagation phase can commonly be found in clear text in these samples.
Three Unique Decryption Keys
Once the xor_init function is executed, it uses an embedded encryption key to decrypt its protected content. Over the last few months, at least three different keys have been used. This allows us to assign them to different groups and look for different patterns among them. The encryption keys are:
- pazdanoisqt
- megacatnet
- fakamebotnet
This could mean that somebody made a modification of Mirai and is selling it to different attackers, or it could show that they are associated with different campaigns. All three sample groups have unique C&Cs but, inside each group, almost all share the same infrastructure.
pazdanoisqt
Most of the samples we have found (123 in the past three months) belong to this group. This is the first group that we started seeing recently in the wild from June 2022 this year. Last time we saw a sample from this group was at the beginning of September 2022.
This botnet is not only focused on Distributed Denial of Service (DDoS) attacks as it also includes most of the same exploits that have been seen in the Mirai variant named Omni. This version of the botnet uses both table_init and xor_init functions.
megacatnet
Our Threat Intelligence systems collected 34 samples for this group of Mirai variants so far. This group of samples, as well as the next one, are more recent; we started to see them in August this year and currently still alive in the wild. This is a simpler variant as it is only focused only on DDoS attacks. It seems this campaign or variant removed the table_init functionality leaving only xor_init. Some functions used init_xor function name instead of xor_init.
fakamebotnet
So far we have collected 16 different samples that use the fakamebotnet string as a key. We also started to see this campaign in August 2022 and they are still actively used. This group of samples maintain both “initialisation” functions table_init and xor_init to prepare the memory to be used during the execution. This group is a little bit more complex as it doesn’t only focus on DDoS attacks, it is also able to exploit CVE-2017-17215 remote code execution in Huawei devices to infect them.
Although we haven’t seen any common infrastructure between fakamebotnet and megacatnet, some of the subdomains they are using share similar names and domains. This, coupled with the fact that they first appeared around the same time, makes us think that they are being used by the same group.
Conclusion
The fact that malware source code is freely available to everybody makes the creation of different variations much easier. This allows malware developers of any level of experience to re-use existing powerful code that they commonly modify according to their needs. As we can see here, not all of the modifications introduced follow the same standards, which allows cybersecurity experts to quickly create solid detections and conduct the research faster.
SHA256 Indicators
- 14d082dccce114ea574098856395157111e58f029cc14921bde702147d1b5646
- 25566a62ab5e8221780f0ae227eca06088077f098366f88454227e4b6e917c31
- 2651d48bb50e77c6647d3bfe3de0ae872109a691fbebcbe305b96c54bd1c96f0
- 2f86bf6baa896dc5b8ac10609e3b5b99d6b58cd2e58a47b6160c7fd9c514fe0b
- 47ddd3b2581f8b70ac6ffa8f32476f423322e80e687ab664a6775bccb88c5d65
- 4da284aec784efc94effdee4ea5b30e0636fe596d38c863415b6e273590a0763
- 51de0c208785e70b83226dc762fc9386589a47ca19129369a70e704e2641bd78
- 682ba2443f2b9ec13d9ba184e799f7c19cee598a844c8c105918c7aca493457c
- 750d7fe81c7d8bad25442a8c653dfb9ffa6a015d68fd0015cc8409df071a0ad2
- 86fbf21abc7d800c133b84a367431407a6f42a9cf2fee2d31626af343f277ef7
- 9019acf6c6910bd92c262e8b5ae5c542ef216a8d7061f89dd715034b0f4cd8e9
- a1eb59c928cb328b6ca4432400bfc93b81726b3754b815d288423f8d65d366b4
- a89ad47d1862813c11d382aafe84a19dc9e79171ba8b688ef81721bb163ba652
- b92b2879eb6e2bb0f9d34b6e2502ff554e002c16ec26f36cc765dfba0884b544
- d1b493023508b85a0afb72c62ce5073e19f752d89dc433623eddd915239658fe
- ec682de50315b173ca162fc3aaca5414f3c1dbd99c54ad99d486790bfddfe573
- f3929937a4a469e78062a744008aeabc91960d3d5a870ef4984c70a428b5488f
