Amai，一个细致但又“鲁莽”的mirai变种
<!--kg-card-begin: markdown--><h2 id="">背景</h2>
<p>2020年12月11日，360netlab发现<code>193.109.217.16</code>正在传播一批未知的ELF样本，经分析，我们确定这是一个复用了mirai结构，但重写了上线信息，加密算法的新型变种。基于样本中<code>amai botnet </code>的字串，我们将其命名为amai。</p>
<p>本以为amai只是一个平淡无奇的mirai变种，但是2020年12月21日，一批佰才邦的基站产品（数量300+）瘫痪，其团队向到我们求助，经过取证，发现背后的黑手就是amai。在之前的分析中，并没有发现amai有让设备瘫痪的功能，为何现实啪啪打脸。带着疑问，我们开始了调查，最终成功定位了问题在于busybox文件系统。鉴于大量IOT设备使用busybox来实现文件系统，一旦被amai侵入会造成巨大危害，我们决定编写本文，向社区披露amai的技术细节。</p>
<h2 id="">分析</h2>
<p>本文选取x86 CPU构架的amai bot样本进行分析，基体信息如下</p>
<pre><code>MD5:cde6336628409d12abcc29d113620f4b
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
Lib:uclibc
</code></pre>
<p>amai运行时，会在console输出<code>amai botnet killing off all your daily shitness off your device, you're welcome :)</code>以迷惑用户，通过绑定端口实现单一实例，解密出加密的资源供后续的进程重命名，进程清理使用。接着通过操纵watchdog设备，以及抹去<code>halt,reboot,poweroff</code>执行权限来实现设备不重起。最后开始telnet爆破；同时和C2建立通信，等待执行C2下发的指令。下文将依此脉络分析amai的实现。</p>
<h3 id="">单一实例</h3>
<p>目前观测到amai一共使用过2个端口：<code>5231，8923</code></p>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_single.jpg" alt="amai_single" loading="lazy"></p>
<h3 id="">解密算法</h3>
<p>解密出字串资源供后续使用,python实现如下</p>
<pre><code>xorkey=&quot;QjfjxSRDFGSFDdf&quot;
def decode_str(ctxt):
    for i in range(0,len(ctxt)):
        
            
        for idx in range(1, len(xorkey)):
			
            ch=ord(ctxt[i])
            
            ch ^=((idx*((ord(xorkey[idx]) + i ) &amp;0xff)) &amp;0xff)
            
            
            
            ctxt=ctxt[:i]+chr(ch)+ctxt[i+1:]
        ch ^=0xaf
        ctxt=ctxt[:i]+chr(ch)+ctxt[i+1:]

    return ''.join(ctxt)

</code></pre>
<p>以密文<code>C8 39 39 02</code>为例，</p>
<pre><code>procname='''C8 39 39 02
'''.replace(' ', '').replace('\n','').decode('hex')
print(decode_str(procname))

;;; sipd
</code></pre>
<p>以下为解密出的字串列表</p>
<pre><code>/proc
/stat
/proc/1/stat
/map
/usr/lib
/lib
sipd
</code></pre>
<hr>
<h3 id="">进程重命名</h3>
<br /> 
<p>新的进程名为解密的字串<code>sipd</code></p>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_prctl.jpg" alt="amai_prctl" loading="lazy"></p>
<h3 id="">权限抹除</h3>
<p>抹除以下系统命令的权限，以让受害者设备无法重起。</p>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_chmod.jpg" alt="amai_chmod" loading="lazy"></p>
<p>值得注意的是，在使用busybox作用文件系统的设备，以上操作会造成<code>额外伤害</code>。</p>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_reboot.jpg" alt="amai_reboot" loading="lazy"></p>
<p>如上所示，halt,poweroff,reboot都是busybox实现的，抹权限操作最终会让<code>/bin/busybox</code>的权限变成0，进而导致大量依赖busybox的服务无法使用，设备陷入瘫痪状态。</p>
<h3 id="">进程清理</h3>
<p>进程清理分成2步，通过<code>kill -9</code>结束非白名单进程，接着为系统建立进程快照，不达标的新进程创建后都将被清除，整个系统保持在amai的控制下运行，让维护变得极其困难。</p>
<h4 id="">第一步，清理非白名单进程。</h4>
<p>当bot样本运行时，遍历系统当前进行的进程，进行号大于299，路径不在以下路径中的进程都会被结束。可以看出，路径都是系统正常运行依赖的，因此可以推测amai<code>无意去破坏系统</code>。</p>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_white.jpg" alt="amai_white" loading="lazy"></p>
<p>同时被结束的进程会回传给C2，这一步的目的未知。</p>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_reportproc.jpg" alt="amai_reportproc" loading="lazy"></p>
<h4 id="">第二步，建立进程快照，不达标的新进程都将被清理。</h4>
<p>当bot清理了非白单名单进程后，认为系统处在一个“纯净的状态”，此时为系统建立进程快照，监控新进程创建，不达标就清理掉。</p>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_killproc.jpg" alt="amai_killproc" loading="lazy"></p>
<p>其中<code>wrap_strin</code>的功能为子串匹配，当新进程的绝对路径不是bot样本的绝对路径的子串时，新进程就会被杀死。以下演示了这个过程，当名为<code>samp</code>样本运行后，<code>netstat</code>系统命令执行时直接被杀死了。我们将netstat拷贝到同路径下，重命名为<code>sa</code>,可以看到sa能正常。</p>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_show.png" alt="amai_show" loading="lazy"></p>
<h3 id="telnet">telnet扫描</h3>
<p>复用了mirai扫描机制，使用以下帐号密码对随机生成的ip地址进行登录尝试</p>
<pre><code>(&quot;root&quot;, &quot;vizxv&quot;)
(&quot;admin&quot;, &quot;admin&quot;)
(&quot;root&quot;, &quot;icatch99&quot;)
(&quot;default&quot;, &quot;default&quot;)
(&quot;default&quot;, &quot;0&quot;);
(&quot;root&quot;, &quot;solokey&quot;)
(&quot;root&quot;, &quot;123456&quot;)
(&quot;guest&quot;, &quot;guest&quot;)
(&quot;root&quot;, &quot;xc3511&quot;)
(&quot;root&quot;, &quot;root&quot;)
(&quot;guest&quot;, &quot;12345&quot;)
(&quot;user&quot;, &quot;user&quot;)
(&quot;support&quot;, &quot;support&quot;)
(&quot;admin&quot;, &quot;samsung&quot;)
(&quot;daemon&quot;, &quot;daemon&quot;)
(&quot;root&quot;, &quot;tsgoingon&quot;)
(&quot;root&quot;, &quot;xmhdipc&quot;)
(&quot;root&quot;, &quot;Zte521&quot;)
(&quot;telnetadmin&quot;, &quot;telnetadmin&quot;)
(&quot;ftp&quot;, &quot;ftp&quot;)
(&quot;root&quot;, &quot;hslwificam&quot;)
(&quot;root&quot;, &quot;2011vsta&quot;)
(&quot;bin&quot;, &quot;0&quot;)
(&quot;admin&quot;, &quot;12345&quot;)
(&quot;vstarcam2015&quot;, &quot;20150602&quot;)
(&quot;root&quot;, &quot;antslq&quot;)
(&quot;e8ehome&quot;, &quot;e8ehome&quot;)
(&quot;e8telnet&quot;, &quot;e8telnet&quot;)
(&quot;root&quot;, &quot;54321&quot;)
(&quot;admin&quot;, &quot;h@32LuyD&quot;)
(&quot;teladmin&quot;, &quot;hacktheworld1337&quot;)
(&quot;root&quot;, &quot;hipc3518&quot;)
(&quot;root&quot;, &quot;888888&quot;)
(&quot;root&quot;, &quot;admin&quot;)
(&quot;root&quot;, &quot;default&quot;)
(&quot;root&quot;, &quot;1234&quot;)
(&quot;root&quot;, &quot;root&quot;)
(&quot;root&quot;, &quot;20080826&quot;)
(&quot;admin&quot;, &quot;12345&quot;)
(&quot;admin&quot;, &quot;54321&quot;)
(&quot;admin&quot;, &quot;123456&quot;)
(&quot;admin&quot;, &quot;1234&quot;)
(&quot;admin&quot;, &quot;aquario&quot;)
(&quot;root&quot;, &quot;ttnet&quot;)
(&quot;admin&quot;, &quot;2601hx&quot;)
(&quot;admin&quot;, &quot;t0talc0ntr0l4&quot;)
(&quot;ubnt&quot;, &quot;ubnt&quot;)
(&quot;root&quot;, &quot;1001chin&quot;)
</code></pre>
<p>将能成功登录的设备信息回传给reporter,格式为<code>ip:23  &lt;user&gt;:&lt;pass&gt;\r\n</code></p>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_telrep.jpg" alt="amai_telrep" loading="lazy"></p>
<h3 id="c2">C2通信及指令</h3>
<p>bot样本向C2发送以下信息通知上线</p>
<h4 id="">上线包</h4>
<p>packet 1</p>
<pre><code>01 01
</code></pre>
<p>packet 2</p>
<pre><code>01 02 20 &lt;group&gt;
</code></pre>
<p>流量抓包如下</p>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_reg.jpg" alt="amai_reg" loading="lazy"></p>
<h4 id=""></h4>
<h4 id="ddos">DDoS攻击</h4>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_attack.jpg" alt="amai_attack" loading="lazy"></p>
<h2 id="">就怕坏人爱学习</h2>
<p>至此分析结束，但是故事并没有结束。 从amai的进程清理功能，我们可以看出其作者起初将作工作做的非常细致，并不想破坏设备的正常运行。但是未曾想到抹除<code>halt,reboot,poweroff</code>系统命令的权限操作意外的影响到了busybox，进而使得以busybox作为文件系统的设备瘫痪，非常巧合的增加了amai的危害性。</p>
<p>amai的作者发现了这个问题，选择修复，随后在2020年12月14日 更新了新版本，去除了权限抹除的操作。</p>
<p>随后其作者又意识到了这个操作的价值------非常方便就能把设备变成只能被他控制的“半砖”。因此在2020年12月20日传播的影响到佰才邦的基站设备的样本中重新加入了抹除权限的操作。</p>
<p>以3个时间节点的样本为例，我们可以看到抹除权限操作的来来往往，真是应了那句话，不怕坏人武功高，就怕坏人脑洞大！</p>
<pre><code>{&quot;uri&quot;:&quot;http://193.109.217.16:80/hohobins/hoho.x86&quot;,
&quot;@timestamp&quot;:&quot;2020-12-11 04:03:09&quot;,
&quot;fn&quot;:&quot;mirai_amai&quot;,
&quot;md5&quot;:&quot;80c982d760648ca07faa5e7ee783710b&quot;}
</code></pre>
<pre><code>{&quot;uri&quot;:&quot;http://193.109.217.16:80/hohobins/hoho.x86&quot;,
&quot;@timestamp&quot;:&quot;2020-12-14 04:00:16&quot;,
&quot;fn&quot;:&quot;mirai_amai&quot;,
&quot;md5&quot;:&quot;6003cf5538dfc184e5f879ef78962a7d&quot;}
</code></pre>
<pre><code>{&quot;uri&quot;:&quot;http://45.153.203.120:80/hohobins/hoho.arm7&quot;,
&quot;@timestamp&quot;:&quot;2020-12-20 03:01:00&quot;,
&quot;fn&quot;:&quot;mirai_amai&quot;,
&quot;md5&quot;:&quot;c626b3c0390d03d822aa25388bb12b25&quot;}

</code></pre>
<p><img src="__GHOST_URL__/content/images/2020/12/amai_version.jpg" alt="amai_version" loading="lazy"></p>
<h2 id="ioc">IOC</h2>
<h3 id="c2">c2</h3>
<pre><code>193.109.217.16:889
45.153.203.120:889
</code></pre>
<!--kg-card-end: markdown-->
背景


2020年12月11日，360netlab发现193.109.217.16正在传播一批未知的ELF样本，经分析，我们确定这是一个复用了mirai结构，但重写了上线信息，加密算法的新型变种。基于样本中amai botnet 的字串，我们将其命名为amai。


本以为amai只是一个平淡无奇的mirai变种，但是2020年12月21日，一批佰才邦的基站产品（数量300+）瘫痪，其团队向到我们求助，经过取证，发现背后的黑手就是amai。在之前的分析中，并没有发现amai有让设备瘫痪的功能，为何现实啪啪打脸。带着疑问，我们开始了调查，最终成功定位了问题在于busybox文件系统。鉴于大量IOT设备使用busybox来实现文件系统，一旦被amai侵入会造成巨大危害，我们决定编写本文，向社区披露amai的技术细节。



分析


本文选取x86 CPU构架的amai bot样本进行分析，基体信息如下


MD5:cde6336628409d12abcc29d113620f4b
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
Lib:uclibc



amai运行时，会在console输出amai botnet killing off all your daily shitness off your device, you're welcome :)以迷惑用户，通过绑定端口实现单一实例，解密出加密的资源供后续的进程重命名，进程清理使用。接着通过操纵watchdog设备，以及抹去halt,reboot,poweroff执行权限来实现设备不重起。最后开始telnet爆破；同时和C2建立通信，等待执行C2下发的指令。下文将依此脉络分析amai的实现。



单一实例


目前观测到amai一共使用过2个端口：5231，8923






解密算法


解密出字串资源供后续使用,python实现如下


xorkey="QjfjxSRDFGSFDdf"
def decode_str(ctxt):
    for i in range(0,len(ctxt)):
        
            
        for idx in range(1, len(xorkey)):
			
            ch=ord(ctxt[i])
            
            ch ^=((idx*((ord(xorkey[idx]) + i ) &0xff)) &0xff)
            
            
            
            ctxt=ctxt[:i]+chr(ch)+ctxt[i+1:]
        ch ^=0xaf
        ctxt=ctxt[:i]+chr(ch)+ctxt[i+1:]

    return ''.join(ctxt)




以密文C8 39 39 02为例，


procname='''C8 39 39 02
'''.replace(' ', '').replace('\n','').decode('hex')
print(decode_str(procname))

;;; sipd



以下为解密出的字串列表


/proc
/stat
/proc/1/stat
/map
/usr/lib
/lib
sipd





进程重命名




新的进程名为解密的字串sipd






权限抹除


抹除以下系统命令的权限，以让受害者设备无法重起。





值得注意的是，在使用busybox作用文件系统的设备，以上操作会造成额外伤害。





如上所示，halt,poweroff,reboot都是busybox实现的，抹权限操作最终会让/bin/busybox的权限变成0，进而导致大量依赖busybox的服务无法使用，设备陷入瘫痪状态。



进程清理


进程清理分成2步，通过kill -9结束非白名单进程，接着为系统建立进程快照，不达标的新进程创建后都将被清除，整个系统保持在amai的控制下运行，让维护变得极其困难。


第一步，清理非白名单进程。


当bot样本运行时，遍历系统当前进行的进程，进行号大于299，路径不在以下路径中的进程都会被结束。可以看出，路径都是系统正常运行依赖的，因此可以推测amai无意去破坏系统。





同时被结束的进程会回传给C2，这一步的目的未知。





第二步，建立进程快照，不达标的新进程都将被清理。


当bot清理了非白单名单进程后，认为系统处在一个“纯净的状态”，此时为系统建立进程快照，监控新进程创建，不达标就清理掉。





其中wrap_strin的功能为子串匹配，当新进程的绝对路径不是bot样本的绝对路径的子串时，新进程就会被杀死。以下演示了这个过程，当名为samp样本运行后，netstat系统命令执行时直接被杀死了。我们将netstat拷贝到同路径下，重命名为sa,可以看到sa能正常。






telnet扫描


复用了mirai扫描机制，使用以下帐号密码对随机生成的ip地址进行登录尝试


("root", "vizxv")
("admin", "admin")
("root", "icatch99")
("default", "default")
("default", "0");
("root", "solokey")
("root", "123456")
("guest", "guest")
("root", "xc3511")
("root", "root")
("guest", "12345")
("user", "user")
("support", "support")
("admin", "samsung")
("daemon", "daemon")
("root", "tsgoingon")
("root", "xmhdipc")
("root", "Zte521")
("telnetadmin", "telnetadmin")
("ftp", "ftp")
("root", "hslwificam")
("root", "2011vsta")
("bin", "0")
("admin", "12345")
("vstarcam2015", "20150602")
("root", "antslq")
("e8ehome", "e8ehome")
("e8telnet", "e8telnet")
("root", "54321")
("admin", "h@32LuyD")
("teladmin", "hacktheworld1337")
("root", "hipc3518")
("root", "888888")
("root", "admin")
("root", "default")
("root", "1234")
("root", "root")
("root", "20080826")
("admin", "12345")
("admin", "54321")
("admin", "123456")
("admin", "1234")
("admin", "aquario")
("root", "ttnet")
("admin", "2601hx")
("admin", "t0talc0ntr0l4")
("ubnt", "ubnt")
("root", "1001chin")



将能成功登录的设备信息回传给reporter,格式为ip:23 <user>:<pass>\r\n






C2通信及指令


bot样本向C2发送以下信息通知上线


上线包


packet 1


01 01



packet 2


01 02 20 <group>



流量抓包如下








DDoS攻击






就怕坏人爱学习


至此分析结束，但是故事并没有结束。 从amai的进程清理功能，我们可以看出其作者起初将作工作做的非常细致，并不想破坏设备的正常运行。但是未曾想到抹除halt,reboot,poweroff系统命令的权限操作意外的影响到了busybox，进而使得以busybox作为文件系统的设备瘫痪，非常巧合的增加了amai的危害性。


amai的作者发现了这个问题，选择修复，随后在2020年12月14日 更新了新版本，去除了权限抹除的操作。


随后其作者又意识到了这个操作的价值------非常方便就能把设备变成只能被他控制的“半砖”。因此在2020年12月20日传播的影响到佰才邦的基站设备的样本中重新加入了抹除权限的操作。


以3个时间节点的样本为例，我们可以看到抹除权限操作的来来往往，真是应了那句话，不怕坏人武功高，就怕坏人脑洞大！


{"uri":"http://193.109.217.16:80/hohobins/hoho.x86",
"@timestamp":"2020-12-11 04:03:09",
"fn":"mirai_amai",
"md5":"80c982d760648ca07faa5e7ee783710b"}



{"uri":"http://193.109.217.16:80/hohobins/hoho.x86",
"@timestamp":"2020-12-14 04:00:16",
"fn":"mirai_amai",
"md5":"6003cf5538dfc184e5f879ef78962a7d"}



{"uri":"http://45.153.203.120:80/hohobins/hoho.arm7",
"@timestamp":"2020-12-20 03:01:00",
"fn":"mirai_amai",
"md5":"c626b3c0390d03d822aa25388bb12b25"}








IOC



c2


193.109.217.16:889
45.153.203.120:889


{"version":"0.3.1","atoms":[],"cards":[["markdown",{"markdown":"\n\n## 背景\n\n2020年12月11日，360netlab发现```193.109.217.16```正在传播一批未知的ELF样本，经分析，我们确定这是一个复用了mirai结构，但重写了上线信息，加密算法的新型变种。基于样本中```amai botnet ```的字串，我们将其命名为amai。\n\n本以为amai只是一个平淡无奇的mirai变种，但是2020年12月21日，一批佰才邦的基站产品（数量300+）瘫痪，其团队向到我们求助，经过取证，发现背后的黑手就是amai。在之前的分析中，并没有发现amai有让设备瘫痪的功能，为何现实啪啪打脸。带着疑问，我们开始了调查，最终成功定位了问题在于busybox文件系统。鉴于大量IOT设备使用busybox来实现文件系统，一旦被amai侵入会造成巨大危害，我们决定编写本文，向社区披露amai的技术细节。\n\n\n\n## 分析\n\n本文选取x86 CPU构架的amai bot样本进行分析，基体信息如下\n\n```\nMD5:cde6336628409d12abcc29d113620f4b\nELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped\nLib:uclibc\n```\n\namai运行时，会在console输出```amai botnet killing off all your daily shitness off your device, you're welcome :)```以迷惑用户，通过绑定端口实现单一实例，解密出加密的资源供后续的进程重命名，进程清理使用。接着通过操纵watchdog设备，以及抹去```halt,reboot,poweroff```执行权限来实现设备不重起。最后开始telnet爆破；同时和C2建立通信，等待执行C2下发的指令。下文将依此脉络分析amai的实现。\n\n\n\n### 单一实例\n\n目前观测到amai一共使用过2个端口：```5231，8923```\n\n![amai_single](__GHOST_URL__/content/images/2020/12/amai_single.jpg)\n\n### 解密算法\n\n解密出字串资源供后续使用,python实现如下\n\n```\nxorkey=\"QjfjxSRDFGSFDdf\"\ndef decode_str(ctxt):\n    for i in range(0,len(ctxt)):\n        \n            \n        for idx in range(1, len(xorkey)):\n\t\t\t\n            ch=ord(ctxt[i])\n            \n            ch ^=((idx*((ord(xorkey[idx]) + i ) &0xff)) &0xff)\n            \n            \n            \n            ctxt=ctxt[:i]+chr(ch)+ctxt[i+1:]\n        ch ^=0xaf\n        ctxt=ctxt[:i]+chr(ch)+ctxt[i+1:]\n\n    return ''.join(ctxt)\n\n```\n\n以密文```C8 39 39 02```为例，\n\n```\nprocname='''C8 39 39 02\n'''.replace(' ', '').replace('\\n','').decode('hex')\nprint(decode_str(procname))\n\n;;; sipd\n```\n\n以下为解密出的字串列表\n\n```\n/proc\n/stat\n/proc/1/stat\n/map\n/usr/lib\n/lib\nsipd\n```\n---\n### 进程重命名\n<br /> \n\n新的进程名为解密的字串```sipd```\n\n![amai_prctl](__GHOST_URL__/content/images/2020/12/amai_prctl.jpg)\n\n### 权限抹除\n\n抹除以下系统命令的权限，以让受害者设备无法重起。\n\n![amai_chmod](__GHOST_URL__/content/images/2020/12/amai_chmod.jpg)\n\n\n\n值得注意的是，在使用busybox作用文件系统的设备，以上操作会造成```额外伤害```。\n\n![amai_reboot](__GHOST_URL__/content/images/2020/12/amai_reboot.jpg)\n\n如上所示，halt,poweroff,reboot都是busybox实现的，抹权限操作最终会让```/bin/busybox```的权限变成0，进而导致大量依赖busybox的服务无法使用，设备陷入瘫痪状态。\n\n\n\n### 进程清理\n\n进程清理分成2步，通过```kill -9```结束非白名单进程，接着为系统建立进程快照，不达标的新进程创建后都将被清除，整个系统保持在amai的控制下运行，让维护变得极其困难。\n\n#### 第一步，清理非白名单进程。\n\n当bot样本运行时，遍历系统当前进行的进程，进行号大于299，路径不在以下路径中的进程都会被结束。可以看出，路径都是系统正常运行依赖的，因此可以推测amai```无意去破坏系统```。\n\n![amai_white](__GHOST_URL__/content/images/2020/12/amai_white.jpg)\n\n\n\n同时被结束的进程会回传给C2，这一步的目的未知。\n\n![amai_reportproc](__GHOST_URL__/content/images/2020/12/amai_reportproc.jpg)\n\n\n\n#### 第二步，建立进程快照，不达标的新进程都将被清理。\n\n当bot清理了非白单名单进程后，认为系统处在一个“纯净的状态”，此时为系统建立进程快照，监控新进程创建，不达标就清理掉。\n\n![amai_killproc](__GHOST_URL__/content/images/2020/12/amai_killproc.jpg)\n\n其中```wrap_strin```的功能为子串匹配，当新进程的绝对路径不是bot样本的绝对路径的子串时，新进程就会被杀死。以下演示了这个过程，当名为```samp```样本运行后，```netstat```系统命令执行时直接被杀死了。我们将netstat拷贝到同路径下，重命名为```sa```,可以看到sa能正常。\n\n![amai_show](__GHOST_URL__/content/images/2020/12/amai_show.png)\n\n### telnet扫描\n\n复用了mirai扫描机制，使用以下帐号密码对随机生成的ip地址进行登录尝试\n\n```\n(\"root\", \"vizxv\")\n(\"admin\", \"admin\")\n(\"root\", \"icatch99\")\n(\"default\", \"default\")\n(\"default\", \"0\");\n(\"root\", \"solokey\")\n(\"root\", \"123456\")\n(\"guest\", \"guest\")\n(\"root\", \"xc3511\")\n(\"root\", \"root\")\n(\"guest\", \"12345\")\n(\"user\", \"user\")\n(\"support\", \"support\")\n(\"admin\", \"samsung\")\n(\"daemon\", \"daemon\")\n(\"root\", \"tsgoingon\")\n(\"root\", \"xmhdipc\")\n(\"root\", \"Zte521\")\n(\"telnetadmin\", \"telnetadmin\")\n(\"ftp\", \"ftp\")\n(\"root\", \"hslwificam\")\n(\"root\", \"2011vsta\")\n(\"bin\", \"0\")\n(\"admin\", \"12345\")\n(\"vstarcam2015\", \"20150602\")\n(\"root\", \"antslq\")\n(\"e8ehome\", \"e8ehome\")\n(\"e8telnet\", \"e8telnet\")\n(\"root\", \"54321\")\n(\"admin\", \"h@32LuyD\")\n(\"teladmin\", \"hacktheworld1337\")\n(\"root\", \"hipc3518\")\n(\"root\", \"888888\")\n(\"root\", \"admin\")\n(\"root\", \"default\")\n(\"root\", \"1234\")\n(\"root\", \"root\")\n(\"root\", \"20080826\")\n(\"admin\", \"12345\")\n(\"admin\", \"54321\")\n(\"admin\", \"123456\")\n(\"admin\", \"1234\")\n(\"admin\", \"aquario\")\n(\"root\", \"ttnet\")\n(\"admin\", \"2601hx\")\n(\"admin\", \"t0talc0ntr0l4\")\n(\"ubnt\", \"ubnt\")\n(\"root\", \"1001chin\")\n```\n\n将能成功登录的设备信息回传给reporter,格式为```ip:23  <user>:<pass>\\r\\n```\n\n![amai_telrep](__GHOST_URL__/content/images/2020/12/amai_telrep.jpg)\n\n### C2通信及指令\n\nbot样本向C2发送以下信息通知上线\n\n#### 上线包\n\npacket 1\n\n```\n01 01\n```\n\npacket 2\n\n```\n01 02 20 <group>\n```\n\n流量抓包如下\n\n![amai_reg](__GHOST_URL__/content/images/2020/12/amai_reg.jpg)\n\n#### \n\n#### DDoS攻击\n\n![amai_attack](__GHOST_URL__/content/images/2020/12/amai_attack.jpg)\n\n## 就怕坏人爱学习\n\n至此分析结束，但是故事并没有结束。 从amai的进程清理功能，我们可以看出其作者起初将作工作做的非常细致，并不想破坏设备的正常运行。但是未曾想到抹除```halt,reboot,poweroff```系统命令的权限操作意外的影响到了busybox，进而使得以busybox作为文件系统的设备瘫痪，非常巧合的增加了amai的危害性。\n\namai的作者发现了这个问题，选择修复，随后在2020年12月14日 更新了新版本，去除了权限抹除的操作。\n\n随后其作者又意识到了这个操作的价值------非常方便就能把设备变成只能被他控制的“半砖”。因此在2020年12月20日传播的影响到佰才邦的基站设备的样本中重新加入了抹除权限的操作。\n\n以3个时间节点的样本为例，我们可以看到抹除权限操作的来来往往，真是应了那句话，不怕坏人武功高，就怕坏人脑洞大！\n\n```\n{\"uri\":\"http://193.109.217.16:80/hohobins/hoho.x86\",\n\"@timestamp\":\"2020-12-11 04:03:09\",\n\"fn\":\"mirai_amai\",\n\"md5\":\"80c982d760648ca07faa5e7ee783710b\"}\n```\n\n```\n{\"uri\":\"http://193.109.217.16:80/hohobins/hoho.x86\",\n\"@timestamp\":\"2020-12-14 04:00:16\",\n\"fn\":\"mirai_amai\",\n\"md5\":\"6003cf5538dfc184e5f879ef78962a7d\"}\n```\n\n```\n{\"uri\":\"http://45.153.203.120:80/hohobins/hoho.arm7\",\n\"@timestamp\":\"2020-12-20 03:01:00\",\n\"fn\":\"mirai_amai\",\n\"md5\":\"c626b3c0390d03d822aa25388bb12b25\"}\n\n```\n\n\n\n![amai_version](__GHOST_URL__/content/images/2020/12/amai_version.jpg)\n\n\n## IOC\n\n### c2\n```\n193.109.217.16:889\n45.153.203.120:889\n```\n\n\n"}]],"markups":[],"sections":[[10,0],[1,"p",[]]],"ghostVersion":"3.0"}