攻击者在利用了 CoinHive 的浏览器端挖矿

浏览： ℃

字体：大中小

发布时间：2018-01-25 11:03:24

来源：

从2017年12月24日，360网络安全研究院注意到一组网站正在滥用客户终端浏览器的算力在挖矿。攻击者在利用了 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代码如下：

图片6.png