作者：安天-捕风：放牛娃

1. 前言

2017年4月被匿名黑客“影子经纪人”公布了第二批NSA武器，其中就包含了"EternalBlue"——MS17-010漏洞，5月中旬该漏洞的自动化利用工具如雨后春笋般在地下黑产出现并迅速传播，目前为止安天捕风监控捕获到的"EternalBlue"自动化利用工具已经已有多套（见图1-1 工具集合），这也证实国外某黑客“NSA工具公布意味着黑客平民化开始”的警告言论。

图1-1 工具集合

"EternalBlue"自动化工具的出现伊始就已经实现漏洞与各类型病毒结合。从早期监控捕获到的"EternalBlue"与Gh0st远控的为虎作伥实现RAT（Remote Accass Trojan）自动化种植感染，到现在的"EternalBlue"与Nitol.M的狼狈为奸实现DDoS botnet快速自动化拓展“肉鸡”，都警示着：互联网安全形势越发严峻，为互联网安全保驾护航更是任重而道远。

2. 基本信息

表1-1 样本基本信息

3. 传播方式

图3-1 监控捕获数据

图3-2 hfs数据

图3-3 木马下载url地址

4. 样本详细分析

1)样本备份与创建服务

样本运行会通过检查服务名称".Net CLR"（该服务名称是Nitol家族默认服务名称）存在与否来验证样本是否初次运行。见图4-1 检查服务名称：

图4-1 检查服务名称

2)如果服务名不存在，则进行样本备份和创建服务实现样本自启动而长期驻留受害系统。

见图4-2 样本备份及自启动设置：

图4-2 样本备份及自启动设置

3)配置解密获取C2并创建连接。

见图4-3 C2配置解密：

图4-3 C2配置解密

4)获取系统配置信息。

获取系统版本和CPU配置及内存信息作为向C2发送的首包内容，并实时等待接收C2远程指令，见图4-4 bot与C2通讯交互：

图4-4 bot与C2通讯交互

5)解析并执行C2的远程指令。

当接收到C2的远程指令是首先对指令类型进行识别鉴定，然后分类执行（见图4-5 识别鉴定指令类型）。

图4-5 识别鉴定指令类型

远程指令类型主要包含有DDoS Attack、Stop Attack、Download Files、CMD Shell、Delete Service，见表4-1指令类型数据表：

表4-1 指令类型数据表

6)DDoS攻击指令协议解析。

该变种的DDoS Attack攻击有syn flood、udp flood、icmp flood、tcp flood、dns flood、cc flood 6种攻击类型，见图4-6 DDoS攻击类型。攻击类型协议整理见表4-2 攻击类型协议表：

图4-6 DDoS攻击类型

表4-2攻击类型协议表

5. 攻击情报

表4-3 受害者Top30

附录：参考资料

参考链接：

http://www.antiy.com/tools.html

MD5:

c7d0827b6224b86f0a90fa42a8d39edd

热点概要：超过1700台IoT设备和相关的telnet凭据已被泄露并公开放、黑客盗取HBO权利的游戏第七季并公开大结局剧情、Apple iOS <=10.3.1 - Kernel Exploit、OSX平台的流量监控和防火墙工具Little Snitch、用Flash利用JSON的CSRF、大量服务器的登录凭证被PDF钓鱼泄露、AVPASS：可绕过Android恶意软件检测系统的工具、恶意软件脱壳工具之二

资讯类：

安全研究人员警告：超过1700台IoT设备和相关的telnet凭据已被泄露并公开放在网上

http://securityaffairs.co/wordpress/62365/iot/iot-devices-credentials-leaked.html

黑客盗取HBO权利的游戏第七季并公开大结局剧情

https://www.hackread.com/hbo-hackers-leak-script-spoilers-of-game-of-thrones-season-finale/

技术类：

Apple iOS <=10.3.1 - Kernel Exploit

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

OSX平台的流量监控和防火墙工具Little Snitch

https://www.obdev.at/products/littlesnitch/index.html

用Flash利用JSON的CSRF

http://www.geekboy.ninja/blog/exploiting-json-cross-site-request-forgery-csrf-using-flash/

https://github.com/sp1d3r/swf_json_csrf/

大量服务器的登录凭证被PDF钓鱼泄露

http://www.ringzerolabs.com/2017/08/large-victim-credential-server.html

https://www.bilibili.com/video/av13897953/

windows, Mac OSX和linux平台的设置HTTPs以及自签名证书详细指南

https://www.humankode.com/asp-net-core/develop-locally-with-https-self-signed-certificates-and-asp-net-core

AVPASS：可绕过Android恶意软件检测系统的工具

http://www.kitploit.com/2017/08/avpass-tool-for-leaking-and-bypassing.html

https://github.com/sslab-gatech/avpass/blob/master/docs/README.md

Demo视频：

https://www.bilibili.com/video/av13898951/

https://www.bilibili.com/video/av13898920/

恶意软件脱壳工具, Part 1. Dumping executables from RWE memory

https://vallejo.cc/2017/08/13/tools-for-unpacking-malware-part-1-dumping-executables-from-rwe-memory/

恶意软件脱壳工具, Part 2. Weak encryption algorithms

https://vallejo.cc/2017/08/27/tools-for-unpacking-malware-part-2-weak-encryption-algorithms/

AI训练算法易被藏后门

https://arxiv.org/pdf/1708.06733v1.pdf

Passwords Evolved: Authentication Guidance for the Modern Era

https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/

iBoot exploitation material from BlackHat

mega:#!Op1gSDxR!n9P4Xy_H6iDErYDAvwWZNPe-aso2CmCeh8vph-UMoT0

https://pastebin.com/9FuxXRtA

WINspect - Powershell-based Windows Security Auditing Toolbox

http://www.kitploit.com/2017/08/winspect-powershell-based-windows.html

https://github.com/A-mIn3/WINspect

翻译：trip1e_chee5e

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

前言

恶意程序Trojan-Banker.AndroidOS.Faketoken已经出现超过一年的时间了，在这一年多的时间里，它已经从最开始的mTAN codes（双因素认证）拦截木马进化到了加密器。随着该程序新变种的作者不断改进，它的影响范围也越来越大。有些变种已经覆盖超过了2000款的商用APP。在该程序的最新版本中，我们检测到了一种新的攻击方式——定出租并支付道路交通安全委员会开具的罚单！ 就在不久之前——感谢来自一家大型俄罗斯银行的同事们——我们检测到了一个新的木马样例“Faketoken.q”，它有很多有趣的特性。

感染

我们目前还无法重建导致感染的整个事件链，不过程序的图标显示出，恶意程序是通过群发带有图片下载链接的短信传播的。

木马结构

木马程序经过检测分为两部分，第一部分是经过混淆处理的程序释放器（Trojan-Banker.AndroidOS.Fyec.az）为了防止被检测，其中的文件都在服务器端做了混淆处理，粗略看的话，根本看不出什么。

然而，这肯定是能正常运行的正确的代码。它会对恶意程序的第二部分进行解密并运行。这是现在最流行的方式，如今已经没多少不经过处理的木马了。 恶意程序的第二部分是DAT格式的文件，它是木马程序的核心功能文件，当然数据已经被加密了。 对数据进行解密后，会得到可读性还不错的代码。

在木马程序初始化后，它会隐藏自己的图标并监视全部通信和用户启动的程序。每当打一个电话/接到一个电话，它就会把它记录下来并发给攻击者。

Faketoken.q的作者对原恶意程序的覆盖面进行了保留与简化，目前木马能够监控几个银行和一些日常应用比如Android Pay，Google Play Store以及支付交通罚单，订机票，宾馆，出粗车的应用。

每当用户启动木马监控的程序时，Faketoken.q就会迅速用假界面替换掉真界面，并且假界面与真界面一模一样，诱骗用户输入银行卡账号密码。 这些被攻击的应用为了支付方便通常都绑定了银行卡，有些甚至是强制绑定，这些应用的安装量达到了几百万的规模，Faketoken也因此能造成巨大的危害。 那么，接下来问题就出现了：当诈骗者要完成一次诈骗支付时，他们怎么得到银行发到用户手机上的验证码呢？攻击者通过将用户收到的每一条短信转发到C&C服务器上解决了这个问题。

我们目前认为手中的样本是还未完成的程序，它的假界面做的还不够好，不足以让用户受到欺骗。

现如今大量的App使用屏幕覆盖技术（windows Managers，Messengers等），这可能会被攻击者利用，并且防范起来非常复杂。 直到现在，我们也没有收到关于Faketoken大量攻击的报告，也就是说，这目前只是一个测试版。通过木马中的俄语界面以及代码中的俄语，我们推测Faketoken.q主要针对的是俄罗斯及独联体国家。

防范

为了防范Faketoken以及类似的恶意程序，应坚决不安装第三方的安卓应用，使用手机杀毒软件和应用锁也会有一些帮助。

MD5

CF401E5D21DE36FF583B416FA06231D5

译者：WisFree

预估稿费：140RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

写在前面的话

今天我们将给大家分析一个恶意HTML文档，这份HTML文档声称“如果用户想要查看UPS收据的话，则必须要下载一款兼容插件”。这个HTML文档中使用了HTML、javascript和混淆技术，接下来我们会带大家一步一步地分析这些恶意内容。

恶意文件细节

文件名：UPS-Receipt-008533234.doc.html

保护机制：经过混淆处理的HTML+JavaScript，以及UPX Exe

MD5：762B0F20C80995D3AC8A66716011C156

样本下载：【点我下载】

类型：钓鱼+木马下载器

演示视频：https://youtu.be/GGXAmRRZcL4

细节分析

首先我们打开这个HTMl文档，此时我们将看到页面中的钓鱼信息。钓鱼信息表示，用户如果想要使用Office 365来查看UPS收据的话，则必须要下载一个兼容插件。

在对HTML文档的代码进行分析之后我们发现，其中所有的组件都包含在一个经过了Base64编码的文件中，而且该文件不需要引用任何外部图片或资源。

如果我们点击了页面中间的蓝色按钮并下载所谓的“兼容插件”，那么该页面将会下载一个ZIP文件。实际上它并不是通过外部网站下载的，因为这个ZIP文件本来就存在于这个HTML文档中。

在对这个ZIP文件进行分析之后，我们发现了一个JavaScript文件，而这个JS文件的文件名会诱使用户更加相信这是一个Office 365的兼容插件。

对这个JavaScript文件进行了分析之后，我们发现其中的JS代码经过了混淆处理，而代码的主要功能就是从五个单独域名的其中一个下载一份文件。这些域名保存在一个数组中，并且通过一个WHILE循环来在数组中选择需要通信的域名，最后将域名信息追加到变量"cvetk"的末尾，而这个文件就是接下来需要下载的文件了。

其中的GET请求所收到的响应为“HTTP错误301，页面永久移除”的错误信息：

但是这个HTTP 301错误信息所下载的文件又是另一个经过混淆处理的JavaScript文件，而这个文件所采用的混淆处理模式比之前的要好得多。

我们发现，这个文件似乎包含的只有一个逐渐追加的变量。下面给出的是我们在文本编辑器中处理了代码格式后的结果：

这个脚本又会生成另一个脚本，而第二个脚本则会通过结尾的EVAL来运行。为了提取出这个动态生成的脚本，我们将所有的"goxe"变量连接了起来，然后留下了如下所示的字符串（与结尾的EVAL有关）：

我们可以对这个字符串的格式进行进一步的调整，并得到可读性更强的脚本代码，接下来我们就能够使用WSCRIPT来对脚本进行调试了：

经过了格式化处理之后，我们就可以使用命令" wscript.exe //X file.js"来对这个JavaScript文件进行调试了。我们可以从代码调试的过程中看到，这个脚本会随机生成一段文本文字，并将其显示在Office文档中。

接下来，这个Office文档会写入目标系统的磁盘中并运行，其实这个Office文档的作用就是为了分散用户的注意力而已。这个文档中包含的是一堆不可读的文本信息（乱码），具体如下图所示：

接下来，我们就要分析这种恶意活动中的钓鱼行为了，实际上其最终目的就是为了在目标用户的计算机中下载一个恶意木马。我们在脚本代码中发现，该脚本会选择五个域名中的其中还一个，并在末尾追加一个非常长的字符串变量。

在对代码中嵌套的FOR循环进行仔细分析之后你会发现，每一次请求之后都会在拼接好的URL结尾添加一个字符变量。如果这里没有添加字符变量的话，你将会再次下载第二步骤中的脚本。如下图所示，红色部分标记的就是追加的字符：

GET请求的响应结果是一个PNG文件，但是却被保存为了一个EXE可执行文件：

最终被下载下来的文件是一个使用UPX封装(UPX (the Ultimate Packer for eXecutables)是一款先进的可执行程序文件压缩工具，压缩过的可执行文件体积缩小50%-70%，这样减少了磁盘占用空间、网络上传下载的时间以及存储费用)的可执行文件，这个文件在VirusTotal上已经有很多次检测实例了。你可以使用免费的UPX工具来对这个可执行文件进行拆封。即使这个文件采用了UPX封装，但反病毒引擎仍然能够识别出该文件就是著名的勒索软件Locky：

注入的恶意文件

1.Install-MSOffice365-WebView-Plugin-Update-0.165.11a.exe.js

网络流量

http://gritfitnesstraining.com/counter/?aD75cxs-h1cis8VurT7CP6OVC5sTkggkP0tfQOUHTZJ9jheseaWP4EpglrB8_TqDYQwKRq7j-PFz10hrfTJb5Xn8o0CJzI-OYIZKKs5__bDnNcQ9WWenNAo-RXFy0

http://amirmanzurescobar.com//counter/?aTZJ9jheseaWP4EpglrB8_TqDYQwKRq7j-PFz10hrfTJb5Xn8o0CJzI-OYIZKKs5__bDnNcQ9WWenNAo-RXFy2

检测结果

初始感染向量：【检测结果-CSV】

译者：我来学英语

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

这篇文章将带你了解TI的本质是什么，进一步探索如何在powershell和NtObjectManager模块的帮助下获取TI权限，以便在操作系统中完成任何你想要的操作。

如果你曾管理过windows系统，那么你应该知道trustedInstaller（TI）组的概念，大部分对系统文件和注册表的操作都需要TI组权限。举个例子，你可以看一下System32文件夹下的文件的属性，在安全选项下TI和文件Owner可以删除和修改文件（甚至管理员都不能），所以你不能直接对安全选项进行修改。

什么是TrustedInstaller

如果TI既不是用户又不是组那它又是什么？查询ACL会给我们一些启示。你可以使用Get-Acl命令来读取一个文件的安全描述，同时我们可以列出TI信息。

SID本身是服务名的大写表示的SHA1值，下面这段代码就可以计算真实的SID值：

成为TrustedInstaller

如果你搜索过如何删除TI拥有的资源，你一般会得到这样的结果：它会告诉你首先要获取文件或者密钥的所有权，然后再更改DACL来添加管理员组。这是因为即使是兼容IFileOperation UAC COM的组件通常也不会自动运行，并且会弹出下面这个对话框：

你也许会想，我可以把当前用户添加到TI组中。不幸的是像NetLocalGroupAddMembers这样的LSASS api不使用SID，修改注册表值NT SERVICE\TrustedInstaller同样无效。因为它根本就不是一个真实的组，它是使用其他方法来创建的。也许你可以通过念一段神奇的咒语来完成这件事，或者至少使用底层的RPC调用，但我认为这么做不太值得。

因此，修改TI服务设置的最快方法是通过改变设置来运行一个其他的二进制文件。奇怪的是，TI服务使得系统上的文件很难被随意修改，但是它却不保护它自己，修改它的操作可以以一个普通管理员的权限完成。所以你可以使用下面的命令来删除任意文件

作为管理员，我们可以调用SeDebugPrivilege函数来打开TI进程和它的token。然后我们就可以做任何事情了，试一下吧：

因此，有两种很简单的方法来绕过这种权限限制，并且不需要任何新的或者修改过的或者注入过代码的服务。我们首先来看创建新进程的问题。一个进程的父进程会调用CreateProcess，对于UAC来说，这将提升子进程的权限，这看起来有些奇怪。为了支持微软所介绍的Vista中的最小权限原则，通过创建新进程时都会显式指定一个父进程，以便权限提升后的进程仍然是调用者的子进程。

在不创建新进程的情况下模拟token也很有用。有没有方法实现呢？有。我们可以使用NtImpersonateThread API，它允许从现有的线程中捕获上下文，并且可以应用到另一条线程中。模拟上下文工作的过程是，内核首先尝试捕获该线程的token，如果线程没有token，那么内核将通过模拟来复制与线程相关进程的token。而NtImpersonateThread API的美妙之处在于，设置父进程时不需要访问token的权限，它只需要THREAD_DIRECT_IMPERSONATION模拟访问一个线程，这一点我们只需要使用SeDebugPrivilege就可以做到。因此，可以通过以下步骤来获得一个不产生新进程的模拟线程：

以至少PROCESS_QUERY_INFORMATION的权限打开一个进程，枚举其线程

以THREAD_DIRECT_IMPERSONATION权限打开进程中的第一条线程

调用NtImpersonate Thread来获取一个模拟token

总结

希望这篇文章能给你一些启示，了解什么是TrustedInstaller，掌握以管理员身份获取TI组token的方法，当然，获取TI组token这种操作在正常情况下是做不到的。这种方法适用于现代Windows操作系统上的不同系统服务，如果你想与它们的资源进行交互来进行测试的话，比如使用沙箱工具来获取它们所拥有的资源时，你就可以用到本文所提到的方法。

译者：WisFree

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

写在前面的话

近期，趋势科技的安全研究专家在Google Play应用商店中发现了一款自动点击型恶意软件，这款恶意广告软件名叫GhostClicker，它的影响范围非常大，目前在大约有Google Play应用商店中大约有340多款移动端应用程序感染了GhostClicker。

值得注意的是，其中有一款感染了GhostClicker的应用程序名叫“Aladdin’s Adventure’s World”，而这款App的下载次数目前已经达到了五百万次。除此之外，嵌入了这款恶意广告软件的应用程序种类还包括休闲游戏、设备性能工具（例如清理工具或加速工具）、文件管理器、二维码/条形码扫描工具、多媒体录音器/播放器、以及一些与GPS定位导航相关的应用程序。

虽然绝大部分感染了GhostClicker的应用程序目前均已从Google Play应用商店下架，但是在2017年8月7日时仍然有101个相关App仍可从Google Play应用商店中下载获取。根据我们的检测工具以及传感器数据显示，目前GhostClicker的活动主要在巴西、日本、台湾、俄罗斯、意大利、美国和部分东南亚国家比较频繁。

GhostClicker分析

根据这款恶意广告软件的特性，即它不仅能够完成自动点击任务并隐藏在Google移动设备服务（GSM）之中，而且它还使用了Google当前最流行的应用程序编程接口（API），趋势科技的研究人员将这种恶意软件标记为了GhostClicker（ANDROIDOS_GHOSTCLICKER.AXM）。除此之外研究人员还发现，GhostClicker甚至还可以隐藏在Facebook的广告软件开发套件（Facebook Ad SDK）之中。为了避免自己被安全产品检测到，它会将自己伪装成一个合法的应用程序组件（伪装成一个名叫“logs”的包），然后将自己嵌入在这两个服务（即Google的API以及Facebok的SDK）之中。

下图显示的是Google Play应用商店中的一款嵌入了GhostClicker的应用程序，我们可以看到其下载量/安装量已经达到了五百万次：

下图显示的是GhostClicker隐藏在GMS以及Facebook Ad SDK之中的代码：

虽然GhostClicker感染范围比较大，而且其持久化感染的能力也比较强，但是它也非常“挑食”，因为它在运行的过程中还有各种各样的要求。比如说在启动的时候，受感染的应用程序需要获取设备的系统属性（http.agent），而这个属性是用来配置安卓设备的User-Agent字符串的。如果这个字符串中包含“nexus”字样的话，GhostClicker进程将不会被触发。趋势科技的研究人员则认为，这种运行机制的目的是为了逃避沙盒检测，例如安卓操作系统内置的安卓应用程序沙箱（Android Application Sandbox），因为安卓模拟器或沙盒环境一般都命名为“Nexus XXX”。

下图显示的是当设备http.agent属性中不包含字符串“nexus”时，GhostClicker的触发和运行过程：

在趋势科技所分析的受感染应用程序中，某些感染了GhostClicker的App在第一次运行时还会请求获取设备的管理员权限，但是它们并不会给用户声明程序的安全策略以及管理员权限的用途（例如擦除数据或重置密码）。除此之外，GhostClicker还会增加卸载应用程序的难度，并通过这种方式来阻止用户删除那些感染了GhostClicker的应用程序。研究人员表示，当用户想卸载这些App时，卸载的过程会非常的不友好：首先，卸载App不仅需要用户拥有管理员权限，而且在卸载之前还需要先禁用App才行。

下图显示的是感染了GhostClicker的应用程序在请求设备管理员权限时的界面：

从下图中可以看到，某些用户在Google Play应用商店中报告称自己无法卸载App（感染了GhostClicker）：

研究人员表示，GhostClicker目前主要通过自动点击欺诈来获取非法收入。但是与其他类型的恶意广告软件不同，GhostClicker在定位、获取和点击广告时并没有使用javascript代码，它主要通过向AdMob（Google自己的移动广告平台）注入自己的代码来获取到广告所在的位置。在获取到设备的屏幕尺寸（屏幕的宽度和高度）之后，它会计算出合适的X、Y坐标，然后使用dispatchTouchEvent API来模拟用户的点击行为。

为了赚取更多的收入，GhostClicker还会生成虚假流量。当用户点击Google Store中其他App的下载链接时它会弹出自己的窗口，而且它还可以通过后台的命令控制服务器（C&C）在受感染设备的浏览器中打开YouTube视频链接。在获取到了设备的管理员权限之后，GhostClicker每分钟都会重复执行这些自动点击操作。

下图显示的是GhostClicker注入在AdMob中的代码，这段代码用于获取AdMob的Context View：

下图显示的是GhostClicker计算生成的坐标信息：

下图显示的是GhostClicker根据X、Y坐标构建MotionEvent（模拟用户的点击行为）的相关代码：

下图显示的是GhostClicker使用dispatchTouchEvent API实现自动点击广告的代码：

本文所分析的GhostClicker样本仍为初级版本

趋势科技的研究人员通过对GhostClicker的跟踪分析后发现，GhostClicker当前的版本仍为初级版本。GhostClicker后来的版本似乎移除了自动点击功能以及设备管理员权限请求，这样做很可能是为了增加这款恶意广告软件的隐蔽性。当用户解锁手机屏幕之后，只要该设备接入了网络，那么GhostClicker将会定时（间隔一定的时间）弹出广告界面，而且我们在Aladdin’s Adventure’s World应用程序中发现的正是这种更新版本的GhostClicker。

在对这款恶意广告软件的活动时间线进行分析之后，我们还发现早在一年多以前就已经有应用程序感染了GhostClicker，而GhostClicker最早在2016年的8月份就已经感染了GMS的SDK了。从2017年3月份开始，GhostClicker去掉了自动点击功能，转而开始利用Admob、Startapp和Facebook Ads并通过接收C&C命令来弹出间隙广告。到2017年5月份，GhostClicker又将自动点击功能重新整合了进来，并且感染了Facebook Ad的SDK。

缓解方案以及最佳实践

虽然广告在移动端生态系统中是一种很容易被人们忽略的因素，但是GhostClicker的存在充分证明了广告也可以成为网络犯罪分子的攻击向量。恶意广告软件的侵略性不言而喻，再加上这些恶意软件会消耗掉目标设备的大量资源（CPU、电池和流量等等），因此恶意广告软件也逐渐成为了一种非常严重的安全威胁。除此之外，它们还会在用户毫不知情的情况下收集目标用户的个人数据，并使用户的隐私暴露在安全风险之中。最最重要的是，恶意广告软件还有可能让用户感染上真正的恶意软件，而此时用户面临的将不仅仅是恶意广告那么“简单”的问题了。

首先，我们可以通过限制设备管理员功能/权限来缓解GhostClicker所带来的威胁。一般来说，设备管理员功能主要适用于一些安全程序，例如反病毒产品，而一般的用户基本上是不需要使用这些权限和功能的。

其次，用户需要定期更新设备的操作系统，并遵循设备制造商给出的安全使用建议。企业用户在使用公司设备或在BYOD环境中时同样需要做到这些。除此之外，当你在下载一款应用程序时，请一定要先看一看其他用户对这款应用程序的评论，如果这款应用程序有问题的话，你肯定能够在评论区中发现的。

总结

目前，趋势科技的研究人员已经将该威胁上报给了Google的安全团队，并且正在与Google的技术人员配合将Google Play上的受感染App下架。

注：关于GhostClicker的入侵威胁指标（IoC）、相关哈希（SHA256）、包名以及App标签等内容，请参考【附录】。

2017年8月17日，多个内容分发网络（CDN）和内容提供商遭受了来自被称为WireX的僵尸网络的重大攻击。该僵尸网络由其命令和控制(C2)协议中的一个分隔符字符串而得名。 WireX僵尸网络主要包括运行恶意应用程序的Android设备，而这些恶意应用程序主要用于制造DDoS流量。

前几天，Google被警告称这个恶意软件存在其Play商店中。不久之后，Google删除了数百个受影响的应用程序，并开始从所有设备中删除该恶意应用程序。

来自Akamai，Cloudflare，Flashpoint，Google，Oracle Dyn，RiskIQ，Team Cymru和其他组织的研究人员共同合作打击了这个僵尸网络。有迹象显示这个僵尸网络可能早在8月2日就已经开始活跃，但直到8月17日的攻击才引起了这些组织的关注。这篇文章代表了研究人员的共同智慧和努力，他们以互联网社区的整体利益为重，分享了关于此次僵尸网络的信息。本文是由来自多个组织的研究人员共同撰写的，由Akamai，Cloudflare，Flashpoint和RiskIQ同时发布。

攻击细节

WireX僵尸网络的最早的活动出现在8月2日，因为当时的攻击比较轻微，因此并没有被注意到。 直到研究人员开始在日志中搜索26字符的User-Agent字符串才发现。 这些初始攻击很小，表明恶意软件正处于发展阶段或部署的初期阶段。 持续时间更长的攻击从8月15日开始，这些事件源自至少7万个并发IP地址，如图1所示。

图1：根据参与攻击的每小时观察到的唯一IP数量，僵尸网络的预计增长

WireX是应用层的DDoS攻击。 攻击节点生成的流量主要是HTTP GET请求，有些变体似乎能发出POST请求。 换句话说，僵尸网络产生类似于普通HTTP客户端和Web浏览器的有效请求的流量。

通过初始观察，发现了通过使用包含小写英文字母字符的HTTP请求的User-Agent字符串，并以随机顺序来区分来自该僵尸网络的大部分流量。

看到的一些User-Agent值：

还观察到恶意软件的变种发出不同长度和扩展字符集的User-Agent字符串，有的包括常见的浏览器User-Agents。 以下是其他User-Agents的一些示例：

追根溯源

对8月17日攻击数据的分析显示，来自100多个国家的设备参与了当前的僵尸网络，这点很不寻常。攻击IP的分布情况以及其独特的User-Agent字符串让当初调查的那些研究人员开始觉得其他组织可能已经看到或可能会遇到类似的攻击。于是研究人员与其他组织的同事们互相交流碰到的情况。

就这样一旦展开了更大规模的协同努力，调查便迅速开始展开。通过对历史日志信息进行分析，发现了攻击IP和恶意的连接，可能运行在Android操作系统之上。

在Mirai攻击之后，信息共享氛围已经出现了复苏，研究人员互相分享状况报告，并在必要时协同解决互联网问题。此外，WannaCry，Petya等全球性活动加强了这一合作的价值。诸如此类的许多信息共享组织完全是业界同行之间的非正式沟通。

找到恶意软件

调查8月17日攻击的日志显示，通过与之前的攻击比对签名，找到了具有相同签名的第一个Android应用程序“twdlphqg_v1.3.5_apkpure.com.apk”。 研究人员很快找到了该应用程序的样本以了解它的工作原理，并确定相关应用程序是否可能存在。 使用应用程序包中的应用程序名和参数的变体搜索可以显示来自相同或类似命名的作者的多个应用程序，他们具有相似的描述，如图2所示。找到新的应用程序之后，团队中的其他人就开始深入分析二进制文件来了解它们的工作原理。

图2：搜索相关恶意软件的截图

其实在移动设备预置的知名app store(像Google Play这样的)发现这样的应用的情况实属少见。联系上Google之后，Google迅速删除了违规内容。 谷歌做了以下评论作为对这项研究的回应：

恶意软件概览

安装这些攻击功能的应用程序虽然本来是恶意的，但似乎对已安装它们的用户来说是良性的。这些应用程序还利用了Android服务架构的特性，它允许应用程序即使在后台也可以使用系统资源，因此能够在应用程序未使用时启动攻击。杀毒工具目前将此恶意软件识别为“Android Clicker”特洛伊木马，但本次事件的目的与点击欺骗并无关系。这种恶意软件可能之前跟点击欺骗有点联系，但之后又被作为DDoS之用。

有关应用程序的流氓组件的内部部分的深入概述，请参见附录1。

总结

只有在DDoS攻击的目标(也就是受害者)，DDoS缓解公司和情报公司之间开放协作，才能得出这么多发现。对于这次事件的揭露，每个集体都扮演了不同的角色; 没有每个人的贡献，这个僵尸网络将一直是一个谜。

当发生DDoS攻击时，可以做的最好的事情就是分享与攻击相关的详细信息。有了这些信息，我们有能力干掉这个攻击的人才能更加了解它们。

这些指标包括数据包捕获，攻击IP地址列表，赎金笔记，请求标头以及任何有趣的模式。这样的数据不应包含任何合法的客户端流量，以减少隐私问题，并且还会导致合法流量污染和减缓分析。最重要的是，允许您分享这些数据，不仅仅是向您的供应商提供这些数据，而是向更广泛的安全社区的可信任的人分享这些数据。

向别人请求帮助并不可耻。不仅不可耻，而且其实大多数情况下，根本不可能隐藏你被DDoS攻击了这样的事实。一些研究工作有能力检测全球范围内针对第三方发生的DDoS攻击的存在，无论这些方面希望保持这个问题的安静。秘密和许多好处即将到来的好处很少。

共享详细的攻击指标还允许正式和非正式的信息共享组在全球范围内沟通和了解正在发生的攻击，而不仅仅是他们在自己的平台上看到的攻击。这份报告是一个例子，说明如何以非正式的形式分享可以对受害者和整个互联网产生巨大的积极影响。跨组织合作对于应对互联网的威胁至关重要，如果没有这种合作，刑事案件可以不经审查就能运作。

我们要感谢Akamai，Cloudflare，Flashpoint，Google，RiskIQ，Cymru团队以及其他未列出来的研究人员。我们也要感谢联邦调查局在这件事上的协助。

作者 & 研究员

Tim April : Senior Security Architect @ Akamai

Chris Baker : Principal of Threat Intelligence @ Oracle Dyn

Matt Carothers

Jaime Cochran : Security Analyst @ Cloudflare

Marek Majkowski : Enthusiastic Geek @ Cloudflare

Jared Mauch : Internetworking Research and Architecture @ Akamai

Allison Nixon : Director of Security Research @ Flashpoint

Justin Paine : Head Of Trust & Safety @ Cloudflare

Chad Seaman : Sen. Security Intelligence Response Team Engineer @ Akamai SIRT

Darren Spruell : Threat Researcher @ RiskIQ

Zach Wikholm : Research Developer @ Flashpoint

附录1：恶意软件详细分析

识别C2域名

还有其他一些有趣的组件，他们都有其独特的角色所在。

这里讨论的第一个组件类型作为基本的，永久的，持久化组件。 一些应用程序使用

功能实例化的Service对象。 其实就是使应用程序通过经常间隔轮询C2服务器的Service以实现持久化 ——即使应用程序是在后台运行的时候。 应用程序的其他变种使用AsyncTask对象可达到相同的目的。

第二个组件是用作C2攻击指令解析器的WebViewClient。 它负责检测来自由轮询服务控制的C2 WebView实例的onPageFinished事件，并解析返回的命令。 当攻击命令被成功解析后，这个组件就负责调用最终用来发起攻击的函数。

组件概述

Service Runner组件

Service Runner伪代码

AttackCommandParser是一个callback， 在C2 WebView检测到页面已经加载时触发。解析器加载页面的内容，并提取<title>标签中的内容作为攻击命令。 根据观察到的样本，来自C2的payload如下所示：

从<title>标签中提取出来的值作为参数传入到String->contains()，确保这个值包含token分隔字符串"snewxwri"。如果分隔符存在，就把内容trim一下，然后用split()分隔成包含几个部分的Array。最后得到的分隔后的值将作为参数传入到DDoS_Service->attack()方法中。

C2服务器端响应解析之后的伪代码

DDoS_Service组件就是用来发动攻击的核心组件了。它包含三个核心函数。它们的任务分别是：运行Service、调用poll_c2()方法加载C2的WebView，以及最重要的——发起攻击。我们先上伪代码，然后对这三个函数逐一进行分析。

DDoS Service伪代码

onCreate()方法直截了当：就创建了一个新的android/os/Handler以及ServiceRunner实例。其中ServiceRunner实例随后通过postDelayed()方法被hook到Handler上。根据Android官方文档的介绍，这"使得Runnable对象被添加到消息队列中，然后经过一段特定的时间之后被调用"。这个方法接收的第二个参数是在Runnable被调用之前需要经过的毫秒(ms)数。在这个例子里面就是2，也就是2ms，可见攻击者多么具有攻击性。

DDoS Service poll_c2()

poll_c2（）方法负责使用C2 URL不断重新加载WebView，同时将AttackCommandParser WebViewClient hook到轮询器WebView实例中。 在轮询C2域之前，这个Service将清除并禁用缓存，并清除WebView实例的历史记录。 执行这些步骤是为了确保客户端始终从C2获取最新信息，而不是从本地设备的缓存中。 在分析attack（）方法时，我们会看到这种策略再次被使用。

DDoS Service attack()

attack()方法负责生成实际的攻击流量。之前讨论的AttackCommandParser-> onPageFinished()将传递由最后一个C2交互发出的target，userAgent和referer值。此方法将创建一个HashMap对象，该对象将配置攻击期间使用的HTTP头。

一旦配置了headers，就会实例化一个空的WebView占位符数组，然后是一个循环，用实际的WebView实例来填充这个数组。每个实例都通过同一组配置过程。创建的WebView实例将具有其历史记录，保存的表单数据和缓存清除。启用JavaScript功能（默认情况下嵌入式WebViews通常被禁用），将使用C2攻击指令提供的值覆盖HTTP头中出现的User-Agent字符串，并将CacheMode设置为LOAD_NO_CACHE，这将强制浏览器实例绕过本地缓存，然后为每个请求获取目标URL。

最终确保设备上不会命中缓存，并将该请求发送到目标，应用程序在加载每个请求之前也会从设备中删除其本地的webview.db和webviewCache.db文件。

最后，我们看到使用目标URL和自定义的WebViewHeaders HashMap在新配置的WebView实例上调用了loadUrl()方法。

虽然许多已识别的应用程序已从Google Play商店中删除，但镜像仍然在线，我们可以从中下载APK文件。 我们将“twdlphqg”（其中一个攻击应用）加载到从2015年开始运行Android 5.0和安全补丁的三星Galaxy S4的设备上。

这个app与我们测试的其他app一样，使用的都是无害化的名称，如“设备分析工具”，“数据存储工具”“软件包管理器”等。

当应用程序运行时，它好像就是一个非常简单的铃声应用程序，只提供了三个铃声。 该应用程序可以播放和设置铃声，但没有其他功能。

然而在后台，这个应用程序产生了额外的进程，手机即使在锁屏的情况下，这些进程也会继续运行。 这允许应用程序在后台从手机端发起DDoS攻击。 当我们将手机放在充电器上让它睡眠时，它就会继续发起DDoS攻击。

值得注意的是，现在已经无法安装这个应用程序了，因为Google的PlayProtect功能现在已经阻止这个应用程序安装了。 Google也将其从已经安装的设备中删除。 我们测试的本次攻击事件中所有这些应用程序都弹出了下面的禁用对话框， 而禁用PlayProtect是运行恶意软件所必需的。

我们测试了此次攻击事件中的多个应用，它们在恶意行为和用户界面方面都有不同的变化，而他们也并不全是铃声应用。 另外所有测试都是在同一台手机上进行的。

来自DDoS统计数据的Xryufrix是最受欢迎的，但是在运行时，它的表现是压倒性的。可能存在兼容性问题，阻止其达到其完整的DDoS潜力。该应用程序在初次安装时要求较少的权限，但是要求与twdlphqg具有相同的锁屏相关设备管理员权限。这个人假装是一个YouTube应用程序。当它首次打开时，它会向axclick域查询DDoS攻击命令以及针对

的GET请求，它返回位于

的app的Play Store URL。当用户尝试播放Youtube视频时，此应用关闭，从应用列表中删除其图标，并且使它自己以后都无法执行，可能已经crash了。它还为“Luckybooster”应用程序打开了Play store的下载链接，它在运行时没有DDoS。 xryufrix应用程序在手机睡眠时不会启动DDoS攻击，在应用程序处于活动状态的任何一个时刻也不会启动DDoS攻击。

热点概要：WireX DDoS僵尸网络:大量被黑Android智能设备构成的DDoS之军、Adwind: 一个跨平台的远控工具(RAT)、Sarahah app 泄露用户隐私、安卓DDOS僵尸网络：The WireX Botnet、大量android恶意软件样本集、安全相关的优秀演讲集合、Domain Analyzer：自动发现并报告与给定域名相关的信息、web安全学习资料汇总

资讯类：

WireX DDoS僵尸网络:大量被黑Android智能设备构成的DDoS之军

http://thehackernews.com/2017/08/android-ddos-botnet.html

Adwind: 一个跨平台的远控工具(RAT)

https://abuse.ch/blog/adwind-a-cross-plattform-rat/

Sarahah app 泄露用户隐私

https://www.bishopfox.com/blog/2017/08/hot-new-anonymous-chat-app-hijacks-millions-contact-data/

http://thehackernews.com/2017/08/sarahah-privacy.html

技术类：

http://bobao.360.cn/learning/detail/4323.html

大量android恶意软件样本集

https://github.com/fs0c131y/Android-Malwares

https://github.com/ashishb/android-malware

安全相关的优秀演讲集合

https://github.com/PaulSec/awesome-sec-talks

https://github.com/CheckPointSW/android_unpacker

【视频】Black Hat USA 2017上的PowerShell混淆检测技术分享

https://www.youtube.com/watch?v=x97ejtv56xw

Schools Alert Management Script - Authentication Bypass

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

Intel ME : 静态分析之道

https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf

Domain Analyzer：自动发现并报告与给定域名相关的信息

https://github.com/eldraco/domain_analyzer

Web安全学习资料汇总

https://github.com/CHYbeta/Web-Security-Learning

UPX - the Ultimate Packer for eXecutables

https://github.com/upx/upx

PowerShell tool that uses WMI to extract saved session information for remote access

https://github.com/fireeye/SessionGopher

https://github.com/CalebFenton/simplify

2017年8月17日，多个内容分发网络（CDN）和内容提供商遭受了来自被称为WireX的僵尸网络的重大攻击。该僵尸网络由其命令和控制(C2)协议中的一个分隔符字符串而得名。 WireX僵尸网络主要包括运行恶意应用程序的Android设备，而这些恶意应用程序主要用于制造DDoS流量。

前几天，Google被警告称这个恶意软件存在其Play商店中。不久之后，Google删除了数百个受影响的应用程序，并开始从所有设备中删除该恶意应用程序。

来自Akamai，Cloudflare，Flashpoint，Google，Oracle Dyn，RiskIQ，Team Cymru和其他组织的研究人员共同合作打击了这个僵尸网络。有迹象显示这个僵尸网络可能早在8月2日就已经开始活跃，但直到8月17日的攻击才引起了这些组织的关注。这篇文章代表了研究人员的共同智慧和努力，他们以互联网社区的整体利益为重，分享了关于此次僵尸网络的信息。本文是由来自多个组织的研究人员共同撰写的，由Akamai，Cloudflare，Flashpoint和RiskIQ同时发布。

攻击细节

WireX僵尸网络的最早的活动出现在8月2日，因为当时的攻击比较轻微，因此并没有被注意到。 直到研究人员开始在日志中搜索26字符的User-Agent字符串才发现。 这些初始攻击很小，表明恶意软件正处于发展阶段或部署的初期阶段。 持续时间更长的攻击从8月15日开始，这些事件源自至少7万个并发IP地址，如图1所示。

图1：根据参与攻击的每小时观察到的唯一IP数量，僵尸网络的预计增长

WireX是应用层的DDoS攻击。 攻击节点生成的流量主要是HTTP GET请求，有些变体似乎能发出POST请求。 换句话说，僵尸网络产生类似于普通HTTP客户端和Web浏览器的有效请求的流量。

通过初始观察，发现了通过使用包含小写英文字母字符的HTTP请求的User-Agent字符串，并以随机顺序来区分来自该僵尸网络的大部分流量。

看到的一些User-Agent值：

还观察到恶意软件的变种发出不同长度和扩展字符集的User-Agent字符串，有的包括常见的浏览器User-Agents。 以下是其他User-Agents的一些示例：

追根溯源

对8月17日攻击数据的分析显示，来自100多个国家的设备参与了当前的僵尸网络，这点很不寻常。攻击IP的分布情况以及其独特的User-Agent字符串让当初调查的那些研究人员开始觉得其他组织可能已经看到或可能会遇到类似的攻击。于是研究人员与其他组织的同事们互相交流碰到的情况。

就这样一旦展开了更大规模的协同努力，调查便迅速开始展开。通过对历史日志信息进行分析，发现了攻击IP和恶意的连接，可能运行在Android操作系统之上。

在Mirai攻击之后，信息共享氛围已经出现了复苏，研究人员互相分享状况报告，并在必要时协同解决互联网问题。此外，WannaCry，Petya等全球性活动加强了这一合作的价值。诸如此类的许多信息共享组织完全是业界同行之间的非正式沟通。

找到恶意软件

调查8月17日攻击的日志显示，通过与之前的攻击比对签名，找到了具有相同签名的第一个Android应用程序“twdlphqg_v1.3.5_apkpure.com.apk”。 研究人员很快找到了该应用程序的样本以了解它的工作原理，并确定相关应用程序是否可能存在。 使用应用程序包中的应用程序名和参数的变体搜索可以显示来自相同或类似命名的作者的多个应用程序，他们具有相似的描述，如图2所示。找到新的应用程序之后，团队中的其他人就开始深入分析二进制文件来了解它们的工作原理。

图2：搜索相关恶意软件的截图

其实在移动设备预置的知名app store(像Google Play这样的)发现这样的应用的情况实属少见。联系上Google之后，Google迅速删除了违规内容。 谷歌做了以下评论作为对这项研究的回应：

恶意软件概览

安装这些攻击功能的应用程序虽然本来是恶意的，但似乎对已安装它们的用户来说是良性的。这些应用程序还利用了Android服务架构的特性，它允许应用程序即使在后台也可以使用系统资源，因此能够在应用程序未使用时启动攻击。杀毒工具目前将此恶意软件识别为“Android Clicker”特洛伊木马，但本次事件的目的与点击欺骗并无关系。这种恶意软件可能之前跟点击欺骗有点联系，但之后又被作为DDoS之用。

有关应用程序的流氓组件的内部部分的深入概述，请参见附录1。

总结

只有在DDoS攻击的目标(也就是受害者)，DDoS缓解公司和情报公司之间开放协作，才能得出这么多发现。对于这次事件的揭露，每个集体都扮演了不同的角色; 没有每个人的贡献，这个僵尸网络将一直是一个谜。

当发生DDoS攻击时，可以做的最好的事情就是分享与攻击相关的详细信息。有了这些信息，我们有能力干掉这个攻击的人才能更加了解它们。

这些指标包括数据包捕获，攻击IP地址列表，赎金笔记，请求标头以及任何有趣的模式。这样的数据不应包含任何合法的客户端流量，以减少隐私问题，并且还会导致合法流量污染和减缓分析。最重要的是，允许您分享这些数据，不仅仅是向您的供应商提供这些数据，而是向更广泛的安全社区的可信任的人分享这些数据。

向别人请求帮助并不可耻。不仅不可耻，而且其实大多数情况下，根本不可能隐藏你被DDoS攻击了这样的事实。一些研究力量是有能力检测全球范围内针对第三方发生的DDoS攻击的存在的，无论这些第三方多么想要对这件事保持沉默。保持沉默并不能带来多少好处，需要积极地面对啊。

共享详细的攻击指标还允许正式和非正式的信息共享组在全球范围内沟通和了解正在发生的攻击，而不仅仅是他们在自己的平台上看到的攻击。这份报告是一个例子，说明如何以非正式的形式分享可以对受害者和整个互联网产生巨大的积极影响。跨组织合作对于应对互联网的威胁至关重要，如果没有这种合作，刑事案件可以不经审查就能运作。

我们要感谢Akamai，Cloudflare，Flashpoint，Google，RiskIQ，Cymru团队以及其他未列出来的研究人员。我们也要感谢联邦调查局在这件事上的协助。

作者 & 研究员

Tim April : Senior Security Architect @ Akamai

Chris Baker : Principal of Threat Intelligence @ Oracle Dyn

Matt Carothers

Jaime Cochran : Security Analyst @ Cloudflare

Marek Majkowski : Enthusiastic Geek @ Cloudflare

Jared Mauch : Internetworking Research and Architecture @ Akamai

Allison Nixon : Director of Security Research @ Flashpoint

Justin Paine : Head Of Trust & Safety @ Cloudflare

Chad Seaman : Sen. Security Intelligence Response Team Engineer @ Akamai SIRT

Darren Spruell : Threat Researcher @ RiskIQ

Zach Wikholm : Research Developer @ Flashpoint

附录1：恶意软件详细分析

识别C2域名

还有其他一些有趣的组件，他们都有其独特的角色所在。

这里讨论的第一个组件类型作为基本的，永久的，持久化组件。 一些应用程序使用

功能实例化的Service对象。 其实就是使应用程序通过经常间隔轮询C2服务器的Service以实现持久化 ——即使应用程序是在后台运行的时候。 应用程序的其他变种使用AsyncTask对象可达到相同的目的。

第二个组件是用作C2攻击指令解析器的WebViewClient。 它负责检测来自由轮询服务控制的C2 WebView实例的onPageFinished事件，并解析返回的命令。 当攻击命令被成功解析后，这个组件就负责调用最终用来发起攻击的函数。

组件概述

Service Runner组件

Service Runner伪代码

AttackCommandParser是一个callback， 在C2 WebView检测到页面已经加载时触发。解析器加载页面的内容，并提取<title>标签中的内容作为攻击命令。 根据观察到的样本，来自C2的payload如下所示：

从<title>标签中提取出来的值作为参数传入到String->contains()，确保这个值包含token分隔字符串"snewxwri"。如果分隔符存在，就把内容trim一下，然后用split()分隔成包含几个部分的Array。最后得到的分隔后的值将作为参数传入到DDoS_Service->attack()方法中。

C2服务器端响应解析之后的伪代码

DDoS_Service组件就是用来发动攻击的核心组件了。它包含三个核心函数。它们的任务分别是：运行Service、调用poll_c2()方法加载C2的WebView，以及最重要的——发起攻击。我们先上伪代码，然后对这三个函数逐一进行分析。

DDoS Service伪代码

onCreate()方法直截了当：就创建了一个新的android.os.Handler以及ServiceRunner实例。其中ServiceRunner实例随后通过postDelayed()方法被hook到Handler上。根据Android官方文档的介绍，这"使得Runnable对象被添加到消息队列中，然后经过一段特定的时间之后被调用"。这个方法接收的第二个参数是在Runnable被调用之前需要经过的毫秒(ms)数。在这个例子里面就是2，也就是2ms，可见攻击者多么具有攻击性。

DDoS Service poll_c2()

poll_c2()方法负责使用C2 URL不断重新加载WebView，同时将AttackCommandParser WebViewClient hook到轮询器WebView实例中。 在轮询C2域之前，这个Service将清除并禁用缓存，并清除WebView实例的历史记录。 执行这些步骤是为了确保客户端始终从C2获取最新信息，而不是从本地设备的缓存中。 在分析attack()方法时，我们会看到这种策略再次被使用。

DDoS Service attack()

attack()方法负责生成实际的攻击流量。之前讨论的AttackCommandParser-> onPageFinished()将传递由最后一个C2交互发出的target，userAgent和referer值。此方法将创建一个HashMap对象，该对象将配置攻击期间使用的HTTP头。

一旦配置了headers，就会实例化一个空的WebView占位符数组，然后是一个循环，用实际的WebView实例来填充这个数组。每个实例都通过同一组配置过程。创建的WebView实例将具有其历史记录，保存的表单数据和缓存清除。启用JavaScript功能（默认情况下嵌入式WebViews通常被禁用），将使用C2攻击指令提供的值覆盖HTTP头中出现的User-Agent字符串，并将CacheMode设置为LOAD_NO_CACHE，这将强制浏览器实例绕过本地缓存，然后为每个请求获取目标URL。

最终确保设备上不会命中缓存，然后将该请求发送到目标，应用程序在加载每个请求之前也会从设备中删除其本地的webview.db和webviewCache.db文件。

最后，我们看到使用目标URL和自定义的WebViewHeaders HashMap在新配置的WebView实例上调用了loadUrl()方法。

虽然许多已识别的应用程序已从Google Play商店中删除，但镜像仍然在互联网上，我们可以从那里下载APK文件。 我们将“twdlphqg”（其中一个攻击应用）加载到从2015年开始运行Android 5.0和安全补丁的三星Galaxy S4的设备上。

这个app与我们测试的其他app一样，使用的都是无害化的名称，如“设备分析工具”，“数据存储工具”“软件包管理器”等。

当应用程序运行时，它好像就是一个非常简单的铃声应用程序，只提供了三个铃声。 该应用程序可以播放和设置铃声，但没有其他功能。

然而在后台，这个应用程序产生了额外的进程，手机即使在锁屏的情况下，这些进程也会继续运行。 这个特性允许应用程序在后台从手机端发起DDoS攻击。 当我们将手机放在充电器上让它睡眠时，它就会继续发起DDoS攻击。

值得注意的是，现在已经无法安装这个应用程序了，因为Google的PlayProtect功能现在已经阻止这个应用程序安装了。 Google也将其从已经安装的设备中删除。 我们测试的本次攻击事件中所有这些应用程序都弹出了下面的禁用对话框， 而禁用PlayProtect是运行恶意软件所必需的。

我们测试了此次攻击事件中的多个应用，它们在恶意行为和用户界面方面都有不同的变化，但他们也并不全是铃声应用。 另外所有测试都是在同一台手机上进行的。

来自DDoS统计数据的Xryufrix是最受欢迎的，但是在运行时，它的表现是惊人的。可能是由于兼容性的问题，妨碍了它达到其完整的DDoS攻击力。该应用程序在初次安装时仅需要较少的权限，但是要求与twdlphqg具有相同的锁屏相关设备管理员权限。这个恶意软件想伪装成一个YouTube应用程序。当它首次打开时，它会向axclick域查询DDoS攻击命令以及针对

的GET请求，它返回位于

的app的Play Store URL。当用户尝试播放Youtube视频时，此应用关闭，从应用列表中删除其图标，并且使它自己以后都无法执行，可能已经crash了。它还为“Luckybooster”应用程序打开了Play store的下载链接，它在运行时没有DDoS。 xryufrix应用程序在手机睡眠时不会启动DDoS攻击，在应用程序处于活动状态的任何一个时刻也不会启动DDoS攻击。

作者：ch4r0n

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

0x01 前言

小夏是一名普通Mac用户，某天，他打算试试思维导图来记录工作学习。

他问同事小芳：“Mac下有啥好用的思维导图软件？”

小芳：“XMind呀，很实用的思维导图软件。”

小夏：“那到哪里下载，要钱吗？”

小芳：“哎，你百度XMind破解版呀! 不需要花钱的，直接安装!”

小夏：“这么方便！我试试！”

这些所谓的破解版真的安全么?

0x02 样本概述

Xmind是一款实用的思维导图软件，正版官网售价高达99刀, 这个价格当然对普通用户无法承受, 通过搜索，很多站点都提供了破解版下载

对比相同版本号的正版和破解版, hash如下:

我们发现该样本采集了用户的很多隐私信息, 上传到了第三方服务器,采集信息如下图

1、黑产非法售卖用户信息, 泄漏用户隐私

2、广告推广, 获取盈利

3、钓鱼执法, 发送侵权律师函

4、etc

下面我们对该样本详细分析

0x03 基本信息

在Mac应用中，OSX系统下的Mach-O是可执行文件格式，程序跑起来解析Mach-O，然后链接系统的库文件以及第三方动态库。

我们使用MachOView进行解析

在可执行文件 Load Commands 字段中记录了程序的加载指令，LC_LOAD_DYLIB是程序加载的动态库，其中Name字段记录了该动态库的路径，通常程序启动会根据该字段加载动态库。这里发现其加载了新增的两个动态库文件libcJFishPoolHook.dylib、libXMindHook.dylib。除此之外，XMind使用Java编写，移植到Mac平台，可执行文件也没有什么值得重点分析。

总结一下，主要做了如下事情:

1、程序启动初始化，获取资源文件。

2、加载.ini配置文件，得到启动的参数键值对。

3、将参数解析，然后运行加载Library（Java打包的动态库）.

直接对比正版和破解版的包目录, 在包中我们发现了多出来的2个dylib文件

libC.JFishPoolHook.dylib

libXMindHook.dylib

下面对这2个dylib进行详细分析

0x04 dylib分析

对于Mac/iOS中使用到的dylib，可以使用class-dump和hoppper结合进行反汇编分析。class-dump又是一款开源解析MachO利器，与MachOView相似的是，他可按照MachO偏移量，找寻符号表（Symbol Table），从而导出类名和方法名，但是他提供了诸多参数用于导出不同架构的MachO链接符号表。使用如下命令导出类名方法名到文件中：

从导出结果来看，很可疑的是CJFishPoolHook类，该类有多达16个成员， 写该动态库的程序员非常老实，没有进行任何加密、混淆类名、方法名的操作，因此从字面上也不难猜出其含义为qq号、微信号、手机号、邮箱号、操作系统、CPU类型、内存、MAC地址、内网IP、公网IP、用户名、应用列表、设备ID，是否上传信息、开启应用和关闭应用的时间。

第二个动态库的类方法较少，很明显能猜出，hook了程序的函数，修改程序运行逻辑。

主要方法为:

1、init初始化方法

2、ExChangeImp，Method Swizzling动态交换函数指针，用于hook

3、BuyHook

4、CheckUpdatesHook

5、HelpHook

6、TitleHook

7、OpenURLHook

8、DateMenuItemHook

最后还使用了一个加密方法方法，该方法传入第一个参数（明文），第二个参数key用于加密内容。

0x05 抓包分析

通过上面的简单分析不难猜测, 他把采集的信息发送到服务端了, 通过抓包分析该样本与服务端通信的过程如下：

第一次向服务端发送了checklocked, 返回值为0, 说明可以传输设备信息

接下的data是用来上传用户信息的。Body是经过AES加密后base编码的密文，既然key已经有了，可以尝试解开请求密文

通过静态分析我们知道他使用了AES加密算法, 而key就硬编码在代码中

结合上述过程，了解到加密算法的第一个参数为kCCEncrypt，第二个为kCCAlgorithmAES128，第三个为加密的填充模式kCCOptionECBMode。 依据此我们写出的AES解密方法应该为：

key为：iMdpgSr642Ck:7!@

解开的密文为

下面我们看看该样本是如何获取这些用户隐私的。

0x06 静态分析

用户隐私收集

CJFishPoolHook.dylib中会获取用户的隐私信息, 其流程如下

在应用初始化过程中，单例类的CJFishPoolHook执行初始化Init，随后，在Init方法中进行初始化成员操作，包含上述的16个信息。

在初始化过后，开启捕获用户信息startCapture。这其中包含获取用户联系方式（getContact），获取设备信息（getDevice），判断设备是否需要上传信息（checkLocked），获取应用ID（getProduct），获取设备上的应用列表（getFeature），获取地理位置（getLocation），获取启动时间（getHabitStart）。

最后一步，上传所有数据到服务器，并且使用AES加密算法加密http body。

恶意收集QQ信息, 电话, 微信号，应用列表

应用从/Library/Containers/com.tencent.qq/Data/Library/Application Support/QQ目录获取个人QQ信息。在该目录下，保存着用户的临时聊天记录，截图等信息。

从/Applications遍历本机安装的应用，形成应用列表。

恶意推广

libCJFishPoolHook.dylib修改了更新xmind的官方网站, 推广其自己的广告站点

进程注入后，使用Method Swizzling挂钩MenuItem、Button等按钮，使其失效或重定向跳转到其他网站，屏蔽注册、激活检查更新功能。难怪启动应用后发现激活按钮失效，无法进行版本更新，购买激活产品却跳转到另一个网站。

0x07 小结

本次的逆向分析过程清晰，单从网络传输和静态分析上就能了解到该重打包应用运行状态的全部过程。对此公司搜集用户信息的这种行为，不想做过多评价。

主要还是从两个方面进行总结，对于开发者而言，要了解一些基本的防御手段，注重网络传输安全、存储安全，在开发过程中，尽量不要把key明文编码于程序中，哪怕是将二次编码后的key放到应用内也好。我们无法得知软件是否会被破解，key是否会泄露，而一旦暴露出来，则很容易被利用从而解开密文信息。更有甚者，直接使用base编码内容、数据位亦或运算编码，这种更容易被分析。同时我们可以混淆加密、反调试等手段增加软件破解的难度。另一方面，站在用户的角度，下载安装未经验证的软件，是一件很危险的事情，例如著名的XcodeGhost事件，其实就是开发者安装了非官方验证的开发软件，导致开发的程序带有后门，窃取和上传大量用户信息。

本文所述的只是个人信息安全的一角，但却不能忽视他的存在。就同本文中libCJFishPoolHook命名一样，真正的含义是鱼塘，软件使用者是鱼，养在破解者的鱼塘中，等鱼养大了，也该收网了。

过去六年间，Mac销量越来越高，也意味着苹果用户越来越多。而用户一多，生态圈内的软件产出势必增长, 同时也会出现更多恶意软件浑水摸鱼

Mac恶意软件发展历史

我们发现很多Mac用户对自身的安全并不是很重视，针对用户的恶意软件逐渐增多，窃取用户的隐私, 监控用户的日常行为, 恶意推广广告, etc。因此，我们应该提高自身的安全意识, 警钟长鸣。

译者：興趣使然的小胃

预估稿费：300RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

一、前言

Windows上的进程属于一种安全的对象，可以阻止已登录Windows主机的某个用户危害其他用户的进程。至少从非管理员的用户角度来看，这是一种非常重要的安全特性。在这种安全特性下，非管理员用户无法破坏任何进程的完整性。然而，这种安全屏障在针对管理员、特别是具有调试（Debug）权限的管理员时会显得捉襟见肘，因为启用这种权限后，管理员就可以无视进程拥有的安全属性，打开任意进程。

在某些情况下，应用程序或者操作系统希望能够保护进程免受用户的影响，这些用户包括管理员用户，甚至在某些情况下，包括当前进程对应的具有完全访问权限的同一个用户。因此，许多解决方案使用了内核支持的（kernel support）特性来实现这种保护机制。在大多数情况下，这种实现方案仍然会存在缺陷，我们可以利用这些缺陷来突破“受保护”的进程。

在本文中，我们会介绍Oracle的VirtualBox在进程保护方面的具体实现方法，也会详细介绍如何通过三种方法绕过这种保护机制，将任意代码注入到进程中（这三种方法目前已被修复）。本文所展示的技术同样可以应用在类似的进程“保护”机制上。

二、Oracle VirtualBox进程防护机制

想在用户模式下完全实现进程的保护几乎是不可能的一件事情，现在有很多方法可以将数据注入到某个进程中。特别是当你想要保护的进程正运行在你想要阻止的用户的上下文环境中时，进程保护更加难以实现。比如，攻击者可以使用PROCESS_CREATE_THREAD访问权限打开某个进程的句柄，然后直接插入一个新的线程，或者攻击者可以使用THREAD_SETCON_TEXT访问权限打开进程中的线程，然后直接修改指令指针（Instruction Pointer）以跳转到任意地址，这些都是直接的攻击方式。攻击者也可以修改进程所处的注册表或者环境，强迫进程加载任意COM对象或者Windows挂钩（Hook）。攻击者能够做的修改操作可以说是不胜枚举的。

因此，VirtualBox（VBOX）借用了内核的帮助来保护它的进程。这种保护机制在源代码中对应的是进程加固（Process Hardening）技术。VBOX会尝试保护进程免受当前所属的同一用户的影响。我们可以在源代码注释中找到详细的解释以及技术概述。在这段注释的开头部分详细描述了VBOX内核驱动方面的保护机制，VBOX内核驱动中包含大量方法，这些方法可以用来突破内核或者至少可以用来提升权限。这也是为什么VBOX要去保护其进程免受当前用户的修改，因为如果用户可以访问VBOX内核驱动，那么就可以以此为据点，获取内核或系统权限。虽然某些进程保护机制也会阻止管理员控制当前进程，但这并不是进程加固代码的目标。

我的同事Jann从设备访问角度开展研究，在linux系统的VBOX驱动及保护机制上发现过许多问题。在Linux上，VBOX限制了只有root才能访问VBOX驱动，然后利用SUID二进制程序赋予VBOX用户进程访问驱动的权限。VBOX驱动在Windows系统没有使用SUID程序，而是使用内核API来尝试阻止用户以及管理员打开受保护的进程，阻止他们注入代码。

内核组件的核心位于Support\win\SUPDrv-win.cpp文件中。这段代码注册了Windows内核支持的两种回调机制：

1、PsSetCreateProcessNotifyRoutineEx。当新进程创建时，驱动就会得到通知。

2、ObRegisterCallback。当进程以及线程句柄创建或者复制时，驱动就会得到通知。

从PsSetCreateProcessNotifyRoutineEx发出的通知可以用来配置新创建进程的保护结构。随后，当进程尝试打开VBOX驱动的句柄时，加固机制会调用supHardenedWinVerifyProcess函数，确保如下验证步骤通过后才允许相应的访问动作：

1、确保没有调试器附加到进程上。

2、确保进程中只有一个线程，并且该线程是打开驱动的唯一线程，以避免出现进程内竞争（in-process races）问题。

3、确保除了一小部分允许的DLL之外，没有其他可执行的内存页面。

4、验证所有已加载的DLL的签名。

5、验证主执行文件的签名，确保该文件为允许的执行文件类型（如VirtualBox.exe）。

VBOX将自定义运行时代码编译到驱动中，依靠这部分代码完成内核中的签名校验工作。这个过程中，只有很少一部分可信根（Trusted Roots）才能通过校验，主要包括微软的操作系统及代码签名（Authenticode）证书，以及用来签名所有VBOX程序的Oracle证书。你可以在官方的代码仓库中找到可信的证书列表。

ObRegisterCallback通知用来限制系统上其他用户进程对被保护进程的访问权限范围。ObRegisterCallback API主要是针对反病毒服务设计，以避免反病毒进程被恶意代码注入或者终止。VBOX使用了类似的方法，限制受保护进程的句柄只能具备如下访问权限：

PROCESS_TERMINATE

PROCESSVMREAD

PROCESSQUERYINFORMATION

PROCESSQUERYLIMITED_INFORMATION

PROCESSSUSPENDRESUME

DELETE

READ_CONTROL

SYNCHRONIZE

这些访问权限可以赋予用户通常需要的大多数权限，比如他们可以读取内存、同步进程以及结束进程，然而他们无法将新的代码注入到进程中。类似地，用户对线程的访问权限也被限制在如下范围，以阻止对线程上下文的修改或其他类似攻击：

THREAD_TERMINATE

THREADGETCONTEXT

THREADQUERYINFORMATION

THREADQUERYLIMITED_INFORMATION

DELETE

READ_CONTROL

SYNCHRONIZE

为了证实这一点，我们可以打开VirtualBox的进程或者其中某个线程，查看我们获得的访问权限。我们获得的有关进程以及线程的访问权限如下图高亮部分所示。

虽然内核回调能够阻止对进程的直接修改，也能阻止用户在进程启动时破坏进程的完整性，然而内核回调对运行时的DLL注入攻击（如通过COM实现的DLL注入）显得有点乏力。进程加固机制需要确定哪些模块可以被载入到进程中。对可载入模块的筛选主要是通过Authenticode代码签名来实现。

现在已经有一些方法可以确保只加载经过微软签名的二进制文件（比如PROCESS_MITIGATION_BINARY_SIGNATURE_POLICY方法），然而，这种策略不是特别灵活。因此，受保护的VBOX进程会安装一些钩子（hook），hook用户模式下的几个内部函数，以验证将要载入内存的DLL的完整性。被hook的函数为：

LdrLoadDll。调用该函数来将DLL加载到内存中

NtCreateSection。调用该函数来为磁盘上的PE文件创建一个Image Section对象。

LdrRegisterDllNotification。这是一个准官方支持的回调函数，当新的DLL被加载或卸载时，该函数就会通知应用程序相关事件。

这些钩子扩大了可被加载的经过签名的DLL的范围。由于内核中只包含Oracle以及微软代码，因此可以通过签名验证，能够用来引导进程。然而，当运行某个较为特别的应用时（VirtualBox.exe显然是个特别的应用），我们可能就需要加载第三方签名的代码（比如GPU驱动）。由于这些钩子位于用户模式下，因此程序可以很方便地调用系统的WinVerifyTrust API函数，使用系统证书库来验证证书链，也可以验证使用Catalog（.cat）文件签名的那些文件。

如果正在加载的某个DLL无法满足VBOX预期的签名标准，那么用户模式下的钩子就会拒绝加载这个DLL。VBOX仍然没有完全信任该用户，WinVerifyTrust会将证书链接回用户的CA证书中的根证书。然而，VBOX只会信任系统的CA证书。由于非管理员用户无法将新的可信根证书添加到系统的CA证书列表中，因此使用这种方法就可以大大限制恶意DLL的注入攻击。

当然，你可以使用合法的经过认证的签名证书，这样应该就能被程序信任，但一般情况下恶意代码不会走这条路。即使代码经过签名，加载程序同样会验证这个DLL文件是否属于TrustedInstaller用户所有。这个验证过程由supHardNtViCheckIsOwnedByTrustedInstallerOrSimilar来实现。除了自己以外，普通用户无法将文件的所有者改成其他人，因此这样就能限制加载任意签名文件可能造成的危害。

VBOX代码中的确存在一个函数（supR3HardenedWinIsDesiredRootCA），可以限制哪些证书能够成为根证书。在官方发行版中，虽然这个函数中与CA白名单有关的代码已经被注释掉，然而却存在一个黑名单列表，只要你的公司名不叫做“U.S. Robots and Mechanical Men, Inc”，那么这个黑名单就不会影响到你。

即使存在这些保护机制，对管理员而言，进程仍然处于不安全的状态。虽然管理员无法绕过打开进程时存在的安全限制条件，但是他们可以在本地主机中安装一个Trusted Root CA证书，签名一个DLL文件，设置DLL文件的所有者然后强制加载该DLL。这种方法可以绕过镜像验证机制，将镜像加载到经过验证的VBOX进程中。

稍微总结一下，VBOX加固机制尝试提供如下几种保护措施：

1、确保在受保护程序初始化过程中，没有任何代码可以插入进来。

2、阻止用户进程打开受保护进程或线程的“可写”句柄，因为这种句柄可以实现任意代码注入。

3、阻止不可信DLL通过常见的加载方法（如COM）进行注入。

整个保护过程很有可能会存在一些bug或者没考虑到的边缘情况。这个过程中，有这么多不同的验证检查操作，这些检查必须全部满足。因此，假如我们不想申请一个合法的代码签名证书，我们也不具备管理员权限，那么这种情况下，我们要如何才能实现在受保护VBOX进程中运行任意代码？我们会重点关注第三种保护措施，因为这可能是所有保护措施中最为复杂的一种，因此很有可能存在最多的问题。

三、利用COM注册中的信任链（Chain-of-Trust）

我想介绍的第一个漏洞为CVE-2017-3563漏洞，这个漏洞在VBOX 5.0.38/5.1.20版本中被修复。该漏洞利用了DLL加载中存在的信任链（chain-of-trust）问题，诱导VBOX加载经过微软签名的DLL，最终实现不可信任意的代码执行。

如果运行Process Monitor来观察受保护的VBOX进程，你会发现该进程使用了COM，更具体来说，该进程使用了在VBoxC.dll COM服务器中实现的VirtualBoxClient类。

从攻击者的角度来看，COM服务器注册最有用的地方，在于COM对象的注册操作可以在两个地方完成，即用户的注册表中或者本地主机（local machine）注册表中。出于兼容性方面的考虑，系统会优先查找用户的注册表，然后再查找本地主机注册表。因此，在普通用户权限下，攻击者可以覆盖COM注册操作，此时当某个应用程序试图加载指定的COM对象时，就会加载我们刚刚覆盖的任意DLL。

劫持COM对象并不是一种新颖的技术，这种技术已经存在多年，许多恶意软件利用这种技术来实现持久化目的。随着众人重拾对COM的兴趣，这种技术又再度出现在公众视野中。然而，除了UAC绕过之外，COM劫持很少用来权限提升场景中。

除此之外，UAC以及COM劫持之间还存在着联系，COM运行时会主动去防止劫持技术用于权限提升（EoP）场景，采用的具体方法是，如果当前进程处于高权限下，那么COM运行时就会禁用特定的用户注册表的读取。当然这种方法不是每次都能成功。只有当你将UAC当成一种安全防御屏障时，这种方法才行之有效，然而微软坚称他们从来没有也永远不会承认过这个观点。例如，2007年初的这篇文章就明确指出这种方法是用于阻止权限提升操作。在我看来，COM的这种查找行为清楚地表明，UAC的设计初衷就是想成为一道安全屏障，然而，它并没有实现这一目标，因此只好被重新包装，用来帮助“开发者”开发更好的代码。

如果我们可以将自己的代码替换COM注册，那么我们应该就能实现在受保护的进程中运行代码。从理论上讲，所有的加固签名检查步骤应该都会阻止我们加载不可信的代码。在实际的研究过程中，我们还是应当具体尝试一下我们觉得会失败的那些操作，万一梦想实现就会收获巨大惊喜。经过尝试后，我们至少可以了解保护机制的具体工作流程。我在用户注册表中注册了一个COM对象，来劫持VirtualBoxClient类，将其指向一个未签名的DLL（实际上我使用了某个管理员账户将DLL的所有者改成TrustedInstaller，当然这只是为了测试方便）。当我尝试启动虚拟机时，程序弹出了如下对话框。

可能我在COM注册时犯了点错误，然而在另一个独立的应用程序中测试这个COM对象时，却显示一切正常。因此，这个错误很有可能意味着程序无法加载DLL。幸运的是，VBOX非常慷慨，默认就提供了所有进程加固事件的日志。日志名为VBoxHardening.log，位于当前虚拟机目录中的Logs文件夹中。在日志中查找DLL的名字，我们得到如下日志条目（我做了大量精简操作，以方便说明）：

因此，可以确认的是我们的测试DLL没有签名，所以LdrLoadDll hook拒绝加载这个DLL。LdrLoadDll hook返回了一个错误代码，这个代码会传递给COM DLL加载器，导致COM认为该类不存在。

虽然事情并不是简单通过指定自己的DLL就能完成（别忘了我们还修改了DLL的所有者属性），但这至少给了我们一丝希望，因为结果表明VBOX进程还是会使用我们劫持过的COM注册。因此，我们需要的就是满足以下条件的一个COM对象：

1、由可信证书进行签名。

2、所有者为TrustedInstaller。

3、当加载时，可以实现在进程中执行任意代码。

条件1以及条件2很容易就能满足，系统中所有的微软COM对象都经过可信证书签名（微软内置的某个发行商证书），并且大多对象的所有者为TrustedInstaller。然而，条件3看起来非常难以满足，COM对象通常是在DLL内部实现的，我们不能修改DLL文件，否则文件就会变成未签名状态。我们最终还是找到了这样一个文件，这是一个默认安装的经过微软签名的COM对象，可以帮助我们满足条件3，这就是Windows脚本组件（Windows Script Components，WSC）。

WSC有时候也称之为Scriptlets（脚本小程序），是可以利用的优秀运行载体。从HTTP URL加载时，我们可以使用WSC来绕过AppLocker。在这里，最让我们感兴趣的是它们也可以注册为COM对象。

经过注册的WSC包含如下两个部分：

1、WSC运行时：scrobj.dll，承担进程内部的COM服务器角色。

2、包含Scriptlet实现的一个文件，由兼容的脚本语言编写而成。

当某个应用程序试图加载注册后的类时，scrobj.dll就会加载到内存中。这个COM运行时会请求对应类的一个新对象，导致WSC运行时会在注册表中查找与Scriptlet文件对应的那个URL。然后，WSC运行时会加载Scriptlet文件，在进程中执行文件内部包含的脚本。这里最关键的一点是，从VBOX角度来看，只要scrobj.dll（还有其他相关的脚本语言库，如JScript.dll）是合法的DLL签名文件，那么脚本代码就会得到运行机会，因为VBOX的加固代码永远不会去检查这些脚本代码。这样我们就能实现在加固进程内部运行任意代码的目的。首先，我们来确认scrobj.dll的确可以被VBOX加载。如下图所示，这个DLL经过微软的签名，并且其所有者为TrustedInstaller。

那么，有效的Scriptlet文件应该满足什么格式？Scriptlet文件是简单的XML文件，我不会去详细阐述每个XML元素所代表的含义，只会重点突出其中涉及任意JScript代码的脚本段。在这个例子中，当被加载时，Scriptlet会启动计算器（Calculator）进程：

.NET运行时使用了常规的DLL加载方法来将代码加载到内存中。因此我们不能加载未签名的 .NET DLL，因为VBOX加固代码会拦截这种行为。然而，.NET提供了一种Assembly::Load方法，利用这种方法可以通过内存中的数组来加载任意代码，并且一旦加载完成，这段代码看起来就如同原生代码（native code）一样，可以调用任意API、检查或修改内存。由于 .NET平台经过微软的签名，因此我们需要做的就是从我们的Scriptlet文件中调用Load方法，然后我们就可以在进程内部获得完整的任意代码执行权限。

为了实现这个目标，我们应该从哪里开始呢？根据之前一篇文章的研究结果，我们可以通过注册方式将.NET对象导出为COM对象，再通过二进制序列化（Binary Serialization）方法，从字节数组中加载任意代码。许多.NET核心运行时类已经被自动注册为COM对象，脚本引擎可以加载并修改这些对象。现在，我们需要确定的是，BinaryFormatter究竟有没有导出为COM对象？

事实证明的确如此。BinaryFormatter是一个.NET对象，脚本引擎可以通过COM来加载这个对象并与之交互。现在，我们可以直接使用上一篇文章的二进制流，从内存中执行任意代码。在上一篇文章中，不可信代码的执行必须在反序列化过程中完成，在本文案例中，我们可以与脚本中的反序列化结果交互，这样一来，我们需要做的序列化操作就会大大简化。

最后我选择反序列化一个Delegate（委托）对象，当脚本引擎执行这个对象时，就会从内存中加载一个Assembly（程序集），并返回Assembly实例。然后，脚本引擎可以实例化Assembly中的一个Type实例，运行任意代码。原理上听起来很简单，实际操作起来还是有许多事项需要注意。我不想在这篇文章里面讲述具体的细节，以免打断整体节奏，你可以访问此链接获取DotNetToJScript这个工具，顺便了解工具的工作原理。此外，你可以访问此链接获取PoC代码。从JSciprt组件到调用VBOX驱动的过程大概如下所示：

现在你已经可以在受保护进程中运行任意代码，我不会详细介绍利用VBOX驱动可以做哪些事情，这是另一个话题。当然你可以参考Jann写的另一篇文章，其中介绍了这种情况下，你可以在Linux系统上做的一些操作。

Oracle如何修复这个问题？他们添加了一个DLL黑名单，在黑名单中的DLL无法被受保护的VBOX进程加载。目前，这个名单中仅包含scrobj.dll这个文件。当开始验证文件时，程序就会验证文件是否位于黑名单中，程序会对当前文件名及版本资源内部的原始文件名（Original Filename）进行检查。这样就能防止用户通过重命名文件绕过黑名单，并且版本资源数据位于签名的PE数据中，攻击者无法在不破坏签名的前提下修改内部的原始文件名。坦诚说来，除了DLL黑名单机制，我也想不出来有其他较好的方法能够阻止这类攻击。

四、利用用户模式下的DLL加载方式

我想介绍的第二个漏洞为CVE-2017-10204漏洞，这个漏洞在VBOX 5.1.24版本中被修复。该漏洞利用了Windows DLL加载器以及VBOX中的某些错误，诱导VBOX加固代码将未经验证的DLL加载到内存中并加以执行。

虽然这个漏洞不需要依赖前面描述过的COM加载逻辑，但用户模式下的COM加载技术的确非常好用，可以使用任意路径来调用LoadLibrary函数。因此我们会继续利用这种技术来劫持VirtualBoxClient COM对象，利用进程内的服务器路径来加载DLL。

LoadLlibrary是一个Windows API，该函数存在大量已知的非常奇怪的行为。就我们看来，其中最为有趣的一个行为就是该函数在文件扩展名方面的处理逻辑。根据具体扩展名的不同，LoadLibrary API在加载文件之前，可能会添加或移除相应的扩展名。为此，我用一个表稍微总结了一下，表中显示了传递给LoadLibrary的具体扩展名以及该函数真正尝试加载的那个文件。

在上表中，我用绿色高亮了两种比较重要的情况。这两种情况下，传递给LoadLibrary的文件名与最终加载的文件名不一致。这里的问题在于，任何程序想在加载DLL之前验证该文件的话，就会用到CreateFile函数，而该函数并不会遵循我们高亮的那两种情况。因此在这两种情况下，如果我们使用原始文件名来打开文件并做签名校验，实际上我们最终加载的是另一个文件，因此我们要对另一个文件做签名校验。

在Windows中，普通代码与Kernel32代码之间通常存在明显的分离界限，Kernel32代码主要是负责处理Win32平台上已存在多年的许多奇怪行为，也负责处理内核通过NTDLL对外提供的“纯净”的NT逻辑层。由于LoadLibrary的实现位于Kernel32中，而LdrLoadDll的实现位于NTDLL中（LdrLoadDll也是VBOX加固代码所hook的那个函数），因此，前面提到的扩展名处理逻辑应该由前者来负责。我们可以分析一下简化版的LoadLibrary，看情况是否如此：

从这段代码中可知，不论具体情况如何，LoadLibrary只是LdrLoadDll的一个封装函数。虽然实际代码比上述代码更为复杂，但简而言之，当LdrLoadDll将文件路径传递给LdrLoadDll时，LoadLibrary并没有作修改，只是将其转换为UNICODE_STRING形式的字符串而已。因此，如果我们传入一个没有扩展名的DLL时，VBOX会检查无扩展名的文件的签名，而LdrLoadDll会使用.DLL扩展名来加载文件。

在我们开始测试之前，我们需要解决另一个问题，即文件的所有者需为TrustedInstaller。为了让VBOX检查我们所提供的文件的签名，我们只需要将某个已有的、经过合法签名的文件重命名即可，这个任务可以交给硬链接（hard links）来完成。我们可以在某个可控的目录中创建一个不同的文件名，该文件实际上指向的是某个经过签名的系统文件，同时还可以维持文件的原始安全描述符属性（包括文件所有者属性）。正如我在两年前的一篇文章中提到的那样，硬链接存在的问题是，虽然Windows支持创建指向系统文件的链接（当然你无法以写权限打开这些系统文件），然而Win32 API以及在CMD命令行中使用的“mklink”命令都需要以FILE_WRITE_ATTRIBUTES访问权限打开目标文件。我们不想使用其他程序来创建硬链接，因此我们复制了目标文件，但复制操作会修改文件的原始安全描述符，使得该文件所有者不再为TrustedInstaller。为了解决这一问题，我们来检查一下验证代码，看有没有方法能绕过这个难题。

文件所有者的检查主要在supHardenedWinVerifyImageByLdrMod函数中完成。这个函数做的第一件事情基本上就是调用supHardNtViCheckIsOwnedByTrustedInstallerOrSimilar函数，后者我们在之前已经见到过。然而，正如在源码中注释部分说明的那样，这段代码还允许使用System32以及WinSxS目录下所有者不为TrustedInstaller的那些文件。这些位置对检查过程来说简直是非常广阔的可利用点，我们要做的只是找到System32下可写入的一个目录。我们可以利用我开发的NtObjectManager PS模块中的Get-AccessibleFile cmdlet来找到这些目录。

如上所述，有很多目录可以为我们所用，我们选择了Tasks目录作为目标，因为这个目录肯定会存在。因此，漏洞利用过程包含如下步骤：

1、将某个已签名的程序拷贝到%SystemRoot%\System32\Tasks\Dummy\ABC

2、将某个未签名的程序拷贝到%SystemRoot%\System32\Tasks\Dummy\ABC.DLL

3、注册COM劫持，将进程内的服务器指向步骤1中的已签名的文件路径。

如果你启动虚拟机，你会发现上述步骤的确能够成功。VBOX加固代码会检查ABC文件的签名，但LdrLoadDll最终加载的是ABC.DLL。为了确认我们没有利用涉及其他操作，我们来检查一下加固代码的日志：

前两行表明文件所有者属性的检查的确已被绕过，如我们预期的那样。接下来的两行表明程序验证通过ABC文件的签名，因此会调用LdrLoadDll，后者会添加文件的扩展名，尝试加载ABC.DLL。稍等，为什么NtCreateSection以及加载回调函数（Loader Callback）没有捕捉到程序正在加载一个完全不同的文件？我们可以在加固日志中搜索ABC.DLL，看一下具体发生了什么：

前面两行依然说明，我们文件所处的位置使得我们绕过了文件所有者的检查。接下来的一行，有关supHardenedWinVerifyImageByHandle的日志显得更为有趣。这个函数用来验证镜像文件。我在上文展示的日志中提到过这个函数，当时这个函数返回的是-22900，这个值表明有错误发生。然而，在上面的日志中，这个函数返回的是22900，VBOX将任何大于等于0的返回值都当成成功的返回值，加固代码没见过这种返回值，因此也会认为这个文件为有效的文件。在源代码中，负值的错误代码为VERR_LDRVI_NOT_SIGNED，正值的“成功”代码为VINF_LDRVI_NOT_SIGNED。

貌似验证代码在调用DLL Loader Lock中的代码时存在错误，这与NtCreateSection中的hook情况类似。当代码尝试加载另一个DLL时，它就无法调用WinVerifyTrust，因此会发生死锁现象。通常情况下，内部签名检查代码会返回VINF_LDRVI_NOT_SIGNED。现有的代码实现只能处理具有内嵌签名的文件，因此如果某个文件没有经过签名，程序就会返回一个信息代码，促使验证代码来检查文件是否经过catalog（.cat）签名。正常情况下，WinVerifyTrust会被调用，如果文件仍然没有经过签名，那么该函数就会返回错误代码。然而，由于死锁问题，WinVerifyTrust无法被调用，因此信息代码会广播给调用者，作为成功代码加以使用。

最后一个问题，为什么最终的加载回调函数没有捕捉到未签名的文件？VBOX基于文件路径实现了一种签名文件缓存机制，以避免某个文件被多次检查。当程序认为supHardenedWinVerifyImageByHandle调用成功时，就会调用supR3HardenedWinVerifyCacheInsert，将该路径添加到缓存的“成功”结果中。我们可以观察到，在加载器回调函数中，程序尝试验证文件，但会从缓存中得到一个“成功”代码，因此会假设一切正常，从而加载过程可以顺利完成。

这一过程涉及到许多交互操作，那么Oracle如何修复这个问题？如果DLL文件没有扩展名，Oracle就会添加相应的扩展名。此外，Oracle针对另一种文件名情况也作了相应处理（加载DLL时会删除文件名尾部的附加字符）。

五、利用内核模式下的镜像加载方式

我想介绍的最后一个漏洞为CVE-2017-10129漏洞，这个漏洞在VBOX 5.1.24版本中被修复。该漏洞实际上并不算是VBOX的漏洞，因为它属于Windows的一种异常行为。

我们需要注意的是，加固代码中存在隐式的条件竞争现象，具体说来，我们可以在验证点以及文件映射点之间修改文件。从理论上讲，我们可以将这种操作应用于VBOX上，但可利用的时间窗口非常短。我们可以选择使用OPLOCK（机会锁）以及类似机制，但这类机制有点麻烦，还不如使用TOCTOU（time-of-check-to-time-of-use）攻击方法。

我们来看看镜像文件在内核中的处理过程。在Windows上执行镜像文件的映射操作是非常麻烦的一件事情，操作系统没有使用位置无关的代码，因此无法将DLL作为简单的文件直接映射到内存中。相反的是，DLL必须重新定位到特定的内存地址。这个过程需要修改DLL文件对应的内存页面，以确保任何相关的指针都被正确修复。当涉及到ASLR时，这个步骤显得更为重要，因为ASLR基本上都会强迫DLL在其基地址基础上进行重新定位。因此，只要条件允许，Windows就会缓存镜像映射的实例，这也是为什么DLL的加载地址在同一个系统的不同进程中不会发生变化的原因，因为它使用的是同一个缓存镜像数据。

缓存实际上位于文件系统驱动的控制之下。当某个文件被打开时，IO管理器会分配FILE_OBJECT结构体的一个新实例，将该实例传递给驱动的IRPMJCREATE处理程序。驱动可以初始化里面的SectionObjectPointer字段。这个字段对应的是SECTIONOBJECTPOINTERS结构体的一个实例，该结构体的定义如下所示：

这些字段本身由缓存管理器负责管理，但结构体本身必须由文件系统驱动来进行分配。更具体的是，每个文件在文件系统中都对应着不同的分配操作。虽然对某个文件而言，每个打开实例都具有不同的FILE_OBJECT实例，但SectionObjectPointer只有一个。这样一来，缓存管理器就可以填充结构体中的不同字段，当同一个文件的另一个实例需要映射时，缓存管理器就能重新使用这些字段。

这些字段中，比较重要的字段是ImageSectionObject，该字段包含映射镜像数据所对应的缓存数据。我不会去深入分析ImageSectionObject指针所包含的具体细节，因为这与文章主题关系不大。重要的是，如果某个FILE_OBJECT实例对应的SectionObjectPointer以及ImageSectionObject指针完全一致，那么将该文件映射为镜像的话，也会映射已缓存的相同镜像。然而，当读取某个文件时并没有用到ImageSectionObject指针，因此系统并没有去检查缓存与硬盘上的实际文件是否相匹配。

在NTFS卷环境下，想要取消SectionObjectPointer的文件数据同步是非常棘手的一件事，特别是当我们没有管理员权限时更是如此。在某种场景下，我们在访问网络共享时，可以借助SMB转向器（redirector）实现数据去同步目的。原理非常简单，当打开远程服务器上的文件时，需要由本地转向器来负责分配SectionObjectPointer结构体的实例。就转向器而言，如果它分两次打开服务器上的“\Share\File.dll”文件，那么它会认为这两个文件属于同一个文件。转向器没有额外的信息可以使用，无法判断文件的真实身份，因此只能靠猜测来执行具体操作。因此，你能想到的所有属性（比如对象ID（Object ID）、修改时间等）都可能是虚假信息。你可以修改SAMBA的副本来实现欺骗目的。此外，转向器无法锁定文件，也无法确保文件处于锁定状态。因此，转向器似乎放弃了这个任务，如果它看到了同一个文件，那么它就会认为一切都处于正常状态。

然而，这种场景仅适用于SectionObjectPointer，如果调用者想读取文件的内容，那么SMB转向器就会退出这种场景，尝试去读取文件的当前状态。此时依然存在虚假信息的可能，因为服务器还是可以返回任意数据。这也是我们为什么能完成去同步化任务，如果我们从SMB服务器上映射某个镜像文件，修改文件底层数据，然后重新打开这个文件，再次映射这个镜像，那么被映射的镜像对应的是已缓存的那个镜像，但读取的数据来自于服务器上的当前文件。这样一来，我们可以先映射一个不可信的DLL，然后将这个文件替换为经过签名的有效文件（SMB支持读取文件的所有者信息，所以我们也能实现伪造所有者为TrustedInstaller的目的），当VBOX试图加载这个文件时，它会验证经过签名的文件，但会映射已缓存的不可信镜像，然而它自己却没有意识到这一点。

很多时候我们无法使用远程服务器，然而我们可以使用本地环回（loopback）SMB服务器，然后通过admin共享（admin$）来访问文件。admin共享其实名不副实，如果我们从本地主机来访问，那么除管理员之外的用户也可以访问这个共享资源。完成这一任务的关键是使用目录连接（Direcory Junction）技术。Junction点由服务器负责解析，转向器无法获取Junction点的任何信息。因此，在客户端看来，如果客户端之前打开过“\localhost\c$\Dir\File.dll”这个文件，然后重新打开这个文件，那么这两次打开的文件可能是完全不同的文件，整个流程如下图所示：

幸运的是，根据前面两个问题的分析结果，我们知道VBOX的加固代码并不在意DLL文件的具体位置，只要能够满足两个条件即可，即文件所有者为TrustedInstaller且文件经过合法签名。我们可以将COM劫持指向本地系统中的某个SMB共享。因此，我们可以按照如下步骤实施攻击：

1、在C:盘上设置一个junction点，将其指向我们不可信文件所在的那个目录。

2、在c$ admin共享的junction点上使用LoadLibrary映射这个文件，在攻击过程结束之前，不要释放映射文件。

3、修改junction点，将其指向一个有效的经过签名的文件，文件名与我们不可信文件的文件名一致。

4、将COM劫持指向这个文件，然后启动VBOX。VBOX会读取文件，验证文件经过签名并且文件所有者为TrustedInstaller，然而当它使用这个文件时，实际上使用的是已缓存的不可信的镜像数据。

那么Oracle如何修复这个问题？Oracle会将文件路径与“\Device\Mup”前缀进行对比，以验证映射的文件是否位于网络共享中。

六、总结

VirtualBox中实现的进程加固机制非常复杂，因此也非常容易出错。我敢肯定的是，只要人们用心去寻找，还能找到其他方法来绕过进程保护机制。当然，如果Oracle不想保护VirtualBox内核驱动免受恶意攻击场景利用，那么这一切都不是问题，然而这属于设计理念问题，短时间内很难解决。

译者：紫曦归来

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

简介

今年4月曝光的CVE-2017-0199漏洞，可在无需用户交互的情况下，直接打开Word文档就可以通过HTA脚本执行任意代码。此漏洞的成因主要是Word在处理内嵌OLE2LINK对象时，通过网络更新对象时没有正确处理Content-Type所导致的一个逻辑漏洞。

近日，Cisco Talos团队发现，有黑客组织将CVE-2017-0199漏洞与较早前的CVE-2012-0158漏洞合并，以逃避Word的安全提示，或通过使用不同的机制以达到强制执行的目的。还有一种可能，那就是黑客仅仅是想测试一种新的漏洞概念。但无论出于哪种目的，使用组合漏洞的黑客都犯了错误而导致攻击效果远远低于预期。

通过对组合漏洞的文档载荷进行分析，研究者发现内嵌OLE2LINK对象具有被利用的潜力，除了可被用于Word文档，还可用于其他文档。但目前，大众对于这点的认识显然不够。

当前，黑客已开始寻找绕开系统发出的安全警告的方式。这篇报告详细分析了黑客如何合并CVE-2017-0199和CVE-2012-0158两个漏洞，并将其置于一条感染链之中。报告还将对组合漏洞失败的原因进行剖析。

虽然组合漏洞的攻击失败了，但这种尝试确实是一种具有开创性的新尝试。攻击者企图利用CVE-2017-0199作为“挡箭牌”，从而绕过系统提示。但从目前效果来看，这种尝试作用不大，还有待进一步完善。

标准CVE-2017-0199漏洞利用

标准的CVE-2017-0199漏洞利用一般包含邮件分发和一个带有嵌入式恶意脚本的假RTF文件。攻击者通过电子邮件向目标用户发送含有OLE2嵌入式链接对象的Microsoft Word文档。

图1：标准CVE-2017-0199漏洞

当用户打开文档时，winword.exe将会向远程服务器发出HTTP请求，以获得恶意HTA文件。服务器返回的文件是一个带有嵌入式恶意脚本的假RTF文件。winword.exe通过COM对象查找application/hta的文件处理程序，从而导致Microsoft HTA应用程序（mshta.exe）加载并执行恶意脚本。恶意脚本将终止winword.exe进程，下载其余的payload，并加载诱饵文件。之所以要终止原始的winword.exe进程，是为了掩盖OLE2link生成的用户提示。该提示具体如图1所示。

图2：Word向用户发出的提示

升级后的CVE-2017-0199漏洞

攻击者此次对CVE-2017-0199漏洞进行了升级，黑客攻击行动最初也是从一份包含恶意程序的邮件开始的。邮件采用了一般的诱骗手段促使用户打开并阅读包含恶意程序的附件。一般此类包含恶意程序的垃圾邮件会伪装成用户合作伙伴的采购订单。

图3：发起攻击的邮件范例

在对其中一个Word样本进行研究时，研究者发现在系统显示CVE-2017-0199的系统提示之前，word会自动对下载文档转换格式。在这之后，word程序会自动暂停，并最终崩溃（如下图所示）。

图4：Word程序崩溃

Word程序的崩溃不是因CVE-2017-0199漏洞导致的，而是由于CVE-2012-0158漏洞。下图所示即MSComctlLib.ListViewCtrl.2 ActiveX的嵌入式指令，这就是典型的CVE-2012-0158漏洞。指令由一串ROP链开始，当漏洞被激活，指令就开始自动运行。在ROP链为包含其他指令的内存块设置正确的权限之后，漏洞指令的第一阶段就开始自动执行。

图5：CVE-2012-0158漏洞第一阶段的指令

CVE-2012-0158漏洞第一阶段的指令就是导致Word崩溃的罪魁祸首！但或许是因为攻击者技术方面仍存在短板，所以导致后续的漏洞运作出现问题。

该shellcode将调用数个API函数地址，通过暴力破解文件句柄号（handle number）来遍历所有文件。这一过程将从句柄号为0的文件开始，每次递增4个句柄号打开新的文件。如果句柄存在，shellcode将利用GetFileSize API函数检测文件大小。如果文件大小符合预期，shellcode将记录该文件，进行文件类型检测。

图6：检查文档大小和确定文档类型

漏洞指令的失误就在于，如果找到的是一个RTF文件，那么所有的条件就符合了，找到的这个RTF文件也将包含另一串指令。如果寻找到的文档类型和大小满足要求，那么下一个步骤就是读取该文档，以寻找下一串指令。但在我们的试验中，这一步就失败了，因为原始的CVE-2017-0199漏洞利用文件还储存在系统之中。这一文件满足之前提到过的几个条件。由于CVE-2017-0199漏洞利用文件先于CVE-2012-0158文件打开，CVE-2017-0199漏洞利用文件的句柄较小，这就导致他被首先读取。

图7：第一阶段指令开始搜索下一阶段指令标记

漏洞指令开始在错误的文档搜索下一个指令的标记0xfefefefefeffffffff，这就会最终导致内存保护错误（memory protection error）。如果漏洞制造者技术更好，他就会意识到这一错误并进行相应更正。因为只要同时运行两个漏洞利用文件就会运行成功。

一个改进方法就是对单一的字节进行修改，将漏洞命令中对判断文件大小的命令修改的更加严格些，从而能在搜索时可排除对CVE-2017-0199漏洞利用文件的搜索。另一个方法，稍微有些难度，这个方法可以在指令没有在RTF文件内搜索到下一条命令标记的情况下，假定Word已经打开了符合条件的RTF文件。

如果没有其他打开的RTF文件，CVE-2012-0158漏洞就会自动执行。因此，为了保障研究的完整性，我们对剩余的部分进行了研究。

第二阶段的shellcode

第二阶段的shellcode要稍微复杂一些，其首先将调用ntdll.dll中的必需API函数。API函数通常被用作在计算机处于挂起状态时创建系统进程svchost.exe，以及利用最终阶段的“下载和执行” shellcode来重写初始入口点，最终植入可执行payload。

图8：调用ntdll.dll的API函数以注入最终阶段的shellcode，同时恢复svchost.exe进程

写入svchost.exe进程的最终阶段shellcode会使用UrlDownloadToFile API函数从C&C服务器上下载可执行文件至临时文件夹当中，并命名为此（%temp%\name.exe），同时再调用ShellExecute最终注入payload。

图9：下载和执行阶段

通过监控C&C服务器的流量可以得知，此前下载的可执行payload实际为一个基于VB脚本的木马施放程序（dropper），包含有旧版Ramnit木马，并且运行着Lokibot。Ramnit是一种非常常见的信息窃取恶意软件，能够自行复制，它同时还包含了rootkit，帮助其躲避杀毒软件检测，具有很强的隐蔽性。本篇博客文章并未对该恶意软件的这一特别部分进行深入讨论。虽然已经有些年头，但Talos团队还是能够经常碰到Ramnit家族恶意软件。在此次攻击过程中，攻击者原本可能想要发动Lokibot攻击，但其目标却恰巧阴差阳错感染了Ramnit木马。

图10：multplelabs.com网站的DNS活动情况

携带恶意软件的域名和其C&C服务器于2016年10月注册，很像是一个遭到入侵的站点，虽然该站点似乎也为其他的Lokibot攻击活动所服务。该站点的DNS活动出现了两个峰顶，说明了两次并不成功的恶意邮件活动，从这里的数据反应出，受感染系统和C&C服务器再无通信活动增多的情况。

相关的DNS活动使我们确认了自己的发现，也为该攻击活动的失败提供了证据。

结论

CVE-2017-0199是垃圾邮件包含恶意软件最常使用的漏洞之一。此前有研究显示，网络攻击者对其的利用频率甚至超过了CVE-2012-0158漏洞。

在本博客中，我们分析了同时合并上述两种漏洞，发动单一网络攻击时出现的情况。在此次攻击过程中，攻击者犯下了一个重大错误，即阻止了Ramnit payload的下载和执行。

图11：组合攻击尝试的各阶段

我们十分好奇，为什么攻击者会选择将新旧两种漏洞同时进行合并？如果目标系统打有任意一个漏洞的应对补丁，这样的组合攻击手段就会被瓦解。同时，如果目标系统确实存在CVE-2012-0158漏洞，攻击者发动针对单一漏洞的攻击活动应该更加容易得手。

我们猜测，攻击者使用这种合并攻击手段，目的是为了防止Word弹出对话框，引起被攻击目标的怀疑。另一种可能是，攻击者意图通过这种手段躲避行为检测系统，从而萌生了在Word文件中组合Ole2Link以及HTA文件的设计。

此次攻击活动并不成功，说明攻击者缺乏相关测试，或者在控制阶段手法不精。然而，我们从中看出了攻击者寻求利用CVE-2017-0199漏洞作为攻击手段，并且躲避用户察觉的试验精神。此次试验的攻击可能并未奏效，但未来的攻击中或许就会将其实现。

IOCs

文件

可执行文件

URLs

C&C服务器地址

WireX家族病毒基本上都会在内部硬编码存放两个URL地址（部分变种的URL经过加密），变种A在内部硬编码了如下两个URL

这些URL地址是病毒的C&C Server的地址，用于返回要攻击的网站的信息，不同之处在于，对这两个URL返回的信息，处理方式不同，执行的恶意行为也不同。

UDP Flood攻击

对于以u开头的URL地址，比如

（实际测试不能正常返回数据，以下是根据代码逻辑进行描述的），返回数据分为两部分，一个要攻击的主机地址，一个是端口，中间使用字符串“snewxwri”分割，代码中对返回数据处理如下：

获得主机地址和端口号之后，会创建50个线程，每个线程中都会连接该主机和端口，开启socket之后，使用udp协议发送随机数据，每次回发送512个字节的数据，一个线程中一共会发送 10000000 (一千万)次，也就是 10000000512=5120000000 字节的数据，因为一共实现了创建了50个线程，所以，理论上会发送10000000512*50=256000000000（2560亿）字节，实现代码如下所示：

Deceptive Access Attack

对于以g开头的URL地址， 比如

，返回数据分为3部分，分别是访问要攻击的网站的URL、UserAgent和Referer，使用硬编码的字符串（比如snewxwri ）进行分割，代码中对返回数据处理如下：

获得要攻击网站用到的URL、UserAgent和Referer后，会创建20个Webview，然后使用每个WebView访问要攻击的网站，代码实现如下：

Deceptive Click Attack

变种B内置了2个URL地址，如下：

请求这两个URL返回的数据是类似的，都是在HTML的title中设置了一段内容，这段内容使用一个硬编码的字符串（比如”eindoejy”）分隔成3或者4部分，前3部分都是一样的，一个URL，一段JS代码，一个UserAgent，后面可能还有一个字段，猜测为国家名字缩写，该样本中为CN（代表中国？）。请求你的地址和返回的数据，类似下图：

该病毒对这些数据的处理方式是，使用WebView加载返回URL，然后在页面加载完成后，执行那段JS代码，JS代码的功能是从页面中所有的URL link（通过查找html的a标签获得）中，随机挑选一个，模拟鼠标事件进行点击，实现代码如下：

实现模拟鼠标点击JS代码如下：

Attack Controller

上述几种攻击的实现都是位于某个Android Service中，那么这几种攻击是怎么启动的呢？通过逆向分析APK得知, 该APK注册了监听某些事件的Broadcast Receiver，比如network connectivity change、device admin enabled等，在这些Receiver中，会启动Attack Controller这个Service， Attack Controller负责启动各种Attack，代码实现如下：

不同的变种，实现方式有些差别，攻击的强度也又有所差别，这个变种中，每隔55秒都会重启一次攻击。

360烽火实验室

360烽火实验室，致力于Android病毒分析、移动黑产研究、移动威胁预警以及Android漏洞挖掘等移动安全领域及Android安全生态的深度研究。作为全球顶级移动安全生态研究实验室，360烽火实验室在全球范围内首发了多篇具备国际影响力的Android木马分析报告和Android木马黑色产业链研究报告。实验室在为360手机卫士、360手机急救箱、360手机助手等提供核心安全数据和顽固木马清除解决方案的同时，也为上百家国内外厂商、应用商店等合作伙伴提供了移动应用安全检测服务，全方位守护移动安全。

0x00 事件公告

2017年8月17日，名为WireX BotNet的僵尸网络通过伪装普通安卓应用的方式大量感染安卓设备并发动了较大规模的DDoS攻击，此举引起了部分CDN提供商的注意，此后来自Akamai, Cloudflare, Flashpoint, Google, Oracle Dyn, RiskIQ, Team Cymru等组织联合对该事件进行分析，并于8月28日发布了该事件的安全报告。

该安全报告分析表明，攻击者可能从7月中旬(可能更早)开始组建WireX BotNet，并通过小规模的攻击受害网络来牟利。8月7日左右，WireX BotNet开始进行流量更大持续时间更长的DDoS攻击。从8月15日开始，WireX引发的DDoS事件源自至少7万个独立IP地址。8月17日攻击数据的分析显示，来自100多个国家的设备感染了WireX BotNet。

WireX BotNet的源IP趋势

WireX BotNet主要伪装成带有极大的诱惑性和隐蔽性的视频播放器、铃声、文件管理器等无害应用，此前已发现大约有300种不同的移动应用程序分散在Google Play商店中。目前Google删除了受影响的应用程序，并开始从所有设备中删除该恶意应用程序，但还不清楚具体有多少安卓设备被WireX感染。

目前，360手机卫士、360安全卫士和360手机助手在内的产品已经能准确地进行WireX BotNet查杀，技术层面（分析报告见参考3）确定了国内有100多个WireX BotNet相关的恶意安卓应用。请使用安卓设备的用户和相关的安卓应用市场尽快进行相关的查杀。

0x01 影响面分析

事件等级： 较大

感染了Google Play商店和部分安卓应用市场，可能有数万台安卓设备受影响。

0x02 处理建议

1、建议安卓用户安装360手机卫士等有效的终端防护应用进行防护；

2、建议各安卓应用市场对于存量和提交的应用进行安全扫描后再上架；

0x03 时间线

2017-8-28 事件披露

2017-8-29 360烽火实验室和360NetLab对WireX进行技术分析

2017-8-29 360CERT发布预警公告

0x04 参考

1、The WireX Botnet: How Industry Collaboration Disrupted a DDoS Attack

https://blog.cloudflare.com/the-wirex-botnet/?utm_content=buffer9e1c5&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

2、安卓DDOS僵尸网络：The WireX Botnet

http://bobao.360.cn/learning/detail/4323.html

3、关于“WireX Botnet”事件Android样本分析报告

http://blogs.360.cn/blog/analysis_of_wirex_botnet

译者：紫曦归来

预估稿费：260RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

摘要

随着网络犯罪手法不断翻新，家用路由器近日也成为网络攻击的新目标。事实上，家用路由器的确存在着大量的安全漏洞。lvaro Folgado Rueda等多名网络安全专家近日撰写了一份报告，深入分析SOHO路由器的安全隐患，并针对家用路由器的最新攻击源展开研究。研究发现，22个知名品牌的路由器存在60余个尚未公开的安全漏洞。这也意味着路由器厂商仍须进一步提升其产品的安全性能。该报告中罗列了一系列存在于家用路由器中的安全漏洞，如果上述漏洞被黑客利用，造成的后果将不堪设想。

1、引言

随着信息时代的到来，小办公室/家庭办公室（Small office Home office，SOHO）的工作方式，因其具有传统办公无法比拟的灵活性、创造性等优点很快被社会大众所接受。SOHO计算机和网络的普及促使家庭办公逐渐成为当今一种白领时尚，也引领其一股SOHO文化热。 SOHO路由器，即小办公室家庭办公室用的路由器是实现家庭办公必不可少的装备。如果 SOHO路由器中存在漏洞将大大影响整个家庭网络系统的安全性，同时也对用户的隐私造成极大威胁。

在过去的几年时间内，也有C. Heffner等专家针对SOHO路由器的安全问题进行了相关研究。这些研究的目标主要是：

（1）通过寻找可能存在的漏洞问题，评估当前网络安全等级。

（2）针对新的攻击源展开研究

（3）研发能够检测出漏洞的工具。

（4）为后续研究提出方法论依据。

路由器的制造商以及互联网服务提供商也将针对该领域研究成果对产品进行安全升级。

2、路由器相关知识

所有路由器都为终端用户提供了各种形式的配置方式。

（1）Web配置界面（Web Interface）：一个用户友好型的Web配置界面有助于用户随时进行设备更改和调试（如图1所示）。当然，访问Web配置界面需要进行身份验证。

图1

（2）命令行界面（command-line interface）：通过命令行界面用户同样可以对路由器进行操作、设置。命令行界面可通过终端模拟器来访问，用户可利用计算机上已经安装的终端模拟器，在终端模拟器的窗口键入命令并获得从路由器返回的信息（如图2所示）。

图2

路由器除了可以使用上述两种方式进行配置外，还可使用诸如FTP和SMB服务器等方式进行配置。此外，路由器还可采用“即插即用”（Universal Plug and Play，UPnP）方式进行配置。但使用FTP或Telnet等方式进行配置存在一定安全隐患，更安全的方法是选择更为高级的SFTP和SSH协议。值得注意的一点是，纳入本研究的大部分路由器都默认启用了UPnP协议，从而可以允许未经身份验证的攻击者更改路由器的关键配置设置。

大多数路由器所提供的服务对于用户来说都是多余且无用的，这些功能有时反而被黑客利用实施网络攻击。此外，研究显示路由器开放端口的数量过多，这一点即使对于有远程WAN的连接来说也是过多了。

研究发现，路由器还普遍存在一个安全隐患，即使用公开的默认密码就可以进入路由器配置界面。（如图3所示）本研究中纳入评估的所有路由器均未使用随机生成的字符串作为默认密码，而是使用了公开的默认密码，而这些用户又不修改默认密码，这使得黑客对路由器实施网络攻击变得更加容易。

图3

3、安全漏洞

通过分析路由器存在的各类安全漏洞，研究发现黑客从不同的位置对路由器实施攻击：

（1）有线连接到受害者的局域网内。在这一案例中，攻击者使用以太网电缆连接到受害者的局域网，并对其实施攻击。

（2）无线连接到受害者的局域网内。这种形式的网络攻击经常发生在提供免费Wi-Fi热点的路边餐厅或咖啡店。

（3）远程攻击。虽然攻击者在受害者的本地网络之外，但用户使用了存在漏洞的路由器，这使他们极易遭受网络攻击。远程攻击可针对某一个特点目标进行，同时也可以通过僵尸网络等形式无目标地感染多台设备。

攻击者可利用远程漏洞，例如利用公开的路由器连接端口密钥，从而利用那些只能在受害者本地电脑设备利用的漏洞。研究发现，目前广泛使用的路由器存在着多种漏洞。

3.1 跨站请求伪造（CSRF）

跨站请求伪造（Cross-site request forgery）通过向受害者发送特定的恶意链接来更改路由器的配置设置。攻击者常使用远程攻击的方式更改合法的DNS设置。从而使得攻击者可以掌握受害者的隐私设置，并将浏览器请求指向恶意网站，并最终构建一个僵尸网络。

当受害者已经登录导路由器的Web配置界面后，该攻击才能顺利进行。但是，Web配置界面的登录密码可以嵌入到恶意URL中。如果管理员（administrator）的密码从未被更改过（这一点在我们研究的案例中极为普遍），则攻击就可以顺利进行。如图4所示，部分浏览器将针对登录尝试弹出警告消息框；但诸如Google Chrome浏览器等常用的浏览器均未显示任何警告。如此，攻击行动可以在受害者毫无察觉的情况下进行。

图4

例如，以下URL利用公共默认凭证1更改了Observa Telecom AW4062路由器的DNS设置。通过BitLy和OwLy等URL短网址工具，链接可以变得很短或者被混淆。如图5所示，缩短的链接容易被用户忽视。

图5

同样，包含恶意参数的网站也可以通过这种做法蒙混过关，如图6所示。

图6

通过共享社交网站上的链接，或者使用一些能够鼓励用户打开恶意URL的社会工程学技巧，可以增强网络攻击的影响面。

3.2 持久型跨站脚本（XSS）

XSS攻击通常是指黑客在Web配置界面植入恶意脚本，从而对用户实施会话劫持（Session hijacking）和感染浏览器（browser infection）的攻击。攻击者可通过向受害者发送恶意链接实施远程攻击（与CSRF攻击类似，如图7所示）；如果用户的密码从未更改过，攻击者可对其实施本地攻击（如图8所示）。

图7

图8

在被发现的XSS攻击中，脚本代码均会保留在Web配置界面中。根据路由器型号的不同，脚本执行可能会在注入后立即进行，也可能在访问某个网页（如主页）时进行。部分输入栏中只能输入有限个数的字符。为了避免这种限制，BeEF（The Browser Exploitation Framework project）是比较流行的web框架攻击平台。通过XSS这个简单的漏洞，BeEF可以通过一段构造好的javascript脚本控制目标主机的浏览器，通过浏览器拿到各种信息并且扫描内网信息，同时能够配合metasploit进一步渗透主机，强大的有些吓人。下面的URL显示了使用BeEF hooks2进行XSS开发的示例。图9所示就是受感染的浏览器。

图9

3.3未经身份验证的跨站脚本攻击

在特殊情况下，执行脚本代码注入可以在没有任何登陆的情况下实施本地攻击。这主要是通过发送一个包含恶意脚本的动态主机配置协议（DHCP）数据单元（PDU）来实现的，如图10所示，当发送了一个具有有效参数的PDU后（例如客户端MAC地址或恶意主机名），路由器将回复一个DCHP ACK，之后恶意脚本将植入到Connected Clients的桌面。

图10

攻击过程如图11所示。恶意的动态主机配置协议PDU可使用以下几种方式发送：

允许更改主机名参数的自定义脚本

数据包处理工具（如Scapy等）

dhclient -H <hostname>命令

/etc/hostname文件修改

图11

3.4特权升级

没有管理员权限的本地或远程用户可以通过特权升级从而成为管理员。攻击者利用隐藏的非管理用户的存在，使用默认密码。通过将这些没有特权的用户连接到路由器FTP服务器，攻击者可以下载/etc/passwd和config.xml文件，如图12所示。最后一个是以明文形式存储所有路由器的配置参数，包括所有用户的密码。文件的一部分如图13所示。这样做，任何用户都可以获得管理员权限。

图12

图13

3.5 信息泄露

无需任何登录过程，外部攻击者就能获取目标路由器的重要信息，如Wi-Fi密码和WLAN参数、Internet配置以及连接用户列表等。这些安全隐患一般由不当的文件权限和意外的调试信息造成。在某些情况下，受支持API（例如JSON）的配置不当，会导致路由器定期发布包含关键信息的无保护文件，如图14所示，而获取这些重要信息就如同访问公开文件（图15）或网页一样简单（图16）。

图15

图16

3.6后门

隐藏管理员帐户对于终端用户来说完全不可见，这使得任何攻击者都能够通过Web界面或拨号网络随意更改路由器配置设置。图17显示了一个名为“admin”的后门管理员帐户，其密码为“7449airocon”。该账户仅出现在备份XML配置文件中，无法被删除。

图17

3.7旁路认证

未经身份验证的攻击者可以通过不当文件权限或是错误服务配置，实现路由器配置更改。

在几个路由器型号中，攻击者可以通过不断访问/rebootinfo.cgi URL来实现永久拒绝服务，如图18所示。攻击者还可以访问/restoreinfo.cgi URL强制重置路由器至默认配置（图19）。之后，任何用户都可以使用默认凭据登录该路由器。

图18

图19

在两次未经身份验证的攻击中，路由器都会回复HTTP 400状态码，但其实际正在执行重新启动或是重置设置的操作。集成在一些设备中的SMB文件共享服务，可能会因为共享外连接特性的一处错误配置，导致严重的安全风险。未经身份验证的攻击者可以利用这一漏洞，通过本地或远程连接Samba服务器，从而下载整个路由器文件系统。如图20和21所示，在这种共享服务（称为存储）中，能够允许路由器文件系统创建符号链接（symbolic links），并下载其中内容。

图20

图21

攻击者因此可以自由查看和下载路由器的整个文件系统，包括密码和配置文件等。使用put和mput内置命令上传修改文件或新文件到路由器同样可行。许多型号路由器均支持Twonky Media Server服务，若存在配置错误，将允许外部攻击者操纵连接到路由器的USB存储设备，从而在不需要任何登录过程的情况下，执行包括下载，修改，删除和上传文件在内的操作。为了做到这一点，攻击者只需要根据9000端口来访问路由器IP就能完成，如图22所示。

图22

3.8 UPnP协议（通用即插即用协议）

多数路由器型号均默认采用UPnP协议。这一协议旨在为不同家用设备之间的连接提供便利。举个例子，UPnP协议可以允许计算机应用程序更改网络配置，比如打开端口，以便在用户不进行干预的情况下增强性能。

由于在进行配置更改时缺乏认证环节，UPnP协议其实极其不安全。不仅如此，路由器厂商的实现手段通常也十分糟糕，这无形中为攻击者提供了许多可用攻击手段，包括为远程WAN主机打开重要端口，终止任何WAN连接，以及执行命令盲注攻击（Blind Command Injection）等等。为了在本地利用UPnP协议漏洞，我们强烈建议使用一款名为Miranda的客户端工具。首先，我们将组播传输SSDP协议的PDU，目的是确定网络中支持的设备，如图23所示。

图23

家用路由器通常会支持多项UPnP协议操作，但从攻击者的角度来看，“添加端口映射”（AddPortMapping）和“强制终止”（ForceTermination）是最为实用的。图24中显示了这些可用选项。

图24

由于该协议的实现并不理想，且NewInternalClient参数未得到准确检查，使未经身份验证的攻击者能够打开连接远程WAN主机的端口，如图25所示。

图25

一旦受攻击者访问包含恶意SWF文件的特定网站，就能实现UPnP协议漏洞远程利用。这个Flash文件正悄然执行着“添加端口映射”操作（或任何UPnP协议支持的选项），并在后台更改防火墙设置。由此，在重要端口对WAN主机开放的情况下，远程攻击者将能对本地相关安全漏洞进行利用。图26是该攻击的图解说明。

图26

4、工具

通过研究，我们制作了多种漏洞利用工具。

（1）SendDHCPRequest。可以向网络中的任一DHCP服务器发送带有自定义参数的恶意DHCP 协议请求 PDU。该工具可用于未授权XSS攻击。

图27

（2）ChangeHostname。改变计算机主机名的简单脚本。该工具可用于未授权XSS攻击。

图28

（3）SMBExploit。该工具将在目标的共享服务中创建一个符号链接。如果路由器存在漏洞，将可以被下载整个文件系统。其主要可用于SMB Symlink攻击。

图29

此外，这些被发现的漏洞将添加到RouterPwn项目，用户和研究人员可以因此更为方便地检查设备存在的漏洞。

5、审计报告

我们目前已经发现超过60个此前未经公开的安全漏洞，影响了22种不同型号的SOHO路由器。大多数路由器在西班牙都非常受欢迎，而互联网服务提供商愿意将这些产品推销给客户。

Amper，Astoria，Belkin，Comtrend，D-Link，华为，Linksys，Netgear，Observa Telecom，Sagemcom和Zyxel等厂商的路由器设备都存在多重安全漏洞，如图30所示。

图30

图31按类型展示了漏洞分布情况。

图31

表1和表2展示了一份包含所有漏洞，以及受影响路由器型号的综合列表。

表1

表2

所有被发现的漏洞都已上报设备厂商和网络服务供应商，方便他们能够尽快解决问题；以及建立多个漏洞数据库，如MITR（CVE-ID）或OSVDB。在向厂商提供足够的时间后，我们披露了这些漏洞。

6、结论

迄今取得的成果表明，绝大多数SOHO路由器都受到了严重的安全漏洞影响，其中一些非常严重，很容易遭到网络犯罪分子利用，使终端用户和小型企业陷入安全威胁当中。我们能够得出结论，路由器的安全性在过去几年内其实并未得到改善。事实上，这些不断涌现的新型安全漏洞和攻击性载体，反而丰富了攻击者的“武器库”。

设备厂商和互联网服务供应商应该共同努力，以解决目前影响SOHO路由器的庞大的安全问题。在漏洞分析过程的基础上，我们开发了多种漏洞利用工具以及一种审计方法，目的是为研究人员未来的工作提供便利。

译者：blueSky

预估稿费：260RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

但是最新一代的协同机器人（“cobots”）并非如此。在符合安全标准的同时，他们与人类或者其他机器在共同的环境中工作。这一代机器人与人类携手并进，协助人类完成工作，而不仅仅是执行自动化的，危险性的操作。 Cobots可以学习移动，通过高清摄像机“看”，或通过麦克风“听到”来完成工作。

因此，Cobots比传统的工业机器人呈现出了更为有趣的攻击研究。但是，Cobots只限于工业应用？不，他们也可以被集成到其他装置中！

去年二月，Cesar Cerrudo和我发表了一篇非技术论文“Hacking Robots Before Skynet”，在这篇论文中我们对来自多家知名厂商的几款家用，商用以及工业机器人进行了研究，在这些机器人中我们发现了近50个关键的安全漏洞。在Cobots这部分机器人部分，我们对包括来自Rethink Robotics的Baxter / Sawyer和Universal的UR机器人进行了研究，这些都是工业机器人行业的领导者。

Baxter / Sawyer：针对这款机器人，我们发现其存在身份验证漏洞，采用不安全的协议传输和默认的部署配置，易受到物理攻击以及使用了一个存在多个安全漏洞的框架-ROS，该公司已经在2017年2月修复了我们报告的主要问题。

UR：我们在许多控制协议中发现了身份验证问题、易受到物理攻击、内存破坏漏洞以及不安全的通信传输等安全漏洞。所有这些问题在最新版本（3.4.2.65，2017年5月）的系统中中仍未修补。

根据IOActive网络安全公司漏洞披露的政策，我们已经在去年1月份与供应商取得了联系，所以他们有足够的时间来修复这些漏洞并通知客户。我们的目标是使cobots机器人更安全，防止攻击者利用漏洞对企业，员工和周围环境造成严重伤害。我真的希望这篇文章可以推动cobots机器人的安全性能够向前发展，使得我们可以安全地使用现在的这些机器人以及后续更多代的机器人。

在这篇文章中，我将讨论攻击者如何通过cobot（例如UR3，UR5，UR10 - Universal Robots）机器人的多个漏洞来远程修改安全设置，违反适用的安全准则，通过移动机器人对其周围的工作人员造成身体上的伤害。通过这个例子我们可以看到如果这些系统被黑客攻击或者控制可能会给人类造成多么严重的后果，操纵安全限制和禁用紧急按钮可能直接威胁到人的生命。在这个例子中，我们利用了cobot机器人的六个漏洞来改变其安全限制，并通过远程网络禁用安全面板和紧急按钮/传感器，演示视频可以在下面这个url中看到：

问：这些机器人真的可以伤害一个人吗？

答：是的，加拿大蒙特利尔(ETS)技术研究所的控制和机器人实验室的一项研究清楚地表明，即使是较小的UR5模型，其强大到足以严重伤害一个人。即使是在慢速移动中，他们的力量也足以造成颅骨骨折

问：等等，他们有没有安全功能，防止他们伤害附近的人类？

A：是的，但是黑客可以远程入侵，我将在下一个技术部分告诉你黑客是如何入侵机器人系统的。

问：这些机器人部署在哪里？

A：世界各地，每天在多个生产环境中都有机器人在工作。

集成商定义所有安全装置

Universal Robots公司是UR机器人的制造商，但是在特定应用中安装UR机器人的公司是集成商，一个机器人只有集成和安装之后才被认为是一个完整的机器。 UR机器人的集成商负责确保消除整个机器人系统的任何重大危险，这包括但不限于：

1. 对整个系统进行风险评估，在许多国家，这是法律规定的的必要流程。

2. 如果风险评估认为安全，则连接其他机器和其他安全装置

3. 在Polyscope软件（控制面板）中设置相应的安全设置，确保用户不会使用“安全密码”来修改任何安全措施。

4. 验证整个系统的设计和安装是否正确

Universal Robots公司已经意识到集成商必须考虑机器人存在的潜在的重大危害例如：

1. 机器人工具或者工具连接器上的锋利的刀边或者刀尖有可能刺伤皮肤；

2. 机器人轨道附近的障碍物上的锋利刀边或者刀尖有可能刺伤皮肤；

3. 由机器人的碰撞引起的瘀伤；

4. 由机器人沉重的机器零件或者材料表面之间的碰撞而产生的扭伤或骨折；

5. 由于未经授权更改安全配置参数而导致的错误

一些安全相关功能是专为cobot应用而设计的，这些功能包括：

1. 力和功率限制：用于在机器人和操作员之间碰撞的情况下，减少机器人在运动方向上施加的夹紧力和压力；

2. 动量限制：通过降低机器人的速度，用于在机器人和操作者之间碰撞的情况下减少高瞬态能量和冲击力；

3. 刀具定向限制：避免锋利的刀边指向操作者；

4. 速度限制：用于确保机器人手臂低速运行；

5. 安全边界：用于限制机器人的工作空间，强制其停留在定义的虚拟平面的正确一侧，而不能通过它们。

6. 安全I/O：当触发此输入安全功能（通过紧急按钮，传感器等）时，向输入端发送低信号，并使安全系统转换到“减小”模式。

安全设置可以有效防止许多潜在危险事件。但是，如果恶意攻击者绕过这些安全措施，操纵机器人来威胁人类生命，那可能会发生些什么呢？

UR用户指南的声明

远程更改安全配置

“安全配置只能根据集成商进行的风险评估进行更改。如果改变了安全参数，机器人的整个系统应当被认为是新的，这意味着包括风险评估在内的整个安全审批流程应该相应的更新“。

远程更改安全配置的过程如下所示：

步骤1.通过在UR Dashboard Server上利用身份验证漏洞来确认远程机器人系统的版本信息；

步骤2.通过在UR Modbus TCP服务中利用基于堆栈的缓冲区溢出漏洞获得对系统的控制权限，并以root身份执行命令；

步骤3.修改security.conf文件，该文件将覆盖所有的通用安全限制，接头限制，边界和安全I/O值限制；

步骤4.强制绕过计算校验和值，并上传新文件。我们需要伪造这个校验和值，因为通常集成商很可能在硬件上写入当前的校验和值；

步骤5.重新启动机器人，以便更新安全配置；

步骤6.通过利用UR控制服务上的认证问题，以任意危险的方式操作机器人。

通过逆向分析ursys-CB3.1-3.3.4-310.img这个系统镜像，我知道了机器人的入口点以及允许网络上的其他机器与操作系统进行交互的服务程序。对于此演示，我使用供应商提供的URSim模拟器，该模拟器包含了机器人镜像中大部分核心的二进制文件。尽管这个示例使用模拟器可以更为清楚展示攻击效果，但我还是修改了这个二进制文件，修改后的文件部分代码可以在linux机器上正常运行。URControl这个二进制文件中导出了很多不同的网络服务，这些网络服务的私有协议在实现上都没有使用强大的认证机制。例如，网络上的任何用户都可以向其中一个服务发出命令，并获取正在运行的进程的远程操作系统的版本（步骤1）：

现在我已经验证了远程目标运行着一个易受攻击的系统ursys-CB3.1-3.3.4-310（UR3，UR5或UR10），下一步我准备利用网络服务漏洞来破坏这个机器人系统（步骤2）。由于UR Modbus TCP服务（端口502）不支持对命令源的认证机制，因此，网络攻击者可能会在控制的过程中破坏机器人系统。与机器人IP连接的攻击者可以发出Modbus读/写请求，并部分更改机器人的状态或向操作人员发送请求，以更改控制链接的状态。发送Modbus写请求并不能改变机器人的任何安全设置，然而，我们在在UR Modbus TCP接收器（URControl内核的一个二进制文件）中发现了一个基于堆栈的缓冲区溢出。

UR Modbus TCP服务程序的recv函数存在堆栈缓冲区溢出漏洞，攻击者通过该函数可以向程序的缓冲区写入超出其长度的内容，造成缓冲区的溢出，从而破坏程序的堆栈，使程序转而执行其他的指令，以达到攻击的目的，这是一个很常见的堆栈缓冲区漏洞。

在进行漏洞利用之前，我们先来看一下漏洞利用的将要面临的阻碍。机器人的Linux内核被设置为堆栈随机化（randomize_va_space = 1 => ASLR），VDSO（virtual dynamic shared object page）和内存区域共享。此外，由于内核中的"No eXecute" (NX) 被置位，因此该内核文件是不可写以及不可执行的。

当对目标缓冲区进行溢出操作时，我们也需要要对指向函数参数的指针执行溢出操作。在函数返回之前，这些参数在其他函数调用中被使用，所以我们必须要为这些函数调用提供有效的实参。否则，我们永远不能找到函数的返回点以及控制函数的执行流程。

如上图所示，edx + 0x2c内存地址中的值作为一个参数传递给了0x82e0c90函数，另一个就是EBX寄存器（从我们以前的EDX控制指针计算出来）也需要指向一个与文件描述符相关的结构体变量。

在实现上，需要选择符合上述两个要求的静态地址，我使用以下静态区域，因为ASLR技术会使内存中其他地址都可能发生变化。

我写了一些脚本用来找到一个合适的内存地址，通过这些脚本我发现0x83aa1fc这个地址是完美的，因为它适合这两个条件：

0x83aa1fc + 0x2c指向有效内存 - > 0x831c00a（“INT32”）

0x83aa1fc + 0x1014包含0（所有这个区域几乎都为零）

现在我已经找到满足上述两个条件的解决方法，可以继续执行代码直到函数返回，并且通过溢出堆栈上保存的寄存器，我能够得到EIP的控制权：

现在，我控制了大部分的寄存器，所以我需要将我的shellcode放到机器内存中的某个地方，并将函数的执行流重定向到shellcode那里。为此，我在实现上使用了面向返回的编程（ROP），遇到的难题是需要合适的EXP代码来执行漏洞利用。自动ROP链工具不能很好地满足我的需求，所以我决定自己手动进行此操作。

现在，我最终目的是希望在目标系统中执行一个反弹shell以连接到我的攻击机器上。在Linux系统中构建基于远程ROP漏洞利用的一个关键点是系统调用，在这些可靠的系统调用函数中，我可以使用诸如write或dup2之类的系统函数去重用已经创建的套接字来反弹一个shell。

在这个二进制文件中，我只找到一个int 0x80指令，该指令用于在支持x86指令集的Linux系统中调用系统调用。使用该指令我只能执行一个系统调用：我将使用execve系统调用来执行一个程序。int 0x80指令需要使用设置在一个寄存器中的一个系统调用号（EAX，在本例中为0xb），然后设置一个指向特殊结构的寄存器（EBX）。这个结构包含一个指针数组，每个指针指向要执行的命令的参数。

想要触发这个漏洞，就不能在请求缓冲区上使用空字节（0x00）。这是碰到的另一个难题，因为我们需要发送命令和参数，并创建一个以空字节结尾的指针数组。为了克服这个难题，在请求中我先发送一个占位符（像0xFF这样的字节块），之后利用ROP在运行时将占位符0xFF替换成0x00。

伪代码中如下图所示（通过TCP链接来反弹一个Shell）：

由于所有的受控数据都位于堆栈中，所以首先我将尝试将堆栈指针（ESP）与我的最大控制区段（STAGE 1）对齐。我将最大的受控部分分为两个阶段，因为它们都可能包含许多ROP代码。

正如前面所叙述的那样，此时我控制了EBX和EIP这两个寄存器。接下来，我必须将ESP与任何控制的区段对齐，以便我可以开始执行ROP代码。

以下代码片段（ROP1 0x8220efa）用于调整ESP：

这样ESP = ESP + EBX - 1，上面的代码将ESP与我的STAGE 1部分的代码对齐。 EBX应该将ESP减少0x137字节，所以我使用数字0xfffffec9（4294966985），因为当把该数字添加到ESP时，我们就能够得到所需的值。

当代码的retn指令执行时，STAGE 1的ROP代码将会开始执行。漏洞利用的第1阶段将执行以下操作：

1. 将结构体变量的末尾字节置0。这样处理器就会知道EXECVE参数只是这三个指针。

2. 在我们的结构体参数中保存指向我们第一个命令的指针。

3. 跳到STAGE 2，因为这里没有太多的空间。

漏洞利用的第2阶段将执行以下操作：

3. 为EXECVE准备寄存器。如前所述，我们需要

4.调用int 0x80代码并执行反弹shell。

一旦TCP反弹shell的有效载荷被执行，机器人系统便会发送一个请求用来和我的攻击电脑建立链接。现在我可以执行命令，并可以使用sudo在机器人控制器中以root身份执行命令。

安全设置保存在security.conf文件中（步骤3），Universal 机器人在系统中实现了CRC（STM-32）算法，使用此算法为二进制文件提供完整性校验，并将计算的校验值保存在磁盘上。但是该算法不会为安全配置提供任何真正的完整性校验，因为对新配置计算产生的新校验值，可能会与文件系统上的某个特殊文件的校验值产生冲突。我逆向分析了对每个安全配置进行计算的算法，并用代码实现了该算法。在视频演示中，尽管伪造一个新的CRC校验值可能会使攻击变得更容易，但我并没有这样做，而是保持该CRC校验值不变（位于屏幕的右上角）（步骤4）。

在修改机器人上的任何安全配置之前，我创建了一个进程，该进程会在25秒后自动启动一个机器人控制器的新实例，这将给我足够的时间来下载，修改和上传一个新的安全设置文件。以下命令创建了一个新的URControl进程。命令中我使用的是python语言，因为它允许我在执行forking操作时关闭当前正在运行的所有进程文件描述符。因为我正在从反弹shell的对象中执行fork操作，所以我需要创建一个不继承任何文件描述符的新进程，以便在父进程URControl被关闭时，从该进程fork的子进程也都会被关闭。

现在我有25秒下载当前文件，修改它，计算新的CRC，重新上传它，并关闭正在运行的URControl进程（它具有较旧的安全设置配置），我可以通过使用kill命令来关闭当前的URControl进程（步骤5）。

最后，我将此命令发送到URControl服务，以加载我们上传的新配置文件，同时我也关闭可能会出现在用户界面上的任何弹出窗口。

最后，攻击者可以简单地调用URControl服务中的movej函数，以自定义速度和加速度远程移动被攻击者控制的机器人（步骤6）。

后记

本文我向大家展示了先进的机器人系统中存在的安全漏洞以及被利用的整个过程，这些其实都是非常技术性的安全漏洞，如其中一个协议的缓冲区溢出漏洞，将整个机器人系统的安全性暴露给了远程的攻击者。 我们已经在一月份向供应商报告了漏洞的整个流程，但是该漏洞还没有被修补。

热点概要：大疆推出无人机漏洞奖励计划、利用PowerShell代码注入漏洞绕过Constrained Language模式、comission：白盒CMS分析（目前支持Wordpress、Drupal）、XSS脑图分享、Kronos恶意软件分析（part 2）

资讯类：

大疆推出无人机漏洞奖励计划

https://threatpost.com/dji-launches-drone-bug-bounty-program/127696/

为了应对国际制裁，朝鲜选择窃取比特币？

http://www.securityweek.com/north-korea-accused-stealing-bitcoin-bolster-finances

技术类：

利用PowerShell代码注入漏洞绕过Constrained Language模式

http://www.exploit-monday.com/2017/08/exploiting-powershell-code-injection.html

comission：白盒CMS分析（目前支持Wordpress、Drupal）

https://github.com/Intrinsec/comission

基于Powershell的windows安全审计工具箱

https://github.com/A-mIn3/WINspect

TLS握手协议分析与理解——某HTTPS请求流量包分析

https://mp.weixin.qq.com/s?__biz=MzI5MzY2MzM0Mw==&mid=2247484067&idx=1&sn=d0d7b123415e3e7b0f400825178e2810

XSS脑图分享

https://raw.githubusercontent.com/jhaddix/XSS.png/master/XSS2.png

360烽火实验室：“WireX Botnet”事件Android样本分析报告

http://bobao.360.cn/learning/detail/4326.html

【安全工具】LANs.py：注入代码，jam wifi，监控wifi用户

https://github.com/DanMcInerney/LANs.py

Kronos恶意软件分析（part 2）

https://blog.malwarebytes.com/cybercrime/2017/08/inside-kronos-malware-p2/

x64dbg:针对Windows的开源x64/x32debugger

https://x64dbg.com/#start

Vulnerable Docker VM

https://www.notsosecure.com/vulnerable-docker-vm/

Wordpress SQLi

https://medium.com/websec/wordpress-sqli-bbb2afcc8e94

Telling Your Secrets Without Page Faults:Stealthy Page Table-Based Attacks on Enclaved Execution

https://argp.github.io/public/b81efa3a4c5826fa441852bd63a402c6.pdf

Disabling Intel ME 11 via undocumented mode

http://blog.ptsecurity.com/2017/08/disabling-intel-me.html

Inside the Massive 711 Million Record Onliner Spambot Dump

https://www.troyhunt.com/inside-the-massive-711-million-record-onliner-spambot-dump/

restic cryptography

https://blog.filippo.io/restic-cryptography/

Extension Breakdown: Security Analysis of Browsers Extension Resources Control Policies

https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-sanchez-rola.pdf

前几天卡巴斯基发布了一个安全事件响应指南的文档，具体内容可以参看阅读原文链接。通读了一遍，感觉这是一个非常基础的过程介绍比较完整的指导资料，适合网络管理员和初级安全事件响应人员阅读。文档里当然也夹带了不少卡巴斯基的私货，本质上这是一个有点干货的市场材料，内容上主要有以下几部分构成：

1. 术语和定义。文档涉及到的多个基本概念的解释，并不学术化，易懂。

2. 洛克希德马丁的Kill Chain介绍。未知攻，焉知防，对攻击者的基本套路有个了解。

3. 推荐的事件响应基本步骤：准备、识别、隔离、清除、恢复、反思。

4. 基于一个虚构事件的响应处理案例细节演示。

5. 推荐相关的工具：IOC收集、取证处理、分析、清除。

其实读下来给我最大的感觉就是IOC的作用，IOC这个词在文档中出现了50多次，基本上整个事件响应事实上是由IOC作为起点驱动的，也就是说由威胁情报驱动事件响应。现在大家都在谈安全的新潮流，出去开会讲个议题不提个机器学习人工智能都不好意思跟人打招呼，创业做安全没个ML/AI加持都拉不到投资。可是，事实上IOC这种低层次的威胁情报对安全能力不强的组织机构才是最有效的发现安全事件的手段，没有之一，而提供精准有效上下文丰富的IOC类威胁情报正是360威胁情报中心所做的。就在一两年前，参加安全相关的展会，进场遍地的威胁情报搭边的Slogan，今年看Blackhat，基本没有了，大家都在谈机器学习和异常检测了，但是几乎所有的检测类产品都集成了可输入的威胁情报，这个东西在大家都不谈的时候开始真正落地了。

总体来说，卡巴斯基的这个指南文档内容中规中矩，但细节不丰富，是一个入门读物，要形成对应的工作能力需要看更多的资料和实践。但是，文档中关于事件触发器的部分感觉很有价值，简单翻译如下供实在没时间读文档原文的同行参考。

事件触发器（Incident Trigger）

事件触发器是这样一个事件，它的出现指示着网络中发生了现实的危害。当这类事件出现时，事件响应团队应该意识到网络中存在进行中的攻击活动，事件触发器从这个意义上来说区别于一般性的网络活动事件。

防病毒系统产生的事件触发器

防病毒管理系统从终端可以汇集事件信息，当一个终端发现威胁产生事件会发到防病毒管理系统。但并不是所有的事件都是事件触发器，比如一个发现恶意代码的事件紧接着一个清除成功事件就不算一个需要响应的事件。

仅有以下情况产生告警事件：

连接至已知的C&C

恶意代码查杀失败

同一台计算机中反复检测到恶意代码

防病毒系统报错和故障导致保护级别的降低

可以作为事件触发器的可疑活动

有些异常迹象也可以作为事件触发器，那些活动的出现需要安全团队加入关注并进行调查，以下是一些例子：

操作系统启动时有未知的软件自动跟随启动

在系统服务列表中存在未知的服务

可执行文件从特定目录中执行，而该操作系统理论上不太可能从那些目录中启动程序，如系统缓存和临时目录

从不太可能存放程序库文件的目录加载程序库，比如从某个软件的安装目录中加载一个系统程序库文件

未预期的用户权限提升操作

虽然是合法的但非常有可能为攻击者所用的软件的存在，比如mimikatz、windows Credentials Editor及其他远控工具

以下可疑网络行为也可以触发作为事件触发器：

非预期的DNS和ICMP流量飙升

与频繁更改IP地址的域名进行通信，该行为可能表明攻击者使用Fast-Flux DNS技术通过把入侵后的机器作为代理来隐藏C＆C服务器

与卡巴斯基实验室威胁情报数据中包含的URL进行通信，比如那个URL被分类为恶意Exploit Kit的Landing Page

与卡巴斯基实验室威胁情报数据中包含的IP地址进行通信，比如那个IP被分类为扫描源或被用于执行DDOS攻击

与包含可疑Whois信息的域名进行交互

以上列举的这些异常迹象其实可以作为Threat Hunting的起点，对于有经验的攻防分析人员其实可以举出更多的场景出来。今年的BlackHat展会上Splunk在他们的展台上就讲了两个通过搜索不常见的主机行为来发现未知攻击的思路，其实很简单，就是通过检索少见的进程链和少见的执行文件路径搜索微软Sysmon框架输出的进程日志来实现检测，360威胁情报中心在内部的Threat Hunting实践中也采用过类似的思路发现了定向攻击事件。

阅读原文链接：https://cdn.securelist.com/files/2017/08/Incident_Response_Guide_eng.pdf

作者：东巽科技2046Lab团队

报告编号：DX-APT1

披露声明

本报告由东巽科技2046Lab团队编写。

考虑到相关信息的敏感性和特殊性，本报告中和受害者相关的姓名、邮箱、照片、文档等个人信息我们将做模糊处理；涉及到的具体的方位，我们将做放大模糊处理；同时为预防攻击者利用公开信息进行反情报，本报告涉及到的IP、Domain、URL、HASH等一系列IOC（Indicatorsof Compromise，攻陷指标）我们将做模糊处理。所有IOC已经整合到东巽的铁穹产品和东巽威胁情报中心，您可访问以下网址进行查询：https://ti.dongxuntech.com

1 概述

2016年7月，东巽科技2046Lab捕获到一例疑似木马的样本，该木马样本伪装成Word文档，实为包含CVE-2015-1641（Word类型混淆漏洞）漏洞利用的RTF格式文档，以邮件附件的形式发给攻击目标，发动鱼叉式攻击。将文件提交到多引擎杀毒平台，发现54款杀毒软件仅8款可以检出威胁，说明攻击者对木马做了大量的免杀处理。随后，2046Lab研究人员对样本进行了深入的人工分析，发现其C&C服务器依然存活，于是对其进行了跟踪溯源和样本同源分析，又发现了其他两处C&C服务器和更多样本。

从溯源和关联分析来看，种种迹象表明，该样本源于南亚某国隐匿组织的APT攻击，目标以巴基斯坦、中国等国家的科研院所、军事院校和外交官员为主，通过窃取文件的方式获取与军事相关情报。由于样本的通信密码含有“January14”关键词，这一天正好是南亚某国盛行的“丰收节”，故把该APT事件命名为“丰收行动”。

2 时间线分析

2.1 从样本进行分析

通过对所有捕获样本的分析，发现较为早期的两个样本最后修改时间为2015年3月9日（..exe）和2015年5月5日(update_microsoft.exe)，而其他样本的最后修改时间多数在2016年3月、4月、5月，表明攻击的时间至少可追溯到2015年3月甚至更早，而从2016年频繁修改多个样本可以看出，今年的攻击活动尤其频繁。

2.2 从C&C进行分析

图1 C&C建立时间分析

通过对其位于摩洛哥、德国、香港的三个C&C服务器的跟踪和溯源，发现其三个据点分阶段建立。其中：

摩洛哥为最早的据点，系统初始化时间可追溯到2013年9月19日，但其真正投入使用部署C&C环境为2014年4月，推测攻击者在这段时间内进行准备工作。随后开始活跃了近4个月，然后蛰伏，今年3月开始频繁活跃。

德国的据点建立在2015年12月，但在今年3月才开始部署C&C环境，然后一直保持活跃至今。

香港是最近时间建立的据点，和前两个据点不同，该据点在2016年3月开始，短时间内便完成了系统初始化和C&C环境部署，然后立即投入使用。后续跟踪过程中发现其7月底已失效。

通过对受害者的主机上线时间和DNS解析记录分析，我们推测出其主要活跃期为2014年4月至8月和2016年3月至今。值得关注的是，与样本分析得到结论一致，今年3月至今攻击者尤其活跃,三个C&C同时运行。

3 受害者分析

3.1 区域分析

图2 受害者区域分布

通过对已知的近800名受害者的互联网IP进行Geo分类统计，得到的统计结论如下：

巴基斯坦77%

中国7%

美国5%

英国0.02%

奥地利0.02%

根据统计结果，推测攻击者主要目标以巴基斯坦为主，中国次之，其中中国以北京区域为主，零星有江苏、内蒙、河北区域。

3.2 领域和群体分析

通过对受害者邮箱、所在单位进行分类统计，我们基本确定攻击者攻击的主要目标领域为：

科研院所

军事院校

外交官员

在这些领域中的又以对外联系人、教授、官员为主要目标。比如***@gmail.com为某国空军将军相关邮箱，***@***.edu.**为某国防大学官方邮箱。通过对跟踪获得的信息分析，发现被窃取的文件包含部分大使馆通讯录和军事外交相关的文件，与分类统计中以科研院所、军事院校和外交官员为目标的分析结果相吻合。

图3 受害者群体、领域分析

图4 失窃文件截图

图5 失窃数据截图

3.3 和中国相关受害者

我们将中国境内的受害者互联网IP做了Geo区域统计，得到图6结论：

图6 中国相关受害者区域分布

北京为主要被攻击区域，占到了86%，其中又以东城区、朝阳区区域为主，考虑到攻击者的目标群体有外交官员，所以推测原因与大使馆多分布在北京的东城和朝阳有关。

对以上受害者被窃取的数据分析，我们发现部分受害者为他国驻华大使馆相关人员，正好与上述IP区域分布相符。虽无直接证据证明攻击者的目标直指中国军事情报，但在被窃数据中发现多例受害者间接暴露了中国某些军工单位以及和军队相关的敏感信息。

4 攻击者画像

三个C&C服务器，分阶段建立；以科研院所、军事院校、外交官员为目标；近三年持续采用鱼叉、水坑方式进行攻击。其幕后的组织是谁？来自哪里？在研究人员的追踪和分析后，发现了一些端倪。

4.1 他们是谁？

4.1.1 从攻击工具分析

同时，我们还发现在这两款远程控制工具的版权中注释了部分darkcoderSC的版权，而以“Green HAT Group/Team”字样出现，我们暂未发现darkcoderSC隶属于“Green HAT Group/Team”的线索，所以推测该组织被雇佣对远程控制工具进行过二次修改，或者事件背后组织的名字就叫“Green HAT”，不幸的是在搜索引擎和社交网络中暂未能搜索到与之相关的信息，所幸的是这个名字与中国传统文化习惯完全相悖，加之报告后面的一些重要线索，国外厂商的某些言论是站不住脚的。

图7 远程控制工具中的版权关键词“Green HAT”

两套远程控制工具中残留了部分历史部署信息，从中我们发现“sitar”、“Avatar”两个ID频繁出现在部署或调试的数据中，而且出现时间是2015年6月，说明很早就在准备此次攻击。

图8 调试/部署bots信息

图9 调试/部署信息，Avatar为帐户的计算机

图10 调试/部署信息，sistar为帐户的计算机

据此，我们推测其组织成员中有“sitar”、“Avatar”为昵称的两个成员。

4.1.2 从关联事件分析

本次攻击者使用的域名多为免费的二级动态域名，所以无法从Whois信息中分析注册人和注册组织，但是通过将域名和解析的IP与业界报告进行关联分析，我们发现本次攻击者使用的域名和业界报告的某些APT事件有重合，如下：

所以，如果排除攻击者为了反情报而故意模仿其他攻击组织之嫌，我们推测多起APT事件幕后为同一组织。

4.2 来自哪里？

4.2.1 线索一：控制源IP

攻击者具备很强的反侦察能力，C&C域名使用了从freedns.afraid.org申请的动态二级域名，同时利用了多层跳板来访问和控制C&C服务器，这些跳板的来源IP包括南亚某国、美国、德国、英国、荷兰等，其中南亚某国的访问最多。

图11 攻击者来源IP的地理区域分布

研究人员对这些IP进行了逐个排查，最后锁定了三个方位的IP：

随后的深入分析阶段对这三个IP进行了研判：

美国方位的IP段属于VPS的IP段区，可在pivateinternetaccess.com租用，且IP对外开放1723端口,提供VPN服务，确认其为一个跳板；

沙特阿拉伯IP段出现的频率较少且后续很少出现，未排除其为攻击者真实IP的可能性，但推测为被控端可能性较大；

在对南亚某国IP段分析时，发现其为Sophos UTM设备,表明其挂载的至少是一个局域网，故而攻击者来自此区域可能性较大。

4.2.2 线索二：语言文化

在对样本和C&C远程控制工具进行分析时，我们发现攻击者将远程控制系统后台通信密码默认设置为“January14”，而这个时间节点是南亚某国盛行的“丰收节”，表明攻击者可能受此风俗习惯影响，有一定的可能性自南亚某国。

图12 木马通讯密码配置

除了密码，我们也把上述推测的组织成员昵称放入搜索引擎进行搜索，得到了一些有趣的结果：

结合密码和昵称的语言文化，我们认为这些信息进一步印证了控制源IP来源于南亚某国的分析推断。

4.2.3 线索三：遗留数据

研究人员在跟踪溯源采集的数据中，发现了攻击者调试免杀木马时遗留的证据，免杀针对的杀毒软件包含但不限于：

AVAST

Trendmicro

Bitdefender

Panda

GDATA

NOD32

AVIRA

NIS诺顿

攻击者把每个杀毒软件部署在一个或者多个独立的WIN7或者WIN8系统上，已知约10个系统，逐个测试样本免杀情况。并且，这些杀毒软件同属10.*.*.*子网，考虑到终端的数量和部署环境，推测该子网为攻击者真实的工作环境，而非被控端。

图13 免杀测试环境和对外链接IP

最重要的是，这个子网对外的出口IP正好是上述南亚某国IP段的*.*.*.138，也就是说这个IP是跳板或另一个受害者的可能性非常低，再次证实了攻击者来源于此IP。

基于相关性分析，推测该组织可能与近期友商公布的一些事件存在关联，或许原本是同一组织活跃在不同时期的不同工作。后续研究人员将持续跟进做进一步的确认。

5 攻击工具分析

我们对攻击工具深度分析后发现，攻击者这次发起的“丰收行动”是精心准备的、有组织的一次网络间谍攻击。其使用了APT攻击中最为典型和常用的攻击方式，有效的绕过了传统防护手段。为预防攻击者利用公开信息进行反溯源，以下仅阐述攻击工具的部分分析结果。

5.1 载荷投递

在本次行动中，我们捕获了伪装成Word文档的RTF格式邮件附件样本，所以可以确定攻击者使用了鱼叉攻击。此外，我们发现攻击者囤积了多个浏览器挂马脚本，脚本的最后修改时间为2016年4月，据此推测攻击者还可能使用了挂马或水坑攻击方式。

5.1.1 鱼叉攻击

5.1.2 水坑攻击

5.2 漏洞利用

5.2.1 鱼叉攻击使用的漏洞

“丰收行动”中，攻击者以邮件形式发送了一份捆绑了漏洞利用代码和远程控制工具的Word文档给受害者。附件文档被点击后会显示一份以乌尔都语描述的网络犯罪法案诱饵文档《PEC Bill as on 17.09.2015》，用以迷惑受害者，如下所示：

图14 诱饵文档内容

但该附件文档实质是包含CVE-2015-1641（Word类型混淆漏洞）漏洞利用的RTF格式文档，用户在打开的同时除了用诱饵文档显示迷惑性文档内容外，还会利用该漏洞释放恶意程序，从而感染并控制用户主机。

该附件文档样本的MD5为******e0b4a6b6a5b11dd7e35013d13a，样本捕获后不久交由54款杀毒引擎检测，仅8款能够查杀。用二进制编辑工具打开该文件，由开头的几个字符为{\rtf1\adeflang1025\ansi\，可确定文件是一个RTF文件。同时，该样本文件中包含以下内容：

{\object\objemb{\*\objclass

None}{\*\oleclsid \'7bA08A033D-1A75-4AB6-A166-EAD02F547959\'7d}

在注册表查询此olecsid，发现是Office的otkload.dll组件，该组件依赖msvcr71.dll动态库，可见此RTF文档打开时会加载msvcr71.dll，而msvcr71.dll文件不支持ASRL，所以判断样本加载该库是借此构建ROP来绕过ASRL&DEP。漏洞利用相关代码如下：

表1 漏洞利用相关代码片段

主要目的是要调用VirtualProtect函数绕过DEP，接着跳到栈上的代码。Shellcode部分的代码如下：

表2 ShellCode代码片段

前面很长的一段“dec ecx”作为空指令，覆盖更多的地址来提高漏洞利用的适应能力。该shellcode的主要功能为释放~$Norm~1.dat和Normal.domx两个文件，~$Norm~1.dat是恶意文件的载体，Normal.domx是一个VBE文件，并通过修改注册表来设置多个版本Office的禁止项目，其目标版本为Office 10.0至Office 16.0。

Normal.domx执行后会释放诱饵文档，释放并运行MicroS~1.exe、jli.dll、msvcr71.dll，这三个文件正是攻击者远程控制程序的投放端植入程序。

5.2.2 水坑攻击使用的漏洞

我们在对攻击者所使用的各种资源跟踪过程中，发现攻击者搭建了一套挂马漏洞集成攻击平台。该平台文件最后修改时间为2016年4月，但未配套挂载欲植入的后门程序，故判断该攻击平台处于预备状态。

平台集成的攻击漏洞有针对IE、FireFox浏览器的，也有针对SWF、PDF浏览器插件，已知CVE漏洞如表3所示。

表3 已知CVE漏洞

另外，攻击者还赫然将针对AOL 9.5的漏洞利用代码输出函数命名定义为“IE_0Day”，说明该组织对美国在线的用户群也非常感兴趣。

表4 IE_0Day漏洞

漏洞利用执行的Shellcode是通过进程的PEB结构来查找自己需要的Dll，继而能够在Dll中查找自己需要的函数。

表5 ShellCode代码片段

通过一系列的函数调用完成对新脚本的加载，从而进行后续的恶意行为。

5.3 后门分析

5.3.1 功能分析

“丰收行动”的攻击者使用了三套远程控制工具，这三套工具均以文件和数据窃取为主要目的，其中一款的具体功能主要包括：

与远程C&C服务器通信接收控制命令，具备文件遍历、文件上传下载、命令无回显执行、屏幕截图等功能；

设置自身为随系统启动，收集用户名、计算机名、样本版本信息，并加密上传；

全盘搜索各类文档（主要包括：“pdf、doc、docx、ppt、pptx、txt”），并在形成索引文件后加密上传；

能够对U盘的使用进行监控，对U盘上各类文档进行截获；

从HTTP通信协议请求的相似性分析，另外一款远程控制工具应是该套后门的高级版本，且对关联到的组件样本进行分析后发现其还具备非驱动型的文件隐藏功能。

5.3.1.1 反沙箱检测技术

样本分析时发现，样本调用了QueryPerformanceFrequency和QueryPerformanceCounter两个系统函数来计算系统运行时长，以此来区分真实系统和虚拟系统，从而实现绕过虚拟机的检测，可见其使用了典型的反沙箱检测技术。

图15 绕过虚拟检测

5.3.1.2 非驱动型的高级隐藏技术

在对投放端样本进行关联时，找到其疑似组件。该组件样本先通过SetwindowsHook挂载到所有进程中，然后inline Hook应用层ntdll!ZWQueryDiectoryFile函数，该函数是系统用于查询遍历文件目录的函数。图16为jmp跳转到的Hook函数，先平衡堆栈，然后调用原ZWQueryDiectoryFile函数来获取系统真实返回数据，最后再对返回的结果数据进行相应的处理。

图16 Hook跳转后的执行代码

后续对数据的处理，Hook函数会对原函数的返回结果进行过滤，查询是否包含其指定的文件名称，如果存在则从返回结果里面移除该文件名相关信息。

这样当“我的电脑”对应的explorer.exe进程在查询某目录（例如开始菜单启动项）时，就无法查看到指定的文件，达到不加载驱动也能对文件进行隐藏的目的，避免防御软件对驱动加载这一高危行为的拦截和防御。

5.3.2 基于PowerShell的恶意代码

攻击者使用PowerShell脚本配合程序实现Agent代理端，利用Web服务器统一接受各Agent在杀毒软件测试虚拟机搜集的数据。免杀辅助系统Agent代理端具备系统信息搜集、截屏录屏、键盘记录、数据回传等功能，涉及的组件包括：

表6 组件说明

5.4 C&C分析

从我们直接获取到的样本来看，“丰收行动”的三个C&C服务器一共可对应出8个域名地址，均为免费的二级动态域名，没有办法直接从注册域名信息进行详细分析。

从一些关联到的数据来看，攻击者有攻击其他正常服务器来放置临时数据，以期在漏洞利用植入阶段提供远程下载恶意模块的行为习惯。

6 TTPs分析

表7 “丰收行动”总览

本次行动涉及到TTPs，我们希望能通过图17来进行简要说明：

图17 一张图展示丰收行动

1．确定目标，并搜集个人信息。“丰收行动”针对的目标主要是巴基斯坦、中国等国家的科研院所、军事院校、外交官员为主，攻击者通过搜索引擎、Facebook等社交网络，获取受害者的电子邮箱地址和个人信息，在后续攻陷受害人，还会从受害人的文档里搜集电子邮箱和个人信息。

2．搭建C&C服务器。攻击者分阶段搭建了三个C&C服务器，该过程可能与步骤1同步进行。跟踪发现，该组织的C&C服务器之间有相互的关联，比如德国的C&C服务器的远程控制工具是从摩洛哥C&C服务器下载部署。同时，这些C&C服务器的建设都采用了标准化流程操作，进行了系统加固、支持库安装、控制模块、监控模块部署等，说明对此已经非常熟练。

3．木马免杀。针对目标使用的系统和杀毒软件，搭建环境进行木马免杀工作。在本次跟踪过程中我们发现，攻击者利用了Powershell+VMware搭建半自动化免杀平台来提高效率，足见其成员非新手。跟踪到的数据显示，其中一次免杀工作是在2016年5月2日和3日进行的。此外，攻击者还制作了多个浏览器挂马漏洞库（参考漏洞利用），最后修改时间为2016年4月18日，搭配三套远程控制工具使用。

4．投放诱饵。攻击者将已免杀的木马捆入带有利用程序的RTF文档中，伪装成Word文档，通过电子邮件附件方式发送给受害人，诱使其点击。用户点击后会弹出一个真实的Word文档，迷惑受害者。此外，推测攻击者也会采取发送浏览器挂马网页，发动水坑攻击。

5．加密回传数据。受害者计算机感染木马后，木马会搜索敏感的电子文档、记录键盘操作等，并加密打包为.enc后缀发回到C&C服务器。加解密工具非通用zip等压缩工具，而是攻击者自己编写的私有工具。

6．长期控制。本次行动中攻击者会长期控制受害者计算机，监控其浏览的网页、读取的邮件、新生成的文档，同时根据需要装载新的模块。通过对远程控制工具分析，其包含文件管理、关键词搜索、摄像头监控、键盘记录、U盘监控等功能模块，以窃取文档为主。此外，攻击者会根据从受害者获取到的个人信息和其他联系人电子邮件，做进一步的扩大攻击。

7 结语

与友商用大量样本统计来分析APT方式不同，2046Lab针对“丰收行动”的分析虽也利用了样本分析手法，但更多是利用跟踪溯源的方式。这种跟踪溯源和分析过程，给了我们一种逐渐拨开迷雾见彩虹的感觉。从一个样本到一个C&C服务器，再到另一个样本，到另一个C&C服务器，每跟踪溯源一次，我们对攻击者的了解就加深一些，包括攻击者的目标对象、使用工具、C&C服务器据点、惯用手法，最后云开雾散，发现攻击者的具体IP，定位到其在南亚某国的幕后大本营。这一过程不免让我们感叹，东巽科技倡导的“人与人”的对抗确实是APT防护对抗的本质所在。

本次“丰收行动”，再一次证明了APT攻击的存在和长期活跃，而导致攻击成功的主要因素是：防守在明、攻击在暗，受害者的防御措施与攻击者攻击手段存在能力差距，尤其是未知威胁的检测和预警能力。

本次的揭露只是全球APT攻击事件的冰山一角,中国也是APT攻击的受害者之一。我们预测和以往同行的报告一样，攻击者并不会因为本次的揭露而销声匿迹，至多是偃旗息鼓一段时间，然后以更隐蔽的方式卷土重来，并用上新的免杀技术、新的漏洞或者新的攻击方式。所以，本报告希望能给用户，尤其是可能遭受APT攻击的重要机构一些提醒和建议，落实习总书记4.19讲话精神，树立正确的网络安全观，充分认识自己的防御措施和攻击技术之间的差距，加快构建安全保障体系，提前部署防御措施，尤其是未知威胁的检测和识别方面的能力建设，增强网络安全防御能力和威慑能力，防患于未然。

本文参考资料：

译者：blueSky

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

简介

在编写“2017年第二季度IT威胁与演变”报告的过程中，我发现“前20名移动恶意软件程序”列表中有几种常见的木马程序，这些木马程序使用WAP计费服务（WAP计费是一种移动支付形式，通过话费的形式直接生成用户手机账单）的方式从用户的账户窃取资金。在这种情况下，木马软件不需要发送任何的短信，用户只要点击网页上的按钮木马软件就会产生WAP计费。

从用户的角度来看，具有WAP计费的页面跟常规的网页看起来没什么区别，通常这些页面都包含一个按钮以及关于付款的完整信息。通过点击此按钮，用户将被重定向到移动网络运营商服务器，该服务器会给用户显示一些其他网页信息，用户最终通过点击网页上的另一个按钮来决定是否向运营商付款。如果用户通过移动数据连接到互联网，移动网络运营商可以通过IP地址识别他/她，移动网络运营商只有在成功识别并且点击按钮后才向用户收费。从计费的角度来看，这种机制类似于短信服务-收费是直接通过用户电话账单的形式收取。然而，在这种情况下，木马软件是不需要发送任何短信的，只要用户点击网页上的按钮，木马便开始WAP计费。

我们已经很长时间没有捕获到这样的木马样本了，但有几个木马软件在这段时间却突然出现，几乎在同一时间，来自不同网络犯罪团体的不同特洛伊木马针对不同国家（俄罗斯和印度）展开了网络攻击。这些木马软件中的大多数自2016年底-2017年初以来一直在发展，但其在2017年第二季度开始有上升趋势，所以我们决定仔细研究一下这些木马。

一般来说，这些木马软件通常都具有相似的功能。首先，它们会关闭WiFi并开启移动互联网，它们这样做是因为WAP计费只能通过移动互联网进行。然后它们打开一个能够重定向到WAP计费页面的URL。通常，木马加载这些页面并使用javascript（JS）文件点击按钮。之后，木马软件将删除从移动网络运营商发来的有关WAP计费的短信消息。此外，它们中的一些还有能力发送短信，另外一些木马还能通过利用设备管理员权限使得木马软件难以被检测和删除。

Clicker.AndroidOS.Ubsod木马软件

在这篇文章中，我将以Trojan.AndroidOS.Boogr.gsh这款木马软件为例来详细分析这些WAP计费木马，这些恶意软件是我们的系统基于机器学习算法识别到的，通过机器学习算法，我们的系统发现2017年第二季度最流行的木马软件是WAP计费木马，通过分析，我发现它们属于Trojan-Clicker.AndroidOS.Ubsod恶意软件系列。

Trojan.AndroidOS.Boogr.gsh是一个小而简单的特洛伊木马，该木马从其命令和控制服务器（C&C）接收URL然后打开。这些网址只是一些广告网址，木马通过使用“ViewAdsActivity”等类名称使其伪装成一款广告软件。但是，它可以删除手机收到的那些包含文本“ubscri”（“订阅”的一部分）或“одпи”（俄语中的“Подписка”的一部分）的所有短信消息。此外，它可以关闭WiFi并打开移动网络数据。木马软件这样做的原因是因为WAP计费仅在通过移动互联网访问该页面时才起作用，而不是通过WiFi。

在分析这些木马样本之后，我发现其中一些木马样本（MD5 A93D3C727B970082C682895FEA4DB77B）也包含其他功能，例如其中一些木马软件包含了解密和加载（执行）其他可执行文件的功能，这些特洛伊木马除了通过WAP计费服务窃取资金外，还执行一个命名为Trojan-Banker.AndroidOS.Ubsod的木马软件。

Trojan-Banker.AndroidOS.Ubsod是一个功能强大的木马程序，它不仅通过其他木马软件进行传播，而且还可以作为独立的特洛伊木马（MD5 66FE79BEE25A92462A565FD7ED8A03B4）进行传播。它可以下载和安装应用程序，覆盖其他应用程序的窗口（主要用于窃取用户登录凭据或信用卡的信息）、显示广告、发送短信、窃取收到的短消息，甚至能够在设备命令行中执行命令。此外，它还具有通过WAP计费服务窃取用户资金的功能。Trojan-Banker.AndroidOS.Ubsod是WAP计费木马中最为流行。根据KSN统计，2017年7月的感染该木马软件的用户接近8,000人，这些用户来自82个国家，其中72％的用户来自于俄罗斯。

Xafekopy木马软件

在已经过去的几个月时间里，另一个特别流行的恶意软件家族当属Trojan-Clicker.AndroidOS.Xafekopy。该木马使用JS文件点击包含WAP计费网页上的按钮，并以静默地方式窃取用户的资金。最有趣的是这些JS文件看起来和Ztorg木马软件中JS文件看起来很像，它们甚至有一些功能具有相同的名称，这个木马程序主要攻击印度（37％）和俄罗斯（32％）的用户。

该木马软件通过广告伪装成正常的应用程序，例如伪装成电池优化器应用。用户安装之后，它的从行为上来看，也像是一个正常的应用程序，但它跟正常应用程序有一点区别：就是该恶意软件会去加载一个恶意程序库。该库文件解密安装包并从安装包的assets文件夹中加载恶意文件，这些恶意文件在解密之后会加载assets文件夹中的另一些恶意文件，这些恶意文件包含了木马软件的主要恶意功能。木马软件通过使用解密后的JS文件，可以绕过验证码表单，并点击WAP网页中的计费按钮，以此来从用户的移动帐户中窃取金钱。它也可以通过点击一些广告页面，从广告中赚钱。

据KSN统计，几乎40％的受感染用户在印度，但总体来看，2017年7月份共有来自48个不同国家的5000多名用户感染了该木马软件。

Autosus木马软件

Trojan-Clicker.AndroidOS.Autosus.a木马软件主要是通过使用WAP计费的劫持页面来窃取用户的金钱，木马软件首先从C&C服务器中接收JS文件和恶意URL网址，之后加载这些页面并使用JavaScript（JS）文件点击页面上的恶意按钮，它还可以使用从C&C服务器收到的规则来隐藏用户收到的短信。

启动之后，木马软件会要求用户激活该木马的设备管理员权限。之后，该木马将从应用程序列表中删除其图标，因此用户将无法轻松找到它。同时，木马将继续在后台运行，从C&C服务器接收命令，打开恶意URL并点击恶意网页上的计费按钮。

该特洛伊木马在2017年7月袭击了1400多名用户，其中大多数来自印度（38％），南非（31％）和埃及（15％）。

结论

在过去的几个月时间里，我们发现木马软件针对不同国家的WAP计费业务攻击趋势在不断的增长。尽管具有这种功能的木马多年来一直存在，但我们发现了几种新的木马，而且最近几个月受这些新木马感染的用户数量正在显著的增长。此外，以前的WAP计费服务大都发生在俄罗斯，但现在我们已经在不同的国家（包括印度和南非）发现了这种攻击，甚至针对其他攻击的特洛伊木马也开始通过劫持WAP计费服务来窃取用户的钱。

木马样本MD5

F3D2FEBBF356E968C7310EC182EE9CE0

9E492A6FB926E1338DADC32463196288

A93D3C727B970082C682895FEA4DB77B

66FE79BEE25A92462A565FD7ED8A03B4

AEAE6BFDD18712637852C6D824955859

DA07419994E65538659CD32BF9D18D8A