kenshinx/netlab-blogs huggingface dataset:
DNS中的“无效Rdata”

所谓Rdata是指在DNS记录中与类型相关的数据部分。比如对于DNS的A记录中的IPv4地址或者MX记录中的主机名及其优先级。


在分析DNS的数据过程中，常常能见到各种不同种类的怪异的Rdata。我们把不能有效反应域名和rdata的对应关系的数据称为“无效Rdata”。对这些无效Rdata进行分析是理解DNS数据的一个有趣的切入点。


另外，结合最近火爆的威胁情报，发现很多的数据源中，都包含了这些“无效的Rdata”，它们降低了这些威胁情报的质量。因此对这些无效rdata的过滤是提高威胁情报质量的一个重要手段。


尽管还有很多其他类型的无效的rdata，但是相比IP地址来说，其他种类的数据影响较小。因此本文主要讨论IP地址。



DNS Sinkhole的IP地址


DNS Sinkhole是安全厂商为了研究恶意软件的行为，将恶意软件的网络流量进行接管的一种方式，具体参见wiki的定义。


从PassiveDNS中的数据来看，sinkhole的域名主要集中在使用DGA技术产生随机域名的恶意软件上。比如上一篇blog中提到的conficker，以及大名鼎鼎的GOZ等。现在来看，多数的DGA域名都已经被不同的安全机构做了sinkhole。


除了DGA域名之外，也有安全厂商对特定的恶意软件进行sinkhole，比如卡巴斯基就惯用这种手法对未知的恶意软件使用sinkhole对其网络行为进行研究。


因此如果你的情报数据中出现了sinkhole的IP地址。说明在安全行为分析上面是完善的，尤其是针对恶意域名的研究是完善的，可是这种分析可能不是最新的。它已经落后于其他的某些安全机构，如果在研究过程中和这些IP有过通信（多数情况都无法正常通信），那么你的某些研究行为也可能已经暴露在那些安全机构面前。


由于各家安全研究机构对自身的sinkhole的保密性，业界尚未有完整的sinkhole列表。但是一些安全研究机构也做了一些整理，比如abuse.ch的sinkdb。



NXDomain引起的虚假IP地址


NXDomain的含义是指对于不存在的域名，DNS系统能够返回确定的IP地址。但如果继续访问的话，这些IP地址呈现的内容往往和你想要的又完全不同。其实上一节的sinkhole也是这种情况当中的一种，只是sinkhole在安全研究方面比较特殊，我们把它单独列了出来。


造成NXdomain有确定IP映射的原因其实不尽相同，我们列举几种比较常见的情况。



运营商的问题


运营商针对不存在的域名，返回自己控制的IP以达到导流的目的，这种现象我们司空见惯。并且这种行为并不仅仅发生在国内，在全世界各地都存在这种“劫持”行为。以至于Google的chrome浏览器（以及基于chrome内核的其他浏览器）在启动的时候要发送随机DNS查询对这种“劫持”行为进行探测以免干扰浏览器的正常工作。


在实际网络环境中，大量的恶意软件会产生无效域名请求，比如未被sinkhole或者sinkhole不完全的DGA域名等。另外各种扫描器以及形如散列前缀攻击的攻击行为都会产生大量的无效域名请求。


如果不加筛选将这种IP列入分析结果，输出为IP黑名单。尽管实际用户使用可能危害并不明显，但是准确度却打了折扣。尤其是在涉及到僵尸网络的C&C分析的时候，会对分析结果造成很大的挑战。



DNS resolver的问题


也许是为了避免被运营商劫持，大量用户开始使用公开的非运营商的open resolver作为自己的DNS服务器。而现在越来越多的DNS服务器提供安全服务，而这种安全服务从技术上来看，与运营商劫持的手法相同。即它们会将其认为存在安全隐患的域名返回为一个其控制的IP地址。页面内容一般是比较显著的安全提示信息。

典型的例子是OpenDNS。其提供安全服务的一个IP地址为146.112.61.105。


同运营商的问题类似，将这类IP地址输出为IP黑名单，对实际用户并不会有太大的影响（其实会干扰这些DNS resolver的功能完整性），但是对所分析问题的准确度有影响。根据我们对PassiveDNS数据的分析，这类IP的数量不在少数。



注册商的问题


如果说前两种情况发生在DNS查询过程中靠近用户这一侧，是对查询结果的劫持。那么由注册商引起的虚假应答就属于“官方作假”了。


从技术手段上来说，实现这种“官方作假”很简单，只需要把对应域名的泛解析开启即可。



顶级域（TLD）级别


在我们的印象中，TLD的管理应该是合规慎重的。因此第一次了解到泛解析开在TLD级别上还是有些吃惊。

现在发现至少ws、sy、ph这几个ccTLD是开启泛解析的。因此如果在分析域名时，发现TLD为这几个后缀的域名，还请留意一下是否为泛解析的IP地址。一个典型的例子银行木马是dyre的DGA域名有的是以ws作为TLD，显然它们都会有有效的解析地址，但并不是真正的C&C地址。


随着ICANN开放TLD的注册，现在越来越多的TLD可供选择。也许为了利益的目的，在TLD上开放泛解析的行为也必然会越来越多。



特殊用途的IP



形如1.1.1.1/2.2.2.2/8.8.8.8/114.114.114.114等


如果在PassiveDNS中以类似如上IP进行查询，能够发现大量的域名与这些IP存在对应关系。尽管这些IP中有些并不可达，比如1.1.1.1，2.2.2.2；有些则完全另有他用，比如8.8.8.8, 114.114.114.114都是知名的DNS resolver。


造成这种对应关系的原因有多种：一种可能是管理员用于测试的配置，还有一种可能是某些DNS服务器在检测到攻击之后，对某些请求返回一些知名的地址。比如我们见到针对DNS的散列前缀攻击，有些DNS服务器对散列前缀的域名返回8.8.8.8以及8.8.4.4的情况。


要说明的是第二种情况是必须禁止的，某些情况下，错误的返回会导致返回地址遭到大流量的DDoS攻击。这种情况在真实环境中出现过。



保留地址


最常见的保留地址就是我们熟悉的私网地址：10.0.0.0/8，172.16.0.0/12，192.168.0.0/16。它们在PassiveDNS中作为rdata并不罕见。显然这是内网数据泄漏的典型，将内网的网络拓扑一览无余的对外暴露了。


其他的保留地址也有出现，比如传统意义上的D类和E类地址，以及用于TEST-NET的保留地址等。

完整的保留地址参见wiki的保留地址列表。


同上一节的原因相同，造成这种问题的原因既有可能是配置错误，也有可能是一种安全防御手段。作为一种安全防御手段，尽管用保留地址在某种意义上来说比胡乱指向其它的有效IP更为保险，但是这种行为仍不建议。



结束语


这篇文章简单的列举了几类无效rdata的情况。它们可能是造成黑名单不准确的一个因素。当然，还有很多其他的因素也有可能对rdata的准确度造成影响，比如国家防火墙造成的域名IP的映射混乱，比如虚拟主机提供商所造成数据准确度的偏差以及那些我们尚未认识到的原因造成的数据错误等等。这里我们无法对每种原因都进行详细的说明，但是在数据分析的过程中需要我们不断的对每种情况进行分析才有可能认清网络世界，同时才能够产生高质量的数据。


文中提到的这些数据，360网络安全研究院都有整理。任何想法都欢迎与我们交流。
A quick stats on the 608,083 Mirai IPs that hit our honeypots in the past 2.5 months

Over the last few weeks Mirai, a DDoS botnet family which is believed to be responsible for the large attacks against Brian Krebs on September 13, 2016, has become a hot topic in security community. Previous investigations show that this malware mainly infects IoT devices, e.g., CCTV, and TCP ports of 23 and 2323, which are used for Telnet, are the main infection vector.

On September 30, Mirai’s source code was leaked, which gives us the chance to better understand how this family of botnet works. After a some exploration on the leaked source, a vulnerability was found in its scan module, which, together with the fact that Mirai only scans TCP ports of 23 and 2323, enables us to distinguish the Mira TCP SYN scans from other scanners by checking the SYN packet's header fields. The evaluation on our old dataset shows 608,083 uinique Mirai IPs have hit our honeypots since August 1, 2016. In this post, I will give a quick statistics on the checked Mira scans.

The first Mirai scan that came to us was on 2016-08-01 12:46:01 UTC+8, August 1, 2016. Till 23:59:59 UTC+8, October 13, 2016, totally 1,063,786 Mirai scans were checked. The daily stats can be shown in Figure 1.



Figure 1, Daily variations of Mirai scans


It seems that after a few fluctuations the Mirai botnets reached a plateau in mid-September and have remained that activeness status till now.

Further investigations show that those scans came from totally 608,083 unique IPs across 196 countries, as shown in Figure 2.



Figure2, Geo-locations of Mirai IPs


The top 10 countries/ASNs stats show that some Asian countries, including Vietnam, China, India, and Korea, have the largest number of Mirai bots.



Figure 3, Top 10 countries of Mirai bot IPs




Figure 4, Top 10 ASNs of Mirai bot IPs


In the future we will still keep an eye on the progress of Mirai scans.


Besides that, we have been able to extract couple of Mirai C2s (command and controller), and added them into our DDos botnet command tracking system, with that, we will hopefully be able to track the Mirai botnet attacks (target, attack type, attack instructions) in real time. Stay tuned for more update on this.
Mirai 变种中的DGA

更新历史


2016-12-09 首次发布

2016-12-12 更新图0，修正了我们DGA实现中一处TLD选择的错误



概要


两个星期前，我们发现2个新的感染载体（也即TCP端口7547和5555变种）被用来传播MIRAI恶意软件。





<A Few Observations of The New Mirai Variant on Port 7547>



我的同事Ye Genshen快速设置了一些蜜罐，并且很快取得收获：11月28日一天就捕获了11个样本。 迄今为止，我们的蜜罐已从6个托管服务器捕获了53个独立样本。


在分析其中一个新样本时，我的同事Qu Wenji发现一些类似DGA的代码，并猜测变种中包含有DGA功能，这个猜测很快就从我们的沙箱数据中得到验证。详细的逆向工作显示，在通过TCP端口7547和5555分发的MIRAI样本中确实存在DGA特征。在本博客中，我将介绍我们的发现。简单来说，我们找到的DGA的属性总结如下：


 1. 使用3个顶级域名：online/tech/support；
 2. L2域名固定长度12字符，每个字符从“a”到“z”中随机选择；
 3. 域名仅由月、日和硬编码的种子字符串确定；
 4. 每天只生成一个域名，因此最多存在365个 DGA域名；
 5. DGA域名仅在硬编码的C2域名无法解析时使用。


通过逆向获取的DGA知识，我们在程序中重新实现了DGA，并用它来预测所有365个可能的域名。当进一步确认这些域名的注册信息时，我们发现其中部分域名已经被MIRAI作者注册，列表如下：





图0, 已经被注册的DGA域名


值得一提的是，作者 dlinchkravitz@gmail.com在更早时间已经注册了其他mirai C2域名：


 * zugzwang.me email dlinchkravitz@gmail.com



样本和分析


本博客中用作说明的样本如下：




 * MD5: bf136fb3b350a96fd1003b8557bb758a
 * SHA256: 971156ec3dca4fa5c53723863966ed165d546a184f3c8ded008b029fd59d6a5a
 * File type: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
   
   


样品做了去符号处理但未加壳。根据以分析mirai样本经验，我们很快就确定了其主要模块。比较代码发现，resolv_cnc_addr函数的CFG（流程控制图）与先前发现的样本非常不同。 新版本的CFG如图1所示。




图1, 新版本的resolv_cnc_addr 流程控制图


在函数开始处，由于在样本中硬编码了多达3个C2域名，所以生成随机数以从第一和第二个C2域名中随机选择一个，如图2所示。




图2, resolv_cnc_addr 函数第一部分


如果被选中的C2域名无法解析，则bot并不解析未选择的域名或第三域名，而是将根据当前日期判断是决定是否去执行DGA代码分支还是去解析第三个C2域名，如图3。




图3, 决定是否进入DGA 代码分支


从上述代码片段我们可以看出，如果当前日期在11月1日和12月3日之间，将去解析第3个C2域名。否则将执行DGA代码分支。这可以理解为作者不希望DGA域名在12月4日之前被启用，这也恰好被前文提及首个被注册的mirai DGA域名对应于12月4日所映证。

DGA主函数名为dga_gen_domain。域名完全是基于种子数字和当前日期生成的。种子通过调用strtol（）从硬编码的十六进制格式字符串进行转换。看起来字符串“\x90\x91\x80\x90\x90\x91\x80\x90”是一个错误的配置，这会导致strtol（）总是返回0。

代码中通过调用time（）和localtime（）的C库函数得到本地日期。但只有月和日被使用，如图4所示。




图4, dga_gen_domain 函数片段


L2域名是通过反复执行图5所示的代码块来生成的。其长度由$ t5和$ t2确定，它们的值在图4中设置，从中我们可以确定L2域名长度是12。




图5, 生成L2域名的循环代码片段
TLD（Top Level Domain）由寄存器$S0中的残余值确定，如图6所示。 我们可以看到在这里使用了3个TLD。




图6, 确定TLD 的代码分支





IOC


目前，DGA相关的特性存在于如下样本，所有这些DGA样本中的种子字符串和算法都完全相同：


 * 005241cf76d31673a752a76bb0ba7118
 * 05891dbabc42a36f33c30535f0931555
 * 0eb51d584712485300ad8e8126773941
 * 15b35cfff4129b26c0f07bd4be462ba0
 * 2da64ae2f8b1e8b75063760abfc94ecf
 * 41ba9f3d13ce33526da52407e2f0589d
 * 4a8145ae760385c1c000113a9ea00a3a
 * 551380681560849cee3de36329ba4ed3
 * 72bbfc1ff6621a278e16cfc91906109f
 * 73f4312cc6f5067e505bc54c3b02b569
 * 7d490eedc5b46aff00ffaaec7004e2a8
 * 863dcf82883c885b0686dce747dcf502
 * bf136fb3b350a96fd1003b8557bb758a
 * bf650d39eb603d92973052ca80a4fdda
 * d89b1be09de36e326611a2abbedb8751
 * dbd92b08cbff8455ff76c453ff704dc6
 * eba670256b816e2d11f107f629d08494


样本中的硬编码C2域名如下：


 * zugzwang.me
 * tr069.online
 * tr069.tech
 * tr069.support


我们将密切关注DGA变种的后续变化，敬请关注后续更新。
关于 mirai 僵尸网络控制主机的数据分析

之前的文章中已经提及，我们的僵尸网络跟踪系统对mirai僵尸网络控制主机做了持续跟踪，并且在文章的结尾处，依据跟踪结果排除了僵尸网络操作者位于北京时区的可能。在这篇文章中，我们将进一步分析mirai僵尸网络的控制主机的行为和特征。之前文章链接如下：


http://blog.netlab.360.com/a-dyn-twitter-ddos-event-report-and-mirai-botnet-review/


目前为止，我们与安全社区合作共享了两位数域名上的超过50个mirai僵尸网络主控。但本文后面的分析仅针对360网络安全研究院独立发现的主控，即13个域名上的16个主控主机名，其中8个在持续对外发起攻击。


在时间线上，我们可以看到各主控随时间变化的注册、在DNS中首次出现、持续保持IP地址变化、首次被监控到发起攻击等事件。地理分布方面，主控的IP地理分布主要在欧洲和美国，尤以欧洲为甚，亚洲很少，这从侧面增强了之前“mirai控制者不在北京时区”的判断。


域名注册信息方面，绝大多数主控在域名注册时在TLD、注册局、注册邮箱方面设置了多重障碍阻滞安全社区的进一步分析。


主控中一个特例是santasbigcandycane.cx，这个域名随着mirai源码泄漏而暴露在大众视野中。KrebsOnSecurity 对这个域名做了深入而有趣的探索。感兴趣的读者可在读完本篇文档后阅读：

https://krebsonsecurity.com/2016/10/spreading-the-ddos-disease-and-selling-the-cure/#more-36538


【所分析的mirai控制端列表】


到目前为止，我们独立发现了16个僵尸网络主机名，分布在13个域名上，如下表所示。出于安全考虑，我们掩去了关键信息。




除了少数两个特例以外，绝大多数主机名所属域名下的所有其他主机名也都完全为 mirai 服务，可据此判定绝大多数域名是专门为了mirai而申请注册的。


特例之一是santasbigcandycane.cx，前文已述；特例之二是 contabo.host ，这个域名属于 Contabo.com，是一家提供低成本虚拟主机和Web空间的网络提供商。合理推测这是一台被攻破的虚拟主机，攻破后被用作mirai的控制端。


注：域名指在注册局注册的域名，主机名指域名所有者获得域名控制权后分配的子域名。


【mirai主控的时间变化情况】


回溯Mirai控制端的活动历史，可以绘制mirai控制端的活动时间线如下图。考虑到大家主要关注mirai近期活动，我们缩放了下图时间轴，主要显示9月1日至今（10月27日）。




图中，四个图标分别表示域名注册、主机名在DNS系统中活跃的时间、主机名在DNS系统中发生IP地址变化、跟踪到该主机名发起攻击。图中部分时间线看起来有些古怪，但都是我们观察到的真实物理世界的反应。尤其最后一个主控，我们无法追踪到最初的注册时间，目前能查到的注册时间在其DNS首次出现时间之后。


从上图中可以看出域名一旦启用（观察到参与攻击）会快速更换IP地址，一般可以判定这是攻击者在逃避安全社区的分析。以某个被认为发起了针对本次 dyn / twitter 攻击的mirai主控为例，下表是该主控的IP变化历史：




图中还可以看到我们累积监控到8个主控对外发起攻击。时间可以回溯到2016年10月18日，并一直持续到当前。另外由于mirai僵尸网络规模特别大，单个主控要应对的bot较多（合理推测数目在万级），我们有理由相信mirai主控与bot之间的通讯模型与既往其他僵尸网络都有所不同。


【mirai主控的IP地理分布】


之前社区里关于这些域名的IP地址变化有一种说法，认为 “某个mirai主控变换IP地址后，原先的IP地址上会出现一个新的域名，仍然是mirai主控”，即不同主控之间共享IP地址。在我们的数据中，上述情况完全没有出现。

前文已经提到这些域名在快速的变换IP，我们持续跟踪的16个主控目前为止一共使用了98个IP地址，其中活跃的8个主控一共使用了57个IP地址。这些IP地址的国家和地区分布如下：



可以看出绝大部分IP分布在欧洲和北美（巴尔及利亚，加拿大，丹麦，法国，德国，匈牙利，意大利，荷兰，罗马尼亚，俄罗斯，苏伊士，英国，美国），其中又以欧洲为甚，分布在亚洲区的只有3个。这从侧面增强了之前“mirai控制者不在北京时区”的判断。


【mirai主控的域名注册信息】


Mirai的控制者在域名注册方面非常小心，以避免被跟踪。一方面选择很少见的新Top Level Domain（TLD），另一方面所使用的注册邮箱、注册局也都强调隐私保护或者很难继续追踪。


TLD的分布上，较少用常见的 .net .org 。 .xyz .work这样的TLD就已经少见，而 .racing 这样就 是更加罕见了。全部域名在常见 TLD (.net .org)上只有23%（=3/13），即使加上上.ru也不超过50%，如下图所示：




注册邮箱和注册局方面情况如下。同样出于安全考虑，我们掩去了关键信息。




这些注册邮箱都比较难以继续追溯下去：Protonmail 是专门强调数据安全的邮件服务商，reg.ru, r01.ru,whoisguard.com 是专门做域名隐私保护的公司，contabo是VPS提供商，freenom运营了大量免费域名。


特别要提及，info@namecentral.com 这个注册局很特殊，在上文提到的krebsonSecurity 连接中，Krebs提到这个注册局上注册的30+域名中大多含有 boot/stress/dos 这样的字眼，通常这暗示域名从事ddos出租服务；Krebs提到的另一个疑点是这个注册局注册的域名太少，无法做到收支平衡。Krebs与注册局的所有者取得联系，对方对Krebs的疑问有所回答，这更进一步加强了Krebs的疑虑。如果您已经读到这里，我们强烈建议您去阅读原文。
RSA大会 '2017上的ScanMon

RSA大会 '2017 即将在2月13日至17日期间在美国旧金山Moscone中心举办。在今年的这次大会上，我们向全世界安全社区推出我们的 ScanMon 系统。


网络扫描是互联网上一种流行的威胁，经常被攻击者用来发现网络空间里存活的主机或者服务，并随后可能被用来定位潜在的受害者。扫描行为通常发生在恶意攻击行为的早期，所以如果能及早发现扫描行为会对抵御对应的攻击有显著改善。


360网络安全研究院的 ScanMon 系统提供全球范围内实时和历史扫描行为的监控和分析。ScanMon 通过分析大量多样的网络数据，包括但不限于网络流、蜜罐等等，来精确有效的检测扫描行为。对已检出的扫描事件，ScanMon 会展示扫描行为的关键信息和统计数据，例如扫描源IP、受害者端口、扫描数量、分布、扫描源之间的伴生关系，等等。基于这些信息，使用者可以第一时间感知网络扫描行为，并方便有效的识别对应的攻击者。例如，近期360网络安全研究院在针对 mirai 僵尸网络出现、发展、新变种的持续跟踪中，就大量借助了 ScanMon 的能力。


您可以在这里观看在线视频（记得调到1080P），也可以试用我们的在线系统。


该系统免费开放，希望能帮助到安全社区。我们也欢迎任何人提供有用的反馈，或者向我们贡献数据以增强系统数据来源的多样性。


另外，今年我们还会在360展台有一个简短的mirai僵尸网络相关演讲。如果您恰好有兴趣，欢迎来参加。时间和地点，2月14日下午14：30～15：00，#S745。
Netlab‘s ScanMon at RSA Conference 2017

The RSA Conference 2017 will be held during Feb 13 - 17 at Moscone Center, San Francisco. This year in the conference, we will introduce our Network ScanMon system to global security community.


Network scanning is a prevalent threat in the Internet. It can discover active hosts or services in cyberspace, thus often be used by attackers to locate potential victims. Scanning activities usually appear at the initial stage of malicious attacks, so it would be helpful to fight against those attacks if we can detect scanning behaviors earlier.


Qihoo 360 Network ScanMon system is a platform that provides both realtime and historical overviews of network scanning activities all over the world. ScanMon detects scanning behaviors effectively and accurately by analyzing large amounts of various network data, including but not limited to Netflow, Honeypot, etc. For those detected scanning events, ScanMon will intuitively show their key information and as well as useful statistics, such as scanner SrcIP, victim DstPort, scanning volume, distribution and correlation of scanners, etc. With these information, users are able to perceive network scannings in the first time and identify the corresponding attackers quickly and conveniently. As an example, 360 Netlab recently used ScanMon to help to monitor the emergence of Mirai Botnet and investigate the evolution of its scanning behavior. You can watch the online video (remember to choose HD 1080p), or check out the live system.


The system is free and open to security community. We hope it will help and also we will appreciate anyone giving useful feedbacks or willing to contribute more network data to improve the system.


Also, this year we will give a talk on mirai botnet at 360 totoal security booth. Feel free to stop by and chat with us on Feb 14 14:30 - 15:00, #S745.
比较“81端口的botnet”和 MIRAI 之间的联系

概述


从 "81 端口的异常流量"中，我们发现了一个新的僵尸网络家族，它和 MRIAI 存在一定的联系，本文将介绍一些对比结果，同时介绍一下我们从这个 botnet 中发现的一种依赖SSDP协议的感染机制。


****注：*如无特殊声明，MIRAI的分析将以github源码为基础；新botnet 将以其中的9584B6AEC418A2AF4EFAC24867A8C7EC样本的逆向结果为基础。



相同点



相同的扫描方案


众所周知，MIRAI在传播过程中用到了SYN端口探测的技巧，来提高传播效率。新Botnet 也使用了该技巧并将其用在了81端口扫描中。随着研究的深入我们发现它和MIRAI有着相同的扫描规则。

在 MIRAI 中，被扫描IP是通过一系列随机函数生成的，但他有个黑名单机制，用于跳过一些IP地址范围（代码来自scanner.c），相关截图如下：





而在我们发现的 新Botnet 中（截图选自sub_A7C4函数），也有完全相同的黑名单机制（上下两图红框中是三行比对样例，实际上整个 while 循环体都是完全一致的）。






部分util函数同源


当我们将 新Botnet 和 MIRAI 进行汇编指令级别对比时，可以很清晰的发现，它们之间的少部分函数具有高度的一致性。






不同点



配置C2的区别


在公开的 MIRAI 源码中，用了 一个异或加密算法 来保护 C2 域名，并将 C2 以密文形式编码在原始代码之中，相关代码可参考 table.c 的 table_init 函数，其截图如下：





而在 该 Botnet 中，却是直接的明文字符串编码，相关截图如下：





值得一提的是，域名 ntp.gtpnet.ir 现阶段的解析目标为一个内网地址。

在此种情况下，攻击者是无法对僵尸网络进行正常控制的，且解析方式也不同于BlackHole（即域名的控制权仍然掌握在管理者手中）。

我们推测产生这种状态的原因有两种可能：


 1. 管理者发现僵尸网络暴露了，切断了解析以防被追踪。
 2. 管理者正在进行新版本的研发和测试，而网络上有大量的被控端，它们会对测试造成干扰，把解析目标设置到自己可控的内网地址后，可以很方便的排除干扰。



传播方式的区别


在所有公开的 MIRAI 源码中，只有弱口令扫描一种传播方式，在 MIRAI 的已知变种中，出现过利用7547/5555/6789/37777等端口传播的情况，关于 MIRAI 更多的跟踪细节可以参考 Mirai Scanner主页。


而 81 端口却从未发现过传播的 MIRAI 的先例，这是 新Botnet 独有的传播方式，“新威胁报告：一个新IoT僵尸网络正在 HTTP 81上大范围传播” 记录了和其有关的更多内容。



通讯协议的区别


MIRAI 的通讯协议可以从 attack.c 文件的 attack_parse 函数获取到。


而在 新Botnet 中却采取了一套全新的指令系统，相关内容可以用下表来表示：





攻击向量的区别


在原版 MIRAI 中，拥有包括 GRE 攻击在内的 10 种 ddos 攻击向量可供选择，相关证据可以参考 attack.h 文件中的相关定义，下面是一张截图证明：





而在 新Botnet 中，只存在两种 UDP-flood 攻击向量，可供选择，具体证据可参阅“通讯协议的区别”章节提供的表格。



更多关于 新Botnet 的细节



除 81 端口外还存在其他传播方案


虽然 新Botnet 是从 81 端口上被披露出来的，但其内部还包含有一个备份的传播方案，它似乎还没有被使用过。


00 04 02 是该传播方案对应的指令码。这是一个基于 “SSDP协议+UPnP实现漏洞利用” 的传播方案，传播将基于 1900 端口。其发送的第一个探测包内容如下：




M-SEARCH * HTTP/1.1
HOST:239.255.255.250:1900
ST:upnp:rootdevice
MAN:"ssdp:discover"
MX:3




这是 SSDP 协议的第一个请求包（函数地址 0x0000A918），当目标可以处理 SSDP 时，则进入 SSDP 交互逻辑，进而获得更多的智能设备信息及相应控制方法，当发现潜在 CVE-2014-8361 漏洞（Realtek SDK Miniigd UPnP SOAP Command Execution）的设备时(识别关键字:52869/picsdesc.xml)，尝试发送 CVE-2014-8361 对应的 payload 完成一次试探性传播（函数地址 0x0000A458）。


当存在漏洞的服务无法从外网直接访问时，扫描器将会通过调用拥有“AddPortMapping” 功能的函数（函数地址 0x0000AE20）建立一个端口映射，并通过新映射的端口来完成试探性payload投递。



UDP-Flood 的网络特征


该样本支持两种UDP-flood 攻击，分别为 00 06 和 00 08。


其中 00 06 对应的 flood 内容同 SSDP 探测包相同，截图证明如下：





而 00 08 对应的 flood 内容为：






回顾


本文从逆向样本出发，详细阐述了 新Botnet 和 MIRAI 之间的2个相同点和4个不同点。


相同点


 1. 相同的扫描方案
 2. 部分util函数同源


不同点


 1. 配置C2的区别
 2. 传播方式的区别
 3. 通讯协议的区别
 4. 攻击向量的区别


虽然 新Botnet 和 MIRAI 之间存在一定的共同点，但从 Botnet 识别的角度来看，这些不同点均为识别 Botnet 的重要指标，我们没有理由将其归类为 MIRAI 的变种，而应当把它当做一个全新的 Botnet 家族。
IoT_reaper 情况更新

在周五晚上披露了IoT_reaper之后，我们收到了来自安全社区和各方很多问题。这里给出一个快速的更新，以澄清各方可能的疑问。



IoT_reaper样本投递历史情况


我们通过蜜罐观察到的 IoT_reaper 样本历史投递情况如下：





可以看出，IoT_reaper 最主要传播的恶意代码位于下面这个URL上：


 * 下载地址：hxxp://162.211.183.192/sa
 * 投递者：119.82.26.157
 * 起止时间：10-04～10-17
 * 样本md5：7 个,详细见文末IoC


这个URL上的样本之间内聚关系比较强，我们称为S簇。


后来进一步的分析，认为S簇还包括其他一些样本；而在S簇之外，还有一个LUA簇，以及其他更小一些的未知簇。



S簇的样本构成


我们认为S簇包含下面这些URL上的样本：


 * hxxp://162.211.183.192/sa
 * hxxp://162.211.183.192/sa5
 * hxxp://162.211.183.192/sm
 * hxxp://162.211.183.192/sml


簇内的命名策略可能是这样的，头部的s代表S簇：


 * sa: arm
 * sa5：arm5
 * sm：mips
 * sml：mips 小端



S簇的C2 布局、感染机制和数字疑问





如上图：


 * loader : 负责通过漏洞植入恶意代码
 * downloader : 提供恶意代码下载
 * reporter : 接收bot扫描到的易感染设备信息
 * controller : 控制bot、发送控制指令
 * 我们猜测，在reporter 和 loader 之间有一个队列，reporter会将收集到的易感染设备信息推入队列，等待loader处理


与 S 簇感染相关的有一组不同的数字，近日来容易引起安全社区的混淆。我们看到的数字如下：


 * 已经汇报到单台 reporter 的易感染设备数：超过2m，到 2017-10-18 为止；
 * 单台 controller 累积控制设备数：超过28k，到 2017-10-24 为止；


这两个数字之间有 显著差距，原因尚不明确。这可能是因为攻击者的实现导致在队列中加入了大量的不存在相应漏洞的设备, 或者是攻击者的 loader 处理能力不足而被动积压，也有可能是攻击者主动抑制了感染速度以减少暴露风险，或者是因为其他我们不得而知的原因。



S 簇单台 C2 感染情况统计（2017-10-13 ～ 2017-10-23）


时间分布：





国家分布:





被感染的前十国家:





与 mirai 初期感染情况对比






S簇的近期样本变化情况


我们会监控视野范围内样本变化情况。在10月23日，我们检测到S簇的如下URL内容发生变化：


 * hxxp://162.211.183.192/sa


变化情况如下表所示：





在原始报告的“样本的投入、C2 的布局和流量变化”一节已经提及：这是一个恶意代码样本，被控制者放置在downloader服务器上，被loader服务器投递，投递成功后会向controller报告心跳，启动扫描并将扫描到的易感染设备信息报告给reporter。


我们仔细观察更新后的样本发现：


 * 新集成了一个新的漏洞利用 :http://roberto.greyhats.it/advisories/20130227-dlink-dir.txt
 * 心跳会指向 e.hl852.com/e.hl859.com
 * 样本中内置了9个硬编码的IP地址，扫描时，扫描目标地址会包含；
 * 上述9个IP地址上有共计 34个端口会被频繁扫描：其中17个端口是硬编码的，样本会随机扫描其中的部分；另外17个端口虽然会被频繁扫描，但是并未被直接硬编码到样本中。我们推测样本中隐藏了某段逻辑来扫描后面17个端口。


这第十个漏洞利用在样本中的调用过程：





上述9个硬编码的IP地址是：


217.155.58.226
85.229.43.75
213.185.228.42
218.186.0.186
103.56.233.78
103.245.77.113
116.58.254.40
201.242.171.137
36.85.177.3



对应的，我们可以观察到大网上这9个IP地址的流量在上述时间点以后开始增加：





34 个硬编码、没有硬编码但是会被扫描的端口号：






S 簇的 C2 DNS流量变化


S 簇先后使用了下面一组C2，对应的 DNS 流量图见后


 * e.hi8520.com：对应图中最上方蓝色曲线；
 * e.hl852.com：对应图中中间绿色曲线；
 * e.ha859.com：对应途中底部黄色曲线；





IoC

hxxp://162.211.183.192/sa 41ef6a5c5b2fde1b367685c7b8b3c154

hxxp://162.211.183.192/sa f9ec2427377cbc6afb4a7ff011e0de77

hxxp://162.211.183.192/sa 76be3db77c7eb56825fe60009de2a8f2

hxxp://162.211.183.192/sa5 95b448bdf6b6c97a33e1d1dbe41678eb

hxxp://162.211.183.192/sa e9a03dbde09c6b0a83eefc9c295711d7

hxxp://162.211.183.192/sa 3d680273377b67e6491051abe17759db

hxxp://162.211.183.192/sa 726d0626f66d5cacfeff36ed954dad70
CLDAP反射放大攻击超过SSDP和CharGen成为第三大反射型DDoS攻击

作者：Xu Yang，kenshin


利用DDoSMon.net，我们实时并持续的监控全球DDoS攻击相关事件。长期以来，DDoS攻击的反射放大细分类型中，DNS、NTP、CharGen、SSDP是最经常被滥用的服务，过去一年中的排位依次是第1、2、3、4位。


近期我们注意到， 基于CLDAP的 反射放大攻击（以下称为CLDAP攻击）已经超过SSDP和CharGEN成为第三大反射型DDoS攻击。CLDAP攻击在过去365天和90天在反射放大类DDoS攻击中占据比例，对比如下图：





数据来源：DDoSMon。网站上Insight页面的内容可以覆盖本次blog中的大部分数据。


CLDAP攻击首次出现是在去年10月底，到现在恰好一年。本篇blog中，我们对CLDAP攻击上升情况做一个回顾：


 * 在过去的一年中，我们累积观察到304,146次CLDAP反射放大攻击，涉及215,229 个独立IP，或者说受害者。CLDAP早已经成为现实存在的DDoS攻击威胁。
 * 值得注意的是，最近两三个月以来，CLDAP攻击发展进入新的阶段。在我们的监测范围内，过去三个月内CLDAP攻击次数累积达到168k(11.2%)次，略超过CharGen （164k次，11%），大幅领先SSDP（70k，4.4%）。


我们OpenData中的DRDoS数据中包括了CLDAP在内的最近一月的TOP反射点IP，符合条件的安全研究人员可以免费通过 netlab@360.cn 申请数据下载权限。



阶段划分





上图是过去一年中每周CLDAP攻击的次数，反映了CLDAP攻击的活跃程度。


回顾过去一年中CLDAP攻击，我们可以比较清晰的将过去一年划分为三个阶段：


 * 初始阶段：2016年10月底开始出现到2017年4月初，周均攻击1000次左右
 * 第一次爬升阶段：2017年4月初到2017年8月底，周均攻击次数6000次左右
 * 第二次爬升阶段：2017年8月底至今，周均攻击15000次左右


我们认为，CLDAP攻击在经历了早期的起伏后，在最近两三个月已经进入一个相对稳定的发展阶段。


另一方面，我们在观察反射点的重用程度时，也注意到了类似的时间阶段划分。数据同样表明最近两三个月是一个稳定发展的阶段：






攻击向量组合


在所有CLDAP攻击中，单一的CLDAP攻击方式目前仍然是主流。如下表，单一CLDAP攻击向量占据超过84%的比例；剩下的是CLDAP与其他攻击向量混合的攻击，共计占据大约15%的比例。






持续时长分布


CLDAP攻击的持续时长变化比较大：最短的攻击小于1分钟，最长攻击我们曾经观察到持续超过3天。如下图所显示，1、2、3个标准差（68%, 95%, 99.7%）对应的攻击时长分别是30分钟、10小时和24小时。





上文提到的长达3天的攻击，发生在2017-09-24 15:00:00～2017-09-28 09:00:00之间。受害者IP地址(151...15)属于某CDN厂商。






目的端口分布


受害者目的端口的分布如下表所示:


 * 绝大部分CLDAP攻击的目的端口是随机化的，与一般情况一致。通常而言，反射型DDoS攻击中的目的端口是攻击者可以随意控制并篡改的，目的端口随机化是普遍现象。
 * 但是在80端口和 26383 端口上可以观察到有两个显著的波峰，特别是 26383 端口并不是一个常用端口。这也许是因为某个特定的CLDAP攻击工具或者攻击服务提供商被很多攻击者使用，从而在攻击中反复出现。
openload.co 等网站绕过 CoinHive 使用客户端浏览器算力挖取门罗币

从2017年12月24日，我们注意到一组网站正在滥用客户终端浏览器的算力在挖矿。攻击者在利用了 CoinHive 的浏览器端挖矿代码基础上，完全绕过 CoinHive 自己运营，避开了 CoinHive 的抽成费用。提供挖矿服务的域名成组出现，共计22个，最早活动时间是2017-11-29。


涉及使用上述挖矿服务的网站，包括openload.co，oload.stream，thevideo.me，streamcherry.com，streamango.com。其中，openload.co 网站的Alex排名为136，流行程度非常高，这意味着全球范围内有较多的终端用户算力会被攻击者攫取。


5个异常域名


dnsmon 是我们的dns异常检测系统。在2017-12-24日，系统报告了一组域名的访问异常，这组域名和对应的访问曲线如下：


do69ifsly4.me
hzsod71wov.me
kho3au7l4z.me
npdaqy6x1j.me
vg02h8z1ul.me






上图中可以注意到域名访问曲线惊人的一致，这意味着不同域名之间，很可能被同源的流量驱动。我们可以利用 dnsmon 进一步探查这些流量来自哪里。如下图所示，不仅前述5个域名之间总是紧密相连，还有一个 streamcherry.com 也总是与之一起出现。





streamcherry.com 与这些异常域名之间的关系


要继续探寻 streamcherry 与上述域名之间的关系，需要我们离开 DNS 世界，寻找更多的数据来支撑。外面的世界很精彩，手段也多种多样，这次我们可以运用来自 Virus Total 的URL数据关联到下面一组URL：





使用浏览器打开这组 URL 时候，可以看到浏览器会去访问 do69ifsly4.me ，前述五个异常域名之一。





进一步的，可以观察到前述全部5个异常域名是对等的，均对外提供了 WebSocket服务。这个关联体现在 hxxps://do69ifsly4.me/v.js 中，在经过多轮次的解码去混淆后，可以找到如下代码片段





源自 CoinHive， 走出 CoinHive


等一下......这段代码的结构为什么跟 CoinHive 的挖矿代码看起来这么一致。


下图中js代码片段左侧来自streamcherry，右侧来自 CoinHive。在 CoinHive 的上下文中，这段代码是要指定挖矿代码上联的服务器地址。





有必要为那些还不了解 coinhive.com 的读者插入一段 CoinHive 平台的介绍。CoinHive 提供了利用浏览器端 javascript 算力挖取门罗币的能力，并建议网站站长引用 CoinHive 的代码，这样网站站长就可以利用自身网站客户的浏览器的算力来挖取门罗币。它们的哲学是，有了门罗币的收入，网站站长就不用在自己的网站上塞入广告，这会有助于提高客户的体验。最后，CoinHive 会“公平”的取走 30% 的门罗币收入。


由于会使用到客户终端的CPU算力，一般认为网站站长应该明确的提示用户，并在获得用户许可的前提下开始使用挖矿，否则可以认为滥用了客户端算力。在这个例子里，我们查看了 streamcherry 的多个页面，并没有看到提示使用客户端算力的地方。


回来继续比较代码。下面这段代码是挖矿对象的创建和启动过程，两边的代码结构也是类似的。同样 streamcherry在左，CoinHive 在右。





继续比较代码。下面这段是挖矿对象的内部实现，两边代码也是类似的，注意这里会涉及几个比较关键的属性列举如下。照例 streamcherry在左，CoinHive 在右。


 * sitekey: 重要属性，CoinHive 使用这个key来标记不同的网站来源，其意义类似于挖矿矿工的银行账户；
 * throttle: 重要属性，浏览器占用CPU的阈值，调节到合适的阈值时，用户会很难注意到浏览器的算力被滥用，引入这个阈值的本意是在用户体验和网站收入之间取得平衡；
 * autothreads: 相对重要，是否允许自动调节线程数目。





由于 streamcherry 调整CPU阈值，我们在浏览器中打开页面时，并不会感觉到明显的卡顿。为了确认上述代码的确会被执行，我们手工在 javascript 代码中挖矿对象被调用的前后加上弹窗告警。重新运行时，的确两个告警都会被运行，这证实了挖矿对象的确在运行。两个告警和手工调整的javascript代码如下：





总体而言，我们认为 streamcherry 从 CoinHive 网站上获取了代码，并且调整了挖矿算力阈值，在未告知客户的情况下，使用客户端浏览器的算力挖掘门罗币。当前的这种方式完全不经过 CoinHive，也绕过了 CoinHive 主张的 30% 的“公平手续费”。


使用这组挖矿服务的网站中有 Alexa 排名 136 的 openload.co


正如 CoinHive 使用 sitekey 来标记不同的网站来源，streamcherry 也使用了 sitekey。这促使我们进一步检查还有哪些其他网站也使用相同的代码和机制。


我们目前能看到四个网站使用了这些代码，如下。其中值得一提的是 openload.co 在 alexa 上的排名在136位，这让我们觉得这段代码的影响范围较大，值得撰写本篇文章提示社区。


openload.co
oload.stream
thevideo.me
streamcherry.com
streamango.com






提供挖矿服务的域名成组出现，共计22个


提供了前述挖矿服务的域名不止前述 5 个，基于 dnsmon 我们进一步寻找到成组出现的22个。详细列表见后面的 IoC 部分。


下面的两张图，分别列出每天有哪些域名活跃，以及全部域名的流行程度排名。








总结这些挖矿服务域名的特点：


 * 最早出现在 2017-11-29；
 * 这些域名的访问流行度不算低，并且随着时间推移流行程度持续上升；
 * 新域名定期出现，同时老的域名仍然被使用；
 * 共计22个域名中的20个域名是5个一组的，2个域名例外。我们追溯了 javascript 代码，确认WebSocket服务列表包含了7个域名；
 * 域名看起来有点类似 DGA ，但是跟既往常见恶意代码的 DGA 生成和使用机制并不相同。


IoC


提供挖矿服务的域名


0aqpqdju.me
5vz3cfs0yd.me
6tsbe1zs.me
8jd2lfsq.me
aqqgli3vle.bid
avualrhg9p.bid
c0i8h8ac7e.bid
do69ifsly4.me
fge9vbrzwt.bid
hzsod71wov.me
iisl7wpf.me
kho3au7l4z.me
npdaqy6x1j.me
ny7f6goy.bid
r8nu86wg.me
uebawtz7.me
vcfs6ip5h6.bid
vg02h8z1ul.me
vjcyehtqm9.me
vl8c4g7tmo.me
xgmc6lu8fs.me
zgdfz6h7po.me



使用上述挖矿服务的网站


openload.co
streamcherry.com
streamango.com
thevideo.me
thevideo.me