PassiveDNS 解析服务提供商对非授权域名解析情况的评估 概要 在之前的文章中，我们披露了Specter僵尸网络序利用api[.]github.com等白域名提供C2服务，以此来逃避基于签名和威胁情报匹配的安全产品的检测。其具体原理经过分析之后，发现其利用了某些域名注册/托管商(cloudns)的权威DNS服务器在解析非其客户域名方面的漏洞。 我们对此现象，即域名注册/托管商，公有云提供商等能够提供域名注册和解析服务的供应商（以下统称为解析服务提供商）对非自己服务域名的DNS请求是否能够返回正确应答的情况，进行了系统的测量和评估。 这篇文章对此现象进行了分析。 数据选择及评估方法 被测域名 被测试域名：Alexa top500。选择他们作为被测域是因为： 这些域名都会使用自己专有的DNS服务器，他们并不会使用外部的解析服务提供商提供的解析服务。所以如果这些域名可以被外部的解析服务提供商的NS服务器解析，那么大概率是非授权的。 这些域名本身也因为其庞大而知名的业务，会被加入到各种白名单中。一些出于探测目的的人也更容易随手添加一些知名网站，而干坏事的人微了躲避检测黑名单检测，
PassiveDNS 被拦截的伊朗域名的快速分析 伊朗新闻网站被美国阻断的事成为了最近的新闻热点，报道的主要内容是： 美国司法部查封36个伊朗的新闻网站，其中许多网站与伊朗的“虚假信息活动”有关。这些网站首页通知显示，根据美国法律，这些网站已被美国政府查封，通知上还附有美国联邦调查局和美国商务部产业安全局的印徽。 到底哪些新闻站被拦截了，我们查询了几个新闻源都没有给出全部被拦截的网站列表。 其实这种从域名角度做拦截的手段，总是会在大网的DNS/whois数据中留下踪迹。我们利用这些网络基础数据分析出了32+2个被拦截的伊朗新闻网站的域名，其中的2个域名是在今年3月和4月份被拦截的；通过技术分析，也确认这些修改是直接通过注册局进行的改动。被拦截的域名的详细列表见文末。 分析 我们拿其中被拦截的域名之一alalamtv.net 来做一个分析(见相关新闻报道)。 DNS记录 从该域名出发，我们利用PassivedDNS记录可以看到，其NS服务器和IP地址在6月23号的凌晨3点40开始发生了变化，无论NS服务器还是IP地址都切换到了亚马逊的服务器。 whois记录 先说结论：
DNS data mining case study - skidmap As the foundation and core protocol of the Internet, the DNS protocol carries data that, to a certain extent, reflects a good deal of the user behaviors, thus security analysis of DNS data
DNSMon DNSMon: 用DNS数据进行威胁发现 ----发现skidmap的未知后门更新记录 [2020-12-07] 在本文发布之后不久，我们注意到该后门的访问模式有了一定的调整。并在最近DNSMon发现攻击者已经启用了新的域名IOC。具体来说有如下变化： 将rctl子域名变更为 r1 新启用了mylittlewhitebirds[.]com，howoldareyou9999[.]com（比原先的howoldareyou999[.]com多了一个字符'9'），franceeiffeltowerss[.]com(比原先的franceeiffeltowers[.]com多了一个字符's')三个域名作为后面的备用域名。 具体如下： r1.googleblockchaintechnology[.]com r1.howoldareyou9999[.]com r1-443.howoldareyou9999[.]com r1-443.franceeiffeltowerss[.]com r1.
DNSMon 360netlab上线域名IOC（威胁情报）评估标准及评估数据服务 版本一：程序员版 一直以来，由于高门槛，安全圈里对威胁情报质量没有一个很好的评估手段， PR狠的公司的威胁情报就更好么？ 名头响的公司的威胁情报就更好么？ 使用了机器学习人工智能这些热词的威胁情报就更好么？ 拿了一堆排排坐吃果果的奖的公司的威胁情报就更好么？ 难有人能给个说法，所以最后我们看到用户只能回到一个聊胜于无的方法，哪家的威胁情报的总数多哪家就好，出现的告警次数多哪家就好！ 这个方法其实巨坑，举个🌰： A和B厂家提供两份威胁情报，A有10万条IOC，B有5万条IOC。 A的10万条IOC在实际网络中总命中IOC不到1000条，产生了20000次告警。 B的5万条IOC在实际网络中命中IOC15000条，也产生了20000次告警。 你愿意选择哪个？ 那咋办？ 经过一段时间的准备，我们推出来了个一个公益的评估标准，而且还免费提供大网的实际评估数据从而让客户有真实数据评估。 我们这么干是为啥？ 是不是有啥阳谋，要怎么收数据之类的？（答案，没有，看看我们的正经页面就能懂）
DNSMon Look at NTP pool using DNS data With the rapid development of the Internet, more and more people have realized the importance of network infrastructure. We don’t hear people talk about NTP ( Network Time Protocol) much though.Whether NTP
DNSMon 从DNS角度看NTP pool服务器的使用 随着互联网的快速发展，其已经深入到日常生活中的方方面面，越来越多的业内人员对于网络基础设施的重要性有了非常深入的认识。不过谈到基础设施，通常都会谈及DNS协议，但是还有一个关键的协议NTP（Network Time Protocol）却没有得到应有的重视。NTP是否能够良好的工作会影响到计算机系统的大部分基于时间判定的逻辑的正确运行。比如DNSSEC是否过期，IPSEC的隧道建立，TLS证书的有效性校验，个人密码的过期，crontab任务的执行等等[1]。NTP协议同DNS类似，是互联网最古老的协议之一，主要作用如其名字所说，用来保持设备时间的同步。在我们使用的操作系统比如windows，Android或者Macos都配置有自己的NTP时间服务器来定期同步设备上的时间。NTP pool 是什么？由于互联网的发展以及NTP业务的特殊性（时间需要定期同步），少量的NTP服务器的负载越来越大，并且公共一级NTP授时服务器存在被滥用的问题，2003年1月NTP pool项目正式设立。其基本原理通过域名“
DNSMon 一些网站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，
Botnet Malicious Campaign luoxk Is Actively Exploiting CVE-2018-2893 Author: Zhang Zaifeng, yegenshen, RootKiter, JiaYu On July 18, in an officially released routine patch update, Oracle fixed CVE-2018-2893, an Oracle WebLogic Server remote code execution vulnerability. Three days later, at 2018-07-21 11:
Botnet 恶意代码团伙luoxk正在积极利用 CVE-2018-2893 传播 文章作者：Zhang Zaifeng, yegenshen, RootKiter, JiaYu 7月18日，Oracle在官方发布的例行补丁更新中修复了CVE-2018-2893，一个Oracle WebLogic Server 远程代码执行漏洞。一般认为漏洞影响严重且相关PoC已经公开，建议相关用户尽快进行评估升级。 三天后，2018-07-21 11:24:31 开始，我们注意到一个长久以来我们跟踪的恶意代码团伙正在积极利用该漏洞传播自身。由于该团伙经常使用 luoxkexp[.]com ，我们将其命名为 luoxk 。 该恶意代码团伙第一次触发我们的警铃是在一年前的2017年3月17日，我们的DNSMon系统，在该恶意代码团伙域名注册后的第二天根据算法自动判断该域名异常。 在那以后，我们持续观察了该恶意代码团伙的行为，包括： DDoS攻击：
Mining A Case Study: How One Big Player Could Impact the Cohive Business in China "Who is Stealing My Power" is a series of articles on the topic of web mining that we observed from our DNSMon system. As we mentioned in this series of one,
Mining 是谁悄悄偷走我的电（四）：国内大玩家对Coinhive影响的案例分析 《是谁悄悄偷走我的电》是我们的一个系列文章，讨论我们从 DNSMon 看到的网页挖矿的情况。在这个系列的之前的 一 、 二 和 三 中，我们已经介绍了整个Web挖矿的市场情况。当前我们知道，市场中的玩家主要可以分为挖矿网站和内容/流量网站，前者提供挖矿能力、后者提供流量，二者合力利用终端用户的浏览器算力挖矿获利。 当前，挖矿网站中最大的玩家是 coinhive 家族，按照被引用数量计，占据了 58% 的市场份额。这些在我们之前的文章中已经提及。 那么，流量网站的情况如何，有哪些有意思的情况？ Coinhive 的关联域名 DNSMon
Mining Who is Stealing My Power III: An Adnetwork Company Case Study We recently noticed that one of the ad network provider started to perform in-browser coinhive cryptojacking when users visit websites which use this provider’s ad network service. As early as mid 2017,
Mining 是谁悄悄偷走我的电（三）：某在线广告网络公司案例分析 我们最近注意到，某在线网络广告商会将来自 coinhive 的javascript网页挖矿程序，插入到自己广告平台中，利用最终用户的浏览器算力，挖取比特币获利。 P公司是一家在线广告网络公司，负责完成广告和广告位之间的匹配，并从中获取收入；Adblock 是一种浏览器插件，用户可以利用来屏蔽广告。显然，上述两者之间有长久的利益冲突和技术对抗。 在2017-09之前，我们就注意到 P公司 会利用类似 DGA 的技术，生成一组看似随机的域名，绕过 adblock，从而保证其投放的广告能够到达最终用户，我们将这组域名称为 DGA.popad。 从2017-12开始，我们观察到P公司开始利用这些 DGA.popad 域名，
Mining Openload.co and Other Popular Alex Sites Are Abusing Client Browsers to Mining Cryptocurrency As of December 24, 2017, we noticed a group of Alex top websites abusing client browser's computing power in cryptocurrency mining. The javascript code is based on CoinHive with tricks to completely circumvent
Mining 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
PassiveDNS Fraudulent Top Sites, an Underground Market Infrastructure [Update History] 2017-01-16 First English version. Updates in original Chinese version is merged. Overview Some domain names contains strings representing well-known companies are noticed in our abnormal traffic detecting system, including 360, ali,
PassiveDNS 以大站的名义：专注地下产业的网络基础设施 【历史更新记录】 2017-01-10 原始版本 2017-01-16 补充了对服务器IP地址同源性的分析，此处分析指向性较弱，仅为完备性考虑 概述 在奇虎网络安全研究院(netlab@360.cn)，我们建立了一个基于DNS的异常流量监测系统，每天会检出若干异常流量以及对应的域名/IP。通常这些被检出的域名/IP都属于地下产业链条。 但是，我们注意到一些代表知名公司的字符串也出现在这些被检出的域名中，包括360, ali, baidu, cloudflare, dnspod, google和microsoft。通过分析，我们认为这是有人冒用大站名义，为赌博、色情、私服等地下产业提供网络基础设施服务。 这一基础设施结构错综复杂，运营时间长、支撑能力强、
PassiveDNS 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对其网络行为进行研究。
PassiveDNS Conficker域名被滥用情况分析 根据对conficker域名的跟踪，我们发现conficker的域名存在明显的滥用。主要表现为浏览器访问conficker域名后，会跳转到广告页面（既有正常业务，也有赌博/色情等灰色业务），有时候还会存在一些垃圾软件（比如虚假的杀毒软件）的推广等。 由于conficker的DGA域名的巨大数量，我们希望了解产生这种状况的原因以及其现在的规模。 Conficker域名现状及被滥用状况 Conficker简介 Conficker是出现于2008年11月，曾感染了数百万台电脑。Conficker有一个独特的特性是它使用了DGA技术。利用随机生成的域名来防止网络设备的封堵。自此以后DGA技术也开始逐渐流行起来。关于conficker和DGA的细节，请参考[1] [2]。 校验数据集及passvieDNS中的命中情况 我们选取了2010-01-01到2016-09-15这段时间内，由conficker.a 和conficker.b生成的全部的DGA域名作为数据全集，共1225000条域名。 检查这些域名在passiveDNS中的命中情况。排除NXDOMAIN之外，总共命中了216352条。
