译者：nstlBlueSky

预估稿费：180RMB

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

前言

2017年4月，我们开始调查通过Google Play应用商店发布的新的系统级恶意软件-Dvmap。

Dvmap木马程序与其他系统级恶意软件不同，该木马软件不仅将其恶意软件模块安装到系统中，还将恶意代码注入到系统运行时库中。卡巴斯基实验室产品检测到了这款木马，并将其命名为Trojan.AndroidOS.Dvmap.a。

其实，通过Google Play应用商店发布系统级恶意软件不是一件什么新鲜事了。例如，自从2016年9月以来，Ztorg Trojan这块恶意软件已经上传到Google Play应用商店几乎多达100次。但是Dvmap是非常特别的系统级恶意软件。它使用各种新技术，其中最有趣的是它将恶意代码注入到系统库libdmv.so或libandroid_runtime.so中。这使得Dvmap成为第一个在运行时将恶意代码注入系统库中的Android恶意软件，该恶意软件已从Google Play商店下载超过50,000次。卡巴斯基实验室向Google报告了该恶意软件，现在该恶意软件已经从Google Play应用商店中删除。

为了绕过Google Play应用商店的安全检查，恶意软件创建者使用了一个非常有趣的方法：他们在2017年3月底之前将一个干净的应用程序上传到Google Play应用商店，然后会在短时间内更新软件，更新后的软件将包含具有恶意功能的模块，一般他们都会同一天在Google Play应用商店上传一个干净的版本。调查发现他们在4月18日至5月15日期间至少进行了5次这样的操作。

一般情况下，所有的类似于Dvmap这样的恶意应用程序都具有相同的功能。他们都会从安装包的assets文件夹中解密多个归档文件，并从解密后的文件中执行以“start.”开头的可执行程序。

有趣的是，从下图可以看出Dvmap木马软件甚至支持64位版本的Android系统，这种情况是非常少见的。

所有加密的文件可以分为两组：第一组包括Game321.res，Game322.res，Game323.res和Game642.res，这些都是在感染的初期阶段使用的，而第二组则是Game324.res和Game644 .res，这些文件用于主要阶段的感染。

初期阶段

在初期阶段，特洛伊木马程序尝试在Android设备上获得root权限并安装一些功能模块。来自此阶段的所有档案都包含相同的文件，除了一个名为“common”的文件。这是一个本地系统漏洞利用工具包，木马程序中使用了4个不同的漏洞利用工具包文件，3个32位系统的和1个64位系统的。如果这些文件成功获得root权限，该木马程序将在系统中安装多个工具，它还将安装恶意应用程序“com.qualcmm.timeservices”。在这些档案文件中，我们发现了一个名为“.root.sh”的文件，这个文件中包含了一些中文注释。

主要阶段

在这个阶段，特洛伊木马从Game324.res或Game644.res启动以“star.”开头的文件。它将检查安装的Android系统的版本，通过Android系统的版本来并决定哪个库应该被“注入”恶意代码片段。对于Android 4.4.4及更高版本，该木马将修改libdvm.so中的_Z30dvmHeapSourceStartupBeforeForkv函数，对于Android 5或者更新版本，它将修改libandroid_runtime.so库中的nativeForkAndSpecialize函数。这两个库都是与Dalvik和ART运行时环境相关的运行时库。在“注入”之前，木马将以名称bak_ {original name}的方式备份原始库。

在代码“注入”期间，木马程序将使用恶意代码覆盖现有的代码，使得木马程序的所有模块可以执行系统模块/system/bin/ip。这种操作将是非常危险的，原因是模块代码被修改之后，设备上现有的需要使用该模块的应用程序将无法正常运行。成功“注入”代码之后，木马程序会将打过“补丁”的库放回系统目录中去。之后，木马将从文件（Game324.res或Game644.res）中使用恶意程序代替原始的/system/bin/ip。他们这样做的目的是：木马软件可以确保其恶意模块将以系统权限被执行。但由于恶意ip文件模块不包含原始ip文件中的任何方法，这意味着所有正在使用此文件的应用程序将无法再正常使用该模块，甚至会开始运行崩溃。

恶意模块“ip”

该文件将由被修改的系统库执行，它可以关闭“VerifyApps”，并可以通过更改系统设置去操作安装任何来自第三方应用市场的应用程序。此外，它还可以授予“com.qualcmm.timeservices”应用程序设备管理员权限，而无需与用户进行任何交互，只需运行命令即可，这种获取设备管理员权限是非常不正常的一种操作方式，在一定程度上这种操作应该引起安全研究人员的足够重视。

恶意应用程序com.qualcmm.timeservices

如前所述，在“初始阶段”中，木马将安装“com.qualcmm.timeservices”应用程序。其主要目的是下载恶意程序并从中执行以“start.”开头的二进制文件。在调查过程中，该应用程序能够成功连接到控制服务器，但由于没有截获到与命令传输相关的网络流量，所以我们不清楚要它将会执行什么样的命令，但可以确定的是它们是一些恶意的程序。

结论

Dvmap木马软件通过Google Play应用商店发布，并使用了一些非常危险的技术，包括修改系统库等操作。它将具有不同功能的恶意模块安装到系统中。它的主要目的是进入Android系统，下载一些二进制程序，并以root权限来执行这些二进制程序。但是，目前为止我们还没有从他们与控制服务器交互的过程中收到过这样的文件，这个也是我们需要进一步调查的工作。

这些恶意模块向攻击者报告他们将要做的每一步操作，所以我认为恶意软件作者仍然在测试这个恶意软件，因为他们使用了一些新兴的技术去感染Android终端设备，这些技术可能还不是很稳定。到目前为止，已经有很多的用户终端感染了他们的恶意软件。我们希望通过早起阶段发现和充分的研究这种恶意软件，以至于当攻击者准备好大规模发起网络攻击的时候，我们将能够有能力防止这种大规模和危险的攻击。

作者：興趣使然的小胃

预估稿费：300RMB

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

在本文中将介绍三种使用 Android设备进行渗透测试的思路。本文中的大多数使用基于 Kali Nethunter.

安装Kali Nethunter

kalinethunter是在已有的 rom上对内核进行修改而定制的一个系统，他通过chroot来在安卓设备中运行 kali。故在安装kalinethunter前你得先有一个被支持的rom.官方支持的设备和rom列表：https://github.com/offensive-security/kali-nethunter/wiki。这里我用的是nexus4，其他设备的流程应该大概差不多。具体流程如下：

从https://build.nethunter.com/nightly/下载对应的kernel-nethunter-makocm<适配设备mako nexus4>-marshmallow<版本号，cm13是 android 6.0 >-*和nethunter-generic-armhf<架构，nexus4为armv7 32位>android-kalifs-full-rolling-*， 然后使用twrp先刷kalifs ，然后刷入kernel.

遇到的问题

nethunter app会卡死在 复制脚本文件那，我注释掉了那两句复制文件的代码，手动把apk中asserts目录下的相应目录复制为：/data/data/com.offsec.nethunter/files/{etc,scripts}和/sdcard/nh_files

在windows下复制脚本到linux, 会因为换行符的问题导致脚本不能执行， 使用 dos2unix 对文件进行转换

com.offsec.nhterm（用于开启、使用 kali的命令行界面）会报错，使用https://github.com/madScript01/install_nh 中的Term-nh.apk 把它替换掉。

为了方便后面的实验，开启 ssh服务，使用PC连接(默认用户名密码： root/toor)， 真正去渗透时我们可以把一些常用的命令写成脚本方便直接运行。

开启ssh

思路一：普通U盘类攻击

点击需要挂载的镜像，然后会有几种挂载方式，这里使用第二种就行。弄好后，用usb线接入电脑，会提示 需要格式化 ，格式化后就和普通的U盘一样用了。

U盘攻击很早之前就有了，那时使用 autorun.inf 来传播病毒， 下面要介绍的是使用 最近的 cve-2017-8464 的 exp来进行攻击。首先使用msf生成 payload

根据你的U盘在pc上识别为什么盘(A,B,...)来复制相应的 .lnk文件 和 .dll。为了通用把他们全复制到u盘根目录。然后设置好 handler:

插入U盘，打开我的电脑，就会反弹shell了。

思路二：HID攻击

手机通过USB连到 PC ,然后：

电脑上会打开 cmd, 执行 ipconfig：

这种方式非常简单，但是不够灵活。当机器的默认输入法为中文时，命令输入有时是会出问题的，比如输入 " （英文双引号）时 会变成 “（中文双引号）。

我建议用下面的那个 DuckHunter HID 模式进行这种方式的攻击。

该模式 允许我们使用 Usb Rubber Ducky的语法来实现 HID攻击，此外该模式还提供了一个 Preview 的选项卡，通过它我们可以发现其实HID攻击实际上就是使用 shell命令向 /dev/hidg0 发送数据，之后该设备就会将他们转换为键盘或者鼠标的操作。

后来在Github瞎找，找到了一个针对该模式生成shell脚本的项目：https://github.com/byt3bl33d3r/duckhunter使用它我们可以很方便的对脚本进行测试（写完Usb Rubber Ducky脚本用该工具生成shell脚本然后再 Nethunter上运行 shell脚本。），同时该项目还提供了简单的Usb Rubber Ducky的语法。

此时我们就能通过Nethunter向主机输入各种的键盘按键，组合键等。所以对于上面提出的 中文问题。我们可以在需要输入字符时，发送shift键切换到英文就行了。

一个通过执行 powershell 反弹shell的脚本示例：

tips:

在中文输入法为默认输入法时，在需要输入字符前，使用 shift 切换为 英文。尽量使用小写，因为大写的字符有时输入不了。

命令前可以插延时，回车， 空格 规避一些错误

powershell 执行的命令是使用了nishang的 Invoke-Encode.ps1模块进行的编码。详细请看：http://m.bobao.360.cn/learning/detail/3200.html

编码前的powershlle要执行的命令为

保存到文件，传到手机，在Nethunter中导入，运行（已连接电脑的前提下）。

然后电脑上就会输入 并执行

然后就可以拿到shell

现在有个问题就是使用这种方式拿到的shell会在 pc上有 黑框， 关闭黑框shell就断了。这里我决定使用 metasploit的meterpreter来解决这一问题。

2. 开启hander, 同时设置自动运行脚本，当shell过来时，自动迁移进程

3. 在目标机器远程调用执行payload

4. 执行完后sleep 几秒，以保证 msf 能够成功迁移进程。

5. 关闭命令行

生成 payload 和 开启handler 设置自动迁移进程

为了简单，复制 生成的 powershell脚本到本地的web服务器。使用nishang对下面的脚本编码。

我这sleep 15秒等待msf迁移进程。编码后，最终DuckHunter HID攻击脚本

执行后 ，msf的输出

思路三：无线攻击

在手机上使用 otg 功能外接支持 monitor 的网卡，然后就和在 pc上使用 kali是一样的了。由于 nexus4 不支持 otg, 同时该方面的攻击网上也有很多文章介绍。下面说下思路并附上一些相关链接。

1. 破解wifi密码

2. 伪造ap，获取wifi密码

3. 进入wifi后，中间人攻击，嗅探，伪造更新。。。

破解wifi密码

破解wifi可以使用 aircrack-ng进行破解, 抓握手包，然后跑包（自己跑或者云平台）或者 直接使用 wifite 自动化的来。

http://www.cnblogs.com/youcanch/articles/5672325.html

http://blog.csdn.net/whackw/article/details/49500053

伪造ap，获取wifi密码

https://github.com/P0cL4bs/WiFi-Pumpkin/

https://github.com/wifiphisher/wifiphisher

中间人攻击

https://github.com/byt3bl33d3r/MITMf/wiki

http://www.CodeSec.Net/sectool/45796.html

参考链接

https://github.com/offensive-security/kali-nethunter/wiki

https://www.52pojie.cn/thread-520380-1-1.html

http://wooyun.jozxing.cc/static/drops/tips-4634.html

译者：興趣使然的小胃

预估稿费：200RMB

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

在这篇安全公告中，我们介绍了Chrome 59版本浏览器中存在的一个类型混淆问题，这个问题最终会导致远程代码执行漏洞。

Chrome浏览器中存在一个类型混淆漏洞。该漏洞出现在用于优化javascript代码的turbofan编译器中，导致访问程序在访问对象数组以及数值数组之间存在混淆，如果以数值形式来读取对象，那么就可以像访问数值那样访问对象（因此可以通过内存地址来读取这些值），反之亦然，也可以将数值写入到某个对象数组中，因而能够完全伪造对象。

二、漏洞细节

2.1 背景知识

对象映射图（object map）

每个对象都有一个映射图与之对应，用来表示对象的结构（键值以及值的类型）。具有相同结构的两个对象（但这两个对象的值不同）会使用相同的映射图。对象最常见的表示方法如下所示：

如上图所示，映射图的字段（指向映射图的某个指针）保存着具体的对象图。两个固定的数组分别保存着额外的命名属性以及编号属性。编号属性通常也称为“元素（Elements）”。

图转换

当我们往对象中添加新的属性时，对象的图会处于失效状态。新的图会被创建，以适应新的对象结构，原始图中会添加一个转换描述符（transition descriptor），以描述如何将原始图转换为新的图。

例如：

随后，当内联缓存（inline cache）没有命中时，编译器可以利用这些转换描述符来重新优化函数代码。

元素类型

如上所述，对象的元素就是编号属性的值。这些值存储在对象指向的常规数组中。对象图中有个名为ElementsKind的特殊字段。这个字段描述了元素数组中的值是否为boxed、unboxed、contiguous、sparse还是其他值。仅通过元素类型进行区分的图不会通过转换关系进行连接。

V8数组

v8引擎中的数组属于有类型（typed）数组，可以使用“boxed”或者“unboxed”值。这基本上就决定了数组是否只能存储双精度值（整数也使用双精度来表示），或者也能存储更加复杂的值，在后一种情况下，这些值实际上是指向对象的指针。

简单描述一下这两种情况，如下所示：

（数组本身的类型就决定了其值是boxed还是unboxed。）

因此，如果我们有一个数组（如上图左图所示），然后我们将某个复杂对象（如数组对象）分配给其中一个数组位置，那么整个数组就会变成boxed数组，所有已有值也会相应地变为boxed类型的值。

V8优化

V8编译器首先会分析javascript代码，以生成JIT编译代码，这一过程使用到了内联缓存（inline cache），同时对类型的处理没有那么严格。

从Google的V8官方文档中，我们找到如下解释：

“在首次执行时，V8会将JavaScript源代码直接编译成机器码。其中不存在中间字节码以及解释器。对属性的访问由内联缓存代码来处理，当V8执行时可能会使用其他机器执行来修改内联缓存代码……”

“V8会根据预测来优化属性访问过程，依据的是同一代码在未来访问所有对象时也会用到当前这个对象的类，然后会根据类中的信息来修改内联缓存代码，以便使用隐藏类。如果V8预测正确，那么属性的值就可以在一次操作中完成分配（或者读取）。如果预测错误，V8会修改代码来删除优化策略。”

因此，编译器只会编译适用于特定类型的那些代码。如果下一次代码（或者函数）所执行的类型与编译的类型不符，那么就会出现“内联缓存丢失”现象，导致编译器重新编译代码。

比如，假设我们有一个函数f，以及两个对象o1和o2，如下所示：

当使用o1第一次调用函数时，编译器会生成如下代码：

如果使用o2再次调用这个函数，就会出现缓存丢失现象，编译器代码就会修改函数对应的JIT代码。

2.2 具体漏洞

元素类型转换

当出现缓存丢失现象并且编译器想重新优化函数代码时，编译器会使用已保存的转换关系，也会使用Map::FindElementsKindTransitionedMap函数，即时生成所需的ElementsKindTransitions（转换到仅在元素类型上有所差别的另一张图）。之所以使用即时方式完成这一过程，原因在于编译器只需要修改ElementsKind这个字段，而不需要完全修改整张图。

稳定（stable）图

当访问图所属元素的代码已完成优化，此时图就会被标记为稳定（stable）状态。

当优化编译器认为函数已经使用得差不多，可以进一步“减少”时（即编译器想进一步优化代码，减少代码大小），此时就会出现漏洞。此时，ReduceElementAccess函数会被调用，以减少对某个对象元素的访问。该函数会继续调用ComputeElementAccessInfos。

ComputeElementAccessInfos这个函数也会搜索可能的元素类型转换，以进一步优化代码。

问题在于这种转换会不会从一张稳定图中生成及使用。原因在于，如果使用了这样一种转换，那么它只会影响当前的函数，使用同一张稳定图的其他函数不会去考虑这种元素类型转换。

具体过程为：首先，某个函数以某种方式被优化减少，使其修改了某张稳定图的元素类型。然后，第二个函数以某种方式被优化减少，使其存储/加载了同一张稳定图中的某个属性。现在，这张图的某个对象被创建。第一个函数被调用，使用该对象作为函数参数，然后元素的类型会被修改。

第二个函数被调用，内联缓存并没有丢失（请记住，元素类型转换并不是转到另一类图的那种转换，因此不会造成缓存丢失）。

由于缓存没有丢失，因此函数会存储/加载属性值，就如同对象的元素仍处于unboxed状态一样，所以，这里我们能读取或写入一个对象指针数组。

然而，实际上在之前的commit中已经提到过这个问题：“如果需要元素类型转换时，请确保对象图处于不稳定状态”。

编译器做的工作如下：当函数发生缓存丢失现象时，编译器会检查是否可以使用元素类型转换来纠正缓存丢失。这个过程由KeyedStoreIC::StoreElementPolymorphicHandlers以及KeyedLoadIC::LoadElementPolymorphicHandlers来完成。对比commit前后的代码差异，我们发现如果用于转换的对象图处于稳定状态，那么它会被设置为不稳定状态（这意味着优化代码会被反编译），以确保转换会影响使用这张图的所有函数。

因此，当第一次函数需要修改图的Elements Kind字段时，StoreElementPolymorphicHandlers会调用FindElementsKindTransitionedMap，查找元素类型转换关系，确保将对象图设置为不稳定状态，从而确保使用该图的代码会被去优化（deoptimized）处理，且未来的代码不会在该图上进行优化，以确保元素类型被正确处理。

那么，尽管如此，我们如何从稳定图中获得元素类型转换呢？

在解释这一点之前，我们需要了解过时图（deprecated map）的概念。过时图指的是该图的所有对象已经全部转变为另一张图的对象。这种图会被设置为不稳定、去优化状态，已经从转换树中移除（即从该图来或者到该图去的所有转换都已被删除）。

现在，如果我们查看ComputeElementAccessInfos源码，我们可以看到代码在调用FindElementsKindTransitionedMap之前会调用TryUpdate。

Tryupdate函数在收到一张过时图时，会尝试从同一棵“树”中查找另一张没有过时的图（即来自同一个根图并经过相同转换形成的图所构成的树），如果找到这种图，就会将其返回。

元素类型转换所对应的原始的对象图会在LoadElementPolymorphicHandlers中被设置为不稳定状态，并已经成为过时图。TryUpdate找到另一张图，然后会切换到这张图。但这张图从来没用于优化这个函数，因此也永远不会被设置为不稳定状态，因此，我们会再次从一张稳定图中得到元素类型转换。

调试版源代码中其实有一个检查过程，以确保不会从稳定图中生成转换关系（相关代码添加在之前的那个commit中），但这段代码显然不会对发行版产生影响：

三、简单的PoC

四、修复方法

修复方法非常简单，只要在调用FindElementsKindTransitionedMap之前添加is_stable()检查函数即可。

五、完整的PoC

使用如下PoC，我们可以攻击没有使用沙箱特性（–no-sandbox）的Chrome 59版本，弹出一个计算器（calc）。具体操作如下：

1、利用该漏洞来读取arraybuffer.proto的地址。

2、我们创建一个伪造的ArrayBuffer图（在图中使用arraybuffer proto的地址），利用该漏洞读取伪造图的地址。

3、利用伪造图的地址，我们可以根据该图创建一个伪造的ArrayBuffer对象，然后再次利用这个漏洞获取对象的地址。

4、我们利用这个漏洞，将指向伪造的ArrayBuffer的指针写入一个boxed元素数组，现在我们就可以从JS代码中正常访问我们伪造的ArrayBuffer。与此同时，我们可以编辑伪造的ArrayBuffer，将用户模式内存中的地址映射出来。因此现在我们掌握了完全的读取/写入权限。我们可以再一次利用这个漏洞，读取已编译函数的地址，然后使用读/写（R/W）权限将我们的shellcode覆盖这个地址，最后，调用这个函数执行我们的shellcode。

热点概要：福熙PDF阅读器被曝存在两个严重0day漏洞、恶意代码分析教程：针对一个具有绕过饭分析技术的恶意word文档分析（含样本）、Bug Bounty：Ubiquiti airMAX/airOS登录绕过漏洞、趋势科技检测到新型Exploit工具包、渗透测试学习笔记、漏洞环境虚拟机生成器（类似Metasploitable2，渗透测试爱好者可使用此项目快速创建漏洞环境）、Koadic：COM 命令控制框架（JScript RAT，类似Meterpreter、Empire）、AndroidManifest.xml文件安全探索

国内热词(以下内容部分摘自http://www.solidot.org/)：

加密邮件服务商ProtonMail 称它反黑了钓鱼攻击者

乌克兰恶意程序作者自首帮助 FBI 调查民主党全国委员会的黑客攻击

福昕PDF阅读器被曝存在两个严重0day漏洞

http://thehackernews.com/2017/08/two-critical-zero-day-flaws-disclosed.html

技术类：

恶意代码分析教程：针对一个具有绕过反分析技术的恶意word文档分析（含样本）

http://www.ringzerolabs.com/2017/08/bypassing-anti-analysis-technique-in.html

Bug Bounty：Ubiquiti airMAX/airOS登录绕过漏洞

http://www.nicksherlock.com/2017/08/login-bypass-in-ubiquiti-airmax-airos-if-aircontrol-web-ui-was-used/

Turla APT组织更新KopiLuwak javascript后门用于攻击2017 G20峰会相关人士

https://www.proofpoint.com/us/threat-insight/post/turla-apt-actor-refreshes-kopiluwak-javascript-backdoor-use-g20-themed-attack

趋势科技检测到新型Exploit工具包

http://blog.trendmicro.com/trendlabs-security-intelligence/new-disdain-exploit-kit-detected-wild/

渗透测试学习笔记

http://avfisher.win/archives/741

http://avfisher.win/archives/756

漏洞环境虚拟机生成器（类似Metasploitable2，渗透测试爱好者可使用此项目快速创建漏洞环境）

https://github.com/cliffe/SecGen

Koadic：COM 命令控制框架（JScript RAT，类似Meterpreter、Empire）

http://www.kitploit.com/2017/08/koadic-com-command-control-framework.html

使用PentestBox工具利用ETERNALBLUE对Win7进行攻击，获取Meterpreter反弹

http://fuping.site/2017/08/16/HOW-TO-USE-PENTESTBOX-TO-EXPLOIT-ETERNALBLUE-ON-windows-7/

3个步骤实现简单语言解释器（自制简易编程语言）

https://francisstokes.wordpress.com/2017/08/16/programming-language-from-scratch/

如何攻击Java反序列化过程

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

自动化PCB逆向工程

https://www.usenix.org/system/files/conference/woot17/woot17-paper-kleber.pdf

AndroidManifest.xml文件安全探索

http://mp.weixin.qq.com/s/C1serFo7aQ2peSLorAS-HQ

Metasploitable 3: Exploiting ManageEngine Desktop Central 9

http://www.hackingtutorials.org/metasploit-tutorials/metasploitable-3-exploiting-manageengine-desktop-central-9/

fastboot oem vuln:Android Bootloader Vulnerabilities in Vendor Customizations

https://www.usenix.org/system/files/conference/woot17/woot17-paper-hay.pdf

vTZ: Virtualizing ARM TrustZone

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

Dodgy behaviour from Speedtest.net & Google

https://medium.com/@slinafirinne/dodgy-behaviour-from-speedtest-net-google-5aef6cb25

Shattered Trust: When Replacement Smartphone Components Attack

https://www.usenix.org/system/files/conference/woot17/woot17-paper-shwartz.pdf

POTUS: Probing Off-The-Shelf USB Drivers with Symbolic Fault Injection

https://www.usenix.org/system/files/conference/woot17/woot17-paper-patrick-evans.pdf

译者：興趣使然的小胃

预估稿费：150RMB

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

一、前言

在上一篇文章中，Rohit向我们介绍了如何使用Frida完成基本的运行时测试任务。简而言之，Frida可以动态改变Android应用的行为，比如可以绕过检测Android设备是否处于root状态的函数。对于在ART（Android Runtime，Android运行时）环境中运行的应用来说，我们可以使用Java.perform来hook函数。

然而，在某些情况下，开发者会使用Android NDK来执行各种操作，比如检测root状态等，这种情况下，开发者就可以使用C++或C语言来开发代码，也可以访问APK中的函数。

在本文中，我们介绍了如何实现使用Android NDK开发的代码的动态插桩，具体而言，我们会介绍如何利用Frida来hook使用C++或C开发的函数。

二、动机

像Xposed之类的框架默认情况下没有提供hook原生函数（native function）的功能，而其他工具，如android eagle eye对初学者来说并不友好，学习曲线非常陡峭。然而，我们可以使用Frida来hook基于Android NDK框架构建的那些函数。接下来我们可以看看具体的操作流程。

三、目标：Rootinspector

在本文中，我们的测试对象为Rootinspector应用，这个应用可以检查设备的root状态，应用由纯C++语言编写的原生代码构建而成。我们的目标是hook这些函数，绕过root检测逻辑。

在Rootinspector中，与root状态检测逻辑有关的代码分为两个部分。APK中的一个封装函数会调用由C++编写的checkifstream()底层函数，这一过程所对应的java函数为checkRootMethodNative12()，如下图所示。

checkRootMethodNative12()是Android APK中使用Java编写的函数，会调用底层的checkifstream()函数，后者使用C++编写。

这个Android APK中声明的所有原生函数如下所示。

检查原生函数的源代码后，我们发现这个函数的具体实现为JavacomdevadvancerootinspectorRootcheckifstream，这个字符串由包名及函数名构成，由“”符隔开。

我们首先尝试hook checkRootMethodNative12()这个Java函数，所使用的代码如下所示：

然而，上述代码没法实现hook任务，出现的错误如下所示。Frida无法获得Root类对应的“localRoot”对象的引用。

在这种情况下，我们无法hook使用C++编写的那些函数，因为这些函数没有运行在Java VM上下文环境中。因此，我们必须做些改变，才能hook到原生的C++代码。

四、Hook原生代码

我们可以使用Frida中的Interceptor函数，深入到设备的底层内存中，hook特定的库或者内存地址。

当APK被封装打包时，编译器会编译C++代码，将其存放在APK文件lib目录中的“libnative.so”，如下所示。

使用Interceptor时，我们需要hook libnative2.so这个.so以及Javacomdevadvance_rootinspectorRootcheckfopen函数。我们需要使用十六进制编辑器或者调试器来读取.so文件，通过逆向工程获取函数名。这里我们耍了点小聪明，因为我们对应用的源代码已经非常熟悉。

现在，我们可以运行如下代码，看看我们是否可以成功拦截到checkfopen这个原生函数。

执行上述代码后，我们又遇到一个错误，错误提示某个指针不存在，这意味着libnative.so文件没有被正确加载，或者应用没有找到这个文件。

然而，再次运行代码，保持应用处于启动状态，我们的代码就能正常执行。具体操作为，先结束第一次运行的脚本，保持应用处于打开状态，再次运行脚本，点击“inspect using native code”按钮后，程序的运行状态如下图所示。

我们有必要了解发生这种情况的具体原因。在Android 1.5中，Android NDK提供了动态链接库（与windows环境中的DLL类似），以支持NDK中的动态加载特性。当我们第一次启动应用时，dll文件（libnative2.so）没有被加载，因此我们会得到一个“expected a pointer”的错误信息。现在，当我们终止脚本、保持应用处于打开状态时，再次运行脚本，程序发现dll文件已经被加载，因此此时我们就可以hook目标函数。

现在换个思路，不必等待程序加载dll文件，我们可以在“dlopen”函数上设置一个陷阱，这个函数是一个原生系统调用，可以用来加载与应用有关的所有动态链接库。一旦dlopen函数hook成功，我们就可以检查我们的目标dll有没有被加载。如果dll是第一次被加载，我们可以继续运行，hook原生函数。我们使用didHookApi布尔值检查hook过程，避免dlopen被多次hook。

我们使用如下代码来直接hook原生函数。代码可以分为两部分。

在代码第17-30行中，我们首先尝试使用Frida的Module.findExportByName API来hook dlopen函数，然后搜索内存中的dlopen函数（这里只能祈祷该函数没有被覆盖）。

在onLeave事件中，我们首先检查我们的目标DLL有没有被加载，只有DLL已经被加载的情况下，我们才会hook原生函数。

执行最终的脚本后，我们就可以通过原生函数，绕过Rootinspector的root检测机制，过程如下所示。

脚本运行之前如下所示：

现在，关掉应用，在不启动应用的情况下运行脚本。脚本会自己打开这个应用。我们只需要点击“Inspect Using Native”这个按钮即可，如下所示。

译者：nstlBlueSky

预估稿费：200RMB

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

背景

在生活和工作中，我们往往都需要用到一些类型的编辑器，这样才能开展我们的工作。但是，当选择一个编辑器时，每个人都有自己的看法。有些人是新潮派，喜欢使用像Atom或者Sublime这一类型的现代编辑器，而另外一些人则是守旧派，更喜欢坚持使用像Vim或Emacs这一类型的编辑器。无论你选择什么，对于一款编辑器而言，你最想做的可能就是以某种方式对此工具进行自定义操作。

现代编辑器的插件和扩展功能都是非常强大的。除了外观上的一些自定义之外（字体，配色方案等），它们还提供了一系列功能，这些功能能够使您的生活和工作变得更轻松，您应该能够找到一个适合您需要的插件。如果没有，你可以创建和发布一个。

通常情况下，用户会下载新的插件以满足他们的需求，这样他们的插件列表就会变得越来越多（因为谁会有时间去删除那么旧的或者未使用的插件呢？）。这其中，许多编辑器是支持自动更新的，以确保及时的修复bug以及增添新功能等。

对于这篇文章，我将重点研究Atom这款编辑器工具Github上的“明星”编辑器。根据他们的网站介绍，这是一个“21世纪的黑客文本编辑器”。 Atom编辑器的用户群在不断增长，它包含了各种各样的软件包。您甚至可以通过一些小技巧在Chromebook上安装Atom，这些技巧是通过绕过ChromeOS上的基本安全模型，使得您可以在Chromebook上安装Atom。

目标

我的任务是探索恶意的Atom插件对该工具的影响程度到底有多大。我们不知道我们将要面临什么障碍，不知道Atom会不会有什么安全措施来阻止我们的恶意程序。但事实证明，没有任何的阻碍...在几个小时之内，我不仅发布了我的第一个应用程序，而且更新了它，在此应用程序中还包含有一点点的恶意代码。

计划很简单：

第一步：获取一个已经发布的简单的包或者插件

这个过程我们需要什么以及该过程是否有难度（我们是否需要我们的应用程序被审查）？

第二步：测试更新过程

如果你打算创建一个恶意软件包，那么你将首先需要创建一个非恶意软件包，这个非恶意的软件包需要拥有一个庞大的用户群，然后推送一个软件更新，该更新包中包含了一些恶意的代码。

第三步：从Atom包中实际测试我们可以实现的功能

我们需要确定我们的恶意软件是否在沙箱中运行以及我们拥有访问哪些系统库的权限等。

创建简易插件

步骤1

网络上有很多指南可以用来指导如何创建和发布Atom的包，包括在Atom官方网站上就有一个很详细的指南。生成一个新的包需要的步骤是：

1.创建一个新的包：

cmd + shift + p

Package Generator: Generate Package

2.步骤1将为我们生成一个简单的包，这个包只包含了一个toggle方法，这个方法我们将在稍后会使用到：

toggle: ->

3.将代码推送到Git 仓库

4.发布我们创建的Atom包

步骤2

在初始设置完成后，我们接下来将对我们之前创建的包做一些修改

toggle: ->

将代码推送到Github

发布新版本的代码

从第一步和第二步操作来看，发布和更新一个Atom包是非常容易的操作，下一步将看看我们发布的包实际上可以干些什么事情。

这似乎是一个合理的请求

步骤3

可以看到，Atom包是通过node.js技术创建的，初始测试我们可以看看有哪些模块可以访问。从请求包入手似乎是一个很好的开始，因为它允许我们将数据从用户的机器中取出并进入我们自己手中。

1.经过一番技术研究发现，可以很容易导入一个第三库到我们的包中：

2.把这个第三库导入我们的代码中：

3.更新我们的代码，用户机器会将一些数据发布到我们的远程服务器

toggle: ->

有了这个，一旦toggle函数被调用，那么我们的包就会自动发送信息给我们。现在我们有一种获取信息的方法，我们需要看看我们能够访问哪些信息。

植入后门代码

我们更改我们的toggle函数尝试获取当前用户机器上的的数据，代码如下所示：

toggle: ->

上面的这个代码片段在实际的运行中是有效的，这意味着我们可以在用户的机器上运行命令，然后根据需要从返回的数据中提取我们需要的数据。其实现在，我们发布的Atom包已经可以执行一些恶意的操作了，但是我们有必要做进一步的研究。

更进一步

之前，我们的命令是硬编码到我们的代码中的，现在我们将修改代码使得软件能够自动发送需要执行的命令！ 之前我们创建的Atom包中，只有toggle函数被调用时才会触发执行命令，现在我们将修改代码，完成一旦一个按键被按下就会触发执行命令的函数。

首先我们需要去hook当前编辑器的onChange事件：

之后，在Atom包中创建myChange函数，该函数将执行一些恶意的操作：

这段代码片段实现了我们想要完成的功能。 编辑器中每发生一个变化，我们都会将编辑器中的文本发送到我们的服务器，然后服务器会返回一个新的命令到用户的机器上执行。 我们运行命令并将执行结果发送到我们的服务器。

现实在存在的后门插件

虽然我们只是想演示这种攻击是如何发生的，但是现实中却出现了一个有趣的故事。Kite公司，一家生产基于云编码工具的软件公司，该公司招聘了Minimap（一个Atom插件，超过380万次下载）的开发人员，随后Minimap插件推出了一个更新，此更新除了其他功能之外，将Kite公司的广告插入到Minimap插件中。同样的，我们发现Kite公司在几个月前就默默地收购了autocomplete-python插件（另一个流行的Atom插件），以用来推广Kite公司的产品。

这个事情一经发现，Kite公司就被迫道歉并采取了相应的措施，以确保他们不会再这样做。但类似于Kite公司收购Atom包这种行为，在过去一周内有报道说，两个Chrome扩展已被网络攻击者利用，并向其中注入了广告软件。 Chrome和Copyfish的Web开发人员都将可能遭受网络钓鱼的攻击。有关这些事件的详细信息，请参阅这里（Web Developer）和这里（Copyfish），其主要原因是用户在不知情的情况了使用了有后门的Chrome的扩展程序。

总结

我们创建了一个插件，并发布了它，但这个插件并不具有任何的危害。此插件是在没有沙盒，没有任何权限限制的环境中运行的，而且也没有任何的防护去阻止我们窃取用户机器上的数据信息。即使安全研究人员会对上传的软件代码进行了某种分析，但攻击者也可以在软件运行时远程执行恶意代码。自动更新意味着即使我们的插件今天很好，但或许这款插件明天可能就会被植入了后门程序。

因此，虽然迫使开发人员仅使用某些可以控制的开发工具或者插件似乎看起来很不人性，但如果不受控制，我们将越来越难以确保这些工具的安全性。

前不久，360安全中心率先发布了MBR木马——“隐魂”的预警，对木马入侵过程分析（史上反侦察力最强木马“隐魂”：撑起色情播放器百万推广陷阱http://bobao.360.cn/learning/detail/4238.html）后发现，“隐魂”的反侦察能力极高，堪称迄今最复杂的MBR木马。360安全中心随即对该木马展开了持续追踪，本篇是对其篡改主页的行为详细介绍。

1摘要

首先，我们来进一步了解“隐魂”木马的反侦察能力和复杂性。

（1）隐蔽性极高：“隐魂”木马会通过挂钩磁盘底层驱动实现自我保护，普通的ARK工具或查杀类工具无法深入磁盘底层，难以有效检测到MBR被修改；同时，应用层代码在TimerQueue中调度，目前除了利用调试器进行反复测试外，根本没有其他方法能检测该系统触发机制；另外，内核LoadImage挂钩代码在Nt节的空白区域，这部分在未知内存区域执行的代码也是检测工具的一大盲区。

（2）对抗性极强：为了与检测工具及杀软对抗，“隐魂”使用签名和PDB文件名方式，禁止一系列驱动加载，即使加载成功相关功能函数也会被IAT挂钩。

（3）兼容性极高：“隐魂”是目前支持系统范围最广的MBR木马，从windows XP到Win10X64位最新系统的均支持，兼容性远远超过2016年开始活跃的暗云Ⅲ木马。

其次，我们再来说一下“隐魂”木马在篡改主页时是如何清理犯罪现场的。

（1）声东击西：不同于直接在浏览器进程中添加参数的劫持方式，“隐魂”为了躲避查杀，采取了结束原浏览器进程——创建新的系统进程——再创建新浏览器进程的方式绕了个大圈才完成主页篡改。

（2）釜底抽薪：“隐魂”会把大多数杀软的正常挂钩全部抹掉，使得浏览器主页失去安全类软件的保护。

接下来，将从WindowsNt系统加载前(BootKit)、系统加载后(RootKit)、注入桌面进程explorer

改首页共三部分对木马的执行流程进行详细分析。

2 NT系统加载前

2.1 MBR部分

将自身代码拷贝到0x600处执行。

图1

而后使用int 13 42扩展读功能读取0x1个扇区到0x7c00，

位置是由bp指定的。

图2

读取：

图3

而后跳转到0x7c00处继续执行。

图4

跳转:

图5

并将自身代码再次拷贝到0x600处执行:

图6

这次相同位置连续读取0x20个扇区：

图7

定位位置:

图8

读取20个扇区:

图9

然后将代码拷贝到0x101000大小为0x1400。

图10

而后跳转到0x10100处执行:

图11

然后预留高端地址0x14 = 20KB页面用来存放代码。

图12

将自身代码拷贝到高端地址:

图13

跳转到0x9a400处执行挂钩代码。

图14

然后挂钩int13中断:

图15

挂钩后：

图16

挂钩处代码为0x9a400 + 45 = 0x9a445。

图17

2.2Int13挂钩部分

Int13挂钩中断被执行，搜索硬编码并挂钩:

图18

挂钩函数为:

图19

挂钩后函数被修改为:

图20

2.3 BootMgr部分

当系统控制权交给BootMgr 16位代码后，

准备转移给32位代码执行时挂钩中断被执行。

相关函数为：

图21

跳转：

然后直接搜0x400000地址并挂钩

图22

从BootMgr PE节信息中搜可执行代码，自带反汇编引擎搜索ImgpLoadPEImage对 LdrRelocateImageWithBias的调用，然后Patch对该函数调用。

挂钩前该处调用为:

图23

特征码为：

图24

搜到后特征码0xc0000221及0x20B后，

找到下一个Call调用机器码为0xE8且指令长度为5即为搜索成功。

图25

后挂钩：

图26

挂钩后调用为：

图27

Winload挂钩函数为：

图28

2.4 WinLoad部分

当系统执行到bootmgr!BmpTransferExecution将控制权转移给Winload时候，

挂钩函数HookWinLoad被执行。

先将LdrRelocateImageWithBias函数地址放置在堆栈上，等挂钩Winload函数执行完毕后就

调用LdrRelocateImageWithBias接着执行原来的流程。

后续的挂钩执行都是如此，并未恢复原先代码。

图29

调用为：

图30

按系统分别挂钩：

图31

然后同样是搜索ImgpLoadPEImage对 LdrRelocateImageWithBias的调用，然后Patch对该函数调用，该部分代码同BootMgr一样。

挂钩后函数为:

图32

先将恢复对函数LdrRelocateImageWithBias的调用：

图33

而后将0x9aa9a函数放置在堆栈上等待被调用:

图34

LdrRelocateImageWithBias调用完成后HooNt函数被执行(0x9aa9a)：

图35

先恢复堆栈后续执行流程将winload!ImgpLoadPEImage+0x67d放置在返回地址处：

图36

通过反汇编引擎搜调用代码搜IoInitSystem对IopInitializeBootDrivers的调用。

图37

3 NT系统加载后

3.1 加载ShellCode部分

当系统执行到Nt中IoInitSystem对IopInitializeBootDrivers调用时候，恶意代码被执行。

先将函数IopInitializeBootDrivers放置堆栈上，然后关闭写保护恢复原始挂钩处代码，而后将后续加载木马代码函数地址（LoadTheShellCode）放置堆栈上。

图38

当函数IopInitializeBootDrivers调用完成后，再次将Nt正确函数返回地址放置堆栈上。

图39

而后将ShllCode1代码映射，大小为0xca0。

图40

校验代码并执行。

3.2 ShellCode1部分

该部分功能为读取磁盘指定位置代码并加载ShellCode2。

先获取相关函数地址，

后读取磁盘数据检测完整并获取大小，大小为0x4a000。

图41

然后为第二块ShellCode申请内存大小为0x4c08。

申请后执行：

图42

3.3 ShellCode2部分

该部分主要为解压之前读取的资源数据并查找加载其中/bin/i386/bootmgr NE文件并加载。

校验完整性，并解压数据:

图43

然后为第三块NE格式ShellCode申请空间大小为0x1f00，准备执行，并将资源作为参数传入。

图44

3.4 ShellCode3部分

主要为加载/bin/i386/kernel到内存并执行，Kenel部分为内核关键代码部分。

图45

拷贝NE文件资源，大小为0x10380：

图46

而后帮第四块ShellCode修正导入表重定位并执行。

图47

3.5 ShellCode4部分

该部分为内核关键代码，包含注入代码挂钩LoadImage反内核调试代码。

入口出先断开内核调试：

图48

而后读取磁盘数据并保存：

图49

创建设备跟应用层交互：

图50

而后重载内核获取一些导出符号，占满情况下，用于清理挂钩回调:

图51

设置LoadImage回调主要后续用于APC注入svchost跟explorer用来修改用户主页。

将真正函数地址LoadImageNotify作为参数传入。

图52

查找节后面空闲区域，将自身挂钩代码拷贝过去。

图53

拷贝代码：

图54

代码为：

图55

其中AAAAAAAA为占位后续将填入实际地址。

然后加载第五块ShellCode,并且挂钩：

图56

而该挂钩会反复被检测执行:

图57

挂钩函数为：

图58

LoadImage中判断svchost.exe进程创建:

图59

如果是svchost.exe进程创建：

图60

判断是否为指定的svchost.exe：

图61

主要通过命令行方式判断：

图62

匹配命令行后准备注入代码：

图63

将APC NormalRoutine设置为Ne入口点得到执行：

图64

Exploer注入代码：

图65

3.6 ShellCode5部分

该内核块功能主要为防止被检出查杀。

获取签名公司列表信息：

图66

代码：

图67

而后调用ShellCode4中设置LoadImage回调函数。

图68

在回调中判断驱动是否有PDB信息，分三种情况Patch

1如果没有PDB符号信息且匹配签名则直接Patch入口点。

图69

2如果有PDB信息，一些常见的工具，也Patch入口点，如gmer.pdb ,Win64AST.pdb。

图70

3如果Pdb有且hash比对一致则导入表Hook：

图71

还会IAT Hook文件操作函数，防止查杀类驱动读取文件恢复钩子。

ZwCreateFile:

图72

IofCallDriver:

图73

防止文件簇读取方式：

图74

获取文件保护列表函数：

图75

Patch函数：

图76

图77

4篡改主页部分

4.1 ShellCode1部分

APC注入Explorer.exe后，入口点修正导入表，创建线程并加载改首页模块。

图78

线程函数中申请执行空间，并将代码拷贝。

高端地址执行：

图79

然后修正导入表，重定位：

图80

执行入口点函数：

图81

4.2 ShellCode2部分

初始化系统模块名字，挂钩时候使用：

图82

初始化恢复钩子列表，发现这些函数一旦被挂钩就直接恢复。

图83

将原始代码备份，并保存到链表中，头部指令最多长度为0x20。

图84

然后打开首页页面地址：

图85

其中共享内存区数据为：

图86

然后枚举所有加载模块IAT挂钩CreateProcessW函数。

图87

挂钩回调函数为：

图88

主要挂钩Shell32.dll对CreateProcessW函数调用。而后检测之前的初始化的系统函数是否被Hook，进行恢复。

图89

CreateProcessW挂钩中判断创建进程是否为浏览器列表之一：

图90

浏览器列表为：

图91

而后创建verclsid.exe为傀儡进程，修改主页：

图92

而后创建傀儡进程：

图93

将代码映射到傀儡进程QueueUserAPC APC函数：

图94

4.3 ShellCode3部分

该部分代码为QueueUserAPC注入到verclsid.exe中执行。

入口点为从PEB LDR中获取信息，修正重定位修正导入表：

图95

然后Patch傀儡进程入口点。

图96

而后在调用CreateProcessW创建带有命令行的浏览器进程

图97

完成修改主页：

图98

svshost部分

主要为创建TimerQueue中回写LoadImage回调并回写MBR：

该部分代码难以有效检出。

创建：

图99

给驱动发送命令写入：

图100

5尾声

“隐魂”木马创下了两周内攻击量上百万次的记录，可谓迄今传播速度最快的MBR木马。其高超的反侦察能力及复杂的利用技巧让不少检测手段力不从心，如今其攻势虽然放缓但远不曾停止，被推广利益驱使的作者很有可能继续兴风作浪，通过远程控制的方式实施对个人数据及财物的大规模攻击。

文档信息

事件概要

事件简述

近日，非常流行的远程终端Xshell被发现被植入了后门代码，用户如果使用了特洛伊化的Xshell工具版本会导致本机相关的敏感信息被泄露到攻击者所控制的机器甚至被远程控制执行更多恶意操作。

Xshell特别是Build 1322在国内的使用面很大，敏感信息的泄露及可能的远程控制导致巨大的安全风险，我们强烈建议用户检查自己所使用的Xshell版本，如发现，建议采取必要的补救措施。

事件时间线

2017年8月7日

流行远程管理工具Xshell系列软件的厂商NetSarang发布了一个更新通告，声称在卡巴斯基的配合下发现并解决了一个在7月18日的发布版本的安全问题，提醒用户升级软件，其中没有提及任何技术细节和问题的实质，而且声称没有发现漏洞被利用。

2017年8月14日

360威胁情报中心分析了Xshell Build 1322版本（此版本在国内被大量分发使用），发现并确认其中的nssock2.dll组件存在后门代码，恶意代码会收集主机信息往DGA的域名发送并存在其他更多的恶意功能代码。360威胁情报中心发布了初始的分析报告，并对后续更复杂的恶意代码做进一步的挖掘分析，之后其他安全厂商也陆续确认了类似的发现。

2017年8月15日

卡巴斯基发布了相关的事件说明及技术分析，与360威胁情报中心的分析完全一致，事件可以比较明确地认为是基于源码层次的恶意代码植入。非正常的网络行为导致相关的恶意代码被卡巴斯基发现并报告软件厂商，在8月7日NetSarang发布报告时事实上已经出现了恶意代码在用户处启动执行的情况。同日NetSarang更新了8月7日的公告，加入了卡巴斯基的事件分析链接，标记删除了没有发现问题被利用的说法。

影响面和危害分析

目前已经确认使用了特洛伊化的Xshell的用户机器一旦启动程序，主机相关基本信息（主机名、域名、用户名）会被发送出去。同时，如果外部的C&C服务器处于活动状态，受影响系统则可能收到激活数据包启动下一阶段的恶意代码，这些恶意代码为插件式架构，可能执行攻击者指定任意恶意功能，包括但不仅限于远程持久化控制、窃取更多敏感信息。

根据360网络研究院的C&C域名相关的访问数量评估，国内受影响的用户或机器数量在十万级别，同时，数据显示一些知名的互联网公司有大量用户受到攻击，泄露主机相关的信息。

解决方案

检查目前所使用的Xshell版本是否为受影响版本，如果组织保存有网络访问日志或进行实时的DNS访问监控，检查所在网络是否存在对于附录节相关IOC域名的解析记录，如发现，则有内网机器在使用存在后门的Xshell版本。

目前厂商NetSarang已经在Xshell Build 1326及以后的版本中处理了这个问题，请升级到最新版本，修改相关系统的用户名口令。厂商修复过的版本如下：

Xmanager Enterprise Build 1236

Xmanager Build 1049

Xshell Build 1326

Xftp Build 1222

Xlpd Build 1224

软件下载地址：https://www.netsarang.com/download/software.html

技术分析

基本执行流程

Xshell相关的用于网络通信的组件nssock2.dll被发现存在后门类型的代码，DLL本身有厂商合法的数字签名，但已经被多家安全厂商标记为恶意：

360威胁情报中心发现其存在加载执行Shellcode的功能：

我们将这段代码命名为loader_code1, 其主要执行加载器的功能，会再解出一段新的代码（module_Activation），然后动态加载需要的windows API和重定位，跳转过去。

经过对进程执行的整体分析观察，对大致的执行流程还原如下图所示：

基本插件模块

Module_Activation

当注册表项”Data”的值不存在时，进入上传信息流程，该流程主要为收集和上传主机信息到每月一个的DGA域名，并保存服务器返回的配置信息，步骤如下：

获取当前系统时间，根据年份和月份按照下面的算法生成一个长度为10-16的字符串，然后将其与”.com”拼接成域名。

年份-月份 和 生成的域名对应关系如下：

当RegQueryValueExA查询到的Data键值存在数据时，则进入后门执行流程，该流程利用从之前写入注册表项的配置信息中的Key解密loader_code2后跳转执行。

解密loader_code2的算法如下：先取出module_Activation偏移0x3128处的original_key，接着取key的最后一个byte对偏移0x312C处长度为0xD410的加密数据逐字节进行异或解码，每次异或后original_key再与从配置信息中读取的key1、key2进行乘、加运算，如此循环。

解密之后跳转到loader_code2中, loader_code2其实和loader_code1是一样的功能，也就是一个loader，其再次从内存中解密出下一步代码：module_ROOT, 然后进行IAT的加载和重定位，破坏PE头，跳转到ROOT模块的入口代码处。

Module_ROOT

ROOT模块即真正的后门核心模块，为其他插件提供了基本框架和互相调用的API，其会在内存中解密出5个插件模块Plugin、Online、Config、Install和DNS，分别加载到内存中进行初始化，如果插件在初始化期间返回没有错误，则被添加到插件列表中。

每个插件由DLL变形而成，加载后根据fwReason执行不同功能 (其中有一些自定义的值100,101,102,103,104).不同的插件模块fwReason对应的功能可能有细微的差异，整体上如下：

接着ROOT模块搜索ID为103（“Install”）的插件，并调用其函数表的第二个函数。进行安装操作。

同时ROOT模块也通过把自身函数表地址提供给其他模块的方式为其他模块提供API，这些API主要涉及跨模块调用API、加解密等功能。

另外其中解密的函数以及加载插件的函数也是由动态解出来的一段shellcode，可见作者背后的煞费苦心：

Module_Plugin

Plugin模块为后门提供插件管理功能，包括插件的加载、卸载、添加、删除操作，管理功能完成后会通过调用Online的0x24项函数完成回调，向服务器返回操作结果。模块的辅助功能为其他插件提供注册表操作。

Plugin的函数列表如下：

其中比较重要的是fuc_switch和CreateLoadRegThread。

fuc_switch

此函数根据第二个参数结构体的0x4偏移指令码完成不同操作，指令码构造如下：

（ID<<0x10）| Code

0x650000功能

此功能获取当前加载的插件列表字符串，此功能遍历全局ModuleInfo结构体获取模块名称列表，完成后通过Online模块的0x24执行调用者参数的回调函数，该回调为网络通知函数。

0x650001功能

此功能首先通过参数ID获取模块信息，如果该ID未被加载，则调用Root的加密函数加密模块数据，随后更新对应注册表值，完成模块更新，模块数据加密后保存，在Root模块初始化过程中会调用Plugin的注册表监听线程，该线程检测到注册表项变动后加载此模块：

0x650002功能

此功能通过文件名称加载PE结构的插件，Root模块的0x30项调用LoadLibrary函数加载DLL，并将插件结构插入全局插件双链表：

0x650003功能

该功能通过模块基址查找指定模块，内存卸载模块后删除对应注册表键值，彻底卸载模块：

0x650004功能

此功能检测参数指定模块ID是否被加载，如果该ID已被加载，通过Online的网络回调发送一个长度为1，数据为0x00的负载网络包，如果ID未被加载则发送一个长度为0的负载网络包。

CreateLoadRegThread

该函数创建线程，异步遍历注册表项“SOFTWARE\Microsoft\<MachineID>”，其中MachineID根据硬盘序列号生成。随后创建Event对象，使用RegNotifyChangeKeyValue函数监测插件注册表键值是否被更改，被更改后则遍历键值回调中解密并加载模块并插入全局插件ModuleInfo。

Plugin模块的维护数据结构为双链表，并为每个插件定义引用计数，当引用计数为0时才从内存卸载插件。结构大致如下：

Module_Online

该模块主要功能是与服务器连接，获取服务器返回的控制指令，然后根据控制指令中的插件ID和附加数据来调用不同的插件完成相应的功能。同时Online也提供API接口给其他插件模块用于回传数据。

Online模块的函数表如下，可以看到其提供了一系列收发数据的API

网络连接开始时首先调用Config表中的第二个函数读取配置信息，通过InternetCrackUrlA将配置信息中的字符串(默认为dns://www.notepad.com)取得C&C地址，并根据字符串前面的协议类型采取不同的连接方式，每个协议对应一个ID，同时也是协议插件的ID，目前取得的样本中使用的DNS协议对应ID为203。（虽然有HTTP和HTTPS，但是ONLINE只会使用HTTP），协议与ID的对应关系如下：

在建立起与C&C服务器的连接之后，可以根据接收到的服务器指令调用指定的插件执行指定的操作，并返回执行结果。首先先接收0x14字节的头部数据，这些数据将用于解压和解密下一步接收的指令数据。

接受的指令结构大致如下：

Online模块会根据PluginID找到对应的模块，调用其函数列表的第一个函数func_switch()，根据OpCode执行switch中不同的操作，并返回信息给服务器。

另外当Online使用内置的URL方式时，会根据指定的参数使用HTTP-GET\HTTPS-GET\ FTP来下载文件：

在请求服务器的时候，也会将受害者的基本信息上传到服务器中，这些信息包括：当前日期和时间、内存状态、CPU信息、可用磁盘空间、系统区域设置、当前进程的PID、操作系统版本、host信息和用户名。

Online模块还通过调用Plugin模块提供的API维护一个注册表项：

Module_Config

Config模块在初始化的过程中，先分别解出数据段保存的一些默认配置信息，然后把这些参数拼接起来，使用Root模块虚表中的DoEncipher函数进行加密，最后保存到一个用硬盘卷标号计算出来的路径里。同时Config模块提供了读取配置文件的接口。

Config模块的虚表共有3个函数

ModInit

该函数共有三个子功能

660000

该功能主要调用Config模块的GetDecodedConfigData函数，获取配置文件作为Payload，最终调用Online模块虚表的0x24功能（上传给CC服务器）

660001

功能主要就是传递了自己的功能ID，没有Payload

660002

功能主要就是传递了下自己的功能ID，没有Payload

GetDecodedConfigData

该函数首先通过磁盘卷标号计算得到当前机器的配置文件路径。然后读取配置文件，并调用Root模块的DoDecipher解密后，返回结果给调用者。

GetEncodedVolumeSN

该函数首先获取系统盘的磁盘卷标号，根据压入的szKey计算出一个结果，然后调用Root模块的Base64Encode1Byte来加密得到加密串。

默认配置信息主要为以下信息

接着写入配置文件，分别通过磁盘卷标号，以及不同的key，得出四组不同的加密串

然后和依次系统路径”%ALLUSERSPROFILE%\\”拼接得到最终配置文件的路径（例如C:\ProgramData\YICIO\PMIEYKOS\IYM\XIEUWSOY），最后将加密后的配置文件直接写入到该路径下。

Module_Install

Install模块主要用于检测进程环境、控制进程退出和进入后门流程。Install模块被ROOT模块调用其函数表的第二个函数开始执行，首先调整进程权限，然后调用Config模块函数表的第二个函数读取配置信息。

接着通过判断ROOT模块从上层获取的参数进行不同的流程：

当参数为5\6时，尝试加载ID为106（这个模块不在默认内置的模块列表中，需要进一步下载）。

如果都不是以上情况，则尝试以系统权限启动winlogon.exe或者启动scvhost.exe，然后注入自身代码，然后启动Online模块。

同时Install模块还会提供检测当前运行环境的接口：是否在调试、是否被进程监控、流量监控等，下面是一些特征字符串和相关代码：

Module_DNS

该模块的主要功能是使用DNS协议处理CC通信过程。模块的函数表如下，对

应的函数功能分别为：

模块的工作流程为：

在模块入口函数100编号对应的初始化过程中，模块会开启线程，等待其他插件数据到来，当收到数据时，调用dispatch将数据通过DNS发送到CC服务器。

其他插件调用该插件的第二个函数(也就是ThreadRecv函数)时，模块开启线程从CC接收数据，并将解码后的数据写到共享内存。

其他插件调用该插件的第三个函数(也就是RecvDataProc函数)可以取得该模块与CC服务器通信后的数据内容

其他插件调用该插件的第四个函数(也就是SendDataProc 函数)可以使用该模块向CC服务器发送数据内容。

在初始化函数中，创建一个线程，在线程内部通过互斥量等待，当互斥量被触发后，调用该模块的dispatch函数。

从CC接收数据的代码过程

在通信过程中，开启线程接收数据

线程函数将接收到数据存储在结构体的0x60偏移处

接收到的数据首先判断接收到的数据长度是否符合要求，然后使用解码函数(DecodeCCData1)进行解码并判断解码后的内容格式是否符合。此后，使用同样的解码算法(DecodeCCData1)再对数据进行一次解码。

将上面解码后的内容使用另一个解码算法(DecodeCCData2)进行解码，解出来的内容的第一个DWORD为解密KEY，使用解密KEY将接收到的数据进行解密后，判断解密后的内容的第一个WORD为数据包类型id，数据包类型ID包括:0，1，3三种。每种不同的数据包使用不同的结构类型和不同的解密算法。

在对不同的数据类型的处理过程中，都会将解码后的内容写入到结构体偏移+0x5C的地址中，该地址就是数据传输时使用的共享内存地址。

数据包的解密算法代码片段为：

向CC发送数据的代码片段

代码分析对抗

样本使用到的技术很多，例如动态加载、花指令、反调试、多层解密、代码注入等，使用的这些技巧大大增加了安全人员分析工作所需要花费的时间，也能有效躲避杀软检测，并使一些分析工具产生异常而无法正常执行恶意代码流程。下面举例说明一下使用到的技巧：

代码中加入了大量的JMP类型花指令，还有一些无效的计算，比如下图中红框中ECX。

在每次获取API地址之后，都会检测API代码第一字节是否等于0xcc，如果等于则结束后续行为，否则继续。

Shellcode通过自身的配置信息，通过一个for循环，循环4次。每次根据EDI定位配置信息，通过下面的结构体来获取要拷贝的数据的大小，将所有需要的数据拷贝到申请的内存中。然后解密数据。

循环拷贝数据

关联分析及溯源

8月的域名为 nylalobghyhirgh.com，360威胁情报中心显示此域名为隐私保护状态：

此域名目前在7月23日被注册，8月3日达到解析量的顶峰，360网络研究院的数据显示解析量巨大，达到800万。

所有的请求类型为NS记录，也就是说域名极有可能被用来析出数据而不是用于C&C控制，这与前面的分析结论一致。

而notped.com作为已知的相关恶意域名，我们发现其注册人为Yacboski Curtis，据此关联点找到了一些其他的关联域名，具体见附件的IOC节，由于这些域名并没有找到对应的连接样本，目前只是怀疑，不能确定就是其他的相关恶意域名。

参考链接

https://www.netsarang.com/news/security_exploit_in_july_18_2017_build.html

https://securelist.com/shadowpad-in-corporate-networks/81432/

https://cdn.securelist.com/files/2017/08/ShadowPad_technical_description_PDF.pdf

附件

IOC列表

Xshell后门代码通过DNS子域名的方式向C&C服务器输出收集到的主机信息，以下是分析得到的编码算法及实现的对应解码程序。

编码算法是先经过下图的算法1加密成二进制的形式如图：

算法1加密后的数据：

然后把结果转换成可见的字符转换方法是通过每个字节的高位减‘j’低位减‘a’，把1个字节拆分成2个字节的可见字符，这样就浪费了一个字节：

解密算法是加密算法的逆运算，解密算法流程入下图：

根据网上的一些公开的流量数据，

解密出的一些上传的数据：

实现的解码代码如下：

ShellCode的处理

本次后门多次解出ShellCode的过程都是用的同一套模版代码。经过分析发现PE的一些基本信息还是保留了的，ShellCode解码用到的结构整理如下：

下面介绍下ShellCode的加载过程，在调用Loader之前先将ShellCode起始地址以及大小入栈。

然后进入Loader部分处理流程：

1）从PEB里找到Kernel模块，从中找到LoadLibrary，GetProcAddress，VirtualAlloc以及Sleep，以备后续过程使用。

2）接着利用ShellCode中的SizeOfImage去分配内存。

3）往分配的内存头部填充垃圾数据，一直填充到代码段开始。

4）根据结构里保存的节表信息，依次填充到分配的内存。

5）如果结构里重定位信息不为空，则使用dwShellKey去解密重定位数据并利用重定位数据去修正内存的数据。处理完之后把重定位数据清零。

解密重定位数据的算法还原如下

6）如果输入表信息不为空，接着使用重定位处理用的dwShellKey去解密输入表对应的字符串信息，如果是ordinal方式的则不做处理。使用解密了的DLL名以及API名获取到API地址后，并不直接填充，而是先把地址做求补操作后，生成一个小的stub再填进去。

最后再把输入表用到的数据清零。

解密输入表的流程还原如下：

7）跳到入口处执行，并设置fdwReason为1。

根据保留的结构可以大致还原出本来模块文件。

概述

近日，NetSarang旗下的Xmanager、Xshell、Xftp和Xlpd等在全球流行使用的服务器远程管理软件曝出被多家杀毒软件报毒查杀的情况，经过360科技集团追日团队调查分析确认，NetSarang旗下多款软件的关键模块被植入了高级后门，这是一起入侵感染供应链软件的大规模攻击事件，我们将其命名为“XshellGhost”（xshell幽灵）。

事件时间轴

2017年7月17日，NetSarang公司发布旗下多款产品的新版软件，更新修复多处bug和增强了会话加密能力，用于对抗CIA木马“BothanSpy”的密码劫持功能。

2017年8月7日，NetSarang与卡巴斯基发布联合声明，声称7月18日发现软件存在安全漏洞被攻击。

2017年8月15日，NetSarang与卡巴斯基更新联合声明，发现在香港利用该软件漏洞的案例。

攻击形式

NetSarang系列软件的关键网络通信组件nssock2.dll被植入了恶意代码，厂商在发布软件时并未发现恶意代码，并给感染组件打上了合法的数字签名随新版软件包一起发布，用户机器一旦启动软件，将会加载组件中的恶意代码，将主机的用户信息通过特定DGA(域名生成算法)产生的DNS域名传送至黑客的远程命令控制服务器，同时黑客的服务器会动态下发任意的恶意代码至用户机器执行。

攻击影响面

使用被感染的软件的用户，将会被黑客窃取用户信息，并在云端下发任意的恶意代码进行远程控制，由于该系列软件在国内的程序员和运维开发人员中被广泛使用，多用于管理企事业单位的重要服务器资产，所以黑客极有可能进一步窃取用户所管理的服务器身份验证信息，秘密入侵用户相关的服务器，请相关软件用户和企事业单位提高警惕。

XshellGhost技术分析

“XshellGhost”（xshell幽灵）是一个精密的定向攻击平台，所有的功能模块实现均为shellcode形式，客户端攻击通过感染供应链软件和各个shellcode模块，实现了无自启动项、无落地文件和多种通信协议的远程控制，后门潜伏于受害者电脑等待黑客在云控制平台下发shellcode数据执行，黑客在云端甚至可能通过上传的用户信息进行选择性的定向攻击。

远程控制逻辑分析

XshellGhost的远程控制主要分为5个步骤：

1.软件启动加载被感染组件nssock2.dll，解密shellcode1执行。

2.Shellcode1解密Shellcode2执行如下功能：

a)创建注册表项，上报数据到每月对应的DGA域名当中；

b)通过发往知名的域名解析器当中上传用户信息给攻击者；

c)将接收的数据写入到创建的注册表项当中；

d)通过获取的key1和key2解密Shellcode 3并执行；

3. Shellcode3会创建日志文件并写入信息,启动系统进程Svchost.exe，修改其oep处的代码，并注入shellcode形式的Root模块执行。

4. Root模块的初始化过程中，会加载并初始化Plugins、Config、Install、Online和DNS等功能模块，然后调用函数Install->InstallByCfg以获取配置信息，监控注册表并创建全局互斥体，调用Online-> InitNet；

5. 函数Online-> InitNet会根据其配置初始化网络相关资源，向指定服务地址发送信息，并等待云端动态下发代码进行下一步攻击。

初始加载模块分析

此次攻击的所有模块调度加载实现方式都是通过shellcode形式，采用了模块化的方法进行统一管理。每个Shellcode的入口函数都会根据传入的第2个参数的数值决定将其具体要执行的功能，参数数值和对应的功能列表如下所示：

根据Shellcode编号102、103和104所对应的功能，可以获取每个Shellcode的信息列表：

关键的网络通信模块，除DNS协议通信，此后门还会利用其他5种网络协议进行远程控制。

基础管理模块分析

Root模块是该次攻击的基础管理模块，其它各个模块的功能的展开和运行都依赖于Root模块提供的函数接口列表：

Root模块的初始化逻辑如下图所示：

插件功能模块分析

Plugins模块为其他插件提供接口，包括读写注册表指定字段的加密数据，加载DLL等，以及监控注册表指定字段变化并将其数据解密作为插件加载：

在调用Install模块的InstallByCfg函数时，会调用Plugins模块的MonitorRegLoadShellCode函数。该函数负责监控注册表指定key，如果key值被改变，该函数将会读取注册表中的数据并调用Root模块的LoadAndInsertShellcodeEx函数将其加载。

如果网络控制端下发调用Plugins模块的OpByCmd函数的指令，将会设置其注册表指定key的数据，过后MonitorRegLoadShellCode函数将会监控到key值发生改变，读取注册表数据动态加载下发的Shellcode代码。

C&C配置模块分析

配置模块Config主要负责管理当前机器当中的配置文件以及对应机器的ID：

该模块包含了一个大小最大为0x858的配置数据块，其中配置数据块是从文件中读取的，文件位置是由该模块的第三个函数RandomStr提供

随机串生成的过程跟系统的卷序列号相关，所以在不同的机器上其位置并不相同。但是其有固定的格式，RandomStr均为大写字母：

%ALLUSERSPROFILE%\RandomStr\ RandomStr\ RandomStr\ RandomStr

配置信息是加密存储在配置文件中的，通过调用该模块的接口函数，可以获取解密后的配置文件，配置数据块的结构如下：

配置块的头部是一个OffsetTable，其中记录了各项配置串相对于EncryptStringStub的偏移，

目前已知的配置位置：

原始串的前2个字节为本串加密的Key，之后通过解密函数解密获取解密后的串，所以解密后的串长度要比原始串的长度少2。经分析还原的解密函数如下：

通过对程序自身的配置文件进行分析：

注入程序路径，加密前的字符：

解密后：%windir%\system32\svchost.exe

CC远程命令控制服务器的 URL，加密前的串：

解密后：dns://www.notped.com

DNS查询地址：

8.8.8.8

8.8.4.4

4.2.2.1

4.2.2.2

代码注入模块分析

主体代码注入模块Install，负责将Root模块代码注入到指定的进程当中，以及调用Online模块的相关初始化工作：

函数InstallByCfg的逻辑如下所示：

功能A：

1、调用Plugins的MonitorRegLoadShellCode函数，创建并监控指定注册表键,读取注册表数据加载shellcode执行；

2、调用Config的RandomStr函数获取字符串，用来创建全局互斥体

a)如果全局互斥体已存且Root的Op数值为3，结束自身进程。

b)调用 Online的 InitNet，初始化网络模块

功能B：

1、调用Plugins的MonitorRegLoadShellCode函数，打开并监控指定注册表键, 读取注册表数据加载shellcode执行；

2、查询Shellcode 106，如果不存在，则休眠1秒继续查询

3、调用Shellcode 106的第2个接口函数

功能C：

1、调用Config的函数GetCfgCon获取配置文件中保存的Pe路径

2、启动Pe，修改Oep处的代码，注入Shellcode Root

a)如果失败，则创建线程调用功能A

b)如果成功，则结束自身

网络通信模块分析

Online模块是本次攻击的网络通信管理模块，在本次攻击事件当中我们已经发现了DNS模块，其它几个网络模块（TCP、HTTP、UDP、HTTPS、SSL）虽然在代码当中有所体现，但是在shellcode当中尚未主动运行，各个网络模块的函数接口及其作用如下表所示：

各个网络模块的功能的展开和运行依赖于Online模块提供的函数接口列表：

InitNet在读取网络代理配置以后每隔1秒调用功能A，如果功能A返回20000，则函数彻底结束，功能A逻辑：

功能B逻辑，用于等待云端下发代码执行：

此次攻击已知使用的通信模块是DNS模块，该后门基于DNS隧道技术进行通信：

该模块发送的数据包有3种类型：

1.初始化数据包，大小为0x18

2.Data数据包，大小0x8+

3.关闭数据包， 大小0x8

其发送函数如下：

在调用DNS模块2号函数返回自定义对象时，其调用了GetAdaptersAddresses获取适配器的DNS

最多收集0x10个DNS，随后在调用该模块第3号函数时，其使用收集到的DNS，合并Config文件中的4个DNS地址，循环往每一个DNS发送查询，等到到任何一个返回数据，或者超时，并记录下第一个返回应答的DNS数据包，以后再次发送的时候，只会给第一个返回应答的DNS发送数据。

在发送数据包时，会将数据嵌套到DNS协议中发送，其中数据会编码成特定的字符串，添加在要配置文件中的CC DNS URL前，实现DNS隧道通讯。

总结

通过技术分析，我们发现“XshellGhost”（xshell幽灵）是一整套复杂的模块化的精密木马病毒，这是一起黑客入侵供应链软件商后进行的有组织有预谋的大规模定向攻击，我们仍将会持续关注此次攻击的进一步发展，建议广大用户使用360安全卫士查杀“XshellGhost”（xshell幽灵）木马病毒和防御供应链软件攻击。

360追日团队（Helios Team）

360 追日团队（Helios Team）是360科技集团下属的高级威胁研究团队，从事APT攻击发现与追踪、互联网安全事件应急响应、黑客产业链挖掘和研究等工作。团队成立于2014年12月，通过整合360公司海量安全大数据，实现了威胁情报快速关联溯源，独家首次发现并追踪了三十余个APT组织及黑客团伙，大大拓宽了国内关于黑客产业的研究视野，填补了国内APT研究的空白，并为大量企业和政府机构提供安全威胁评估及解决方案输出。

已公开APT相关研究成果

联系方式

邮箱：360zhuiri@360.cn

微信公众号：360追日团队

扫描上面二维码关注微信公众号

译者：WisFree

预估稿费：180RMB

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

在浏览器与跨站脚本漏洞（XSS）的抗争过程中，内容安全策略（即Content Security Policy，简称CSP）的出现绝对是具有里程碑式意义的。由于内容安全策略的存在，我们能依靠的不仅仅只是浏览器的反XSS过滤器了，我们现在将有可能通过浏览器来对类似javascript这样的外部资源进行额外的限制（可以通过CSP HTTP头来强制实现）。但是在CSP配置自动生成机制嵌入到Web框架之前，这种技术还很难成为一种实践标准。就目前的情况来看，绝大多数情况下仍然需要开发人员手动配置Web应用程序的内容安全策略。

在这篇文章中，我们将跟大家讨论关于如何将内容安全策略整合到现有网站中的一些基本策略。除此之外，我们还会介绍CSP Auditor的最新功能以及相关的理论知识。如果你对内容安全策略或者CSP Auditor不够了解的话，我建议大家先阅读我们之前所发表的这篇【文章】。

CSP Auditor

该插件提供了以下几种功能：

1.在Response标签下提供了可视化的CSP Header；

2.采用了被动扫描规则来检测存在安全漏洞的CSP配置；

3.基于Burp crawler或手动浏览实现了一个CSP配置生成器；

注：该项目以ZAP和Burp插件的形式进行封装。

工具下载

最新版本：2017年8月3日更新

Burp插件：【点我下载】

ZAP插件：【点我下载】

CSP Auditor：【GitHub项目主页】

你可以使用以下命令构建CSP Auditor插件：

如果你已经安装了Gradle，那你可以选择使用下列命令:

如何配置出高效的内容安全策略

如果你想配置出有效的内容安全策略，你可以先考虑以下三种最基本的因素：

1.针对外部资源采用白名单机制，这里的外部资源可以是CSS样式、图片或JavaScript代码；

2.识别内联脚本标签；

3.替换内联脚本事件；

针对外部资源采用白名单机制

这一步可以算是实现起来最简单的一步了，这一步需要对Web应用程序所使用的JavaScript、图片以及CSS样式表进行分析和识别。只有托管在外部域名的文件以及资源才需要被添加到内容安全策略的配置之中。

上面给出的这些资源将会被转译成下面这种CSP HTTP头，内容如下所示：

在CSP Auditor中，我们可以通过两种方法来列出所有的外部资源。在"External Resources"（外部资源）标签下，我们可以看到所有已选择域名所加载的全部资源。外部资源视图如下：

在"Configuration"（配置）标签下，你可以对所有托管了外部资源的域名进行配置，并设置一份CSP配置草案。注:列表内容会根据目标网站的分析结果进行自动填充。配置视图如下：

为了让内容安全策略尽可能地覆盖你网站所加载的全部资源，你需要使用网络爬虫（例如Burp crawler）或其他手动的爬取方法来尽可能多地爬取你的网站页面。一般来说，开发人员通常都会在Web应用程序的主页（Home page）中导入绝大多数的资源，即便是这个页面不需要使用的资源也有可能会加载进去，因为这样做可以尽早地对资源进行缓存，而且还可以简化之后的页面开发。这样一来，我们大多数情况下只用访问几个页面就能收集到网站加载的绝大多数资源了。

识别内联脚本标签

刚才介绍的第一步操作应该还是比较容易完成的。但是相对来说，控制内联脚本还是比较困难的。在我们的分析场景中，需要对HTML页面做以下修改：

正如上面这段代码所示，内容安全策略的默认模式下是不允许内联脚本的，而这样做的目的是为了防止攻击者通过XSS攻击向量在Web应用程序中嵌入恶意脚本代码。目前主要有两种方式来防止内联脚本，第一种方法是将脚本代码移动到一个单独的JavaScript文件中，而不是像之前一样直接把脚本代码嵌入在HTML页面之中。

另一种方法是在脚本块中添加一个随机数（nonce）。这种方法需要生成一个随机令牌并存放在header中，然后在每一个脚本块中添加一个nonce属性并填充随机数值。

除了上述这些内联脚本之外，还有一个我们目前还没介绍的变种版本的内联脚本：DOM on-events handlers（一种HTML属性）。跟内联脚本标签一样，我们需要找出每一个相关属性并完成修改替换。下面给出的是一个简单示例：

原始的HTML：

修改后的HTML：

JavaScript (/site-event-bundle.js)

替换内联脚本事件

由于内联脚本在Web应用程序中几乎是随处可见的，因此这些内联脚本的数量对我们来说会是一个很大的麻烦。为了确认我们需要修改的内联脚本数量，我们可以在"Inline Scripts"视图中查看到工具对Web流量的分析结果。下面给出的是内联脚本视图:

总结

在这篇文章中，我们给大家介绍了三种部署内容安全策略的方案。但不幸的是，针对传统网站目前还没有一种通用的缓解方案。因此，我们希望CSP Auditor插件的这些新功能可以帮助广大开发人员更好地将新型的安全Header整合到自己的Web应用程序中以提升安全性。

如果目标网站中不存在跨站脚本漏洞，或者说其中的跨站脚本漏洞不足以影响网站安全性的话，添加额外的CSP Header可能并不会产生非常好的效果。你可以通过查看"External Resources"以及"Inline Scripts"视图下的内容来评估部署内容安全策略的工作量。

最后来一波预告：我们目前仍然在优化CSP Auditor，希望对该项目感兴趣的用户可以帮助我们一起提升CSP Auditor。最终的解决方案将适用于所有的WordPress站点。

参考资料

1.CSP配置命令表：https://content-security-policy.com/

2.内联脚本缓解样例：http://www.cspplayground.com/compliant_examples

3.使用Burp和ZAP审计CSP Header：https://gosecure.net/2016/06/28/auditing-csp-headers-with-burp-and-zap/

4.CSP Auditor项目地址：https://github.com/GoSecure/csp-auditor

概述

近日，NetSarang旗下的Xmanager、Xshell、Xftp和Xlpd等在全球流行使用的服务器远程管理软件曝出被多家杀毒软件报毒查杀的情况，经过360科技集团追日团队调查分析确认，NetSarang旗下多款软件的关键模块被植入了高级后门，这是一起入侵感染供应链软件的大规模攻击事件，我们将其命名为“XshellGhost”（xshell幽灵）。

事件时间轴

2017年7月17日，NetSarang公司发布旗下多款产品的新版软件，更新修复多处bug和增强了会话加密能力，用于对抗CIA木马“BothanSpy”的密码劫持功能。

2017年8月7日，NetSarang与卡巴斯基发布联合声明，声称7月18日发现软件存在安全漏洞被攻击。

2017年8月15日，NetSarang与卡巴斯基更新联合声明，发现在香港利用该软件漏洞的案例。

攻击形式

NetSarang系列软件的关键网络通信组件nssock2.dll被植入了恶意代码，厂商在发布软件时并未发现恶意代码，并给感染组件打上了合法的数字签名随新版软件包一起发布，用户机器一旦启动软件，将会加载组件中的恶意代码，将主机的用户信息通过特定DGA(域名生成算法)产生的DNS域名传送至黑客的远程命令控制服务器，同时黑客的服务器会动态下发任意的恶意代码至用户机器执行。

攻击影响面

使用被感染的软件的用户，将会被黑客窃取用户信息，并在云端下发任意的恶意代码进行远程控制，由于该系列软件在国内的程序员和运维开发人员中被广泛使用，多用于管理企事业单位的重要服务器资产，所以黑客极有可能进一步窃取用户所管理的服务器身份验证信息，秘密入侵用户相关的服务器，请相关软件用户和企事业单位提高警惕。

XshellGhost技术分析

“XshellGhost”（xshell幽灵）是一个精密的定向攻击平台，所有的功能模块实现均为shellcode形式，客户端攻击通过感染供应链软件和各个shellcode模块，实现了无自启动项、无落地文件和多种通信协议的远程控制，后门潜伏于受害者电脑等待黑客在云控制平台下发shellcode数据执行，黑客在云端甚至可能通过上传的用户信息进行选择性的定向攻击。

远程控制逻辑分析

XshellGhost的远程控制主要分为5个步骤：

1.软件启动加载被感染组件nssock2.dll，解密shellcode1执行。

2.Shellcode1解密Shellcode2执行如下功能：

a)创建注册表项，上报数据到每月对应的DGA域名当中；

b)通过发往知名的域名解析器当中上传用户信息给攻击者；

c)将接收的数据写入到创建的注册表项当中；

d)通过获取的key1和key2解密Shellcode 3并执行；

3. Shellcode3会创建日志文件并写入信息,启动系统进程Svchost.exe，修改其oep处的代码，并注入shellcode形式的Root模块执行。

4. Root模块的初始化过程中，会加载并初始化Plugins、Config、Install、Online和DNS等功能模块，然后调用函数Install->InstallByCfg以获取配置信息，监控注册表并创建全局互斥体，调用Online-> InitNet；

5. 函数Online-> InitNet会根据其配置初始化网络相关资源，向指定服务地址发送信息，并等待云端动态下发代码进行下一步攻击。

初始加载模块分析

此次攻击的所有模块调度加载实现方式都是通过shellcode形式，采用了模块化的方法进行统一管理。每个Shellcode的入口函数都会根据传入的第2个参数的数值决定将其具体要执行的功能，参数数值和对应的功能列表如下所示：

根据Shellcode编号102、103和104所对应的功能，可以获取每个Shellcode的信息列表：

关键的网络通信模块，除DNS协议通信，此后门还会利用其他5种网络协议进行远程控制。

基础管理模块分析

Root模块是该次攻击的基础管理模块，其它各个模块的功能的展开和运行都依赖于Root模块提供的函数接口列表：

Root模块的初始化逻辑如下图所示：

插件功能模块分析

Plugins模块为其他插件提供接口，包括读写注册表指定字段的加密数据，加载DLL等，以及监控注册表指定字段变化并将其数据解密作为插件加载：

在调用Install模块的InstallByCfg函数时，会调用Plugins模块的MonitorRegLoadShellCode函数。该函数负责监控注册表指定key，如果key值被改变，该函数将会读取注册表中的数据并调用Root模块的LoadAndInsertShellcodeEx函数将其加载。

如果网络控制端下发调用Plugins模块的OpByCmd函数的指令，将会设置其注册表指定key的数据，过后MonitorRegLoadShellCode函数将会监控到key值发生改变，读取注册表数据动态加载下发的Shellcode代码。

C&C配置模块分析

配置模块Config主要负责管理当前机器当中的配置文件以及对应机器的ID：

该模块包含了一个大小最大为0x858的配置数据块，其中配置数据块是从文件中读取的，文件位置是由该模块的第三个函数RandomStr提供

随机串生成的过程跟系统的卷序列号相关，所以在不同的机器上其位置并不相同。但是其有固定的格式，RandomStr均为大写字母：

%ALLUSERSPROFILE%\RandomStr\ RandomStr\ RandomStr\ RandomStr

配置信息是加密存储在配置文件中的，通过调用该模块的接口函数，可以获取解密后的配置文件，配置数据块的结构如下：

配置块的头部是一个OffsetTable，其中记录了各项配置串相对于EncryptStringStub的偏移，

目前已知的配置位置：

原始串的前2个字节为本串加密的Key，之后通过解密函数解密获取解密后的串，所以解密后的串长度要比原始串的长度少2。经分析还原的解密函数如下：

通过对程序自身的配置文件进行分析：

注入程序路径，加密前的字符：

解密后：%windir%\system32\svchost.exe

CC远程命令控制服务器的 URL，加密前的串：

解密后：dns://www.notped.com

DNS查询地址：

8.8.8.8

8.8.4.4

4.2.2.1

4.2.2.2

代码注入模块分析

主体代码注入模块Install，负责将Root模块代码注入到指定的进程当中，以及调用Online模块的相关初始化工作：

函数InstallByCfg的逻辑如下所示：

功能A：

1、调用Plugins的MonitorRegLoadShellCode函数，创建并监控指定注册表键,读取注册表数据加载shellcode执行；

2、调用Config的RandomStr函数获取字符串，用来创建全局互斥体

a)如果全局互斥体已存且Root的Op数值为3，结束自身进程。

b)调用 Online的 InitNet，初始化网络模块

功能B：

1、调用Plugins的MonitorRegLoadShellCode函数，打开并监控指定注册表键, 读取注册表数据加载shellcode执行；

2、查询Shellcode 106，如果不存在，则休眠1秒继续查询

3、调用Shellcode 106的第2个接口函数

功能C：

1、调用Config的函数GetCfgCon获取配置文件中保存的Pe路径

2、启动Pe，修改Oep处的代码，注入Shellcode Root

a)如果失败，则创建线程调用功能A

b)如果成功，则结束自身

网络通信模块分析

Online模块是本次攻击的网络通信管理模块，在本次攻击事件当中我们已经发现了DNS模块，其它几个网络模块（TCP、HTTP、UDP、HTTPS、SSL）虽然在代码当中有所体现，但是在shellcode当中尚未主动运行，各个网络模块的函数接口及其作用如下表所示：

各个网络模块的功能的展开和运行依赖于Online模块提供的函数接口列表：

InitNet在读取网络代理配置以后每隔1秒调用功能A，如果功能A返回20000，则函数彻底结束，功能A逻辑：

功能B逻辑，用于等待云端下发代码执行：

此次攻击已知使用的通信模块是DNS模块，该后门基于DNS隧道技术进行通信：

该模块发送的数据包有3种类型：

1.初始化数据包，大小为0x18

2.Data数据包，大小0x8+

3.关闭数据包， 大小0x8

其发送函数如下：

在调用DNS模块2号函数返回自定义对象时，其调用了GetAdaptersAddresses获取适配器的DNS

最多收集0x10个DNS，随后在调用该模块第3号函数时，其使用收集到的DNS，合并Config文件中的4个DNS地址，循环往每一个DNS发送查询，等到到任何一个返回数据，或者超时，并记录下第一个返回应答的DNS数据包，以后再次发送的时候，只会给第一个返回应答的DNS发送数据。

在发送数据包时，会将数据嵌套到DNS协议中发送，其中数据会编码成特定的字符串，添加在要配置文件中的CC DNS URL前，实现DNS隧道通讯。

总结

通过技术分析，我们发现“XshellGhost”（xshell幽灵）是一整套复杂的模块化的精密木马病毒，这是一起黑客入侵供应链软件商后进行的有组织有预谋的大规模定向攻击，我们仍将会持续关注此次攻击的进一步发展，建议广大用户使用360安全卫士查杀“XshellGhost”（xshell幽灵）木马病毒和防御供应链软件攻击。

360追日团队（Helios Team）

360 追日团队（Helios Team）是360科技集团下属的高级威胁研究团队，从事APT攻击发现与追踪、互联网安全事件应急响应、黑客产业链挖掘和研究等工作。团队成立于2014年12月，通过整合360公司海量安全大数据，实现了威胁情报快速关联溯源，独家首次发现并追踪了三十余个APT组织及黑客团伙，大大拓宽了国内关于黑客产业的研究视野，填补了国内APT研究的空白，并为大量企业和政府机构提供安全威胁评估及解决方案输出。

已公开APT相关研究成果

联系方式

邮箱：360zhuiri@360.cn

微信公众号：360追日团队

扫描上面二维码关注微信公众号

译者：紫曦归来

预估稿费：260RMB

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

我对集成DIY智能家居非常感兴趣，也曾经通过黑进部分家用电器的内部系统，来进行家庭自动化的DIY改造。几个月前，我父亲购买了多个瑞克斯（RAEX）品牌433兆赫射频的电动百叶窗，以取代家里的手动窗帘。

图1：瑞克斯牌433兆赫射频电动百叶窗

注：购买的百叶窗在Spotlight上以“Motion Motorized Roller Blind”的名义销售

百叶窗给这个家带来了非同凡响的感受，尤其是对于比较懒惰的我来说，不用手动开关窗帘，这一点大为省事。但是，遥控百叶窗需要购买瑞克斯品牌遥控器。瑞克斯公司生产了不同型号的遥控器，我挑选了以下两款遥控器：

R型遥控器 （YRL2016）

X型遥控器（YR3144）

每一个房间里都放一个遥控器的做法不可行，因为遥控器的部分功能用不上，购买过多的遥控器就显得非常浪费了。事实上，不同房间的百叶窗可以被编程到同一个遥控器上使用。因此，购买多个遥控器就没有必要了。

解决这一问题就是使用名为“ RM Pro”的App。这款App，可允许用户通过智能手机来操控家电等设备。

但是，在我看来，这个App运行起来非常缓慢，完全不适合家庭自动化系统。我希望家里的百叶窗可以通过苹果智能家居系统（Apple Homekit）进行操控。

如果想要遥控到这些百叶窗，我需要做以下两件事中的任意一件：

1、逆向出RM Pro的应用程序（App）与RM Pro之间是如何实现通信的。

2、逆向出遥控器操控百叶窗的RF协议。

首先，我尝试了第一种选项，但是我无法弄清楚iPhone和集线器之间是如何进行通信的，所以我选择了放弃。此后，我开始逆向RF协议。

我在Ebay网站上购进了一套433兆赫兹Arduino开源电子原型平台的发射器和接收器。以防发射器和接收器之间链接断掉，大家也可以尝试在Ebay上购买一套433兆赫兹Arduino开源电子原型平台的发射器和接收器的链接工具。

初步研究结果

我在Google上反复搜索RAEX正在使用的协议的技术指标，但没有任何结果：

我通过FCC认证查询网站和专利查询网站找不到协议的任何技术指标。

我向RM Pro发送电子邮件想要获取其技术指标，但依旧毫无所获。

我向瑞克斯公司发送电子邮件想要获取其技术指标，他们表示不会在没有保密协议的情况下给我提供产品技术指标。

我发现RFXTRX可以在百叶窗处于T4模式和Outlook Motion模式下操控百叶窗。

我拆开了一个百叶窗遥控器，发现遥控器内部还装有微控制器（micro-controller）。但我找不到关于通用RF协议如何进行编码的相关说明文档。

我发现似乎可以通过I2C工程远程固件上的ROM芯片逆向出遥控器的固件。

获取信号数据

在收到网购的Arduino开源电子原型平台的发射器和接收器后，我将接收器与Arduino开源电子原型平台相连接，并开始尝试进行信号数据搜索。我反复进行了多次尝试，最后我找到了一条可以获取数据的路径。

获取了足够的信号数据信息后，我开始进行数据分析。我发现这些数据颇难理解，我甚至不能确定这些数据的准确性。

我进行了延伸学习，阅读了如何进行RF 逆向的相关书籍和文档。这些书本里介绍了一种方法，就是将接收器插入电脑的麦克风端口来捕捉信号，之后通过Audacity音频软件进行分析。（如下图所示）我想，何不尝试一下呢？

这一办法帮助我搜集了许多的信号数据。我搜集到了4个不同的R型遥控器和2个不同的X型遥控器的信号数据。意外的是，我还搜集到了与Broadlink RM Pro（B型）配对的8种不同设备的信号数据。

通过分析这些信号数据，我可以得出以下结论：

1、 设备之间传输的信号没有使用滚动码（rolling code）。因此，我可以通过重播捕获的信号，使百叶窗进行重复动作。

2、 设备之间传输的信号要重复至少3遍（根据所使用的遥控器类型不同而有所区别）。

缩小信号的波形，我们可以看到捕获到的信号的不同部分。下图展示了遥控器与百叶窗配对状态下1号遥控器，在1频道时的信号波形：

放大信号波形：

在缩放图像中，不难看出信号首先以振荡0101 AGC模式（oscillating 0101 AGC pattern）进行传输，此后以双宽度前导码模式传输，再之后以较长的header模式传输，此后转为data模式。

R型遥控器的传输信号中，Header和data模式要重复三边，AGC模式仅在开头出现过一次。

纯粹研究这些信号并不会有太大的帮助。我需要将这些信号数字化，并对其进行分析，找出不同遥控器和频道之间信号传输模式的差异。

解码信号波形

我们需要确定信号波形是如何编码的。这一类硬件应用通常会使用下列方法之一：

曼彻斯特编码（又称相位编码）

三态/三位编码，附加信息

PWM编码

原始数据？high long = 11，high short = 1，low long = 00，low short = 0？

通过一些研究，我能够确定其最有可能使用的是曼彻斯特编码。这一点需要我们谨记！

信号数字化

我开始按照上述原始方案处理信号（即使我认为其采用了曼彻斯特编码）。这样做的理由是，如果编码方式并不是曼彻斯特编码，我还可以尝试通过另一种方案解码。（另外，手抄原始信号的方式总比我通过思考进行曼彻斯特解码更容易）。

我将每次捕获的信号写入Google Sheets电子表格。写下每个频道的每次动作大概需要5分钟时间，每个遥控器都有6个频道。我开始认为这将需要一段时间才能真正得到足够的数据进行分析。（考虑到我需要对160条捕获信号进行数字化）

在从2个遥控器中收集8个不同频道的所有动作后，我选择了暂停。我获得了32条捕获信号用于分析。从这些数据中，我能够推断出一些关于原始bits的特点：

不同频道会有一些bits改变。

不同遥控器会有一些bits改变。

对于不同频道/遥控器/动作组合，有些bits似乎会随机变化。

我仍然需要更多的数据，但这也使得我必须手动解码大量捕获信号。为了能够在任意地点实现操作，我还需要一个脚本来帮助处理这些通过Audacity软件捕获的WAV文件。我编写了一个脚本，使其可以通过原始编码方式检测标头和提取数据（就是我一直手动在做的）。该脚本生成了JSON格式的输出文件，我可以添加额外的元数据，并反复检查捕获信号的波形：

一旦确认，我就会对这些数据进行列表，并将其插入我的电子表格进行进一步处理。不幸的是，每次捕获信号的 bits量已经大到让我失去理智：

我认为如果以曼彻斯特编码方式进行解码可能会有更好的效果。为此，我又写了一个脚本，将原始捕获数据按照曼彻斯特编码进行处理（或其他编码类型）。在将这些数据计入电子表格时，我逐渐得到了更加合理的答案。

观察这些数据，我们立即可以得到这些bits和其用途之间所存在的一些联系：

6bits用于频道（C）

2bits用于动作（A）

6bits用于某些校验和，似乎是动作和频道的一个函数。 F(A, C)

行动改变时发生变化

频道改变时发生变化

没有频道是相同的，因此不能确定是否会因遥控器不同而发生变化。

1bit似乎是动作的一个函数 F(A)

1bit似乎是F(A)的一个函数，于是，G(F(A))。它取决于F(A)的值，有时是1对1映射，有时是反映射。

经过进一步调查，我确定对于同一个遥控器和频道来说，每个不同的动作，会使F(A, C)增加1.（如果你将这些bits看作大端格式）。

再仔细观察这些数据，我同时能够确定，对于相邻的频道，bits与C（Channel）存在递加/递减算法关联（X型遥控器递加计算，R型遥控器递减计算）。另外，F(C)还会一起增加/减少。注意C栏。

由此，我可以确认F(A, C)和C之间的关系，即F(A, C) = F(PAIR, C0) == F(PAIR, C1) ± 1。在有了这个发现之后，我确定F(A, C)和A之间也存在其他的数学联系。

制作更多数据

根据我们所收集的现有信息，我们似乎可以通过改变6 bits频道数据，以及按照我们上面发现的数学联系改写校验和，制作新的遥控器。这意味着我们可以从单一源频道生成64个频道。而这已足够控制房间里的所有百叶窗了。但我还是想完全解码校验和字段，从而无限量地制作遥控器。

我编写了一个工具来通过元捕获数据输出所有频道：

我想要生成更多数据的原因是，如果我们可以在同一个频道上查看不同的遥控器，也许我们可以确定校验和的构成方式。即R0CH0，R1CH0，X1CH0，等...

实际上，我想做的是解出下列方程式的函数G：

然而，在查看所有频道0的PAIR捕获数据后，校验和似乎仍然是以完全混乱和随机的形式表达：

在看这些数据的同时，我又发现了另一种模式。G(F(A))的位置相比F(A)出现了整个字节的偏移（8 bits）。另外，前2 bits的F(A, C)位于字节边界，并与A（Action）对齐。随着行动增加，F(A, C)也是如此。我们再将所有处于字节边界的bits进行排列，看看其有什么特征：

在这里，我们需要确定基于前4个字节产生的已知校验和的函数。最初，我尝试通过字节进行异或（XOR）运算：

但结果并不成功，输出结果是随机形式的数据，使用校验和与输出结构异或运算后，并没有产生常数键。因此，我推断出校验和不是通过异或运算生成的。那会不会是采用的加法呢？我们从上面已经能看到加法/减法的运算关系。

我们的推测看起来越来越有希望——相同类型遥控器的频道之间存在一个常数差异。因为我制作的项目存在漏洞，会不会不同类型遥控器的常数也存在不同？在频道或校验和变化时，我们是否没有打包正确的位数，或使用错误的字节边界？

事实证明，这就是原因所在。

分析校验和

查看原始捕获数据，并执行相同的模加法，我们确定校验和是通过添加前导的4个字节和加3来计算的。我无法确定为什么在这里使用3，除了瑞克斯公司（购买百叶窗的品牌）想要使其校验和的解码过程变得更多困难，或者为了确保正确的传输模式。

我改装了我的遥控器应用来处理这些刚刚识别的边界：

这样的一组数据可以解释我们的问题。事实证明， F(A)不是A（Action）的一个函数，它实际上是被传输的动作数据（action data）的一部分：

另外，频道和遥控器之间的拆分或许是没有必要的。相反，这可能只是一个任意的24位整数，但是更容易的是将其拆分为8位int和16位int。基于此，我可以推断，协议可以容纳2 ^ 24个遥控器（约1670万）！这将是很多的百叶窗！

最终，我在这里正式写出了校验和的函数：

附加工具

我的“衍生遥控器”（remote-gen）项目是为了通过原有遥控器生成代码，但现在需要一些其他功能。

我需要一种从捕获数据中提取信息的方法，并验证在生成校验和期间，其校验和是否与我们的规则集一致。我写了一个info命令：

运行—validate后，如果猜测的校验和！=校验和，则将显示错误并退出。在我们的所有捕获数据中运行这一进程，可以证明我们的校验和函数是正确的。

该工具所需的另一个功能是能够生成任意代码来创建我们自己的遥控器：

好了到这里，我已经可以使用这个工具来生成任何我所需要的遥控器了。

结语

这就是我如何逆向出一个完全模式的协议的整个过程。我未来还将和大家分享更多智能家居DIY的文章。

热点概要：内网主机发现技巧、使用SpiderFoot与SHODAN识别目标操作系统及开放端口、Pentest Cheat Sheets、Kronos恶意软件分析、混淆的Locky勒索软件下载者分析、Xshellghost后门事件分析、CVE-2017-6327: 赛门铁克 <= 10.6.3-2远程代码执行漏洞、NSA无人机袭击目标致数百平民丧生、FBI 警告私营部门停止使用卡巴斯基

国内热词(以下内容部分摘自http://www.solidot.org/)：

FBI 警告私营部门停止使用卡巴斯基

Chrome 将会对 HTTP Web 表单显示不安全警告

NSA无人机袭击目标致数百平民丧生

http://thehackernews.com/2017/08/nsa-spying-australia.html

暗网新闻：

Valhalla Market 也被查,初期已有200+用户信息被芬兰海关获取到,目测已经被采取强制措施

https://www.deepdotweb.com/2017/08/18/valhalla-market-seized-finnish-customs-allegedly-identified-hundreds-valhalla-users/

使用SpiderFoot与SHODAN识别目标操作系统及开放端口

https://asciinema.org/a/127601

逆向工程家庭安全系统：解码固件更新

https://markclayton.github.io/reverse-engineering-my-home-security-system-decompiling-firmware-updates.html

Kronos恶意软件分析（part 1 ）

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

Bug Bounty：如何使用Shodan和Golang扫描多个组织

https://medium.com/@woj_ciech/scan-multiple-organizations-with-shodan-and-golang-bug-bounty-example-d994ba6a9587

udp2raw tunnel:通过raw socket给UDP包加上TCP或ICMP header，进而绕过UDP屏蔽或QoS，或在UDP不稳定的环境下提升稳定性。可以有效防止在使用kcptun或者finalspeed的情况下udp端口被运营商限速。

https://github.com/wangyu-/udp2raw-tunnel

Pentest Cheat Sheets

https://github.com/coreb1t/awesome-pentest-cheat-sheets

混淆的Locky勒索软件下载者分析

http://www.ringzerolabs.com/2017/08/analyzing-several-layers-of-obfuscation.html

信息收集：内网主机发现技巧

https://mp.weixin.qq.com/s?__biz=MzI5MDQ2NjExOQ==&mid=2247484689&idx=1&sn=67433d76467ed12fcd86981a1b2e32c2&chksm=ec1e3539db69bc2f2f7f9095b2bde41e21096179fcd3cabf20f149b2814c442fc42d78ef5e1e&scene=21#wechat_redirect

https://mp.weixin.qq.com/s/l-Avt72ajCIo5GdMEwVx7A

Xshellghost后门事件分析

360追日团队：http://bobao.360.cn/learning/detail/4280.html

360天眼实验室：http://bobao.360.cn/learning/detail/4278.html

通过加密Payload实现杀软绕过（C#实现）

https://www.linkedin.com/pulse/bypass-all-anti-viruses-encrypted-payloads-c-damon-mohammadbagher?trk=v-feed

使用VENOM工具加密payload绕过杀软

https://www.linkedin.com/pulse/bypass-anti-virus-detection-encrypted-payloads-using-venom-james-ceh?trk=v-feed

cansina：基于python的目录扫描器

https://github.com/deibit/cansina/

dockerscan：docker安全分析工具

https://github.com/cr0hn/dockerscan

沙盒攻击面分析工具v1.0.9

https://github.com/google/sandbox-attacksurface-analysis-tools/releases/tag/v1.0.9

CVE-2017-6327: 赛门铁克 <= 10.6.3-2远程代码执行漏洞

http://seclists.org/fulldisclosure/2017/Aug/28

Scanning Effectively Through a SOCKS Pivot with Nmap and Proxychains

https://cybersyndicates.com/2015/12/nmap-and-proxychains-scanning-through-a-socks-piviot/

如何一步一步解码复杂恶意软件

https://blog.sucuri.net/2017/08/malware-decoding-step-step-guide.html?utm_source=Twitter&utm_medium=Social&utm_campaign=Blog&utm_term=EN&utm_content=Malware-Decoding-Step-by-Step

Secrets and LIE-abilities: The State of Modern Secret Management (2017)

https://medium.com/on-docker/secrets-and-lie-abilities-the-state-of-modern-secret-management-2017-c82ec9136a3d

Chainspace: A Sharded Smart Contracts Platform

https://www.benthamsgaze.org/2017/08/18/chainspace-a-sharded-smart-contracts-platform/

RETGUARD, the OpenBSD next level in exploit mitigation, is about to debut

http://undeadly.org/cgi?action=article&sid=20170819230157

CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management

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

译者：興趣使然的小胃

预估稿费：200RMB

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

一、前言

最近一段时间，我发表了关于Flash沙箱逃逸漏洞的一篇文章，最终导致已存活十多年的Flash Player本地安全沙箱寿终正寝。

之前的这个漏洞向我们展示了对输入数据进行正确性验证的重要性。攻击者只需要向运行时的Flash输入混合的UNC以及文件URI，就足以提取本地数据，并可以将Windows用户凭证发往远程SMB服务器。

Flash Player在23版本中移除了本地文件系统（local-with-filesystem）沙箱，从本地角度来看，这样处理有效解决了这两个问题。然而非常有趣的是，官方的发行注记中忽略了剩下的两个沙箱：本地网络（local-with-networking）沙箱以及远程（remote）沙箱。因此我想了解这两个沙箱的问题是否得到了修复。

实际上，根据最初的测试结果，Flash会拒绝任何UNC或者文件形式的路径。这两个沙箱似乎都不会接受任何非HTTP形式的URL。因此，这就带来一个非常有趣的问题：如果我们能以另一种方法来绕过这个限制呢？我们能否在通过输入验证后，修改输入表达式的含义呢？

简而言之，Adobe Flash可能会受到某个已知Windows漏洞的影响。虽然我们可以通过运行时的安全解决方案来削弱该漏洞所能造成的影响，但这些安全方案原本是用于不同的目的，因此还是可以被针对性地绕过。因此，我们可以绕过Flash Player新引入的输入验证机制，让攻击者恢复获取Windows用户凭证的能力。

本文分析了我最近向Adobe报告的一个安全漏洞，Adobe对该漏洞的编号为APSB17-23，对应的CVE编号为CVE-2017-3085。

二、HTTP重定向问题

再次重申一下，之前那个漏洞利用的关键点是将我们的恶意Flash应用连接到我们的SMB服务器上。在不对客户端进行身份认证的前提下，通过拒绝客户端的访问请求，服务器可以使得Windows客户端向其发送用户的凭证信息。

Adobe似乎非常了解这种攻击方法。之前版本的Flash会从所有SMB服务器上加载资源，但在23版中，Flash会拒绝掉任何UNC以及文件形式的路径，这两种路径是SMB主机的表示方法。现在许多路径会被Flash拒绝掉，如\\10.0.0.1\some\file.txt路径，以及等效的file://///10.0.0.1/some/file.txt路径。

然而，我们可以根据微软提供的URI列表，构造各种富有创造力的URL，但依然无法获得任何突破。在这两个沙箱中，不论哪个沙箱的URLLoader似乎都不会接受没有使用HTTP或者HTTPS作为前缀的那些路径。看上去Adobe似乎使用白名单机制来加固他们的产品。

这种情况下，如果我们可以在通过输入验证后，修改请求路径，那么会发生什么事情呢？根据前面的分析，我们必须使用HTTP形式的地址，因此我们需要利用HTTP重定向功能来访问SMB主机。

幸运的是，SMB以及HTTP还是可以组合在一起的。首先映入我脑海的就是一个Windows漏洞，名为重定向到SMB（Redirect-to-SMB）漏洞。通过设置HTTP头部中的Location信息，以及提供一个适当的响应代码（比如301或者302代码），攻击者就可以利用这个漏洞将HTTP请求重定向到一个恶意的SMB服务器。攻击场景如下图所示：

三、漏洞复现

在我们的攻击场景中，恶意Flash应用以及SMB服务器都托管于一台主机上，主机IP地址为23.100.122.2。这个Flash应用会运行在受害者本地主机的远程（remote）沙箱中。也就是说，Flash运行时会阻止访问本地文件系统，但允许远程连接。

跟踪Win32 API后，我们发现受Redirect-to-SMB漏洞影响的函数位于urlmon.dll中。因此，Internet Explorer以及任何使用IE浏览器的第三方应用都会受到该漏洞影响。

这个漏洞吸引了许多媒体的关注，很多厂商发布了修复补丁来修复他们的产品。那么，Adobe Flash的表现如何呢？我们可以尝试重定向某个出站请求GET /somefile.txt，结果如下所示：

#2032错误代码是Flash用来表示流错误（Stream Error）的代码。根据之前的研究成果，我们知道除了#2048代码以外，其他代码都可以用来表示成功状态。我们来看看实际出现了什么情况：

额，看起来Flash Player并没有受到任何影响：我们返回的HTTP/1.1 302响应没有触发SMB流量。然而，我们注意到，抓取的报文中出现一个GET报文请求crossdomain.xml。这个文件是跨域策略的配置文件，当Flash客户端被允许从另一个域中加载资源时就会涉及到这个文件。比如，如果没有经过domain-b.com的明确许可，那么托管在domain-a.com上的Flash应用就不会加载domain-b.com上的图片。

细心的读者可能会注意到Adobe的有关定义，与HTTP CORS（读者可以阅读RFC6454了解更多细节）不同的是，Adobe会将自身限制在跨域（cross-domain）数据处理上。更具体地说，Adobe不会去考虑不同协议的区分问题。因此，我们的攻击被阻止应该与这种安全机制无关：因为我们正在尝试重定向到SMB，这是同一主机上的不同协议。

有趣的是，根据Wireshark的记录，我们发现应用正在请求某台主机上的crossdomain.xml，而这台主机正是运行Flash应用的同一台主机。因此，我们可以来构造一个最为宽松的跨域策略。根据Adobe开发者指南中的语法，我们构造的策略如下：

最后，我们重新加载我们的Flash应用，观察执行情况：

成功了！我们最终建立了从受害主机（23.100.122.3）到我们的远程服务器（23.100.122.2）的SMB连接。此时此刻，我们只需要重复我们之前做的工作就可以了。我们可以使用一个名为SMBTrap的脚本来承担我们恶意SMB服务器的角色，用来捕捉传入的任何请求，其中也包括受害者的用户凭证信息：

四、受影响的环境

有趣的是，与上一个漏洞相比，Edge以及Chrome浏览器并不会受到这个漏洞影响（这些浏览器都启用了Flash功能）。尽管这两个浏览器都存在类似的行为，比如跨域策略文件的请求行为，但两者貌似都会阻止Flash连接到SMB主机。

也就是说，Firefox以及Internet Explorer会受到漏洞影响。同时这也会影响到当前Microsoft Office的所有版本。此外，这个漏洞同时会影响远程（remote）以及本地网络（local-with-networking）沙箱。

五、总结

在引入新的输入验证机制后，Flash Player 23就已经通过拒绝任何非HTTP URL形式的出站请求，来尽可能地降低潜在的攻击方法的成功率。然而，非常意外的是，Adobe只做了一次输入验证过程：即只检查初始的HTTP请求是否有效，没有检查后续的重定向请求是否有效。同时因为Flash仍然会受到某个已知的Windows漏洞的影响，因此结合这个事实，我们就能绕过看起来坚不可摧的防御机制。这是非常不幸的一件事情，也许通过这件事情，我们会意识到在必要的时候还是应该考虑特定平台漏洞所会造成的潜在危害。

Flash Player 26.0.0.151修复了这个问题，我们可以通过Windows Update或者Adobe的官网下载新的版本。

六、附录

6.1 受影响的主机环境

Firefox

Internet Explorer

Microsoft Office 2010、2013以及2016

6.2 受影响的平台

Flash Player 23.0.0.162到26.0.0.137

Windows XP、Vista、7、8.x以及10

6.3 时间线

11-02-2017：向趋势科技零日倡议项目报告漏洞。

21-04-2017：ZDI承认该漏洞，并分配编号ZDI-17-634。

05-06-2017：请求状态更新。Adobe回复他们会于2017年7月发布Flash Player 26，修复这个漏洞。

12-07-2017：请求状态更新。Adobe回复他们仍在做修复工作，新版与预期于2017年8月份发布。

08-08-2017：Adobe在Flash Player 26.0.0.151中修复了这个漏洞。

08-08-2017：漏洞信息公布。

6.4 参考资料

Adobe Security Bulletin APSB17-23

CVE-2017-3085

ZDI-17-634

Threatpost - Patched Flash Player Sandbox Escape Leaked Windows Credentials

Security.NL - Radboud-student ontdekt opnieuw lek in Adobe Flash Player

ComputerBild - Adobe Patchday: Updates gegen über 80 Sicherheitslücken

WCCFTech - Adobe Addresses Several Vulnerabilities in Flash Player, Acrobat Reader

SecurityWeek - Adobe Patches 69 Flaws in Flash, Reader, Acrobat

Blorge - Adobe Flash Player and Acrobat Reader Security Updates

SecurityTracker - Adobe Flash Player Bugs Let Remote Users Obtain Potentially Sensitive Information and Execute Arbitrary Code

译者：興趣使然的小胃

预估稿费：150RMB

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

一、前言

在本文中，我们会分析一个带有VBA功能的恶意Word文档。文档的作者对文件中的VBA代码采取了密码保护措施，以避免研究人员检查恶意代码。同时，恶意代码开发者针对密码移除技术也做了相应的防护。自动化分析工具无法处理这一样本，但我们依然可以绕过这些反分析障碍，具体细节如下文所述。

大家可以先观看演示视频从直观上了解分析过程。

二、样本细节

打开恶意文档后，首先出现在我们眼前的是一则钓鱼信息，声称该文档使用早期版本的Microsoft Office创建，为了查看文档，用户需要启用宏功能。

启用宏后，样本开始往cfai66.fr地址发送信息。

为了了解具体是什么代码负责往法国地址发送信息，我们必须在“开发者”选项卡中查看文档的宏代码。然而，恶意代码作者对VBA代码做了加密处理，不想让我们检查代码。这种情况下，我们难以从Microsoft Office内部来精确分析VBA脚本。

为了继续分析，我们可以尝试使用常见的十六进制编辑技术去掉Office文件中的密码。首先，我们在文档中搜索“DPB”字符串，将其改为“DPx”。某些版本的Office会把这个信息当成损坏的密码哈希。然而，这种方法对这个文档不起作用，我们仍然会看到密码提示框。

接下来，我们自己创建了一个密码保护的启用VBA功能的文档，然后继续尝试将样本文档中的“CMG”、“DPB”以及“GC”的值替换成我们自己文档中对应的值。不幸的是，恶意文档作者有意对“CMG”的值做了处理，使其超过了这个字段的长度值。因此，尝试替换样本的CMG值再次失败。此外，我们也尝试了在CMG引号内部及外部填充数据以保留文件的长度，但依然以失败告终（如下左图是我们构造的新文档，右图是恶意样本）。

由于我们删除密码的尝试均告失败，接下来我们使用了OfficeMalScanner这个常用的Office产品分析工具来分析这个样本。利用这个工具的扫描（scan）/暴破（brute）功能，但没有得到任何结果。

使用info选项再次运行这个工具，我们得到3个VBA对象：

我们使用了ViperMonkey这个工具来动态分析这些VBA对象。ViperMonkey是个VBA仿真引擎，使用python语言编写，用于Microsoft Office文档（如Word、Excel、PowerPoint、Publisher等）中的恶意VBA宏的分析及去混淆。

然而，ViperMonkey无法完整分析这些VBA，原因有两点：

1）无法识别UBound这个VBA函数。

2）无法分析“i = UserForm1.T.Top”这条语句的变量赋值操作，因为该工具无法定位UserForm1.T.Top的值。

看样子我们需要手动分析Module1这个VBA脚本。首先，我们将这个脚本加载到一个新的Word文档中，以便使用内置的VBA调试器对其进行调试。在调试脚本中，我们很快就发现了导致ViperMonkey失效的那段代码。

代码之所以无法运行，是因为Form1无法通过OfficeMalScanner工具导出。只有Form1的元数据被导出，导致Form1.T.Top的值无法找到。这种方法非常好，可以干扰自动化VBA分析工具的处理过程，因为密码保护表单的变量无法被获取到（这也是我所关心的变量）。我们不得不手动跟踪代码，逆向分析使用这个变量的函数，来尝试识别变量所对应的值。

跟踪i=Form1.T.Top的变量赋值过程，我们发现代码最终将i分配给变量T，我们继续跟踪到代码的56行。

fr变量等于T-11，在第60行，Wet变量等于1-fr。

第62行表明，如果Wet=0，那么rd就等于变量rd的字符表现形式。

如果我们按照相反的逻辑处理顺序来分析这几条语句，我们可以得到以下结论：

为了使rd成为一个Char字符，Wet必须等于0：

如果我们将UserForm1.T.Top的值替换为12，然后调试脚本，我们可以看到可读文本会逐渐填充到onearm变量中。我们成功逆向出了VBA的代码逻辑，提取出变量中所保存的批处理文件，如下所示：

这个脚本会从cfai66.fr网站上（我们无法确定这个网站是不是被黑客攻陷的一个无辜网站）下载一个恶意的PNG文件（实际上这是个EXE文件），然后在受害者主机上执行这个文件。这个文件是个通用的木马程序，不属于某个特定的攻击组织。

三、总结

这个样本是个非常有趣的包含VBA代码的Word文档，使用了密码保护机制以规避被分析的风险。经过若干次删除密码尝试，使用OfficeMalScanner以及ViperMonkey自动化工具对其分析后，我们最终选择了手动方式来逆向分析VBA函数，以寻找导致脚本调试过程失败的那个变量值，最终成功还原了恶意脚本。

四、附录：样本信息

文件名：efax543254456_2156.doc

保护机制：密码保护的VBA程序

MD5值：30B9491821923A1ECB5D221A028208F2

样本地址：点击此处下载样本

样本类型：微软Word VBA下载器

释放的文件：i.bat，npzdi.exe

网络流量：cfai66.fr/parabola.png， cfa-noisylegrand.com/parapola.png

在线分析结果：查看此链接了解更多信息

译者：blueSky

预估稿费：120RMB

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

2016年底，黑客使用“曼巴”勒索软件对旧金山市政交通局进行了一次大规模的网络攻击，该勒索软件调用一个合法的应用程序DiskCryptor对磁盘进行加密，最终成功对旧金山市政交通局的电脑磁盘进行了加密操作。这个月，我们注意到这个勒索软件背后的团体又开始对该公司发起新一轮的网络攻击。

攻击者来自哪里？

我们的调查显示，对旧金山市政交通局进行网络攻击的团体主要来自以下两个国家：

1. 巴西

2. 沙特阿拉伯

攻击方式是什么？

与其他的网络攻击一样，在该起网络攻击事件中，网络攻击者首先获得对目标公司网络的访问权限，之后攻击者使用psexec这个工具来勒索。此外，我们从这起网络攻击事件中发现一些重要的信息，那就是对受害公司里的每一台电脑，攻击者都会使用“DiskCryptor”这个软件生成一个密码，并且将该密码通过命令行参数的方式传递到勒索软件的服务器端。

攻击技术分析

这起网络攻击事件其实并不复杂，简单来说，整个网络攻击事件可以分为两个阶段：

1. 阶段1（准备阶段）：

下面是阶段1中所涉及到的网络攻击步骤：

a. 第一步首先在目标机器上创建“C\xampp\http”这个文件夹；

b. 第二步将DiskCryptor程序放入步骤1创建的文件夹中；

c. 第三步就是在目标机器上安装DiskCryptor驱动程序；

d. 第四步是在目标机器中注册DefragmentService这个系统服务；

e. 最后一步是重新启动受害者机器。

2. 阶段2（加密阶段）：

阶段2所涉及到操作主要有：

a. 第一步首先是将引导程序安装到MBR中并使用DiskCryptor软件对磁盘分区进行加密操作；

b. 第二步是清理攻击者在目标机器上的操作痕迹；

c. 最后一步就是重新启动受害者机器。

阶段1（准备阶段）

在第一阶段中，网络攻击者首先将DiskCryptor程序安装到计算机上，因为这个工具在第二阶段会用到，用它来对受害者的磁盘进行加密操作。技术上，恶意软件的创建者使用了常用的隐藏恶意程序的方法，那就是将DiskCryptor程序作为木马程序资源信息的一部分，将其存储在木马软件的的资源数据中。

DiskCryptor程序分为32位和64位两种版本，恶意软件会首先探测受害机器的操作系统的信息，之后根据目标操作系统的信息，再对32位或者64位的DiskCryptor进行选择，并将最终选择的DiskCryptor释放到之前创建的“C\xampp\http”这个文件夹中。

之后，恶意软件将启动释放到“C\xampp\http”这个文件夹中的DiskCryptor安装程序。

当DiskCryptor安装完成后，恶意软件将在目标机器注册DefragmentService系统服务，创建这个系统服务需要SERVICE_ALL_ACCESS和SERVICE_AUTO_START两个参数。

以上的步骤完成之后，第一阶段的最后一步就是重新重启目标机器，这步操作如下图所示：

第二阶段（加密阶段）

在第2阶段，网络攻击者会使用DiskCryptor，在MBR中设置了一个新的引导加载程序。

有意思的是，在这个引导程序中包含了受害者需要缴纳的赎金信息。

引导加载程序设置好之后，网络攻击者将使用之前通过命令行方式生成的密码加密磁盘分区。

磁盘分区加密结束之后，受害者机器将重新启动。此时，勒索软件将运行，并在受害者的屏幕上显示受害者需要缴纳赎金才能解密信息。

卡巴斯基实验室检测到了这款勒索木马软件，并将其命名为：Trojan.Win32.Generic。

能否解密？

到目前为止，仍然没有任何办法去解密使用DiskCryptor勒索软件加密的数据，因为这个合法的程序在实现中使用了强大的加密算法。

IOCs：

79ED93DF3BEC7CD95CE60E6EE35F46A1

前述

2016年8月份，360白名单分析组披露了数字签名冒用的案例，然而并未引起相关数字证书颁发机构的重视。2017年，360白名单分析组监控到大量带有“李鬼”签名的私服和木马在传播。通过伪造知名公司的资料，可以成功在境外证书颁发机构申请相应公司数字证书。这些证书被用来签发恶意程序，而恶意程序由于带有知名公司的“签名”，容易被安全软件放行，严重危害了网络安全。同时，这种冒用行为，使多家知名公司躺枪，对被冒用的公司的名誉带来了恶劣影响。

以下为2017年新增签名冒用事件的时间轴。

时间轴上方三家公司的冒用签名主要被大量传播中的劫持类私服使用，其签发过的样本种类主要如下：

时间轴下方的冒用签名则频繁用于签发其他恶意程序，目前发现5家不同的数字签名，其签发过的样本种类主要如下：

由于360在第一时间发现并查杀带有冒用签名的样本，其他恶意程序虽然换签名更频繁，但由于及时查杀并未大规模流通。而私服类程序虽然受到360的拦截，但依靠不知情用户的主动使用和信任得以在互联网上泛滥 。带冒用签名的私服类程序劫持流量，而且屏蔽安全软件的防护功能及正常网站访问，对网络秩序和用户个人电脑安全危害极大。

冒用方式

签名冒用的利用方式在之前的披露文章早已分析，这里简单再说明一下。下图是官方正常数字签名与冒用数字签名的样本对比，两者都显示数字签名正常且签名主体均为“上海**软件有限公司”。左图是该公司官方的程序签名，颁发者为国内知名的签名机构“WoSign”。而右图则是冒用的数字签名，其是冒用签名的作者伪造该公司资料在国外签发机构“Go Daddy”申请的数字证书。

目前为止，发现的冒用签名主要都是通过“Go Daddy”和“Startfield”两家国外签发机构申请的，今年新增的8种冒用签名如下所示，其中每种签名对应若干张数字证书，且部分证书目前已被颁发者直接吊销：

样本分析

（一）流程框架

当玩家电脑上的私服程序运行时会释放并启动一个劫持程序的母体splog.exe，该母体负责检测环境并下载安装劫持模块msvcs.dll。母体程序开始运行时会检测ip地址，控制在特定地区不进行传播，如：

一旦开始进行传播，将从某个服务器地址直接下载劫持模块msvcs.dll，并以命令行参数“/install”启动进行安装，由于后面将安装成服务程序，所以安装前检测了特定服务名“ExtendApp”，若服务已存在则删除该服务来准备进行重装：

msvcs.dll模块以 “/install”参数首次进行安装时将自身创建为服务程序，之后并没有立即启动服务程序，而是将服务的启动类型设置为开机自启动，劫持流程将在下次重启开机时自动运行：

一旦服务例程开始运行，将首先循环进行联网判断，保证在网络畅通环境下进行后续的感染：

从前文的流程图看，本模块主要进行两条劫持流程，首先进行的是流程图的上半部分，母体是dnetsup.dll，最终通过安装文件过滤驱动进行劫持：

紧接着进行流程图的下半部分，母体是drvsup.dll，最终通过安装tdi过滤驱动进行劫持：

下面分别对劫持的两条流程线进行分析。

（二）文件过滤流程劫持DNS

首先是文件过滤流程，过程基于dotnet（.Net）的运行环境，所以dnetsup.dll先判断并安装dotnet环境：

确保运行环境具备执行dotnet程序的条件时，再进一步判断dotnet环境的执行版本：

判断版本的目的是为了搭配合适的版本模块，然后通过注册通用类库的方式来得到程序运行机会：

一旦注册成功，之后每次用户启动浏览器，浏览器进程都会被“注入”该劫持模块（donetset2/4），从而执行其中的程序代码，通过我们的行为监控工具查看，可以看到IE浏览器的进程树下多出了两个子进程，这两个子进程其实是注入其中的劫持模块donetset2.dll创建的（见下文）：

Donetset2.dll是一个C#编写的.Net程序，更具体地说其实是一个.Net的COM类库组件，如下可以看出该组件将自身注册成一个shell图标覆盖类库，所以每次浏览器运行都能顺其自然地被引入执行：

当该组件的工作例程开始运行时，就进行文件过滤驱动的安装或启动，并下载一份hosts列表保存到dida.mid这个文件来进行本地DNS劫持，上文看到浏览器的进程树即是下载完劫持列表文件后调用cmd的ipconfig命令进行DNS缓存刷新：

下载的列表格式与系统hosts文件一致，主要用于劫持安全软件和竞争对手的DNS请求：

当然，劫持的关键还在于文件过滤驱动，本模块安装的驱动程序是从资源里释放的，并且根据int类型指针的大小来判断使用x86还是x64的文件过滤驱动：

另外，文件过滤驱动的安装和启动操作都是通过导入从本模块释放出来的dHelperKit.dll导出函数，该模块相对应地分为x86版本和x64版本，负责和文件过滤驱动的通信操作：

先看一下驱动程序，发现具有一个国外公司EldoS的数字签名，并且是由VeriSign机构签发的非冒用签名，可以确认是官方的程序：

从版本信息上可以看出该文件是出自EldoS公司的一款名为“CallbackFiler“的产品，版本号为3.1.85，该产品实际上是专门为开发人员提供文件系统过滤功能的程序库：

既然是第三方驱动程序库，那么与其通信的操作模块dHelperKit.dll就显得尤其重要，负责控制完成劫持的功能。该模块的导出函数“kitStartCbfltfs”通过“CallbackFiler“提供的API来操作文件过滤驱动cbfltfs3.sys，借助其对文件系统的的过滤功能来劫持DNS。具体实现的方式是添加一个文件名（路径）重解析的回调函数，设置请求的目标文件名（路径）为本地hosts文件的路径，在系统进程访问到该文件路径时重定向到一个新的控制路径（dida.mid文件的路径）：

回调函数中，会进一步过滤请求访问hosts文件的进程，只有当请求进程为svchost时才进行文件名（路径）重定向操作，因为包括DNS查询的本地网络服务其所属进程为svchost，判断该进程一方面已经足够达到通过hosts文件重定向劫持DNS的目的，另一方面也可以让用户正常访问hosts文件，难以发现hosts文件被重定向：

设置完重定向回调后，过滤驱动也正常工作，待重新下载dida.mid列表文件后调用命令刷新DNS缓存，此时负责网络服务的进程svchost会将新的hosts列表刷入本地DNS缓存，安全软件或竞争私服等程序在联网时默认先查询DNS缓存，发现缓存列表里存在相关记录项就会导致该域名解析被重定向，从而实现屏蔽或劫持网络的作用。此时检查系统的hosts文件将看不到任何异常，然而通过ping命令便能验证出DNS已被劫持：

由于目标域名劫持后重定向到一个本机回环地址（127.0.0.1），所以屏蔽了对劫持域名（ip***360safe.com）的网络请求，此目的为干扰安全软件的正常联网。当然要进行劫持的域名都是由云端分配控制的，劫持列表可以随时更换，例如下面是一组被劫持的知名游戏网站，均被劫持到某一固定的ip地址（139.***.246.167）：

（三）TDI过滤流程劫持网络流量

接下来分析tdi过滤流程，最终实现通过驱动劫持用户的网络流量。母体drvsup.dll通过IsWow64Process判断系统环境，选择下载x64或者x86版本的tdi驱动到本地保存为mstd32.sys：

下载后按照正常启动服务的方式直接启动该驱动程序：

一旦驱动加载起来，后面的流程全靠该驱动独立完成，无需与应用层程序进行其他交互。驱动每次启动时重新下载一份劫持列表tdipaddr.dll到内存，并将其解析到链表中方便后面进行劫持过滤：

下载的列表经常发生变化，并且同时存在多种不同的传播版本，对不同类型的知名网址进行劫持，如下是截获的其中一个版本，其中包含大量知名的游戏公司官网，如盛大游戏和冰川网络，均被劫持到某搜索引擎的一个服务器ip（14.***38）：

后面过滤IO请求时，将以该列表去匹配当前网络访问的host：

满足过滤规则的所有网络IO请求会被标记，待相应的请求响应后对接收到的数据进行修改，添加301重定向响应头或者嵌入html框架来实现劫持，最后将修改后的内容返回给请求联网的应用层程序（如浏览器）处理：

例如我们通过浏览器正常访问盛大游戏官网时如下：

而驱动劫持后访问盛大游戏官网则会发生跳转，将其劫持到某搜索引擎（或其他地址，根据云端列表来控制），阻碍用户正常访问游戏网站。从360浏览器的抓包工具可以看出劫持方式是嵌入一个指向搜索引擎地址的html框架：

对劫持过程进行双机调试，也能观察到访问盛大游戏官网时驱动程序劫持的过滤过程：

最后发现驱动程序还注册了一个关机回调，在系统关机时改变驱动文件名，重写驱动文件来增加自身的隐蔽性。驱动的路径如下图所示，可以看到文件名为8位随机字母：

重写驱动文件后将新的驱动路径注册成一个开机自启动的服务，以保证在用户电脑上的劫持活动得以延续。

传播情况

冒用签名的恶意程序在搜索引擎中的排名非常靠前，吸引了很多用户去下载，例如通过一些关键字：

该网站打开之后可以直接下载：

根据360大数据监测统计，今年新增冒用样本数量约400个，感染量约35万。下图所示是2017年8月份之前的受害用户地域分布图，其中沿海一带以浙江、辽宁和广东传播最多，内陆则以四川和湖南居多 。

除了以上“梁山传奇”还有上万款传播相关样本的私服网站，共同形成了一条庞大的灰色产业链，这里列出部分：

查杀

自从签名冒用的恶意程序出现以来，我们持续监测其发展的动态，并率先进行查杀。本次带有冒用签名的恶意模块通过私服程序大量传播，受害用户群主要为传奇游戏玩家，希望广大的用户提高安全意识，尽量通过正规的官方渠道下载游戏，避免损失。同时，希望相关的数字证书签发机构严格审查企业资质，避免此类情况再次发生。

译者：興趣使然的小胃

预估稿费：200RMB

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

一、前言

2017年3月14日，微软公布了安全公告MS17-013，修复了CVE-2017-0005漏洞。CVE-2017-0005漏洞位于windows Win32k组件中，攻击者利用该漏洞可能实现权限提升。根据合作伙伴的可信报告，我们发现了该漏洞的零日（zero-day）利用方法。漏洞利用的目标系统为老版本的Windows系统，攻击者可借此在目标系统上提升进程权限。

在本文中，我们详细分析了漏洞利用方法的技术细节，评估了Windows 10周年更新版（于2016年8月份发布）对漏洞的防御效果，同时也评估了一些缓解措施的效果，比如SMEP（Supervisor Mode Execution Prevention，管理模式执行保护）以及VBS（virtualization-based security，基于虚拟化的安全）。此外，我们也展示了Windows在创造者更新（Creators Update）中带来的Windows Defender ATP（Windows Defender Advanced Threat Protection）的增强功能，Windows Defender ATP可以检测攻击者实施的权限提升（elevation-of-privilege，EoP）攻击行为，自然也能检测与该漏洞有关的权限提升攻击行为。

二、权限提升攻击细节

经过对漏洞利用代码的审计分析后，我们发现此次EoP攻击的目标为运行Windows 7以及Windows 8的主机。攻击者精心构造了利用工具，避免其运行在较新的平台上。

漏洞利用工具的执行过程中的各个阶段以及对应的函数如图1所示。

2.1 阶段1&2：解密器以及API解析器

为了保护主功能代码，攻击者使用AES-256算法对初始阶段的PE文件进行加密。为了加载下一阶段的代码，程序需要将某个密码作为参数传递给主入口函数。代码中使用了CryptHashData这个API，将传入的密码作为密钥来解密下一阶段的载荷。

第2阶段充当了一个中间阶段的角色，这个阶段用来解析API函数。这一阶段所做的API解析工作与shellcode或者位置无关（position-independent）代码的运行过程类似。

GetProcAddressAPI解析过程的部分代码如下所示。这部分代码似乎会混淆后续的载荷，阻止对其的安全分析。

2.3 阶段3：避免在新平台上运行

在阶段3中，利用工具会执行一些环境检查过程，特别是会检查操作系统平台以及具体的版本信息。攻击者借此确保漏洞利用代码运行在存在漏洞的系统上（具体说来，这些系统为Windows 7以及Windows 8），它们较少启用对应的漏洞防护功能。

从代码中我们可知，工具专门针对特定版本的Windows系统研发，具体版本为：

主版本号（Major release version）为5；

主版本号为6，次版本号（minor version）为0、1或者2。

这些版本对应的是Windows 2000以及Windows 8之间的Windows操作系统，其中不包含Windows 8.1以及Windows 10。此外，仔细研究其中的系统架构检查代码后，我们发现漏洞利用代码针对的是64位操作系统。

下一阶段的载荷通过DLL反射技术完成加载。

2.4 阶段4：漏洞利用程序

环境检查通过后，攻击代码开始真正利用CVE-2017-0005这个Windows内核漏洞，最终造成内存崩溃，实现代码权限提升目的。

通过破坏PALETTE.pfnGetNearestFromPalentry中的一个指针，程序可以实现内存空间中的代码执行。微软安全研究员一直在密切跟踪这种利用技术，这种技术可以通过精心构造的PALETTE对象实现在内核中执行代码。此前我们在Duqu安全事件的一个样本中观察到这种漏洞利用技术，并于Virus Bulletin 2015的演讲中介绍过这种技术。

如下代码片段中，我们可以看到PALETTE函数指针处于损坏状态：

漏洞利用代码调用NtGdiEngBitBlt这个原生API来触发win32k!XLATEOBJ_iXlate函数，后者使用了已损坏的那个处理函数。这样一来，控制流就会传递给之前已分配的一段shellcode。相对比而言，Duqu 2.0中的漏洞利用代码使用了Gdi32.dll中的GetNearestPaletteIndex函数，以便将程序执行权传递给损坏的回调处理函数。虽然这两个漏洞利用代码在某些地方有些相似，但根据这个不同点，我们可以判定这两个漏洞利用代码并不相关，此类漏洞利用技术有非常翔实的参考文档，因此也能解释这两段利用代码的相似性。

漏洞利用代码使用动态创建的系统调用（syscall）代码片段来调用原生的Windows API，如下所示。

shellcode执行期间的调用栈如下所示：

shellcode执行后，利用程序会使用一种常见的令牌交换（token-swapping）技术来将当前进程的权限提升到SYSTEM权限。在类似的EoP漏洞利用中我们经常可以看到这种技术。

三、防护及检测方法

前面提到过，这个零日漏洞利用程序没有针对诸如Windows 10之类的较新的系统。如果环境检查过程通过，那么漏洞利用代码就会在目标系统中执行，根据我们的测试结果，我们发现如果系统部署了其他的防护机制，那么漏洞利用程序就无法执行全部代码。我们可以分析一下这两种防护技术，一种是中期的防护方法，也可以称之为战术级防护方法，旨在打破漏洞利用的执行过程，另一种是长期的防护方法，也可以称之为战略级防护方法，旨在完全消除漏洞，阻止漏洞利用。

3.1 战术级防护：阻止程序滥用pfnGetNearestFromPalentry

漏洞利用代码中利用PALETTE.pfnGetNearestFromPalentry作为控制权传送点，微软安全研究员对这种技术已经跟踪了一段时间。事实上，我们一直在研究针对这种技术的战术级防护方法。2016年8月，在发布Windows 10周年更新版的同时，微软公布了一种战术级防护机制，目的在于防止程序滥用pfnGetNearestFromPalentry。当PALETTE函数指针被调用时，这种防护机制会检查函数指针的有效性，确保只有预定义的一组函数会被调用，防止相应的结构体被滥用。

3.2 战略级防护

除了上面描述的战术级防护机制外，Windows 10在64位内核中引入了SMEP、ASLR增强特性，也引入了基于虚拟化的安全（virtualization-based security，VBS）机制，可以阻止漏洞利用过程。

3.2.1 管理模式执行保护

SMEP（Supervisor Mode Execution Prevention，管理模式执行保护）是一种战略级防护特性，新版的Intel CPU支持这一功能，自Windows 8以来，微软也引入了这种安全特性。

启用SMEP特性后，页表项（page table entry，PTE）中的标志位作为用户/管理员（U/S）标志，可以指定页面处于用户模式或者内核模式。如果内核模式代码调用了某个用户模式页面，SMEP就会产生访问冲突，系统会触发错误检查过程，停止代码执行过程并报告安全冲突。这种机制可以阻止利用用户模式分配的可执行页面来运行内核模式下的shellcode，而这种运行机制是EoP漏洞利用程序常用的方法。

类似SMEP之类的战略级防护措施可以导致数以百计的EoP漏洞利用代码无效，从而显著提高攻击者的技术门槛，这类漏洞利用代码中不乏从内核态直接调用用户态shellcode的老式漏洞利用方法，如本文分析的CVE-2017-0005漏洞利用技术。

我们可以使用Coreinfo这个工具来判断主机是否支持SMEP特性。该工具使用CPUID指令，在输出结果中显示支持SMEP特性的CPU以及平台。如下图所示，从工具的执行结果中，我们可知正在测试的CPU支持SMEP。Windows 8以及更高版本的Windows系统支持SMEP特性。

3.2.2 Windows内核64位ASLR增强特性

启用SMEP后，虽然攻击者被迫使用更为复杂的漏洞利用代码才能实施攻击行为，但根据安全会议以及安全事件中分享的技术方法，我们的确了解到有多种方法可能绕过SMEP保护机制。如使用内核ROP工具或者通过读写（RW）方法直接修改PTE都可以实现绕过目的。为了应对漏洞利用中不断出现的新技术，微软在Windows 10周年更新版中提供了Windows内核64位ASLR增强特性，通过随机化的内核地址增强了SMEP功能，避免基于直接修改PTE实现的漏洞利用技术。

3.2.3 基于虚拟化的安全

VBS（virtualization-based security，基于虚拟化的安全）增强特性可以从另一个角度来防止内核中执行恶意代码。比如，设备保护（Device Guard）会阻止执行内核内存未签名区域中的代码，当然也会阻止内核EoP代码的执行。设备保护中的增强功能也可以保护MSR、控制寄存器以及描述符表寄存器（descriptor table registers）。这样一来，对CR4控制寄存器（包括SMEP区域的数据）未授权的修改会被立即阻止。

3.3 Windows Defender ATP功能

在创造者更新版系统中，Windows Defender ATP可以检测通过修改CR4寄存器实现的SMEP攻击技术。Windows Defender ATP可以监控CR4.SMEP标志，一旦出现不一致就会报告相应情况。此外，Windows Defender ATP可以监控进程结构中的令牌区域状态，以检测令牌交换攻击。

四、总结

在较新的系统中，本文分析的CVE-2017-0005漏洞利用代码会直接停止工作，以避免引起用户警觉，因此这些系统不会受到该工具影响。攻击者没有特别去关注老版本的系统，但有意识地在规避新的硬件以及操作系统平台（如Windows 10周年更新版）中所使用的安全增强特性。虽然我们一直在针对特定的漏洞来发布特定的补丁，但从本文对攻击者行为的分析来看，系统内置的防御机制（如SMEP、ASLR增强机制以及VBS机制）可以提供一种弹性的防御屏障。

与创造者更新版一起发布的Windows Defender ATP（公众预览版）能够检测端点上的漏洞利用行为，进一步扩展了这种防御屏障。在即将发布的增强特性中，Windows Defender ATP可以发布安全警报，以便安全操作人员第一时间察觉EoP攻击行为，采取对应的响应动作。大家可以阅读我们之前发表的分析跨进程注入技术的文章，进一步了解Windows Defender ATP如何检测复杂的攻击行为。

除了加强对EoP利用技术的通用检测方法之外，微软安全研究员同时也在积极收集属于ZIRCONIUM的威胁情报以及特征信息，这一组织正是使用CVE-2017-0005漏洞利用技术的组织。我们会向Windows Defender ATP客户推送综合威胁情报，分析正在活跃的攻击组织以及他们的攻击方法。

Windows 10企业版中集成了Windows Defender ATP，大家可以免费试用。

热点概要：Tunnel Manager - From RCE to Docker Escape、针对福昕阅读器拒绝修复的漏洞及其安全模式浅析、针对多款路由器的漏洞挖掘、以DVRF（路由器漏洞靶机）为例解读JEB固件漏洞利用（Part 1）、Awesome Security Gists、虚拟货币投资平台Enigma被黑，价值逾47万美元的以太坊已被盗

国内热词(以下内容部分摘自http://www.solidot.org/)：

Gentoo 将移除加固内核

虚拟货币投资平台Enigma被黑，价值逾47万美元的以太坊已被盗

http://thehackernews.com/2017/08/enigma-cryptocurrency-hack.html

Tunnel Manager - From RCE to Docker Escape

https://xianzhi.aliyun.com/forum/read/2009.html

关于福昕阅读器 - 安全阅读模式和其他漏洞的故事（针对前段时间福昕阅读器拒绝修复的漏洞及其安全模式浅析）

http://insert-script.blogspot.co.at/2017/08/a-tale-about-foxit-reader-safe-reading.html

重温SOHO路由器攻击（针对多款路由器的漏洞挖掘）

http://www.sicherheitsforschung-magdeburg.de/uploads/journal/MJS_054_Rueda_SOHORouter.pdf

利用SQLMAP检测和利用SQL注入（科普）

https://gbhackers.com/sqlmap-detecting-exploiting-sql-injection/

一道CrackMe题目分析（含样本下载）

https://secrary.com/CrackMe/AdvancedKeygenme/

以DVRF（路由器漏洞靶机）为例解读JEB固件漏洞利用（Part 1）

https://www.pnfsoftware.com/blog/firmware-exploitation-with-jeb-part-1/

SLAE：自定义RBIX Shellcode编码器/解码器

https://www.rcesecurity.com/2015/01/slae-custom-rbix-shellcode-encoder-decoder/

Solving a Danish Defense Intelligence Puzzle（对一道CrackMe题目的分析）

https://safiire.github.io/blog/2017/08/19/solving-danish-defense-intelligence-puzzle/

记一次意外攻击失误导致的后果

http://blog.portswigger.net/2017/08/how-i-accidentally-framed-myself-for.html

The Art of Becoming TrustedInstaller

https://tyranidslair.blogspot.co.uk/2017/08/the-art-of-becoming-trustedinstaller.html

使用RIG EK投放Ramnit木马

https://malwarebreakdown.com/2017/08/21/seamless-campaign-uses-rig-ek-to-drop-ramnit-trojan/

针对JS_POWMET无文件恶意软件分析

http://blog.trendmicro.com/trendlabs-security-intelligence/look-js_powmet-completely-fileless-malware/

Awesome Security Gists

https://github.com/Hack-with-Github/Awesome-Security-Gists/

Cryptocurrency Miner利用WMI和永恒之蓝实现无文件恶意软件

http://blog.trendmicro.com/trendlabs-security-intelligence/cryptocurrency-miner-uses-wmi-eternalblue-spread-filelessly/

译者：shan66

预估稿费：260RMB

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

在本文中，我们将向读者全面介绍各种DLL注入技术。所谓DLL注入，本来是软件用于向其他程序添加/扩展功能、调试或逆向工程的一种合法技术。不过，后来恶意软件也常用这种方式来干坏事。因此，这意味着从安全的角度来看，我们必须知道DLL注入是如何工作的。

之前，当我开始开发Red Team的定制工具（为了模拟不同类型的攻击者）时，我完成了这个小项目的大部分代码，并将该项目命名为“injectAllTheThings”。如果你想看一些使用DLL注入的具体示例，请访问这里。如果你想了解DLL注入，该项目也会很有帮助。实际上，我已经在一个单一的Visual Studio项目中组合了多种DLL注入技术（实际上是7种不同的技术），它们都有32位和64位版本，并且非常便于阅读和理解：每种技术都有自己单独的源文件。

以下是该工具的输出，给出了所有已经实现的方法。

根据@SubTee的说法，DLL注入是“没什么大不了”的。我同意这种观点，但是，DLL注入远不止加载DLL这么简单。

你虽然可以使用经过Microsoft签名的二进制代码来加载DLL，但是却无法附加到某个进程来利用其内存。大多数渗透测试人员实际上不知道什么是DLL注入以及它是如何工作的，主要是因为Metasploit可以代劳的事情太多了。他们一直在盲目地使用它。我相信，学习这个“怪异的”内存操纵技术的最佳地点，不是安全论坛，而是黑客论坛。如果你加入了红队，你可能需要鼓捣这种东西，除非你安于使用他人提供的工具。

大多时候，我们首先会使用一项高度复杂的技术展开攻击，如果我们没有被发现，才会开始降低复杂程度。这就是说，我们会先将二进制文件丢到磁盘上，然后使用DLL注入。

这篇文章将全面介绍DLL注入，同时也是GitHub托管的该项目的“帮助文档”。

概述

DLL注入简单来说就是将代码插入/注入到正在运行的进程中的过程。我们注入的代码是动态链接库（DLL）的形式。为什么可以做到这一点？因为DLL（如UNIX中的共享库）是在运行时根据需要来进行加载。在这个项目中，我将只使用DLL，但是实际上还可以使用其他各种形式（任何PE文件、shellcode / assembly等）来“注入”代码，这些在恶意软件中非常常见。

此外，请记住，您需要具有适当级别的权限才能鼓捣其他进程的内存。但是，这里不会探讨受和保护的进程、windows特权级别（由Vista引入）有关的内容——这是一个完全不同的主题。

如上所述，DLL注入可以用于合法目的。例如，防病毒和终端安全解决方案就需要使用这些技术将自己的软件代码/挂钩放置到系统上的“所有”运行的进程中。这使他们能够在运行过程中监视每个进程的行为，从而更好地保护我们。但是，该技术也可以用于恶意的目的。一般来说，常用技术是注入“lsass”进程以获取密码哈希值。恶意软件也广泛使用代码注入技术，例如，运行shellcode、运行PE文件或将DLL加载到另一个进程的内存中以隐藏自身，等等。

基础知识

我们将使用MS Windows API完成各种注入，因为这个API提供了非常丰富的功能，允许我们连接和操纵其他进程。自从微软第一个版本的操作系统以来，DLL一直是MS Windows的基石。事实上，MS Windows 所有API都涉及DLL。最重要的一些DLL有“Kernel32.dll”（其中包含用于管理内存、进程和线程的函数）、“User32.dll”（主要是用户界面函数）和“GDI32.dll”（用于绘制图形和文字显示）。

您可能奇怪为什么会提供这样的API，为什么微软给我们这么好的一套函数来操作进程的内存？实际上，它们的最初用途是扩展应用程序的功能。例如，一家公司创建一个了应用程序，并希望允许其他公司扩展或增强应用程序。所以，DLL最初是用于合法的目的。此外，DLL还可用于项目管理，节省内存，实现资源共享等。

下图讲解DLL注入技术的流程。

就像上面看到的那样，DLL注入分为四个步骤：

1.附加到目标/远程进程

2.在目标/远程进程内分配内存

3.将DLL路径或DLL复制到目标/远程进程内存中

4.让进程执行DLL

所有这些步骤都是通过调用一组API函数来实现的。每种技术都需要一定的设置和选项才能完成。实际上，每种技术都有自己的优点和缺点。

技术详解

我们有多种方法来让进程执行我们的DLL。最常见的方法就是使用“CreateRemoteThread()”和“NtCreateThreadEx()”。但是，我们无法将DLL作为参数传递给这些函数。我们必须提供一个保存执行起始点的内存地址。为此，我们需要完成内存分配，使用“LoadLibrary()”加载我们的DLL，复制内存等等。

这个项目我称之为'injectAllTheThings'（取这个名字，只是因为我讨厌‘injector’的名字，加上GitHub上已经有太多的‘injector’了），它有7种不同的技术。当然，这些技术都不是我发明的。我只是使用了这七种技术（是的，还有更多）。一些API具有详细的文档说明（如“CreateRemoteThread()”），有些API则没有相关的文档说明（如'NtCreateThreadEx()'）。以下是已经实现的技术的完整列表，它们全部适用于32位和64位。

CreateRemoteThread()

NtCreateThreadEx()

QueueUserAPC

SetWindowsHookEx()

RtlCreateUserThread()

通过SetThreadContext()获取代码洞

反射型DLL

其中，可能有一些是你早就接触过的技术。当然，这不是所有DLL注入技术的完整列表。如我所说，还有更多的技术，但是并没有包括在这里。这里给出的，是到目前为止，我在一些项目中使用过的技术。有些是稳定的，有些是不稳定的——当然，之所以不稳定，可能是由于我的代码的原因，而不是这些技术本身的原因。

LoadLibrary()

如MSDN所述，“LoadLibrary（）”函数的作用是将指定的模块加载到调用进程的地址空间中。而指定的模块可能会导致加载其他模块。

The name of the module. This can be either a library module (a .dll file) or an executable module (an .exe file). (...)

If the string specifies a full path, the function searches only that path for the module.

If the string specifies a relative path or a module name without a path, the function uses a standard search strategy to find the module (...)

If the function cannot find the module, the function fails. When specifying a path, be sure to use backslashes (\), not forward slashes (/). (...)

If the string specifies a module name without a path and the file name extension is omitted, the function appends the default library extension .dll to the module name. (...)

换句话说，它只需要一个文件名作为其唯一的参数。也就是说，我们只需要为DLL的路径分配一些内存，并将执行起始点设置为“LoadLibrary()”函数的地址，将路径的内存地址作为参数传递就行了。

实际上，这里最大的问题是“LoadLibrary()”使用程序来将加载的DLL添加到注册表中。意思是它可以轻松被检测到，但是实际上许多终端安全解决方案仍然无法检测到它们。无论如何，正如我之前所说，DLL注入也有合法的使用情况，所以...另外，请注意，如果DLL已经加载了'LoadLibrary()'，它将不会被再次执行。如果使用反射型DLL注入，当然没有这个问题，因为DLL没有被注册。如果使用反射DLL注入技术而不是使用“LoadLibrary()”，会将整个DLL加载到内存中。然后找到DLL的入口点的偏移量来加载它。如果你愿意，还可以设法将其隐藏起来。取证人员仍然可以在内存中找到你的DLL，只是这不会那么容易而已。Metasploit使用了大量的DLL注入，但是大多数终端解决方案都能搞定这一切。如果你喜欢狩猎，或者你属于“蓝队”，可以看看这里和这里。

顺便说一句，如果你的终端安全软件无法搞定所有这一切...你可尝试使用一些游戏反欺骗引擎。一些反欺诈游戏的反rootkit功能比某些AV更加先进。

连接到目标/远程进程

首先，我们需要得到要与之进行交互的进程的句柄。为此，我们可以使用API调用OpenProcess()。

如果您阅读MSDN上的文档，就会明白，为此需要具备一定的访问权限。访问权限的完整列表可以在这里找到。

这些可能因MS Windows版本而异，不过几乎所有技术都需要用到以下内容。

在目标/远程进程内分配内存

为了给DLL路径分配内存，我们需要使用VirtualAllocEx()。如MSDN所述，VirtualAllocEx()可以用来预留、提交或更改指定进程的虚拟地址空间内的内存区域的状态。该函数将其分配的内存初始化为零。

我们需要完成类似下面的工作：

此外，您还可以使用“GetFullPathName()”API调用。但是，我不会在整个项目中使用这个API调用。不过，这只是个人偏好的问题。

如果要为整个DLL分配空间，则必须执行以下操作：

将DLL路径或DLL复制到目标/远程进程的内存中

现在只需要使用WriteProcessMemory()API调用将DLL路径或完整的DLL复制到目标/远程进程。

这就像：

如果我们要复制完整的DLL，就像在反射DLL注入技术中那样，则还需要另外一些代码，因为这需要将其读入内存，然后再将其复制到目标/远程进程。

如前所述，通过使用反射DLL注入技术，并将DLL复制到内存中，DLL就不会被注册到进程中。

这稍微有点复杂，因为需要在内存中加载DLL时取得它的入口点。作为反射DLL项目用到的“LoadRemoteLibraryR()”函数可以为我们完成这些工作。如果你想查看源码的话，可以访问这里。

需要注意的一点是，我们要注入的DLL需要使用适当的include和options进行编译，使其与ReflectiveDLLInjection方法相适应。'injectAllTheThings'项目包括名为'rdll_32.dll / rdll_64.dll'的DLL，您可以使用它来完成这些工作。

让进程执行DLL

CreateRemoteThread()

CreateRemoteThread()是一种经典和最受欢迎的DLL注入技术。另外，它的说明文档也是最全面的。

它包括以下步骤：

1.用OpenProcess()打开目标进程

2.通过GetProcAddress()找到LoadLibrary()的地址

3.通过VirtualAllocEx()为目标/远程进程地址空间中的DLL路径预留内存

4.使用WriteProcessMemory()将DLL路径写入前面预留的内存空间中

5.使用CreateRemoteThread()创建一个新线程，该线程将调用LoadLibrary()函数，以DLL路径名称作为参数

如果浏览MSDN上的CreateRemoteThread()文档，会发现我们需要一个指向由线程执行的、类型为LPTHREAD_START_ROUTINE的应用程序定义函数的指针，它实际上是远程进程中线程的起始地址。

这意味着为了执行我们的DLL，只需要给我们的进程发出指示，让它来完成就行了。这样就简单了。

完整的步骤如下所示。

完整的源代码，请参阅CreateRemoteThread.cpp文件。

NtCreateThreadEx()

另一个选择是使用NtCreateThreadEx()。这是一个未公开的ntdll.dll函数，在将来它可能会消失或发生变化。这种技术实现起来有点复杂，因为我们需要使用一个结构体（见下文）作为参数传递给它，而使用另一个结构体接收来自它的数据。

这里有一篇对该调用的详细说明。这种方法与CreateRemoteThread()方法比较接近。

完整的源代码，请参阅t_NtCreateThreadEx.cpp文件。

QueueUserAPC()

对于前面的方法，有一个替代：使用QueueUserAPC()函数。

如MSDN所述，这个调用“将用户模式异步过程调用（APC）对象添加到指定线程的APC队列。”

下面是具体定义。

A pointer to the application-supplied APC function to be called when the specified thread performs an alertable wait operation. (...)

A handle to the thread. The handle must have the THREAD_SET_CONTEXT access right. (...)

A single value that is passed to the APC function pointed to by the pfnAPC parameter.

所以，如果我们不想创建自己的线程，那么可以使用QueueUserAPC()来劫持目标/远程进程中的现有线程。也就是说，调用此函数将在指定的线程上对异步过程调用进行排队。

我们可以使用真正的APC回调函数代替LoadLibrary()。这里的参数实际上可以指向注入的DLL文件名的指针。

当你尝试这种技术的时候，你可能会注意到，这与MS Windows执行APC的方式有关。但是，这里没有查看APC队列的调度器，这意味着，只有当线程变为可警示状态时，队列才会被检查。

这样，我们就可以劫持每一个线程了，具体如下。

我们这样做，主要是想让一个线程变为可警示状态。

顺便说一句，很高兴看到这种技术被DOUBLEPULSAR应用。

完整的源代码，请参见“t_QueueUserAPC.cpp”文件。

SetWindowsHookEx()

为了使用这种技术，我们首先需要了解一下MS Windows钩子的工作原理。简单来说，钩子就是一种拦截事件并采取行动的方式。

你可能会猜到，会有很多不同类型的钩子。其中，最常见的是WH_KEYBOARD和WH_MOUSE。是的，你可能已经猜到了，它们可以用来监控键盘和鼠标的输入。

SetWindowsHookEx()的作用是“将应用程序定义的钩子装到钩子链中。”

Type: int

The type of hook procedure to be installed. (...)

Type: HOOKPROC

A pointer to the hook procedure. (...)

Type: HINSTANCE

A handle to the DLL containing the hook procedure pointed to by the lpfn parameter. (...)

Type: DWORD

The identifier of the thread with which the hook procedure is to be associated. (...)

MSDN上一个有趣的评论指出：

“SetWindowsHookEx可以用于将DLL注入到另一个进程中。32位DLL不能被注入到64位进程中，同时，64位DLL也不能被注入到32位进程中。如果应用程序需要在其他进程中使用钩子，则需要使用一个32位应用程序调用SetWindowsHookEx将32位DLL注入32位进程中，或者使用64位应用程序调用SetWindowsHookEx来把64位DLL注入64位进程。32位和64位DLL必须具有不同的名称。”

请大家务必记住这一点。

下面是取自具体实现中的一段代码。

我们需要知道，发生的每个事件都将通过一个钩子链，这是一系列可以在事件中运行的过程。SetWindowsHookExe()要做的基本上就是如何将自己的钩子放入钩子链中。

上面的代码需要用到要安装的钩子类型（WH_KEYBOARD）、指向过程的指针、具有该过程的DLL的句柄以及将要挂钩的线程的ID。

为了获得指向程序的指针，我们需要首先使用LoadLibrary()调用加载DLL。然后，调用SetWindowsHookEx()，并等待我们想要的事件发生（这里而言就是按一个键）。一旦相应的事件发生，我们的DLL就会被执行。

完整的源代码，请参阅t_SetWindowsHookEx.cpp文件。

RtlCreateUserThread()

RtlCreateUserThread()是一个未公开的API调用。它的设置几乎与CreateRemoteThread()以及后面介绍的NtCreateThreadE()完全相同。

实际上，RtlCreateUserThread()会调用NtCreateThreadEx()，这意味着RtlCreateUserThread()是NtCreateThreadEx()的封装。所以，这里没有什么新玩意。但是，我们可能只想使用RtlCreateUserThread()，而不是NtCreateThreadEx()。即使后者发生了变动，我们的RtlCreateUserThread()仍然可以正常工作。

我们知道，mimikatz和Metasploit都使用RtlCreateUserThread()。如果你有兴趣的话，可以看看这里和这里。

所以，如果mimikatz和Metasploit正在使用RtlCreateUserThread()...是的，那些家伙都了解自己的代码...按照他们的“建议”，使用RtlCreateUserThread()——特别是，如果你打算鼓捣一些比简单的“injectAllTheThings”程序更复杂的事情的时候。

完整的源代码，请参阅t_RtlCreateUserThread.cpp。

SetThreadContext()

这实际上是一个很酷的方法。通过在目标/远程进程中分配一大块内存，以便将特制代码注入目标/远程进程。而该代码是负责加载DLL的。

下面给出的是32位的代码。

对于64位代码，没有找到任何可用的代码，只好自己动手了，具体如下。

在将这个代码注入目标进程之前，需要填充/修补一些占位符：

返回地址（代码完成执行后线程应该恢复的地址）。

DLL路径名。

LoadLibrary()的地址。

接下来就是劫持、暂停、注入和恢复线程发挥作用的时候。

我们首先需要连接到目标/远程进程，并将内存分配到目标/远程进程中。请注意，我们需要分配具有读取和写入权限的内存来保存DLL路径名，以及存放加载DLL的汇编代码。

接下来，我们需要获得在目标/远程进程上运行的一个线程的上下文（将要注入我们的汇编代码的线程）。

为找到线程，我们可以使用函数getThreadID()，它位于‘auxiliary.cpp’中。

一旦我们获得了线程id，就可以设置线程上下文了。

接下来，我们需要暂停线程来捕获其上下文。线程的上下文实际上就是其寄存器的状态。我们特别感兴趣的寄存器是EIP / RIP（有时称为IP指令指针）。

由于线程被暂停，所以我们可以更改EIP / RIP的值，并强制它继续在不同的路径（我们的代码洞）中执行。

所以，我们暂停线程，捕获上下文，从中提取EIP / RIP。当我们注入的代码运行完成时，保存的这些数据将用来恢复现场。新的EIP / RIP设置为我们注入的代码位置。

然后我们使用返回地址、DLL路径名地址和LoadLibrary()地址对所有占位符进行填补。

一旦线程开始执行，我们的DLL将被加载，它一旦运行完成，将返回到被挂起的位置，并在那里恢复执行。

如果你想练习调试的话，这里有具体的操作指南。启动要注入的应用程序，如notepad.exe。运行injectAllTheThings_64.exe与x64dbg，如下所示。

也就是说，我们可以使用以下命令行（具体视您的环境而定）：

在调用WriteProcessMemory()处设置断点，如下所示。

当代码运行时，断点触发，这时要注意寄存器RDX的内存地址。至于为什么要关注RDX，可以阅读x64调用约定方面的资料。

利用单步方式（F8）调用WriteProcessMemory()，启动x64dbg的另一个实例，并连接到'notepad.exe'。转到以前复制的地址（RDX中的地址），按“Ctrl + g”，您将看到我们的代码，如下所示。

太棒了！ 现在，请在这个shellcode的开头设置一个断点。转到被调试进程的injectAllTheThings，让它运行。正如在下面看到的，我们的断点触发，现在可以单步调试代码，进行仔细研究了。

一旦调用LoadLibrary()了函数，就可以加载我们的DLL了。

这真是太好了。

我们的shellcode将返回到之前保存的RIP的地址处，notepad.exe将恢复执行。

完整的源代码，请参阅t_suspendInjectResume.cpp。

反射型DLL注射

我还将Stephen Fewer（这种技术的先驱）代码引入了这个“injectAllTheThings”项目，此外，我还构建了一个反射型DLL项目使用这种技术。请注意，我们正在注入的DLL必须使用适当的include和options进行编译。

由于反射型DLL注入会将整个DLL复制到内存中，因此避免了使用进程注册DLL。我们已经完成了一切繁重的工作。要在DLL中加载内存时获取入口点，只需使用Stephen Fewer的代码即可。他的项目中包含的“LoadRemoteLibraryR（）”函数为我们完成了这些工作。我们使用GetReflectiveLoaderOffset（）来确定我们进程内存中的偏移量，然后使用该偏移加上目标/远程进程（我们写入DLL的位置）中的内存的基地址作为执行起始点。

有点太复杂了？是的，确实如此。下面是实现这一目标的4个主要步骤。

1.将DLL头写入内存

2.将每个节写入内存（通过解析节表）

3.检测import并加载所有其他已导入的DLL

4.调用DllMain入口点

与其他方法相比，这种技术提供了强大的隐蔽性，并在Metasploit中大量应用。

如果你想了解更多详情，请访问官方的GitHub信息库。此外，请务必阅读Stephen Fewer的文章。

另外，最好读一下MemoryModule的作者Joachim Bauch写的一篇文章，讲述了如何从内存加载一个DLL，同时，这也是在没有LoadLibrary（）的情况下手动加载Win32 / 64 DLL的好方法。

代码

当然，还有一些复杂的注入方法，所以后面还会更新injectAllTheThings项目。我最近看到的最有趣的一些是：

DOUBLEPULSAR使用的一种方法

由@zerosum0x0编写的，使用SetThreadContext()和NtContinue()的反射型DLL注入技术，此处提供了可用的代码。

我上面描述的所有技术都是我在GitHub上提供的一个项目中已经实现的。此外，我还提供了每种技术所需的DLL。下表可以了解实际实现的内容以及使用方法。

不用说，为了安全起见，最好始终使用injectAllTheThings_32.exe注入32位进程或使用AllTheThings_64.exe注入64位进程。当然，您也可以使用injectAllTheThings_64.exe注入32位进程。其实我还没有实现这一点，但是我可能稍后会再试一次，你可以试着用WoW64鼓捣一下64位进程。Metasploit的smart_migrate基本上就是这种情况，具体请看这里。

本文涉及的整个项目的所有代码，包括DLL，都可从GitHub下载。当然，如果您有兴致的话，也可以自己试着编译32位和64位代码。