关于 dyn / twitter  受攻击情况的说明和 mirai 僵尸网络的回顾
<!--kg-card-begin: markdown--><p>【更新记录】</p>
<p>2016-10-23 初始版本<br>
2016-10-27 获得了少量攻击现场数据，分析结果与之前观点吻合一致。</p>
<p>北京时间2016年10月21 日晚间，北美地区大量反馈若干重要的互联网网站无法正常访问。涉及到的网站包括 twitter， paypal，github等等，由于这些网站与北美地区日常生活强烈相关，这次网络故障被北美主要媒体广泛报道，也引起了安全社区的强烈关注。我们与国外安全社区一起协同，对本次网络事件提供数据、加以分析并做了溯源跟踪。</p>
<p>目前我们已经能够确定本次事件是一次DDoS网络攻击事件，攻击目标主要是Dynamic Network Services（dyn）公司，twitter、paypal、github等网站作为dyn公司的客户，在本次攻击中不幸被波及。<br>
在攻击持续溯源的过程中，虽然目前Flashpoint公司已经确认最近广泛受关注的mirai僵尸网络参与了本次网络攻击，但是我们倾向认为虽然mirai贡献了本次攻击的部分攻击流量，但并非所有的攻击流量都来自原始泄漏版本mirai。具体来源不明，可能是源自我们数据地缘性导致的分析误差，也可能是来自mirai的变种或者混合模式的DDoS攻击。</p>
<p>2016年10月27日更新：在安全社区的帮助下，我们获得了少量攻击现场的数据，证实了之前分析中的若干观点：攻击手段中包含 syn flood，真实源IP，小包，这些真实 bot IP 在我们到今天为止的bot IP 列表中命中率大约33%；攻击手段中包含dns flood，使用伪造源IP，可以断定这部分攻击不是有mirai发起，至少不是泄漏版本mirai发起。所有这些现象与我们之前的观点吻合一致。</p>
<p>【攻击受害者的判定和影响范围的评估】</p>
<p>接到反馈后，我们很快认定攻击受害者是twitter.com使用的域名服务器，而非 twitter.com paypal.com 的Web服务器直接遭受攻击。</p>
<p>dyn公司是知名的网络域名服务提供商，本次攻击中受影响的twitter等多个著名公司都是dyn公司的客户。Dyn公司使用了四个域名/IP为twitter提供域名解析服务，这四个IP分布在四个C类段或者两个B类段中，传统上这是一种常见的网络负载均衡手段。四个IP地址如下表所示。</p>
<p><img src="__GHOST_URL__/content/images/2016/10/table_01_direct_victim.png" alt="" loading="lazy"></p>
<p>在本次事件中，四个IP地址在当天19：00～22：50期间的网络流量波形图如下。峰值达到日常背景流量的20倍，可以判定发生了流量攻击。<br>
<img src="__GHOST_URL__/content/images/2016/10/01_direct_target_flow_chart.png" alt="" loading="lazy"></p>
<p>在我们数据基础上进一步的分析指出，攻击者的攻击手段是混合使用DNS_flood和 syn_flood，结合公开媒体的报道，我们推断这组攻击得手，这组服务器不再对外提供服务，twitter.com  网站在这段时间内也无法访问。以上是攻击的直接受害者。<br>
<img src="__GHOST_URL__/content/images/2016/10/table_02_ddos_vector.png" alt="" loading="lazy"></p>
<p>但是除了twitter还有大量网站例如 paypal.com 和  github.com也无法访问，我们推断这是由于上述攻击造成的波及效应。如下表所示，paypal和github也是DYN的客户。</p>
<p><img src="__GHOST_URL__/content/images/2016/10/table_03_sympathatic_victim.png" alt="" loading="lazy"></p>
<p>dyn为每个重要客户提供四组地址，分布在四个C类段中，如前所述，这是一种传统的网络负载均衡手段。但是在这个结构中，如果四个网段同时遭到大流量的网络攻击，则全部四个段的客户都会受到影响。</p>
<p>我们认为在本次事件中就发生了这种情况，大流量针对 <em>.34/twitter的攻击影响到了同网段不限于 <em>.15/github、</em>.57/paypal服务器的网络流量，最终 github/paypal和twitter一同暂时无法访问。不仅是以上列出的三家网站，其他该网段的客户也会受到影响，比如</em>.5/playstation.net；而如果一个网站不使用dyn的域名解析服务则不会受到影响，比如 wikileak。</p>
<p>在我们的分析中，我们也注意到  github.com 的Web服务器在当天早些时候遭受了直接的DDoS攻击，但是我们不认为那次攻击可以解释整体大范围的安全事件，也并未深究个体事件与整体事件背后的关系。<br>
以上攻击信息可以通过  <a href="https://ddosmon.net/explore/your.target/">https://ddosmon.net/explore/your.target/</a> 来验证。部分链接如下，读者可以根据需要自行调整查询。<br>
<a href="https://ddosmon.net/explore/twitter.com/">https://ddosmon.net/explore/twitter.com/</a><br>
<a href="https://ddosmon.net/explore/github.com/">https://ddosmon.net/explore/github.com/</a><br>
<a href="https://ddosmon.net/explore/paypal.com/">https://ddosmon.net/explore/paypal.com/</a><br>
<a href="https://ddosmon.net/explore/208.78.70.34/">https://ddosmon.net/explore/208.78.70.34/</a><br>
<a href="https://ddosmon.net/explore/208.78.71.34/">https://ddosmon.net/explore/208.78.71.34/</a><br>
<a href="https://ddosmon.net/explore/204.13.250.34/">https://ddosmon.net/explore/204.13.250.34/</a><br>
<a href="https://ddosmon.net/explore/204.13.251.34/">https://ddosmon.net/explore/204.13.251.34/</a></p>
<p>【攻击现场技术特征】</p>
<p>攻击现场有更多技术细节可供讨论，我们列举出部分认为重要的特点，供安全社区进一步分析，以期减轻攻击者对网络的影响。</p>
<p>时间窗口方面，本次攻击主要发生在北京时间2016年10月21日晚间19：00～22：50之间。</p>
<p>攻击手段方面，如前所述本次事件中主要是syn flood和dns flood。下面我们分析攻击的具体特征，并试图分析攻击与mirai泄漏版本/未知mirai变种/其他基于IoT的僵尸网络之间的归因关系。</p>
<p>关于本次攻击中的Syn flood部分，攻击发起的bot IP地址我们倾向认为是真实的。这些IP地址中有45%在最近有扫描23/2323端口的历史行为记录，这一点与mirai的行为相似。在安全社区已经公开的信息中，认为本次攻击流量特征符合Mirai的流量特点。综合以上两点，我们认为本次攻击中有Mirai或者其变种参与。但是对比这些Ip地址与已知mirai bot列表，只有&lt;2%的比例命中，这会一定程度上削弱“整体而非部分攻击由mirai发起”的说法，我们在后文试图引入不同的假设给予解释。</p>
<p>关于本次攻击中的 dns flood 部分，我们倾向认为发起的bot IP是伪造或者是非Mirai家族的。这些IP地址分布离散度直观上看并不高，并且没有历史扫描行为，探查部分IP的开放端口看起来也不像是IoT设备。再加上从泄漏版本的Mirai源码分析，原始版本的mirai 在发起dns flood攻击的时候不会伪造源IP地址，我们可以判定：要么这些IP地址是伪造的，那么一定不是原始版本的mirai；要么这些IP地址是真实的，那就与mirai的关系更远，甚至可能是其他任何僵尸网络发起的。</p>
<p>2016年10月27日更新：在安全社区的帮助下，我们获得了少量攻击现场的数据，证实了之前分析中的若干观点：攻击手段中包含 syn flood，真实源IP，小包，这些真实 bot IP 在我们到今天为止的bot IP 列表中命中率大约33%；攻击手段中包含dns flood，使用伪造源IP，这部分攻击可以断言不是由mirai发起，至少不是泄漏版本mirai发起。所有这些现象与我们之前的观点吻合一致。</p>
<p>以上IP地址和mirai/mirai变种之间的分析汇总如下表所示：<br>
<img src="__GHOST_URL__/content/images/2016/10/table_04_ddos_sip_attribute.png" alt="" loading="lazy"></p>
<p>多个公开的消息源还提到本次攻击中存在DNS变前缀攻击。这种攻击手段通常是针对域名解析服务器，本次攻击中的受害者正是如此。虽然在我们自有的数据中无法验证上述说法，按照我们对消息源既往的信任程度，我们认为这种说法的确成立。</p>
<p>综合起来在攻击手段方面，我们本次攻击中看到了syn flood 和 dns flood，并且相信有dns变前缀攻击存在。总体而言，我们虽然可以认定泄漏版本mirai贡献了本次攻击中的部分流量，但是无法将全部流量归结到泄漏版本mirai。加入不同的假设可以对现象做不同的解释：<br>
——也许是我们收集的bot IP 列表不全面；<br>
——或者我们看到的攻击流量不足以代表dyn在北美地区实际遭受的攻击；<br>
——或者是mirai产生了变种，并且参与了本次攻击；<br>
——或者是其他僵尸网络家族参与了本次攻击。<br>
目前为止我们无法用手头的数据或事实来选择任何一种假设继续深入。</p>
<p>botIP方面，部分bot IP 探测情况是光猫、网络摄像头和网关路由器，这可以验证近期安全社区对以maria为代表的基于IoT的僵尸网络的担心，也值得我们在这里呼吁各IoT设备厂商加强与互联网安全厂商的合作，共同增强网络空间中的安全感。</p>
<p>部分攻击源IP系统截图如下：<br>
<img src="__GHOST_URL__/content/images/2016/10/02_bot_system_list.png" alt="" loading="lazy"></p>
<p>【Mirai僵尸网络历史情况回溯和统计数据】</p>
<p>在2016年8月1日，我们设置的蜜罐第一次被未知扫描源扫中。在9月6日，我们意识到在2323端口上的扫描源有一个显著的spike，并在后续的时间里，我们与安全社区一起，对mirai的源码、扫描感染行为、攻击行为在流量特征、样本特征等方面做了持续的跟踪和分析。整体过程的时间线如下：<br>
<img src="__GHOST_URL__/content/images/2016/10/table_05_marai_traceback_timeline.png" alt="" loading="lazy"></p>
<p>蜜罐被mirai首次扫描到的时间是2016-08-01 12:46，如下图所示。对应的数据可以在下图附属的URL中获得，即2016-08-01～2016-08-08期间感染marai的bot ip数据。<br>
<img src="__GHOST_URL__/content/images/2016/10/table_06_marai_port23_scan_first_hit.png" alt="" loading="lazy"><br>
<a href="http://data.netlab.360.com/feeds/mirai-scanner/scanner.list">http://data.netlab.360.com/feeds/mirai-scanner/scanner.list</a></p>
<p>端口2323上的mirai扫描首次出现在 2016-09-06，如下图所示。2016-08-09及以后的数据，可以发邮件到 <a href="mailto:netlab@360.cn">netlab@360.cn</a> 申请。<br>
<img src="__GHOST_URL__/content/images/2016/10/table_07_marai_port2323_scan_first_hit.png" alt="" loading="lazy"></p>
<p>我们在9月6日观察到的在端口2323上的扫描源暴涨的情况，可以在下图中直观的观察到，或者可以在图下附属的URL中看到最近30天变化的版本。<br>
<img src="__GHOST_URL__/content/images/2016/10/03_spike_on_port2323_first_notice.png" alt="" loading="lazy"></p>
<p><a href="http://scan.netlab.360.com/#/dashboard?dstport=2323">http://scan.netlab.360.com/#/dashboard?dstport=2323</a></p>
<p>我们首篇关于marai的文章发表于2016年10月16日，在blog.netlab.360.com上。在这篇文章中我们提及了收集marai bot IP列表的基本原理和当时的数据统计情况：<br>
<a href="__GHOST_URL__/a-quick-stats-on-the-608-083-mirai-ips-that-hit-our-honeypots-in-the-past-2-5-months/">http://blog.netlab.360.com/a-quick-stats-on-the-608-083-mirai-ips-that-hit-our-honeypots-in-the-past-2-5-months/</a></p>
<p>我们在分析mirai泄漏源码的过程中，发现了mirai扫描模块的一些缺陷/特征，基于这一点我们可以通过检查syn包头部将mirai的扫描与其他在 tcp 23 和tcp 2323 上的扫描源做显著的区分。基于以上分析，我们在历史数据中将mirai的扫描活动可以一直回溯到首次命中时间2016年8月1日。<br>
进一步对Mirai的历史扫描做统计，使得我们有机会细致观察mirai的感染过程的不同阶段：</p>
<p>——8月1日开始，扫描感染过程发起，至9月6日以前，mirai仅扫描23端口。每日扫描源在2k～13k之间波动，中间两个波峰期每日扫描源维持在8k～11k上下，这段时间内每天大约90%～80%的扫描源是之前没有看到的；</p>
<p>——9月6日开始，mirai开始扫描2323 端口，与23端口相比，数量小了大约1个数量级。但此时扫描量相对较小，无论是23端口还是2323端口。</p>
<p>——9月16日到现在，mirai的扫描感染进入一个稳定的发展期，日均扫描IP稳定在16k~22k之间，全新扫描/botIP的比例从80%逐渐下滑到65%～55%区间以后下降速度非常缓慢。</p>
<p>——至2016年10月23日凌晨，累积观察到的mirai bot IP已经有大约720k。这是一个大规模的僵尸网络。</p>
<p>总体而言，marai僵尸网络目前规模已经有720k，这是个相当大的数字，再加上当前的规模扩张仍然保持高速且稳定，这让人相当不安。<br>
以上数据可以从下面两个图中直观的观察：<br>
<img src="__GHOST_URL__/content/images/2016/10/04_mirai_stats_01.png" alt="" loading="lazy"><br>
<img src="__GHOST_URL__/content/images/2016/10/04_mirai_stats_02.png" alt="" loading="lazy"></p>
<p>在来源IP的地理分布方面，我们观察到的bot主要来自 .vn .br .cn .in .co .ru。这五个国家和地区累积占据了我们视野中56%。<br>
<img src="__GHOST_URL__/content/images/2016/10/04_mirai_stats_03.png" alt="" loading="lazy"><br>
<img src="__GHOST_URL__/content/images/2016/10/table_08_marai_geo_distibute.png" alt="" loading="lazy"></p>
<p>我们已经建立了系统实时跟踪mirai僵尸网络，上述数字每日更新，可以在下列网址访问。这个网址上还有mirai的2016.08.01～2016.08.08的bot IP列表可供下载。更完整的bot IP 列表可以发电子邮件到 netlab@360.com申请。<br>
<a href="http://data.netlab.360.com/mirai-scanner">http://data.netlab.360.com/mirai-scanner</a></p>
<p>我们还进一步跟踪了mirai的攻击指令发送渠道。通过分析过去七天的指令发起时间，从时间分布上来看，指令的高峰期发生在北京时间 (GMT +8)的凌晨5：10～7：50之间，这不太符合这个时区既往僵尸网络操作者发出指令的时间，我们倾向于排除mirai的操作者来自北京时区（GMT +8）的可能性。<br>
<img src="__GHOST_URL__/content/images/2016/10/05_mirai_attack_cmd_timezone_distribute-1.png" alt="" loading="lazy"></p>
<p>分析过程中涉及到的工具系统均统一列出在 netlab.360.com，如下表。其中大部分的系统向公众开放，白帽子可以自行运用。部分数据不宜直接公开，仅向受信任的安全社区开放， 白帽子可以在取得我们信任的前提下申请访问。<br>
<img src="__GHOST_URL__/content/images/2016/10/table_09_marai_tracing_related_systems.png" alt="" loading="lazy"></p>
<!--kg-card-end: markdown-->
【更新记录】


2016-10-23 初始版本

2016-10-27 获得了少量攻击现场数据，分析结果与之前观点吻合一致。


北京时间2016年10月21 日晚间，北美地区大量反馈若干重要的互联网网站无法正常访问。涉及到的网站包括 twitter， paypal，github等等，由于这些网站与北美地区日常生活强烈相关，这次网络故障被北美主要媒体广泛报道，也引起了安全社区的强烈关注。我们与国外安全社区一起协同，对本次网络事件提供数据、加以分析并做了溯源跟踪。


目前我们已经能够确定本次事件是一次DDoS网络攻击事件，攻击目标主要是Dynamic Network Services（dyn）公司，twitter、paypal、github等网站作为dyn公司的客户，在本次攻击中不幸被波及。

在攻击持续溯源的过程中，虽然目前Flashpoint公司已经确认最近广泛受关注的mirai僵尸网络参与了本次网络攻击，但是我们倾向认为虽然mirai贡献了本次攻击的部分攻击流量，但并非所有的攻击流量都来自原始泄漏版本mirai。具体来源不明，可能是源自我们数据地缘性导致的分析误差，也可能是来自mirai的变种或者混合模式的DDoS攻击。


2016年10月27日更新：在安全社区的帮助下，我们获得了少量攻击现场的数据，证实了之前分析中的若干观点：攻击手段中包含 syn flood，真实源IP，小包，这些真实 bot IP 在我们到今天为止的bot IP 列表中命中率大约33%；攻击手段中包含dns flood，使用伪造源IP，可以断定这部分攻击不是有mirai发起，至少不是泄漏版本mirai发起。所有这些现象与我们之前的观点吻合一致。


【攻击受害者的判定和影响范围的评估】


接到反馈后，我们很快认定攻击受害者是twitter.com使用的域名服务器，而非 twitter.com paypal.com 的Web服务器直接遭受攻击。


dyn公司是知名的网络域名服务提供商，本次攻击中受影响的twitter等多个著名公司都是dyn公司的客户。Dyn公司使用了四个域名/IP为twitter提供域名解析服务，这四个IP分布在四个C类段或者两个B类段中，传统上这是一种常见的网络负载均衡手段。四个IP地址如下表所示。





在本次事件中，四个IP地址在当天19：00～22：50期间的网络流量波形图如下。峰值达到日常背景流量的20倍，可以判定发生了流量攻击。




在我们数据基础上进一步的分析指出，攻击者的攻击手段是混合使用DNS_flood和 syn_flood，结合公开媒体的报道，我们推断这组攻击得手，这组服务器不再对外提供服务，twitter.com 网站在这段时间内也无法访问。以上是攻击的直接受害者。




但是除了twitter还有大量网站例如 paypal.com 和 github.com也无法访问，我们推断这是由于上述攻击造成的波及效应。如下表所示，paypal和github也是DYN的客户。





dyn为每个重要客户提供四组地址，分布在四个C类段中，如前所述，这是一种传统的网络负载均衡手段。但是在这个结构中，如果四个网段同时遭到大流量的网络攻击，则全部四个段的客户都会受到影响。


我们认为在本次事件中就发生了这种情况，大流量针对 .34/twitter的攻击影响到了同网段不限于 .15/github、.57/paypal服务器的网络流量，最终 github/paypal和twitter一同暂时无法访问。不仅是以上列出的三家网站，其他该网段的客户也会受到影响，比如.5/playstation.net；而如果一个网站不使用dyn的域名解析服务则不会受到影响，比如 wikileak。


在我们的分析中，我们也注意到 github.com 的Web服务器在当天早些时候遭受了直接的DDoS攻击，但是我们不认为那次攻击可以解释整体大范围的安全事件，也并未深究个体事件与整体事件背后的关系。

以上攻击信息可以通过 https://ddosmon.net/explore/your.target/ 来验证。部分链接如下，读者可以根据需要自行调整查询。

https://ddosmon.net/explore/twitter.com/

https://ddosmon.net/explore/github.com/

https://ddosmon.net/explore/paypal.com/

https://ddosmon.net/explore/208.78.70.34/

https://ddosmon.net/explore/208.78.71.34/

https://ddosmon.net/explore/204.13.250.34/

https://ddosmon.net/explore/204.13.251.34/


【攻击现场技术特征】


攻击现场有更多技术细节可供讨论，我们列举出部分认为重要的特点，供安全社区进一步分析，以期减轻攻击者对网络的影响。


时间窗口方面，本次攻击主要发生在北京时间2016年10月21日晚间19：00～22：50之间。


攻击手段方面，如前所述本次事件中主要是syn flood和dns flood。下面我们分析攻击的具体特征，并试图分析攻击与mirai泄漏版本/未知mirai变种/其他基于IoT的僵尸网络之间的归因关系。


关于本次攻击中的Syn flood部分，攻击发起的bot IP地址我们倾向认为是真实的。这些IP地址中有45%在最近有扫描23/2323端口的历史行为记录，这一点与mirai的行为相似。在安全社区已经公开的信息中，认为本次攻击流量特征符合Mirai的流量特点。综合以上两点，我们认为本次攻击中有Mirai或者其变种参与。但是对比这些Ip地址与已知mirai bot列表，只有<2%的比例命中，这会一定程度上削弱“整体而非部分攻击由mirai发起”的说法，我们在后文试图引入不同的假设给予解释。


关于本次攻击中的 dns flood 部分，我们倾向认为发起的bot IP是伪造或者是非Mirai家族的。这些IP地址分布离散度直观上看并不高，并且没有历史扫描行为，探查部分IP的开放端口看起来也不像是IoT设备。再加上从泄漏版本的Mirai源码分析，原始版本的mirai 在发起dns flood攻击的时候不会伪造源IP地址，我们可以判定：要么这些IP地址是伪造的，那么一定不是原始版本的mirai；要么这些IP地址是真实的，那就与mirai的关系更远，甚至可能是其他任何僵尸网络发起的。


2016年10月27日更新：在安全社区的帮助下，我们获得了少量攻击现场的数据，证实了之前分析中的若干观点：攻击手段中包含 syn flood，真实源IP，小包，这些真实 bot IP 在我们到今天为止的bot IP 列表中命中率大约33%；攻击手段中包含dns flood，使用伪造源IP，这部分攻击可以断言不是由mirai发起，至少不是泄漏版本mirai发起。所有这些现象与我们之前的观点吻合一致。


以上IP地址和mirai/mirai变种之间的分析汇总如下表所示：




多个公开的消息源还提到本次攻击中存在DNS变前缀攻击。这种攻击手段通常是针对域名解析服务器，本次攻击中的受害者正是如此。虽然在我们自有的数据中无法验证上述说法，按照我们对消息源既往的信任程度，我们认为这种说法的确成立。


综合起来在攻击手段方面，我们本次攻击中看到了syn flood 和 dns flood，并且相信有dns变前缀攻击存在。总体而言，我们虽然可以认定泄漏版本mirai贡献了本次攻击中的部分流量，但是无法将全部流量归结到泄漏版本mirai。加入不同的假设可以对现象做不同的解释：

——也许是我们收集的bot IP 列表不全面；

——或者我们看到的攻击流量不足以代表dyn在北美地区实际遭受的攻击；

——或者是mirai产生了变种，并且参与了本次攻击；

——或者是其他僵尸网络家族参与了本次攻击。

目前为止我们无法用手头的数据或事实来选择任何一种假设继续深入。


botIP方面，部分bot IP 探测情况是光猫、网络摄像头和网关路由器，这可以验证近期安全社区对以maria为代表的基于IoT的僵尸网络的担心，也值得我们在这里呼吁各IoT设备厂商加强与互联网安全厂商的合作，共同增强网络空间中的安全感。


部分攻击源IP系统截图如下：




【Mirai僵尸网络历史情况回溯和统计数据】


在2016年8月1日，我们设置的蜜罐第一次被未知扫描源扫中。在9月6日，我们意识到在2323端口上的扫描源有一个显著的spike，并在后续的时间里，我们与安全社区一起，对mirai的源码、扫描感染行为、攻击行为在流量特征、样本特征等方面做了持续的跟踪和分析。整体过程的时间线如下：




蜜罐被mirai首次扫描到的时间是2016-08-01 12:46，如下图所示。对应的数据可以在下图附属的URL中获得，即2016-08-01～2016-08-08期间感染marai的bot ip数据。



http://data.netlab.360.com/feeds/mirai-scanner/scanner.list


端口2323上的mirai扫描首次出现在 2016-09-06，如下图所示。2016-08-09及以后的数据，可以发邮件到 netlab@360.cn 申请。




我们在9月6日观察到的在端口2323上的扫描源暴涨的情况，可以在下图中直观的观察到，或者可以在图下附属的URL中看到最近30天变化的版本。




http://scan.netlab.360.com/#/dashboard?dstport=2323


我们首篇关于marai的文章发表于2016年10月16日，在blog.netlab.360.com上。在这篇文章中我们提及了收集marai bot IP列表的基本原理和当时的数据统计情况：

http://blog.netlab.360.com/a-quick-stats-on-the-608-083-mirai-ips-that-hit-our-honeypots-in-the-past-2-5-months/


我们在分析mirai泄漏源码的过程中，发现了mirai扫描模块的一些缺陷/特征，基于这一点我们可以通过检查syn包头部将mirai的扫描与其他在 tcp 23 和tcp 2323 上的扫描源做显著的区分。基于以上分析，我们在历史数据中将mirai的扫描活动可以一直回溯到首次命中时间2016年8月1日。

进一步对Mirai的历史扫描做统计，使得我们有机会细致观察mirai的感染过程的不同阶段：


——8月1日开始，扫描感染过程发起，至9月6日以前，mirai仅扫描23端口。每日扫描源在2k～13k之间波动，中间两个波峰期每日扫描源维持在8k～11k上下，这段时间内每天大约90%～80%的扫描源是之前没有看到的；


——9月6日开始，mirai开始扫描2323 端口，与23端口相比，数量小了大约1个数量级。但此时扫描量相对较小，无论是23端口还是2323端口。


——9月16日到现在，mirai的扫描感染进入一个稳定的发展期，日均扫描IP稳定在16k~22k之间，全新扫描/botIP的比例从80%逐渐下滑到65%～55%区间以后下降速度非常缓慢。


——至2016年10月23日凌晨，累积观察到的mirai bot IP已经有大约720k。这是一个大规模的僵尸网络。


总体而言，marai僵尸网络目前规模已经有720k，这是个相当大的数字，再加上当前的规模扩张仍然保持高速且稳定，这让人相当不安。

以上数据可以从下面两个图中直观的观察：






在来源IP的地理分布方面，我们观察到的bot主要来自 .vn .br .cn .in .co .ru。这五个国家和地区累积占据了我们视野中56%。






我们已经建立了系统实时跟踪mirai僵尸网络，上述数字每日更新，可以在下列网址访问。这个网址上还有mirai的2016.08.01～2016.08.08的bot IP列表可供下载。更完整的bot IP 列表可以发电子邮件到 netlab@360.com申请。

http://data.netlab.360.com/mirai-scanner


我们还进一步跟踪了mirai的攻击指令发送渠道。通过分析过去七天的指令发起时间，从时间分布上来看，指令的高峰期发生在北京时间 (GMT +8)的凌晨5：10～7：50之间，这不太符合这个时区既往僵尸网络操作者发出指令的时间，我们倾向于排除mirai的操作者来自北京时区（GMT +8）的可能性。




分析过程中涉及到的工具系统均统一列出在 netlab.360.com，如下表。其中大部分的系统向公众开放，白帽子可以自行运用。部分数据不宜直接公开，仅向受信任的安全社区开放， 白帽子可以在取得我们信任的前提下申请访问。



{"version":"0.3.1","markups":[],"atoms":[],"cards":[["markdown",{"cardName":"card-markdown","markdown":"\n【更新记录】\n\n2016-10-23 初始版本\n2016-10-27 获得了少量攻击现场数据，分析结果与之前观点吻合一致。\n\n\n北京时间2016年10月21 日晚间，北美地区大量反馈若干重要的互联网网站无法正常访问。涉及到的网站包括 twitter， paypal，github等等，由于这些网站与北美地区日常生活强烈相关，这次网络故障被北美主要媒体广泛报道，也引起了安全社区的强烈关注。我们与国外安全社区一起协同，对本次网络事件提供数据、加以分析并做了溯源跟踪。\n\n目前我们已经能够确定本次事件是一次DDoS网络攻击事件，攻击目标主要是Dynamic Network Services（dyn）公司，twitter、paypal、github等网站作为dyn公司的客户，在本次攻击中不幸被波及。\n在攻击持续溯源的过程中，虽然目前Flashpoint公司已经确认最近广泛受关注的mirai僵尸网络参与了本次网络攻击，但是我们倾向认为虽然mirai贡献了本次攻击的部分攻击流量，但并非所有的攻击流量都来自原始泄漏版本mirai。具体来源不明，可能是源自我们数据地缘性导致的分析误差，也可能是来自mirai的变种或者混合模式的DDoS攻击。 \n\n2016年10月27日更新：在安全社区的帮助下，我们获得了少量攻击现场的数据，证实了之前分析中的若干观点：攻击手段中包含 syn flood，真实源IP，小包，这些真实 bot IP 在我们到今天为止的bot IP 列表中命中率大约33%；攻击手段中包含dns flood，使用伪造源IP，可以断定这部分攻击不是有mirai发起，至少不是泄漏版本mirai发起。所有这些现象与我们之前的观点吻合一致。\n\n【攻击受害者的判定和影响范围的评估】\n\n接到反馈后，我们很快认定攻击受害者是twitter.com使用的域名服务器，而非 twitter.com paypal.com 的Web服务器直接遭受攻击。\n\ndyn公司是知名的网络域名服务提供商，本次攻击中受影响的twitter等多个著名公司都是dyn公司的客户。Dyn公司使用了四个域名/IP为twitter提供域名解析服务，这四个IP分布在四个C类段或者两个B类段中，传统上这是一种常见的网络负载均衡手段。四个IP地址如下表所示。\n\n![](__GHOST_URL__/content/images/2016/10/table_01_direct_victim.png)\n\n在本次事件中，四个IP地址在当天19：00～22：50期间的网络流量波形图如下。峰值达到日常背景流量的20倍，可以判定发生了流量攻击。 \n![](__GHOST_URL__/content/images/2016/10/01_direct_target_flow_chart.png)\n\n在我们数据基础上进一步的分析指出，攻击者的攻击手段是混合使用DNS_flood和 syn_flood，结合公开媒体的报道，我们推断这组攻击得手，这组服务器不再对外提供服务，twitter.com  网站在这段时间内也无法访问。以上是攻击的直接受害者。\n![](__GHOST_URL__/content/images/2016/10/table_02_ddos_vector.png)\n\n\n但是除了twitter还有大量网站例如 paypal.com 和  github.com也无法访问，我们推断这是由于上述攻击造成的波及效应。如下表所示，paypal和github也是DYN的客户。\n\n![](__GHOST_URL__/content/images/2016/10/table_03_sympathatic_victim.png)\n\ndyn为每个重要客户提供四组地址，分布在四个C类段中，如前所述，这是一种传统的网络负载均衡手段。但是在这个结构中，如果四个网段同时遭到大流量的网络攻击，则全部四个段的客户都会受到影响。\n\n我们认为在本次事件中就发生了这种情况，大流量针对 *.34/twitter的攻击影响到了同网段不限于 *.15/github、*.57/paypal服务器的网络流量，最终 github/paypal和twitter一同暂时无法访问。不仅是以上列出的三家网站，其他该网段的客户也会受到影响，比如*.5/playstation.net；而如果一个网站不使用dyn的域名解析服务则不会受到影响，比如 wikileak。\n\n在我们的分析中，我们也注意到  github.com 的Web服务器在当天早些时候遭受了直接的DDoS攻击，但是我们不认为那次攻击可以解释整体大范围的安全事件，也并未深究个体事件与整体事件背后的关系。\n以上攻击信息可以通过  https://ddosmon.net/explore/your.target/ 来验证。部分链接如下，读者可以根据需要自行调整查询。\nhttps://ddosmon.net/explore/twitter.com/\nhttps://ddosmon.net/explore/github.com/\nhttps://ddosmon.net/explore/paypal.com/\nhttps://ddosmon.net/explore/208.78.70.34/\nhttps://ddosmon.net/explore/208.78.71.34/\nhttps://ddosmon.net/explore/204.13.250.34/\nhttps://ddosmon.net/explore/204.13.251.34/\n\n\n【攻击现场技术特征】\n\n攻击现场有更多技术细节可供讨论，我们列举出部分认为重要的特点，供安全社区进一步分析，以期减轻攻击者对网络的影响。\n\n时间窗口方面，本次攻击主要发生在北京时间2016年10月21日晚间19：00～22：50之间。\n\n攻击手段方面，如前所述本次事件中主要是syn flood和dns flood。下面我们分析攻击的具体特征，并试图分析攻击与mirai泄漏版本/未知mirai变种/其他基于IoT的僵尸网络之间的归因关系。\n\n关于本次攻击中的Syn flood部分，攻击发起的bot IP地址我们倾向认为是真实的。这些IP地址中有45%在最近有扫描23/2323端口的历史行为记录，这一点与mirai的行为相似。在安全社区已经公开的信息中，认为本次攻击流量特征符合Mirai的流量特点。综合以上两点，我们认为本次攻击中有Mirai或者其变种参与。但是对比这些Ip地址与已知mirai bot列表，只有<2%的比例命中，这会一定程度上削弱“整体而非部分攻击由mirai发起”的说法，我们在后文试图引入不同的假设给予解释。\n\n关于本次攻击中的 dns flood 部分，我们倾向认为发起的bot IP是伪造或者是非Mirai家族的。这些IP地址分布离散度直观上看并不高，并且没有历史扫描行为，探查部分IP的开放端口看起来也不像是IoT设备。再加上从泄漏版本的Mirai源码分析，原始版本的mirai 在发起dns flood攻击的时候不会伪造源IP地址，我们可以判定：要么这些IP地址是伪造的，那么一定不是原始版本的mirai；要么这些IP地址是真实的，那就与mirai的关系更远，甚至可能是其他任何僵尸网络发起的。\n\n2016年10月27日更新：在安全社区的帮助下，我们获得了少量攻击现场的数据，证实了之前分析中的若干观点：攻击手段中包含 syn flood，真实源IP，小包，这些真实 bot IP 在我们到今天为止的bot IP 列表中命中率大约33%；攻击手段中包含dns flood，使用伪造源IP，这部分攻击可以断言不是由mirai发起，至少不是泄漏版本mirai发起。所有这些现象与我们之前的观点吻合一致。\n\n以上IP地址和mirai/mirai变种之间的分析汇总如下表所示：\n![](__GHOST_URL__/content/images/2016/10/table_04_ddos_sip_attribute.png)\n\n多个公开的消息源还提到本次攻击中存在DNS变前缀攻击。这种攻击手段通常是针对域名解析服务器，本次攻击中的受害者正是如此。虽然在我们自有的数据中无法验证上述说法，按照我们对消息源既往的信任程度，我们认为这种说法的确成立。\n\n综合起来在攻击手段方面，我们本次攻击中看到了syn flood 和 dns flood，并且相信有dns变前缀攻击存在。总体而言，我们虽然可以认定泄漏版本mirai贡献了本次攻击中的部分流量，但是无法将全部流量归结到泄漏版本mirai。加入不同的假设可以对现象做不同的解释：\n——也许是我们收集的bot IP 列表不全面；\n——或者我们看到的攻击流量不足以代表dyn在北美地区实际遭受的攻击；\n——或者是mirai产生了变种，并且参与了本次攻击；\n——或者是其他僵尸网络家族参与了本次攻击。\n目前为止我们无法用手头的数据或事实来选择任何一种假设继续深入。\n\nbotIP方面，部分bot IP 探测情况是光猫、网络摄像头和网关路由器，这可以验证近期安全社区对以maria为代表的基于IoT的僵尸网络的担心，也值得我们在这里呼吁各IoT设备厂商加强与互联网安全厂商的合作，共同增强网络空间中的安全感。\n\n部分攻击源IP系统截图如下：\n![](__GHOST_URL__/content/images/2016/10/02_bot_system_list.png)\n\n\n【Mirai僵尸网络历史情况回溯和统计数据】\n\n在2016年8月1日，我们设置的蜜罐第一次被未知扫描源扫中。在9月6日，我们意识到在2323端口上的扫描源有一个显著的spike，并在后续的时间里，我们与安全社区一起，对mirai的源码、扫描感染行为、攻击行为在流量特征、样本特征等方面做了持续的跟踪和分析。整体过程的时间线如下：\n![](__GHOST_URL__/content/images/2016/10/table_05_marai_traceback_timeline.png)\n\n蜜罐被mirai首次扫描到的时间是2016-08-01 12:46，如下图所示。对应的数据可以在下图附属的URL中获得，即2016-08-01～2016-08-08期间感染marai的bot ip数据。\n![](__GHOST_URL__/content/images/2016/10/table_06_marai_port23_scan_first_hit.png)\nhttp://data.netlab.360.com/feeds/mirai-scanner/scanner.list\n\n端口2323上的mirai扫描首次出现在 2016-09-06，如下图所示。2016-08-09及以后的数据，可以发邮件到 netlab@360.cn 申请。\n![](__GHOST_URL__/content/images/2016/10/table_07_marai_port2323_scan_first_hit.png)\n\n我们在9月6日观察到的在端口2323上的扫描源暴涨的情况，可以在下图中直观的观察到，或者可以在图下附属的URL中看到最近30天变化的版本。\n![](__GHOST_URL__/content/images/2016/10/03_spike_on_port2323_first_notice.png)\n \nhttp://scan.netlab.360.com/#/dashboard?dstport=2323\n\n我们首篇关于marai的文章发表于2016年10月16日，在blog.netlab.360.com上。在这篇文章中我们提及了收集marai bot IP列表的基本原理和当时的数据统计情况：\n__GHOST_URL__/a-quick-stats-on-the-608-083-mirai-ips-that-hit-our-honeypots-in-the-past-2-5-months/\n\n我们在分析mirai泄漏源码的过程中，发现了mirai扫描模块的一些缺陷/特征，基于这一点我们可以通过检查syn包头部将mirai的扫描与其他在 tcp 23 和tcp 2323 上的扫描源做显著的区分。基于以上分析，我们在历史数据中将mirai的扫描活动可以一直回溯到首次命中时间2016年8月1日。\n进一步对Mirai的历史扫描做统计，使得我们有机会细致观察mirai的感染过程的不同阶段：\n\n——8月1日开始，扫描感染过程发起，至9月6日以前，mirai仅扫描23端口。每日扫描源在2k～13k之间波动，中间两个波峰期每日扫描源维持在8k～11k上下，这段时间内每天大约90%～80%的扫描源是之前没有看到的； \n\n——9月6日开始，mirai开始扫描2323 端口，与23端口相比，数量小了大约1个数量级。但此时扫描量相对较小，无论是23端口还是2323端口。\n\n——9月16日到现在，mirai的扫描感染进入一个稳定的发展期，日均扫描IP稳定在16k~22k之间，全新扫描/botIP的比例从80%逐渐下滑到65%～55%区间以后下降速度非常缓慢。\n\n——至2016年10月23日凌晨，累积观察到的mirai bot IP已经有大约720k。这是一个大规模的僵尸网络。\n\n总体而言，marai僵尸网络目前规模已经有720k，这是个相当大的数字，再加上当前的规模扩张仍然保持高速且稳定，这让人相当不安。\n以上数据可以从下面两个图中直观的观察：\n![](__GHOST_URL__/content/images/2016/10/04_mirai_stats_01.png)\n![](__GHOST_URL__/content/images/2016/10/04_mirai_stats_02.png)\n \n \n在来源IP的地理分布方面，我们观察到的bot主要来自 .vn .br .cn .in .co .ru。这五个国家和地区累积占据了我们视野中56%。\n![](__GHOST_URL__/content/images/2016/10/04_mirai_stats_03.png)\n![](__GHOST_URL__/content/images/2016/10/table_08_marai_geo_distibute.png)\n \n我们已经建立了系统实时跟踪mirai僵尸网络，上述数字每日更新，可以在下列网址访问。这个网址上还有mirai的2016.08.01～2016.08.08的bot IP列表可供下载。更完整的bot IP 列表可以发电子邮件到 netlab@360.com申请。\nhttp://data.netlab.360.com/mirai-scanner\n\n我们还进一步跟踪了mirai的攻击指令发送渠道。通过分析过去七天的指令发起时间，从时间分布上来看，指令的高峰期发生在北京时间 (GMT +8)的凌晨5：10～7：50之间，这不太符合这个时区既往僵尸网络操作者发出指令的时间，我们倾向于排除mirai的操作者来自北京时区（GMT +8）的可能性。\n![](__GHOST_URL__/content/images/2016/10/05_mirai_attack_cmd_timezone_distribute-1.png)\n\n分析过程中涉及到的工具系统均统一列出在 netlab.360.com，如下表。其中大部分的系统向公众开放，白帽子可以自行运用。部分数据不宜直接公开，仅向受信任的安全社区开放， 白帽子可以在取得我们信任的前提下申请访问。\n![](__GHOST_URL__/content/images/2016/10/table_09_marai_tracing_related_systems.png)\n\n"}]],"sections":[[10,0]],"ghostVersion":"3.0"}