In-depth Analysis of a New Mirai Variant

I. Background

Recently, NSFOCUS [1], National Cyber Security Center (NCSC) [2], and 360 Security Brain [3] detected a batch of botnet samples that integrate the TEA algorithm for encryption based on the leaked source code of Mirai, targeting IoT/Linux devices of various architectures such as ARM, MIPS, and x86.

II. Sample Analysis

2.1 Mirai.CatDDoS (or GorillaBot)

The first batch of captured samples is a variant of the Mirai botnet operated by the CatDDoS group. Taking the sample adda181984cda825dbfa1cb071a066f5 as an example, its source code basic structure is as follows:

• Source File: ‘attack.c’
• Source File: ‘attack_tcp.c’
• Source File: ‘attack_udp.c’
• Source File: ‘checksum.c’
• Source File: ‘killer.c’
• Source File:’main.c’
• Source File: ‘rand.c’
• Source File:’resolv.c’
• Source File: ‘util.c
• Source File: ‘watchdog.c’
• Source File: ‘xxtea.c’

Compared with the leaked Mirai source code, Mirai.CatDDoS does not contain the scanner.c module used for Telnet brute force cracking, and replaces the table.c module used for XOR decryption of strings with 0xdeadbeef with the xxtea.c implementation. The 16-byte XXTEA algorithm key is: 78h 56h 34h 12h 21h 43h 65h 87h 68h 98h BAh DCh FEh

There are 3 cross-references in total. The first one is to decrypt the string output to the console after the sample runs, and the XXTEA decrypted result is "Hello, world!":

The other two are used to decrypt the C2 addresses contained in the sample, which are: retardedclassmate.dyn and servernoworky.geek. These two C2 addresses have appeared in the report [5] describing the recent attack activities of the CatDDoS group.

Since the C2 is an OpenNIC domain name and cannot be resolved via public DNS servers, the sample has hard-coded the OpenNIC DNS server used for C2 resolution:

unsigned int _fastcall get_dns(_int64 a1)
{
    unsigned int result;  // eax
    result = (unsigned int)rand_next(a1) % 11;
    switch (result)
    {
    case 0u:
        result = htonl(0xC30AC3C3);  // 195.10.195.195
        break;
    case 1u:
        result = htonl(0xC2249057);  // 194.36.144.87
        break;
    case 2u:
        result = htonl(0x33FEA23B);  // 51.254.162.59
        break;
    case 3u:
        result = htonl(0x5E1072FE);  // 94.16.114.254
        break;
    case 4u:
        result = htonl(0x339E6CCB);  // 51.158.108.203
        break;
    case 5u:
        result = htonl(0x334D958B);  // 51.77.149.139
        break;
    case 6u:
        break;
    case 7u:
        result = htonl(0xB2FE16A6);  // 178.254.22.166
        break;
    case 8u:
        result = htonl(0x51A988DE);  // 81.169.136.222
        break;
    case 9u:
        result = htonl(0x86C30402);  // 134.195.4.2
        break;
    case 10u:
        result = htonl(0x5BD98925);  // 91.217.137.37
        break;
    default:
        break;
    }
    return result;
}

The C2 port is randomly selected between 25596 and 25616. In terms of the communication mechanism, Mirai.CatDDoS basically follows the original design of Mirai, except that the fixed 4-byte \x00\x00\x00\x01 when Mirai goes online is modified to a fixed 8-byte:\x31\x73\x13\x93\x04\x83\x32\x04

In terms of the ATTACK_VECTOR, Mirai.CatDDoS implements a richer variety of DDoS attack types than Mirai. The comparison is as follows:

Based on relevant characteristics, we have associated a batch of similar samples. They are more concise and more similar to the original Mirai in terms of code function and structure design. It is speculated that they may be earlier bot versions. From the naming method of the C2, it conforms to the consistent style of the CatDDoS group - that is, having a special preference for "cats". The similarities and differences between the old and new versions are as follows:

2.2 Traffic Analysis

We will conduct protocol analysis on several newly added attack commands in order to obtain effective traffic evasion rules.

Attack Command #11 attack_udp_openvpn

The sample sends attack packets to the target victim machine via the send function at the end of the attack_udp_openvpn function.

The sent data payload is the fixed memory content pointed to by unk_211040:

38 C4 FB 98 76 1F FC FE F4 00 00 00 01 63 31 7B 62 36 3E B1 A8 93 A8 61 98 8B 11 2A 3F 7C 1E AA BF C0 63 AD B7 50 68 A0 D6 2D 0E 17 3D F8 D4 F4 39 69 8D 69 0D 7D 

We then captured the traffic generated by the sample in a controlled environment, and the generated data was consistent with our memory analysis:

I’ll help you create a Suricata rule to detect UDP packets with that specific payload.

Here’s the detection rule:

alert udp any any -> any any (msg:"ET SCAN ELF/Mirai Variant UDP (Inbound)"; content:"|38 C4 FB 98 76 1F FC FE F4 00 00 00 01 63 31 7B 62 36 3E B1 A8 93 A8 61 98 8B 11 2A 3F 7C 1E AA BF C0 63 AD B7 50 68 A0 D6 2D 0E 17 3D F8 D4 F4 39 69 8D 69 0D 7D|"; sid:1000001; rev:1;)

Attack Command #12 attack_method_udprape

The attack_method_udprape has no characteristics consistent with regular traffic. The only difference may be in the random value part. So, conservatively, we didn’t give a matching rule. However, there are still some strings with fixed patterns shown in the sample program:

Attack Command #13 attack_udp_r6

The attack_udp_r6 function also sends attacks to the target object via send at the end. When executed, the memory at the position of unk_211080 is fixed as:

A5 E4 43 C7 00 3F 10 16 01 12 2F F8 3C E1 D0 5D 49 2A 43 A4 25 77 00 00 00 F2 60 25 D8 FF FF FF FF F4 6D 89 0B DC 36 47 F7 3A A5 38 8D 

The captured traffic is as follows:

The corresponding rule is:

alert udp any any -> any any (msg:"ET SCAN ELF/Mirai Variant UDP (Inbound)"; content:"|A5 E4 43 C7 00 3F 10 16 01 12 2F F8 3C E1 D0 5D 49 2A 43 A4 25 77 00 00 00 F2 60 25 D8 FF FF FF FF F4 6D 89 0B DC 36 47 F7 3A A5 38 8D|"; sid:1000002; rev:1;)

Appendix

• Captured traffic (pass: infected): downloads

• Added command protocol specifations: downloads

IoCs

MD5:

adda181984cda825dbfa1cb071a066f5

c1ca3665f762e11a727ad8899b628fd8

9f72a19d57ff74b9ed98639ff10ba4fa

ec744ef35a1650b27a3c314fe4b95412

5cf5e2b114b7253de95483615ac840d8

1074c5e50a96b50fd60ec36053981b7b

1ad8e1b5927c4166e815d3c0eafabee7

1fab9849b2fe8327382a1591d4e7cb0d

844d7d1e8e6fc47b989f5986769bb3f0

f0022798b0fec29fa0153d9ca61e8bc3

25cf45b475f738c97530512b9c94f52e

d31c417346d0012c234fde8f2be517e8

276adc6a55f13a229a5ff482e49f3a0b

63cbfc2c626da269c67506636bb1ea30

7f134c477f307652bb884cafe98b0bf2

3a3be84df2435623132efd1cd9467b17

03a59780b4c5a3c990d0031c959bf7cc

5b37be51ee3d41c07d02795a853b8577

15f6a606ab74b66e1f7e4a01b4a6b2d7

C2:

retardedclassmate.dyn

servernoworky.geek

catsarecool.gopher

ilikecats.parody

ihateyou.indy

catsliketo.pirate

kittycattos.dyn

References

[1] https://nsfocusglobal.com/over-300000-gorillabot-the-new-king-of-ddos-attacks/

[2] https://www.ncsc.admin.ch/dam/ncsc/de/dokumente/dokumentation/fachberichte/NCSC-CH-GorillaBot.pdf.download.pdf/NCSC-CH-GorillaBot.pdf

[3] https://mp.weixin.qq.com/s/AlmeQJVeWr2c1gf7yzo48w

[4] https://mp.weixin.qq.com/s/Hc_zHeByTdOvDZPGxQaxlw

[5] https://blog.xlab.qianxin.com/catddos-derivative-cn/