As part of our recently released 2022 Threat Roundup report, Forescout Vedere Labs described how the Mirai IoT botnet continues to evolve via new variants and adaptations, such as Gafgyt and RapperBot, more than six years after it started taking over IoT devices and had its source code leaked.
Extracting strings from these Mirai variants is very useful, as these strings may contain references to C2 domains and IP addresses that can be used for identifying attacker infrastructure and responding to incidents. However, the strings are often obfuscated in the malware to thwart automated analysis.
To help members of the cybersecurity community analyze variants of the Mirai botnet, we are releasing an open-source tool to deobfuscate strings for automated extraction of tactical threat intelligence and variant classification.
Using the Mirai string deobfuscator
The tool provides a simple and easy way to retrieve obfuscated strings from various Mirai variants: just run the script against a Mirai sample, and you should get deobfuscated strings as the output.
While many Mirai variants still use the default XOR encryption key of the original Mirai, some variants use different keys or completely different obfuscation methods. For example, RapperBot does not encrypt strings but builds them on the stack character-by-character, while Satori uses a combination of XOR encryption and a substitution cypher to deobfuscate the strings.
We have encoded in the tool several techniques against obfuscation heuristics that we (and other researchers) observed:
- The obfuscated strings are located in the .rodata segment of the malicious ELF binary (except for some of the RapperBot variants, in which the obfuscated strings will be located in the .text segment).
- Because the same XOR keys are frequently used by multiple variants, we added a list of known keys to the tool. For example, the XOR key of the original Mirai (0xDEADBEEF or 0x22) is often used. Some other variants use different keys (or even several different ones).
- Some of the variants, such as Satori, use a simple substitution cypher to obfuscate strings; we include the substitution tables that we extracted and the XOR key that was used to encrypt both of them.
- Some of the variants may include multiple keys (or even use 255 different keys for every 255 different strings). While brute-forcing the 1-byte key is trivial, the amount of output may still be quite large. We noticed that, typically, the majority of the obfuscated strings in Mirai are NULL-terminated: there’s a NULL octet at the end of the obfuscated string. However, the deobfuscated string needs to be NULL-terminated as well. Therefore, the last non-NULL character of the obfuscated string is actually the NULL octet of the original string XORed with the key (0x00 ^ XOR key = XOR key). By applying this heuristic, we can recover most of the obfuscated strings without even knowing the key itself in a single pass:
Since the deobfuscator is a lightweight script, it can also be plugged into an automated malware analysis pipeline. Below, we use as an example the open-source projects MWDB and Karton developed by the CERT Polska team:
- Step 1: an unknown file (MD5 hash 793bf9870d0a7442) has been uploaded to MWDB from a “honeypot” feed:
- Step 2: a Karton service identifies the file as a Linux runnable packed with UPX. The file is then unpacked:
- Step 3: another Karton service uses the Mirai deobfuscator to extract strings from the unpacked sample and dump them as a blob. A Mirai classifier service uses these strings and other indicators to identify the likely variant, and adds a family/variant tag to the unpacked sample (in this case, the sample is a Sora variant):
The deobfuscation tool does not attempt to replace well-known, general-purpose tools for defeating XOR obfuscation. However, we have successfully tested it against samples of the following Mirai variants:
|Sora||Has polymorphic capabilities that supports a variety of DDoS attacks and uses SSH credentials brute-forcing and IoT vulnerabilities for propagation.|
|RapperBot||Supports several DDoS attacks and propagates via SSH credential brute-forcing exclusively. Unlike other variants that use the SSH vector, the C2 server collects and distributes all the previous successful brute-forced credentials. Since the DDoS attacks seem to be limited, it is deemed that the main purpose of the bot is to achieve persistent access to vulnerable systems (possibly, for future use).|
|Moobot||Spreads over Telnet (credential brute-forcing and default IoT device credentials). Additionally, since August 2022 the samples of this family use several command execution vulnerabilities in D-Link routers for propagation. The DDoS functionality seems to be no different than in the original Mirai.|
|InfectedNight||Uses known Telnet and SSH credentials of IoT devices (e.g., home routers provided by ISPs) for propagation. The DDoS functionality seems to be no different than in the original Mirai.|
|Iot Reaper||Propagates exclusively via exploitation of command execution vulnerabilities in IoT devices (Vacron NVR, D-Link routers, Netgear routers, etc.). The variant constantly evolves by adding new exploits. It supports a variety of DDoS attacks, as well as execution of arbitrary commands received from the C2 server.|
|Gafgyt||Propagates over Telnet and SSH with predefined default credentials. This variant (and its derivatives) is known to target online game servers. Most of the samples we have observed do not have any propagation capabilities and were planted by the attacker(s) via SSH by some other means. Other variants we observed support propagation techniques inherited from Mirai, as well as exploits for several IoT devices (D-Link and Huawei routers). The samples support a multitude of DDoS attacks via TCP/UDP/HTTP, as well as attacks against the Valve Source engine (inherited from Mirai).|
|Satori||Also known as FBot, has been around since 2019. Satori does not contain hardcoded credentials for brute-forcing; it receives them from the C2 instead. This variant uses a peculiar technique for string obfuscation: a substitution cipher in which the substitution tables are additionally encrypted with a XOR key (0x59).|
|Corona||Stripped-down variant of Mirai. In contrast to typical variants, it has no string obfuscation. Supports a limited set of DDoS attacks (TCP and UDP flood), communicates with C2 in cleartext.|
|V3G4||Besides the common SSH vector, this variant relies on several device and web-administration tool vulnerabilities for self-propagation. In common with most Mirai variants, it supports a variety of DDoS attacks.|
Learn more about Mirai and other relevant threats in our 2022 Threat Roundup. Download the open-source deobfuscator, contribute to it and have a look at our previous open-source projects on the Forescout Github page.