olepro32dll无法被更新(谈谈Office Moniker类漏洞和公式编辑器类漏洞)

olepro32dll无法被更新(谈谈Office Moniker类漏洞和公式编辑器类漏洞)

olepro32dll文章列表:

• 1、谈谈Office Moniker类漏洞和公式编辑器类漏洞
• 2、独家解密：浅谈 Windows10 安全体系的新变化
• 3、天鬼指示器-WA字符串
• 4、深入剖析CVE-2021-40444-Cabless利用链
• 5、企业IT部王森：腾讯企业终端安全管理最佳实践

谈谈Office Moniker类漏洞和公式编辑器类漏洞

在近几年出现的诸多office漏洞中，有两类漏洞是很值得谈谈的，第一类是Moniker导致的逻辑漏洞，第二类是公式编辑器漏洞。

对于第一类漏洞，其重点在于攻击者和微软安全团队之间的攻防过程，了解这类漏洞攻防过程对威胁追踪与研究较有益处：

第一回合：CVE-2017-0199，用URL Moniker加载远程HTA文件实现远程代码执行；

第二回合：CVE-2017-8570，用compositeMoniker、FileMoniker、NewMoniker、scriptletfile实现远程代码执行；

第三回合：CVE-2017-8759，用office文档加载.Net组件漏洞，实现远程代码执行；

第四回合：CVE-2018-8174，用office文档加载IE VBScript组件漏洞，实现远程代码执行；

第五回合：CVE-2020-0674，用office文档加载IE JavaScript组件漏洞，实现远程代码执行。

对于第二类漏洞，其难点在于对相似漏洞之间的区分。从CVE-2017-11882开始，到CVE-2018-0802，再到CVE-2018-0798，三个都是非常相似的漏洞，在静态层面不容易区分，本文将分享一个在动态层面区分它们的方法。

下面跟随笔者一起来看一下这两类漏洞。

Moniker类漏洞

第一回合：CVE-2017-0199

2017年4月7日，著名office漏洞研究员李海飞发布了一篇在野0day攻击预警，首度披露了CVE-2017-0199漏洞的在野攻击。随后，2017年4月11日和12日，FireEye连发两篇文章，披露了他们捕获到的CVE-2017-0199漏洞样本细节。后续的披露表明这几篇文章中披露的漏洞是一种借助URL Moniker特性加载远程hta文件的新型漏洞，这是一个由于开发者对office文件加载机制设计不合理导致的逻辑漏洞，且要求触发环境安装IE10/IE11。漏洞触发过程不需要用户交互，但在触发的过程中会弹出一个对话框，不点击或者点击任意该对话框的按钮都不影响执行过程，对话框样式如下：

该漏洞的发现者之一李海飞曾经在Syscan360 2017会议上做过题为《Moniker Magic: Running Scripts Directly in Microsoft Office》的演讲，里面详细介绍了CVE-2017-0199的细节，包括：

微软在CVE-2017-0199的补丁中修复了两个漏洞，分别是被在野利用的RTF URL Moniker加载远程HTA文件的远程代码执行漏洞，和李海飞独立发现的PPSX Script Moniker远程代码执行漏洞；

office安全团队在这两个漏洞的基础上设计了一类针对Moniker的黑名单机制，禁用了一些他们觉得不安全的Moniker。

Moniker本身是office的一个特性，可以用来链接一些本地或远程对象，其本身不属于漏洞，漏洞发生在office软件对远程链接的文件的执行策略上。譬如，如果远程加载的是一个Excel文件，直接打开没问题；但如果加载的是HTA文件和Script这类脚本文件时，直接执行就存在问题了，导致了漏洞。

第二回合：CVE-2017-8570

在对CVE-2017-0199补丁的研究过程中，李海飞发现（上面也已经提到）：

office安全团队在这CVE-2017-0199的补丁中设计了一类针对Moniker的黑名单机制，禁用了一些他们觉得不安全的Moniker。

于是他开始寻找那些还没有被禁用的Moniker，尝试用那些没有被禁用的Moniker构造出另一个逻辑漏洞，结果确实找到一个，即CVE-2017-8570。

在CVE-2017-0199中，用到的Moniker是下面这两个：

3050F4D8-98B5-11CF-BB82-00AA00BDCE0B // htafile06290BD3-48AA-11D2-8432-006008C3FBFC // scriptlet(or ScriptMoniker)

而在CVE-2017-8570中，用到的Moniker是下面这几个：

00000309-0000-0000-C000-000000000046 // CompositeMoniker00000303-0000-0000-C000-000000000046 // FileMonikerECABAFC6-7F19-11D2-978E-0000F8757E2A // NewMoniker06290BD2-48AA-11D2-8432-006008C3FBFC // scriptletfile(or ScripletFactory)

可以看到CVE-2017-8570利用未被加入黑名单的Moniker绕过了CVE-2017-0199的补丁。

不过，许多分析过CVE-2017-8570的读者可能会观察到一个奇怪的现象：漏洞中触发时script脚本中的代码会被执行两次。这是为什么呢？原来，在这个漏洞的触发逻辑中，会涉及到wwlib.dll库中的一个函数调用，该函数内部会顺序调用ole32!CDefLink::BindToSource和ole32!CDefLink::Update两个函数，如下（以office 2010为例）：

而这两个函数最终都会调用kernel32!CreateProcessW创建进程，所以script脚本中的代码会被执行两次。其中ole32!CDefLink::BindToSource创建进程的栈回溯如下：

0:000> k 50ChildEBP RetAddr 0013a5b4 729cd2f5 kernel32!CreateProcessW0013a63c 729cd5f7 wshom!CreateNewProcessW 0x6f0013a69c 76da3e75 wshom!CWshShell::Exec 0x19a0013a6bc 76da3cef OLEAUT32!DispCallFunc 0x1650013a74c 729d0267 OLEAUT32!CTypeInfo2::Invoke 0x23f...cut...0013ae9c 7705b5dc comsvcs!CNewMoniker::BindToObject 0x14f0013aed0 770c3cc6 ole32!CCompositeMoniker::BindToObject 0x105 [d:w7rtmcomole32commoniker2ccompmon.cxx @ 1104]0013af3c 68ee87ce ole32!CDefLink::BindToSource 0x1bf [d:w7rtmcomole32ole232stdimpldeflink.cpp @ 4637]0013af80 68a61429 wwlib!wdGetApplicationObject 0x69230 // 第一处调用0013b010 68a23b2c wwlib!DllGetLCID 0x4753b3...cut...

而ole32!CDefLink::Update创建进程的栈回溯如下：

0:000> k 50ChildEBP RetAddr 0013a57c 729cd2f5 kernel32!CreateProcessW0013a604 729cd5f7 wshom!CreateNewProcessW 0x6f0013a664 76da3e75 wshom!CWshShell::Exec 0x19a0013a684 76da3cef OLEAUT32!DispCallFunc 0x1650013a714 729d0267 OLEAUT32!CTypeInfo2::Invoke 0x23f...cut...0013ae68 7705b5dc comsvcs!CNewMoniker::BindToObject 0x14f0013ae9c 770c3c55 ole32!CCompositeMoniker::BindToObject 0x105 [d:w7rtmcomole32commoniker2ccompmon.cxx @ 1104]0013af08 7710f7ee ole32!CDefLink::BindToSource 0x14e [d:w7rtmcomole32ole232stdimpldeflink.cpp @ 4611]0013af30 7710f42a ole32!CDefLink::Update 0x62 [d:w7rtmcomole32ole232stdimpldeflink.cpp @ 5347]0013af44 68ee8830 ole32!CDefLink::Update 0x33 [d:w7rtmcomole32ole232stdimpldeflink.cpp @ 2695]0013af80 68a61429 wwlib!wdGetApplicationObject 0x69292 // 第二处调用 0013b010 68a23b2c wwlib!DllGetLCID 0x4753b3...cut...

第三回合：CVE-2017-8759

在CVE-2017-8570漏洞被修复后，累计有如下这些Moniker被加入黑名单：

3050F4D8-98B5-11CF-BB82-00AA00BDCE0B // htafile06290BD3-48AA-11D2-8432-006008C3FBFC // scriptlet(or ScriptMoniker)00000309-0000-0000-C000-000000000046 // CompositeMoniker00000303-0000-0000-C000-000000000046 // FileMonikerECABAFC6-7F19-11D2-978E-0000F8757E2A // NewMoniker06290BD2-48AA-11D2-8432-006008C3FBFC // scriptletfile(or ScripletFactory)

在前面几个Moniker不能使用之后，攻击者又注意到了下面这个Moniker：

ecabb0c7-7f19-11d2-978e-0000f8757e2a // SOAPMoniker

SOAP Moniker可以用来加载一个远程的SOAP配置文件，当Word进程远程加载这个配置文件时，.Net组件会被加载用来解析对应的配置文件，并按照配置自动生成一个C#文件，再自动将该C#文件编译得到一个动态链接库并执行。攻击者借助.Net SOAP WSDL模块中的一个代码注入漏洞（CVE-2015-8759），将恶意脚本代码注入到了待编译的C#文件中，从而让编译得到的动态链接库包含恶意代码并自动执行。

从CVE-2017-8759开始，攻击者开始借助office组件与其他Windows组件之间的交互进行攻击。.Net的漏洞本身不属于office的范围，却可以借助office文档进行触发，这种攻击方式当时给笔者留下了深刻的印象。

第四回合：CVE-2018-8174

CVE-2017-8759被修复后，Moniker黑名单又得到了更新：

3050F4D8-98B5-11CF-BB82-00AA00BDCE0B // htafile06290BD3-48AA-11D2-8432-006008C3FBFC // scriptlet(or ScriptMoniker)00000309-0000-0000-C000-000000000046 // CompositeMoniker00000303-0000-0000-C000-000000000046 // FileMonikerECABAFC6-7F19-11D2-978E-0000F8757E2A // NewMoniker06290BD2-48AA-11D2-8432-006008C3FBFC // scriptletfile(or ScripletFactory)ecabb0c7-7f19-11d2-978e-0000f8757e2a // SOAPMoniker

在上面这些Moniker都不可用之后，攻击者又想出了一种新的攻击方式：借助URL Moniker去加载远程html文件，这样就可以借助office加载IE漏洞。攻击者首先用URL Moniker CVE-2014-6332的组合试了一下该方案的可行性，笔者追溯到的这方面的最早样本为2018年1月17日的下面这个文件（以及相关文件）：

// CVE-2014-6332Document MD5: A9D3F7A1ACD624DE705CF27EC699B6B6URL Moniker: hxxp://s.dropcanvas[.]com/1000000/940000/939574/akw.htmlakw.html MD5: C40A128AE7AEFFA3C1720A516A99BBDF

到了2018年4月，攻击者终于按捺不住了，借助URL Moniker IE VBScript 0day的方式对特定目标进行了攻击，这次攻击所用漏洞就是著名的CVE-2018-8174，相关样本如下：

// CVE-2018-8174Document MD5: b48ddad351dd16e4b24f3909c53c8901URL Moniker: hxxp://autosoundcheckers[.]com/s2/search[.]php?who=7search.htm MD5: 15eafc24416cbf4cfe323e9c271e71e7

CVE-2018-8174出现后，微软安全团队并未直接将office加载VBScript脚本的功能进行限制。随后，在2018年7月，攻击者又借助另一个IE VBScript 0day（CVE-2018-8173），用相同的方式实施了攻击。

这下微软不淡定了，赶紧对Office加载VBScript脚本进行了限制。

第五回合：CVE-2020-0674

故事到这里就结束了吗？当然没有。此时，微软依然没有限制office加载JavaScript脚本，所以IE浏览器的两个JavaScript引擎：JScript和JScript9依然可以通过此种方式进行攻击。

其一，据笔者所知，在2018年的天府杯上，针对office项目的攻击采用了URL Moniker IE JScript9 0day的组合。

其二，2019年-2020年，由于几个JScript漏洞被相继披露，陆续有APT攻击组织使用URL Moniker JScript 1day的方式实施攻击，相关样本如下：

// CVE-2020-0674Document MD5: 90403dfafa3c573c49aa52c5fe511169URL Moniker: hxxp://tsinghua.gov-mil[.]cn/images/A96961AA/36604/1836/65449576/ab8feeeab8feee MD5: 1892D293030E81D0D1D777CB79A0FDBE// CVE-2020-0968Document MD5: 60981545a5007e5c28c8275d5f51d8f0URL Moniker: hxxp://94.156.174[.]7/up/a1a.htma1a.htm MD5: 293916af3a30b3d7a0dc2949115859a6

于是微软在高版本office中（office2016及以上版本）也加入了对JScript9脚本和JScript脚本的加载限制。

至此，攻击者针对Moniker的所有尝试都被微软进行了封堵，此后未观察到针对Moniker的新攻击方式。

公式编辑器漏洞

2017年11月补丁日，国外安全公司_embedi发表了一篇《SKELETON IN THE CLOSET: MS Office vulnerability you didn’t know about》详细描述了他们发现office公式编辑器漏洞CVE-2017-11882的整个过程（笔者发现这家公司的官网已经挂了…）。

属于office公式编辑器漏洞的时代至此开启。

由于组件源码的丢失，微软的补丁开发人员花了较长时间来修复这一漏洞，并且以一种近乎炫技的方式，直接在二进制层面对程序作了修补，在没有重新编译源码的情况下修复了漏洞，并添加了ASLR支持。

然而，一时激起千层浪，CVE-2017-11882出现后，广大安全研究员蜂拥而至，都开始关注office公式编辑器这一组件，这直接导致微软在2018年1月的更新中砍掉了公式编辑器组件。

在第二次修复的诸多office公式编辑器漏洞中，有两个漏洞比较值得注意，这两个漏洞分别为CVE-2018-0802和CVE-2018-0798，三个漏洞并称为office公式编辑器漏洞领域的“三驾马车”，

由于笔者经常看到分析人员对这三个漏洞的样本进行误判，所以这里分享一种在动态层面区分这三个漏洞的方法。

首先跟随笔者来了解一下这三个漏洞的具体成因，下文中的汇编代码基于以下公式编辑器组件：

eqnedt32.exe 2000.11.9.0

在office中，公式编辑器的数据被存储在一个OLE文件的“Equation Native”流中，三个公式编辑器漏洞都是在处理这个流的数据时出现的问题。

CVE-2017-11882

首先来看一下CVE-2017-11882。

该漏洞的成因为：在读入“Equation Native”流中的Font Name Record数据时，在将Name拷贝到某个局部变量的时候没有对Name的长度做校验，从而造成栈缓冲区溢出，漏洞发生点如下图所示：

从下图可以看出，函数给SrcStr变量分配的大小是0x24个字节，Name长度超过该大小就会造成栈溢出。

CVE-2017-11882的触发逻辑如下所示：

CVE-2018-0802

再来看一下CVE-2018-0802。

该漏洞的成因为：在将“Equation Native”流中的Font Name Record数据拷贝到一个LOGFONT结构体（位于栈上）内的lfFaceName成员（它是一个以空结尾的char型字符串，最大长度为0x20，其中包含终止符NULL），没有对Name的长度做校验，从而造成栈缓冲区溢出，漏洞发生点如下图所示：

CVE-2018-0802漏洞的触发路径和CVE-2017-11882有很大的重叠，下图可以做一个直观的比对：

由于某些限制，CVE-2018-0802在未打CVE-2017-11882补丁的版本上只会造成crash，但在打了补丁的版本上可以实现远程代码执行。

CVE-2018-0798

最后看一下CVE-2018-0798。

该漏洞的成因为：在读入“Equation Native”流中的Matrix Record数据时，存在一处while循环内的数据读取操作，由于未对Matrix的行和列两个参数进行校验，从而使攻击者可以控制由此计算得到的拷贝长度，导致栈缓冲区溢出：

上述汇编片段描述了一个while循环，反汇编成伪代码如下，攻击者可以控制伪码中v2的大小，从而导致了数据读写越界：

上述代码位于sub_443F6C函数内，所以理论上只要调用sub_443F6C函数的地方均存在CVE-2018-0798漏洞。作为与之前两个漏洞的对比，在之前两个漏洞的基础上加入CVE-2018-0798的触发路径如下：

动态区分三个公式编辑器漏洞

以上笔者已经介绍了三个公式编辑器漏洞的成因，借助上述知识，很容易在调试器中确认特定样本使用的漏洞，判定方式如下：

// CVE-2017-11882.text:00411655 C1 E9 02 shr ecx, 2 // 获取此偏移处的ecx值，若ecx的值位于(0x20, 0x94]区间，即为CVE-2017-11882.text:00411658 F3 A5 rep movsd.text:0041165A 8B C8 mov ecx, eax.text:0041165C 83 E1 03 and ecx, 3// CVE-2018-0802.text:00421E5B C1 E9 02 shr ecx, 2 // 获取此偏移处的ecx值，若ecx的值大于0x94，即为CVE-2018-0802.text:00421E5E F3 A5 rep movsd.text:00421E60 8B C8 mov ecx, eax.text:00421E62 83 E1 03 and ecx, 3.text:00421E65 F3 A4 rep movsb// CVE-2018-0798.text:00443F79 8D 04 45 02 00 00 00 lea eax, ds:2[eax*2].text:00443F80 83 C0 07 add eax, 7.text:00443F83 C1 F8 03 sar eax, 3.text:00443F86 66 89 45 08 mov [ebp arg_0], ax // 获取此偏移处的eax值，若eax的值大于4，即为CVE-2018-0798

有些样本会同时满足上述两个或三个条件，因为这些样本中内嵌多个公式编辑器漏洞利用。

延伸

细心的读者会发现2020年极棒大赛上使用的某国产软件公式编辑器漏洞和CVE-2018-0798基本一样，有兴趣的读者可以自行对比研究。

参考链接

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/critical-office-zero-day-attacks-detected-wild/
https://www.fireeye.com/blog/threat-research/2017/04/cve-2017-0199-hta-handler.html
https://www.fireeye.com/blog/threat-research/2017/04/cve-2017-0199_useda.html
https://0b3dcaf9-a-62cb3a1a-s-sites.googlegroups.com/site/zerodayresearch/Moniker_Magic_final.pdf
http://justhaifei1.blogspot.com/2017/07/bypassing-microsofts-cve-2017-0199-patch.html
https://www.fireeye.com/blog/threat-research/2017/09/zero-day-used-to-distribute-finspy.html
https://securelist.com/root-cause-analysis-of-cve-2018-8174/85486/
https://ti.dbappsecurity.com.cn/blog/index.php/2020/07/13/sidewinder-new-attack-target-cn/
https://ti.dbappsecurity.com.cn/blog/index.php/2020/09/18/operation-domino/
https://support.microsoft.com/en-us/help/4058123/security-settings-for-com-objects-in-office
https://www.anquanke.com/post/id/87311
https://www.anquanke.com/post/id/94210
https://www.freebuf.com/vuls/160409.html

独家解密：浅谈 Windows10 安全体系的新变化

操作系统的安全性是微软关注的重点之一。新一代Windows的开发人员积极响应针对Windows平台的重要威胁，他们使用了以前只是应用于第三方安全解决方案中的众多安全技术。系统受到了更好的保护，让攻击者更难开展活动。

然而，在某些情况下，有操作系统提供的安全工具并不足够，开发人员只好折衷让第三方的安全工具作为补充。

因为Windows系统的普遍，Windows一直是形形色色的网络犯罪分子攻击的首选目标。每个Windows的版本都会有千千万万的黑客寻找新的赚钱机会。当然，Windows也是白帽子和违法分子作斗争的主战场，白帽子也在寻找Windows系统中的安全隐患。自然卡巴斯基实验室（下文简称“KL”）一直也在进行细致的分析Windows的安全体系中心的变化，以给用户提供最大限度的保护。

这篇文章着重突出了三个Windows10的影响安全的特征，它们分别是Microsoft Edge，基于虚拟化的安全和内置的安全解决方案——Windows Defender。这些给Windows安全体系带来了新功能，但是它们自身也有弱点，在本文中，我们举例子来演示Windows10的保护技术是如何运作的以及它们怎样配合第三方安全解决方案的。

Ⅰ Microsoft Edge

Edge，Microsoft最新的浏览器，目的是替代IE，它包含在Windows10中作为默认浏览器。Microsoft努力地为Edge开发新功能，其中一些与安全有关。

CSP（Content Security Policy）和HSTS（HTTP Strict Transport Security）是用来抵御XSS（Cross-site Scripting）攻击的。这些技术不仅降低了攻击的成功几率，也提醒站长这些攻击的存在。

Content Security Policy，主要是用来定义页面可以加载哪些资源，减少跨站脚本攻击的发生。

HTTP Strict Transport Security （一般简称为HSTS） 是一个安全功能，它告诉浏览器只能通过HTTPS访问当前资源， 禁止HTTP。

Cross Site Scripting（通常简写为XSS），跨站脚本攻击。

Microsoft也在想办法使Edge免受漏洞利用的危害，这是IE不安全的祸根。现在通过使用containers和多进程机制，漏洞利用越来越难。而且，SmartScreen也能阻止用户访问带有恶意内容的网页。

SmartScreen 筛选器是Edge中的一种帮助检测仿冒网站的功能。

Edge除了拥有新技术，也不再支持VML，BHO和ActiveX，它们是经常被广告软件和恶意浏览器加载项利用的，这意味着Edge已经免疫了此类威胁。

VML指The Vector Markup Language（矢量可标记语言），可以用来在浏览器中绘制矢量图形。

BHO（IEBrowser Helper Object）是IE的拓展程序，文件格式是DLL。能够对IE浏览器的界面和访问内容进行修改。

ActiveX指面向Microsoft的IE的以OCX为扩展名的OLE控件。

然而浏览器的安全性要在实战中检验。大多数以窃取资金为目的的恶意程序利用网上银行，通过浏览器来攻击，这些浏览器有IE，Chrome，Firefox和Opera等。典型的例子是Zeus（Zbot），Dryeza（Dyre）和Dridex，尽管它们都是老病毒了，但依然被使用着。

通常银行木马经常使用浏览器中间者攻击。大多数的银行木马在攻击时将自己的代码注入浏览器进程，拦截网络交互数据。不过，各种浏览器情况不同，病毒编写者必须不断修改和更新他们的软件，这样才能在可能出现的浏览器和各种版本中运行。

据报道，在2015年11月，Dyreza有了攻击Edge的功能。不过之后，这种木马的僵尸网络活动降至零，木马更新包不再发布，C&C服务器也处于离线状态。

C&C=command-and-control

另一个有名的银行木马Kronos在2016年也盯上了Edge，我们在虚拟机上分析了这个木马。在Kronos的新版本的代码中，我们发现了一个函数检查进程的名称和综合校验码（checksum），以及木马挂钩的函数的hash值。

检测进程名和总合校验值来确定浏览器种类的函数

Kronos检查进程名称， 将字符串转换为小写，计算其校验值，这样获得的hash值会和一张表对比，如果在这张表里找到，木马会挂钩浏览器进程的某个函数。

木马所监测的浏览器进程名称和校验值。

wininet.dll挂钩的函数如下。

Kronos使用splicing挂钩函数，在程序代码首添加一个无条件跳转指令，因为恶意代码是作为一个shellcode被加载而不是library，所以浏览器内置的安全策略不会阻止它。

InternetReadFile function hook in MicrosoftEdgeCP.exe

挂钩函数的处理程序

成功挂钩这些函数后木马可以向Web页面注入数据，它还可让Kronos来获取有关用户的信息，用户的凭据和银行帐户的余额，将用户重定向到钓鱼站点，或银行的合法页面，启用恶意软件找出用户的答复的机密问题，信用卡卡号，日期出生或电话号码。

对一个银行页面的注入

请注意，Kronos目前仅可以攻击32位Windows10的Edge，不过现在有能够在64位Windows10运行的银行木马。

在今年年初，一个Gozi银行木马的变种出现，它被设计来在64位Windows10上使用浏览器中间人攻击的手段来攻击Edge。这个木马将自己的代码注入RuntimeBroker.exe，一旦启动浏览器，它的代码就会注入浏览器的进程。

用于检查进程名来注入的函数的一部分

在某些方面Gozi的这个变种和Kronos一样，它们都挂钩创建和发送HTTP请求的函数。然而，它却替换IAT Poniters，以及函数地址。

检查进程名为每个浏览器配置合适的hook的函数的一部分

HttpSendRequestW hook（Gozi银行木马在MS Edge浏览器中的）

现在Windows Defender已经可以成功封锁当前版本的Kronos和Gozi。然而，新的恶意软件和广告软件将会继续出现，利用Edge实现自己的目的。

Ⅱ 基于虚拟化的安全

在企业版本的Windows10中，微软有了一种新的方法——使用Microsoft Hyper-V来提高安全性，一个应用硬件辅助虚拟化的技术。Virtualization Based Security （基于虚拟化的安全，下文均称VBS）使用一种白名单机制，仅允许受信任的应用程序启动，将最重要的服务以及数据和操作系统中的其他组件隔离。

VBS取决于平台和CPU功能，使用这项技术必须满足下列要求。

Windows10 Enterprise

UEFI固件2.3.1版本 安全启动支持

CPU支持Intel VT-x/AMD-V虚拟化功能

-64位结构

-CPU支持SLAT机制

SLAT（Second Level Address Translation）二级地址转换技术，主要用在Hyper-V中，帮助执行更多内存管理功能，减少在客户机物理机地址和实体机物理地址之间转换的系统资源浪费，减少了运行虚拟机时Hypervisor的CPU和虚拟机的内存占用。

Intel VT-d/AMD-Vi IOMMU

IOMMU指I/O Memory Management Unit，I/O内存管理单元

微软使用Hyper-V hypervisor作为虚拟化平台。虚拟机管理程序包含的代码越少，受到的攻击越少。在这一方面，Hyper-V安全性很高。与以往的Windows系统不同，虚拟机管理程序不是以内核驱动启动，而是在UEFI中在计算机启动的早期启动。

Hyper-V初始化过程

在VBS，虚拟机管理程序活动时，每个虚拟CPU会被分配一个VTL属性，目前使用两个属性，VTL1和VTL0，VTL1权限高于VTL0。

VTL，Virtual Trust Level ，虚拟信任水平。

VTL1（Secure World），VTL0（Normal World）。

安全内核模式（Ring0，VTL1）包含一个最小的内核（SK），一个代码完整模块（CI）和加密模块。单独用户模式（IUM，Ring3，VTL1）包含几个服务，称为Trustlets，和外部甚至这几个服务彼此都是分开的。在VTL0模式中，传统的内核，内核模式驱动程序，进程和服务工作根据前先前的规则运行。

图示两个环境

当虚拟机管理程序处于活动状态时，物理RAM页和它们的属性只能由安全隔离内核（SK）控制。它可以编辑页面属性，阻止/允许在特定页面的读写及执行代码。这可以防止不受信任的代码，受信程序中被恶意篡改的代码的执行，这让泄露受保护的数据更难。

在这种体系结构下，在系统中唯一管理系统中任何代码执行的组件是CI模块，Normal World的内核无法设置内核模式物理页的属性。

Credential Guard

凭据保护是VBS的主要功能之一。它使用隔离技术确保只有受信任的代码可以访问机密。这可以用来抵挡DMA攻击（直接内存访问攻击），以及pass-the-hash和pass-the-ticket攻击。

系统信息，凭据保护和HVCI。

我们已经测试了此项技术，尝试使用DMA获取机密数据。我们使用了Mimikatz和Inception hacker tools。这些攻击手段都没有成功。这些黑客工具对于凭据保护无能为力。

使用Inception tool的DMA的攻击。

Device Guard

设备保护是VBS的一部分，是AppLocker的后续。它控制着所有代码的启动和执行：可执行文件，动态链接库，内核模式驱动和脚本（比如PowerShell）。这基于系统管理员配置的代码完整性策略来识别程序是否受信任。

使用设备保护的主要困难是创建一个恰当的策略，有时甚至对有经验的系统管理员也是难事。一般配置过程如下所示：

在计算机上启用Windows10的VBS机制。

准备Windows系统的主映像。

安装所有需要的软件。

创建一个基于某些规则的代码完整性策略，将其设为审查模式一段时间，在这段时间里，仍然可以添加更改软件。

看CI事件的事件日志

执行任何必要的策略调整，比如签署未签名的软件。

整合原有的规则和在审查模式中的调整。

在代码完整性策略中关闭审查模式，使用“enforced mode”。

给最终用户分发准备好的策略。

代码完整性策略定义在用户模式（UMIC）和内核模式（KMIC）执行代码的条件。Windows内核本身的安全启动有安全启动技术提供。代码完整性策略需要维护和根据软件的要求更新。

为了不让程序任意存取，很多CPU架构都支持Kernel mode与User mode两种执行模式。当CPU运行于Kernel mode时，任务可以执行特权级指令，对任何I/O设备有所有的访问权，还能够访问任何虚拟地址和控制虚拟内存硬件；这种模式对应x86的ring0层，操作系统的核心部分，包括设备驱动程序都运行在该模式。当CPU运行于User Mode时，硬件防止特权指令的执行，并对内存和I/O空间的访问操作进行检查，如果运行的代码不能通过操作系统的某种门机制，就不能进入内核模式；这种模式对应于x86的ring3层，操作系统的用户接口部分以及所有的用户应用程序都运行在该级别。

除了完整的策略，还有其他对执行代码的限制。只有在证书验证后，物理内存也才会获得“可执行”的属性。而且，内核模式的页不能同时有可写和可执行两种属性。这可以在内核模式中防御大多数的漏洞利用攻击和hook。如果尝试修改内核模式页面具有“可读”和“可执行”属性的内容，这将引发异常。如果不进行处理，Windows 将停止工作并蓝屏。当虚拟机管理程序的所有安全选项都激活时，如安全启动，TPM，IOMMU和SLAT，无法启动未签名的驱动，应用程序，动态链接库，UEFI模块和一些脚本。根据设置，即使签名的代码也可以阻止执行。

当然，设备保护不完美。使用更多的保护要付出代价，使用过程中的“Performance”会降低，由于虚拟机监控程序的存在是不可避免的。创建，配置和维护策略的高度复杂性可看为这项技术的弱点。这些策略的选项分散在系统的各处，没有统一的管理面板控制。其结果是，犯错误很容易，反而导致降低了保护等级。

由于安全启动在这项技术中起关键作用，保护的等级很大程度上取决于UEFI 代码的质量，这个Microsoft无法控制，有第三方来编写。在User Mode下没有针对漏洞利用攻击的保护也是一个令人失望的地方。

Testing VBS

如果恶意代码在开启VBS的计算机上利用漏洞，必须提权至内核模式，才能攻击虚拟机管理程序。我们尝试这样操作，使用一个签名过的和可信的内核驱动。

内核模式渗透测试结果：

这里蓝屏意味着失败。

我们尝试过的攻击方式全部无效，基于CCR和MSR的攻击也未生效，都是以0xC0000096结束（意为“特权指令异常”）。

我们还在User Mode下进行了一些测试，试图规避enforced mode下的代码完整些策略，目的是为了启动未签名的程序和向受信任的进程里加载未经签名的动态链接库。我们不能直接这么做，但在Windows 10 preview release （10154）中发现了一个奇怪的错误。

错误原因在于，尽管设备保护检查应用程序，驱动和动态链接库是否签名，但它不会验证签名对于程序是否是有效配对的。也就是说，可以在受信任的应用程序中提取签名插入到不受信任的程序中，然后系统就会认为程序是受信任的。所以这样可以启动不受信任的程序和不受信任的动态链接库。

我们立即向Microsoft报告了这个问题，Windows 10 RTM （10240）不存在这个问题。

我们也发现了一个拒绝服务错误，这可能让一个汇编指令能是系统崩溃，或是虚拟机管理程序蓝屏。此错误的修补程序在Windows 10 TH2 （10586）。

虚拟机管理程序的蓝屏。

总的来说，Microsoft在安全机制方面做得不错，然而在以前的版本中，依然有利用固件来攻击的可能，另一方面，系统管理员必须专业水平很高才能正确配置。如果配置错误或是私有证书泄露，所有的保护将毫无用处。此外，针对User Mode没有漏洞利用保护。VBS仅在Windows10企业版中适用。

我们已经通知Microsoft所有在测试中系统所暴露出的漏洞。

Ⅲ Windows内置的反恶意程序保护

让我们来看下Windows内置的实时防护组件。对于没有安装第三方恶意程序保护软件的用户是默认开启的，它是最主要的Windows安全工具。

它的主要目的是防止恶意程序的安装和运行，它实时扫描文件和进程，通过使用一个定期更新的病毒数据库判断恶意程序。在大多数情况下，这种保护是足够的。

然而，如果你是一个积极的互联网使用者，经常有一些重要的操作，比如在线管理银行账户，就需要多层次地保护。最顶级的反恶意软件保护也会有时漏过检测最新未知的威胁。在这种情况下，只有多层保护才能阻止恶意程序进一步的破坏。

我们做了一些研究，发现了一些真实的例子来证明内置的保护可能不够。

Keystroke Interception（键盘记录）

一些银行木马截取用户输入在键盘上的信息来盗取银行账户。这种类型的木马的例子很多，如Qadars，Zbot和Cridex。许多反恶意软件解决方案，比如KIS，有一个组件专门检测和阻止应用程序截获击键顺序（即记录键盘输入的信息）的行为。在一些情况下，即使电脑已被感染，银行账户也不会被盗。

我们测试了内置保护对于防御键盘记录的能力，测试程序调用GetAsyncKeyState这个API。在Windows Defender开启的状态下，我们成功截取了PayPal账户的帐户名和密码。

截取PayPal账户凭据。

Unauthorized Web Camera Access（未经授权的网络摄像机访问）

在下一个测试中，我们尝试未经授权开启网络摄像机。在过去几年里，越来越多的黑客工具和木马使用这种方法。在众多网络犯罪实例中，Adwind包含秘密开启摄像头展开监控的功能。

Adwind是一个RAT（远程控制工具）。

打开网络摄像头追踪受害者可以获得很多信息，这可以非法赚钱，比如，威胁公布受害者的亲密视频除非付钱给勒索者。

一些恶意软件防护解决方案有控制程序访问摄像头的能力，在实际使用中，几乎没有合法的程序需要在用户不知情的情况下打开摄像头，所以在检测到这些操作时提示用户是一个方便又被广泛接受的策略。用户可以选择允许必须的程序访问摄像头的请求，也可以拒绝可疑程序访问它。

我们的测试程序使用了一个公开的library，叫做OpenCV（举个例子，Rover木马在使用它）。一个简单的Python脚本从网络摄像机中录下一段视频，以一个单独的窗口播放。即使Windows Defender在开启时，用户也会对应用程序使用摄像头录像一无所知，不会有任何提示。

用一个脚本开启网络摄像机录像。

Control of Drive-By Downloads

Windows用户面临的另一严峻的安全问题是漏洞利用程序的攻击，漏洞存在于各种程序中。我们测试了内置保护对于利用Adobe Flash Reader的CVE-2016-1019漏洞的反应（较新的漏洞）。

利用此漏洞的文件是使用ZLIB压缩算法的SWF文件。

flash漏洞利用攻击

这种形式下的文件被Windows Defender识别并隔离。

成功检测到打包的漏洞利用工具。

但是，如果该文件解压到原SWF，Windows Defender会忽略它。

此外，如果一个有漏洞的Adobe Flash Reader安装在系统中，且一个压缩文件（漏洞利用）从一个挂马网页下载到本地磁盘中从浏览器的context中执行（Drive-by attacks），可以发生感染，因为 Windows Defender并不包括本地下载控制组件。

成功下载一个漏洞利用工具，曾经检测过的。

此外，我们要提一个微软的组件，SmatScreen，基于信誉检测可以阻挡Drive-by攻击，但是有些情况，尤其是针对性较强的攻击，需要启发检测技术。

结论

如今，需要一个全面的方法来保护用户的系统，结合常规检测模块（基于签名的分析，行为分析等）和一些附加检测模块来检测网络犯罪分子的某些攻击手段。

我们简要地分析表明，在某些情况下，Windows10内置的保护不足以全面抵挡攻击。而在以前的Windows版本中，所有的攻击一般都由专用的安全产品解决。

对本号感兴趣的朋友可以请点击右上角的“关注”哦！

天鬼指示器-WA字符串

!WA:2!TZxEWrXv(9ZSdEXEm7UizaBaBJm2MY63Vaf6g5SyzncjnYiqIrJqajzv3Zm9mDdJ6PP7EKqkB2yK9AlFW6y5RGTXylBJXPGexYoS(CTxLnBQK4QY3AswVQs5DtkcsavLJQO2A3C4eNVFF9H6EoeJoWl4q)hsT6(96(9EF(8571B04zhfRfSY1x26RQ4EkoAXrh6Mpv4KQrfu9ZhzVrvtQOSe)jKgyaE1OLekzYe6skP5tPlMuTnfDPKYA(u7VTyX0e0dC3v9ehBb4XO8YrW73Esjz9Wn042c1yWrnEMnKmrs17XJhpEv5JW6D1b105v195xsws3x4y4V0e9nOUQu84cQARCTQMN(aJeviCQyXc1VIGAGgBT9M6Sv)64FeKpLkF5dQPiKirlr18DkTuHf6vqwVdS1s7F0UBO(oc1DhHQpyi)PWxsyLe89lOguMVhbnFbznnCab(e6I2DTDvbSRb7O9gBT1HtjBoe8DECcjOkZNyh4qdh97DynHeXyZtyrJGDoOqC2sI)ej5J2KFnPbewEWEsHlA(8JdWilhUvFbJKGxtJolSoFc8LrNMoS5QTXkKxVEB37gwFvH1sMsnIqyPEusQQhulc2bVHnwlfhX43ngnUGsrDSVu8QcL0uQejkPlrjDHruzJfA5kyC1KPumBEh4y6QgZ4CdC7AgrpzKEnMrxDVF0AKIQSMjE0N6Ch9PNy0tSUjE1tEMh65oZZE)t8kV(5o(7p5J(GN5vE3jo0XgnMkUa2HUkVoV3ZBG4nrxIEJH7OHGn242kpLu0rhyJLLquS8TfwyxdZll1dpH7vd(AckYVCszHXe41ONJGCCDXfLokIMul6MWwvnHijLJQni1g6bd3P)E4LKX(c3j8BUi4BcBcUl80fN5vcJ9lMuCFQ73ICUVFzI7fjNJqpqjdM7OsYXsQAmI8zsrBrgBT3IJ8I34q32isyJ7Gbb34cGf6dUkpWxfwu6iOoiAY(K7OpjfbUXS(tcje9t9Hd(AF91cF9HkoiU(ezV(rbtsLIvfOXUKC8UtItnE9KQf)nthxqwqvkshIj7Rn5tPX(vdMpqy5W1pSDVkVSQ2a8nGLKoLMq32xLdwkSmyfkRWQtL0UAY4QcAALChDqAIsHBWxAvKFZ(RTHi05N4Xo(ep5RCMJ8MtCFpgIPShOM1D5GRZNsr0LCn04GIcYAdSk4ghMUnBQXnSDhV6pQA4MWUsk7EfczOz2AYOchFbWnV3ZVxbbL6jrGEqAbxewnQzIkOXRtio(Al5EwouuAufrAbIYkhDOLPuSUW(17wtKhNB70al9OSc2fz)Waa7wZ8e4oh2(EdpXd89N4GV1PF7tOSehpLPmcDkJRoLgw56yxHGlIvePlPO6I(Rh)ZZB8YK2Vqu2fpqAdk)UmhsJXU)EsPPlfRFCIPMuhNuHWl6FBTTTgHIuXjg1MrynmILm37WMZczDLL0KQ0aLS9u8rjrvjHc5AYB9MsZUwFizTlvELb7Y8eJbqVsAsHtiWzoHDyiE426eTd3DO2A38P6A8V602ddYaXMmND7017KUlZ8l(OATLT14NKoEIK91KQW(sjihP)2x4gwF5vzmtPBmgssAoH56T4G0LOENoCkD9KYTHwCqdXJqxUvM2FzJsNBnnhoUvxzltS7znC8t)HiRfDWmjYgiHeLISxzK47LDNwLWZlI989ByWCOvc)oEGUxZTRa8m8hcdlcIarbHdOCBzrPu6wxQhHUtieNps)DhlrsCwaXXEicsqmpkLMVEeTF03IuKU1frzOiQk9GgN2toiTkMNeK6wuyVSzkKa6b0rnJShLsY3RONKr72q1KeuG(G9dQJzaW(BluO22kSpoLBoFD24V8aP2e0RhLBjFntrviIe5uWByrbP4I69d3smMYN5bJdwl65A5Vj3imJbmxzIWTV2WAOvPecJU5gRpuGTSTwAoqi0bhCBKBoynSFEhqPW6HabNsfmOLnurOwdFdUTVx3f2IVYsTEgKQBZsA8OqiQO)bsMShpqnJoqN1Rj3x77U3A3duUHFUZB4tZ2mbufuTsX40XYwkA9kiTkhSpsZ3puPx4U9PkjtElfedYNqrK3lCn4i2hCT(Gf7d87dAWhuVNHUnOrtFgFBVKtdOjoOzria6A4MrxdNeh9ftMUtJR4ref0mSYM2WbWwL0OvryfWkjZTOf5XOOCyMALIQTYGvvvf1u75XrAJ7hn32HrSpCOLEYLb5KaTeJVLDWElJWXUYlUYGvuEzBSCwtUjFWUy2LHDZSed)wOb4)FOby43(taBPmma87kcFB43d(old(99a3Rbd9aEGbfH7ZlC)EHVBrWdicp22HBPx4pGdECX0sYyiDYreyEWxlm8VWhCRnTWRL72wm3VWh3sxSnXbjlWWWt4MDS2Y1fK5grVpKo1Fm0rcNfDbEsJ3(tn75iWtlcpdrg2AWEfAl(wAFVBUxNKHZC)VXKp)F0zFTJoXJ94ezaEwo452UbSdpViC4PfSDJ0gnCXS26aYFXvcVe8cJzGZ1ZCV6aMzoZj8brstylxaj8Y5befHsUZCaIiGLfiIa7GCecEFMG40zEeEqNM(GHyw0GhcE4SnAbpIdJsWJIwIGdI2AQaT1aFpVmMsmIPyrcECXCZdGxLdo6uGF9EO1AdGhbucxDa8zCLfN1vquhrre(rG0eWhZaWnrBePr0fbBc2RzuXkQUhz5E8V1TlqapQJrLlI3i5ZGgAI51N0mOqxOUb9WTqhEb41DI0OCSQARU8QjunV6w6Qm424wfiCNpnlNtn7qRYgUreZbuJ4RfutaSbSroWCg3GPR4L5e)ryg9QSphW)Og(KcYCcysQKzKbKb9GIztgCI8zYkqIIfzyHmGarel9SWgISNeDYVRnxLGTE(CV3JFUt8Kt(MpLjcJylcYe8Eyl9msjM1Msme)UidUycUT0JG4XrgWrMh165XGD(06Io16ZAzOPn45Ou8Wzifvk2gSMY(lcwi(q4fIC1mAhcBS6AJVVkeQUgc6qHNtlSgsZf6BO7atCqpbg7hY)wOpL))rL0Oe(dvaHP1FAxrAJakIMkLK)NGzGukljcg3FYEOw0PsumGbyfNYDoeOYklldh1cNjkbbXiLGygOHHQ3qfBOCIxqueBIb1HDaDsDy7Soee6acXb7KY8Q1rnCPeuGpA)qxCoSyOSM8pfSdKuzT5VrUdbE2Qy8t5pGMjkzLmwlClnzgoObB72z)KOJ(g0kpKvt8U0Us(ZlSE)KDObTYacugzQ0YU)fJkeLBn)tLPcQvzv5SvMPr(Wq9F2cidlvTJ4DvRSCTL3RQz2D(BTXMczZCVHZDOJn5F4roZlFmkF6h61p9hCOjFMtEUN5TGRQEl(RPO5U9nQJxjA4D0mti10OYQdBef)q3b8Min2S7)LKP6)udwjCspW3h5bVTnXYrGgh12LtgmldpnKJNkQDdBSqjwW76MobVhhzg6hIg5)a3W5AZcona4FadhHpeXo4JM9goWfh0W)FMx49fHFeIqO9JFm8x4ajU3JmX7E0ZEW)KjFJ3Yfsu)QTqcetQz0MAVP(kVPW12wBAWB1p8xzS0pgYDO1E4VoxwZDTiFx4A2KS1ml9jU2rRtow7WLCA1Kw2X18UmxmTxUNE8PYnwE1vnf(m0suXeSf5L1vw(5o09tgkpXrN4qhBD2wnhusxOhwryEHppCFc8kjLlpzSyWks3cEJsACFPKuueIYsvtZSEoSX8wP3pLPE30tOJej15g06SBL1CJNg3O05MJcUWgpd41T7PrLJkYpD(ud8y4mD5gTrosYEcZJwcTc0zfJ0GDL4gKAcvCwoghZBoJXzOLrbS8TqIq3bnSYLDyQoIDHcq1rWjyyhuyjy0jQGgl6eJqs1lDw5(eZf(bq3NNYU0z7vML96ASTILJeCgzQwsKb3b0mhDP(SCUDPQgSX638UkPCI5Fyt3O9JK)AQmwSDjYNOw5ozUr9KNaBPmxxDgHZS(mIN9iUJNf(BYvSShfs7b(5IgMx(hy37F0G5HCd4t5M1MHCZrMd5UwrHfkKVlgjIgPVQAPZM7PM(fBWoVeg5EDt8AF4K37bSZcTIluwO)g2rH(zliFgUiaeLriGqGhHbe4n(QmwIlc(zSLDdq0OSYRjhLvMznPhm)8siReLc)uohg9y0aedrGTRmW2LNnnaBfoyObY8alGBML8RyEs(DAZgYmZ3tGVzhgx(ES0AWeASZ8zeJmFyHkCqwsrPkLm3yAYI4CM1lXM2XyAklLzNLQQJl7ktriDtfryFEpVyd(35E13yIN4aw5fxHzEXb1BtR5EkT5k7DJtFEXcUnF4k6xgn86G0x9HVoBIiY4SjHMj(UcLBihSpYHwPeXPtN0oIhtmwg9ZnX7IV5hUzwA4IZM0WhYknC4eUs6gZ4odQh8hBvZLmzCZmRCzLKTI89STQQwSNk6mAgCfJyUiwYfTmSVDOrVmNsUSUrELOOX(Xiz6f(CgdGbG)lma8tTPgTocfXs9j6JVFngfdPBtfE1Yz9EuJ4uy12LZIto(TYANl7JmogXB)u6v9tCB)JgcJWiNiDHE1FP3jOvsnTejPC4ZEWh6Sp9HM9yoA3ajoiJdjsU5ygH8AXUm8hwZOXBSRAQyhDwwZsHj6gYtZY1izrArtT7T5YV4BVyp4s)NOkjZ2QCCE7xLxkkUsa)ko4NZbl9RWWneZw1xHbzisFd(ymMEqRs8Xfyb2EEhxG2Rlr34AXguhhbn52DRDJZk5cRujMINrubZqTYk5ILhujzFcQRP6nCk2j2738AURnX2ah2vXNAW2PtyBZm7suf7)A4SmTDJOR4GD(aStjHar8j(lt3z4V3Omv2vWYUULJ44wXmk6bBHrfFlS8ggM2Cd2NhJvg(0V)rM4vEnhpRX9SaUX94zLJD63(Gt(wh40VZJmXd)CMdJIZX78DY370yAq6wwn4N2BF8P92u9zkBJ2LLZkDfI0VdgH(Um8WgwbDzjOJzlHmR9s086CD)X9Cvb1e53RaDRS9nNZuFc3rikW(ck3Na19V(DyhbQ7h9K0XtLRCH03eKA7KNc07XSyBdSZfco1fi9h4FkJSEAWNP7fuqJk3PcbzCpxTz5)WCwmc8iqRc9vwOg7k2(AHe6MwFidFgrFySlmzRZjpeMYBJqqDkMje8xsdYFLPuNjRH)DrsM)FKL61SwDo0UKe9gmd6nhQxMS0u(InZT6LEmMY3mct()evUW)fkwHpJ67)nRz)pKWe(8CkgnDezPfntRplXOP1gxPNZeJ4nSKzJ75RKzPOzIQ80xxYIQQOIQRA(s3z9Uh3ZcDROlG6dq8N5pbcRybmfI(MMv(wDiqYmEFhAeM6iJO79quBNE0SIftU6nR372llCL7XE3Sh0WYW6kNenMXH5mNXSmpH2BqlqJ75RMHzjRRVOcyxpYJG7A()WcUlSQAQR6L1nQ9ZsnNJDhA(sveOU3DL0XQcu3F)ZYo8o)Ok4kevro9zuOQID32o34E6QTq7VHDyxw4Lyklo3HFHjEUrM85p(xSYdthvttSNMAfxYI8gYjjviapBTIv9KDiwyQKm2DX5AOLZCTY0fPOZWbDQvMTH19Yt7Th3JVlCqBMyEUcwJW8cpsT5x52mpknX8gLwH4ecZHGhJ(NZzWAKLLCuWiLIZuIH(GmQBKDzN3t0W8LVNu7C3b6kZYoVqwgAfzRuw9vukZZkLtsvFGnbol7I)uoy8LPCDSp3EcA6nLu1QoBCwE3Oz2m0VZfpL0AUDT5tLuPZrL0MMHkPX98nkiz01NLmAYh6rM4vFgNAPnr1HtSYycjkRLwArJPL(yVzlMYQszUka78v8zZ4YzC5r8z5pcStAu0Ah1yKPLg3tXZfLtEJyB(L47iITsNv5XSPzweBUj(U30S5CKwwH8vzy1TlvDFBOM(BAAesMfO2AZ02KRcuBiEO9q7JDU7N5pITR1ZC39qblEo504VJ0gu3YT(SG1nxyFloZyj)LEl7Y9TJP(mVM3B9o5)whpV3AAQkWfp)qbBUT)T3)afyLfEJLWocu3hX(Dr50vuZqkHlTk92OMANMBBD1Kzn46QIAdVXTi3CTsrNMAWLd5dRMazOAMvUck4scCYS9T5sgnFQAMJ55NDD5COAY7TEN8FRJxifoGeqfUFOMBBEK1Z8dXO96nFPs90A1Ff6BDlXJLiyZwkH0tPeQE9v8fzvdUIc6xVkilTXfQ2BhFMu7TRVqRi93IDeOUXkMDC5IckAhYb6T0612XwcNtfu5xrbDzPcAg5OzMQGEPlg(G(N)u64NfOUF4JZoUCrbvzWWADgwu1VySCQGk7lyfeosVIc6lAFqZ8pnc5ksU5fkXCXrgk(kIoWibthKo6W7LwYWPkhrodhSSeLoqfnl1s06ZHuSQ8go4cT(44IMXUIFOF95hAM)rp4Ir(qbQ7hCZ0XnfOU)w2XpX7Ll(I8x9U3CdHtu2oRz35uaCLO5(YMkAMgY2CpNOcwf9NVm6y5bQ7tEA2XLnQO9Dpn23anSL47wlvovrFHgrNXMcvXv2tO5)9ek7Dx9cVJqutPVsaC9V3)L87iexwFTF4S(Zg74tHwd6ls7iuJ9KQ1b0t2slTVv7DeAPMQo37R6uFdFmDBhurSDy9QE(89HCBU(Xryg)HC7lbFCeMDBI6LcsMz(NEaUS(Ixi)sMC6TX922mVS9w5yJFYuJyULPMBbK13lkvQeAGgQpW(IQvQ5))xz)TWW0web3(C(6ZlrWvGFGEUYEcvOX9L5xbjFCM66P(kLQQkRPQnM)Bt)Nsu7LELNyMVtvLoB)mU(0S)JBKf6L(pUjBxJO42WyqE)4UA))HNP)sMtU(BTZKn2A4a6vxJTaEft(EVKX3DktESxAYd)HR70V9bp7h8bt8DFvRamnI20omtZDUTbkG1I79VBN)V)

深入剖析CVE-2021-40444-Cabless利用链

背景

CVE-2021-40444为微软Mhtml远程命令执行漏洞，攻击者可通过传播Microsoft Office文档，诱导目标点击文档从而在目标机器上执行任意代码。该漏洞最初的利用思路是使用下载cab并释放、加载inf文件的形式执行恶意代码。独立安全研究员Eduardo B.在github公开了一种新的“无CAB”的漏洞利用方法及其POC。公众号之前发布的研判文章中已对在野利用中出现的新的Cabless利用链以及RAR文件隐藏载荷的巧妙方法进行了分析。本篇将进一步探究该利用链的技术本质，并在复现攻击场景的前提下尝试对利用链进行改进。

基于Url Scheme的Cabless利用链

与基于cab的攻击方式一样，新攻击链依然需要在Office文档中插入恶意htmlfile OLE对象，当目标用户点击文档后会请求访问远程html页面，而html页面中通过ActiveX控件调用".wsf:../" URL Scheme链接，最终调用wcript.exe执行RAR中嵌入的wsf脚本。

'.wsf:../../../Downloads/?.wsf'

URL Scheme也叫URL protocol，它的作用是通过链接启动对应的本地程序，格式为[scheme]://[host]/[path]?[query]。文件后缀名可同样用作scheme，调用相关文件类型绑定的程序。’?[query]’的存在则可利用URL Scheme与程序在处理路径时不同的行为，达到忽略真实后缀名，绕过扩展名校验的目的。在之前的攻击链中曾使用”.cpl”链接调用系统rundll32.exe程序将inf文件作为cpl文件加载执行。

目前公开的配合RAR的Cabless利用链的POC有两个利用条件，一是猜测到WINRAR的存储位置，默认其位于用户目录的Downloads文件夹下，否则无法获取wsf脚本位置；二是明确wscript.exe运行的当前路径（例如Documents目录），否则无法构造正确的路径。下面将从不同的利用场景考虑，思考更灵活的URL Scheme构造方式。

基于不同利用场景的利用链改进

配合RAR的Cabless利用链在实际执行时有两种可能，用户直接在WinRAR中打开DOCX文件，以及先解压再打开，对这两条攻击路径进行分别的探究。

直接在WINRAR中打开DOCX文件

当用户直接在WINRAR中打开压缩包中的DOCX文件时的进程树如下：

WinRAR的当前路径为RAR文件所在文件夹。

Word的当前路径为C:UsersuserDocuments，RAR中的DOCX文件被释放到%TEMP%临时文件夹中。

wscript.exe被触发执行后的当前路径为WinRAR的路径（也就是压缩包所在的文件夹）。

".wsf:"被用于Url Scheme唤起wscript.exe，而在被唤起后又被当作普通目录名去解析。’.wsf:’后的两个’.’可替换为其他内容，不影响执行，但是如果去掉这两个字符会在参数传递给wscript.exe时吞掉一个“../”导致找不到文件。这是因为wscript.exe解析路径的时候会将“.wsf:aa”整体当作一个host看待，后面拼接“../”就抵消了这层目录关系，相当于当前目录。

基于以上测试可知，当DOCX文件在WinRAR中直接执行时虽然DOCX文件释放于临时目录，但wscript.exe的当前目录即是RAR文件所在的目录。由此我们可以构造此情况下100%可用的URL Scheme（直接从当前路径读取RAR文件）：

'.wsf:aa/../exp.rar1?.wsf'

先解压DOCX文件再打开

这种情况其实更复杂，也是公开的POC针对的场景，对应进程树：

直接点击解压后的DOCX文件打开时，Word的当前路径为DOCX文件所在路径，wscript.exe的路径也将保持一致。

值得注意的是，在一些情况下Word会将当前路径设置为C:UsersDocument，这可能是公开POC中构造路径的依据。但无论当前路径是什么，攻击者都必须成功获取(猜测)到RAR所在的文件夹。

漏洞修复

微软在9月的补丁中已将MHTML中使用URL Scheme的问题修复，在ieframe.dll中加入了一个新的校验函数IsValidSchemeName：

该函数将对URL Scheme进行校验，诸如”.cpl”、“.wsf”这种以文件扩展名启动应用程序的方式由于以字符“.”开头无法通过该校验函数的判断。

总结

本文主要分析了CVE-2021-40444的Cabless利用链中存在的路径问题以及对之前技术研判内容进行补充。通过分析CVE-2021-40444新利用链，可以看到该漏洞的根本原因是Office文档可以通过MHTML协议请求访问远程HTML页面从而执行JavaScript代码，并最终通过Url Scheme启动本地应用程序执行投递的恶意代码，而中间投递恶意代码的方式是可以替换的。同时也给了作为初学者的笔者很多启发，在分析漏洞时需加入对根本问题的思考：在攻击链中哪些部分是必不可少的，哪些是可以替换的。必不可少的部分作为漏洞根本问题要更深入地分析，而可以替换的部分要尝试去挖掘可替换的新利用链。而对于防守方，把握漏洞本质与漏洞利用必经之路，方能以不变应万变彻底控制各种漏洞利用变体。

了解更多

了解讨论网络安全和领取网络安全的学习资料“关注”并私信“资料”免费领取

企业IT部王森：腾讯企业终端安全管理最佳实践

8月29日，2018网络安全分析与情报大会在北京新云南皇冠假日酒店正式开幕，本次大会由国内威胁情报领军企业微步在线主办，十数位来自政府、央企、金融、互联网等一线公司的安全专家将对威胁情报的落地应用进行多点发散的深度剖析，来自国内外顶级安全公司的学者、研究员也将根据全球威胁态势，结合自身业务分享最新溯源对象和研究成果，拓宽网络威胁分析的时间空间跨度，与参会者共同探讨威胁情报应用落地的典型行业、场景和解决方案。

腾讯企业IT部安全运营中心信息安全组组长、高级工程师王森出席本次大会，并在会上发表《腾讯企业终端安全管理最佳实践》的主题演讲，以下为王森演讲全文：

今天我的分享主要有三个内容：腾讯这样一个体量的互联网企业日常面临的安全风险和挑战都有哪些，在座的各位专家是否也有共鸣。腾讯经过十几年的安全建设，应对这些挑战的时候实践的理念是什么，这些理念和思路在有些企业没有办法快速落地，腾讯通过自己的技术积累有什么成熟的产品可以输出给行业帮助到大家。

这里列出了腾讯内网的三大安全挑战：

首先是钓鱼邮件，2016年一直到今年，整个行业面临的钓鱼邮件态势应该是差不多的，非常严重的就是勒索软件，其实勒索软件的鼻祖级家族：locky，对腾讯的攻击是最严重的，基本上就是不计成本、非常蛮力的方式，一天当中峰值收到locky的攻击邮件可以达到几十万次，而且一天可以完成多次变种，doc变成js等等。另一种是高级后门，我们同样也会收到这种钓鱼，这种攻击基本上是小范围点到点的，比如Adwind家族，还有Formbook是一个外国的木马家族，其实它也是紧跟着最新的安全对抗技术，比如去年Office DDE和OLE Link漏洞出来后，Formbook马上会用最新的漏洞投送。帐号钓鱼也有很多，比如模拟高管对敏感岗位的钓鱼，一个钓鱼邮件内容可能会模拟pony说“帮我看一看这个帐号怎么回事”，点击进去的话就是让你输入帐号和密码。

再就是军工木马，行业当中有些比较高级的后门和所谓的0Day都是掌握在职业黑客手里，但16年以来，HackingTeam、方程式组织等职业黑客团队的黑客工具在互联网被公开以后，这种军工木马平民化的趋势也是越来越严峻，黑客团队又会针对这种软件供应链展开攻击。比如Xshell后门，它是采用DNS隧道激活和远控，同时是隐藏在Xshell的一个合法DLL模块中，可以想像一下，如果一个企业开发或者运维使用这样被植入过后门的软件去登录服务器运维的话，它的威胁是非常严峻的。我们也有遭遇到一个中国的职业黑客团队，采用的通讯方式也是类似于DNS隧道，但利用偷盗来的合法数字签名，同时又采用全内存化的运作方式，白加黑启动，隐蔽性也非常强，这是军工木马的攻击态势。

广谱木马，我们一年大概会发现五千多个广普木马，比较常见的有广告和蠕虫，最近两年比较多的是挖矿。

除了应对上面的威胁，腾讯的终端管理还要考虑一些其它的内容。比如我们的业务腾讯云、微信支付、游戏等等，要在国内或者海外进行业务上线推广的时候要符合当地的行业法规要求，所以我们的终端管理和内网安全就要针对当地的法律法规来做一些定制化，比如国内的等级保护，国外的PCI以及欧盟新推出的GPDR。如果我们不做这些事情会怎么样呢？一旦内网发生了数据泄露，不仅仅是用户信心丢失，监管层面也会有天价罚款，比如GDPR最多会罚到企业一年百分之四的营收额度。

另外，企业的管理层，比如CIO、CSO这种级别可能会想知道内网有多少终端，有多少windows、多少mac，都是谁在使用，有没有被黑客入侵等等，这种摸底的需求也是我们需要去支持的。

要应对前面讲的风险挑战和管理要求，我们认为有三点是最重要的：首先是高可见，只有对安全数据的高可见才能通过数据掌握全网。发生安全事件的时候一定要有急速处置的能力，第一时间将风险隔离出去。通过云管云控给用户一个比较轻量的客户端，同时又可以灵活地部署。

我们只有通过高可见，才能发现黑客入侵内网整个过程的痕迹。比如黑客入侵过程当中会在我们的出口和终端还有网络、服务器上面留下痕迹。比如利用钓鱼软件或者网站投毒的时候会在网关留下恶意代码痕迹，员工在终端上面打开恶意文件，触发shellcode执行，也会在终端留下一些痕迹，然后shellcode去云端拉取后门，后门通过HTTP/DNS/ICMP等隧道的方式进行远控，也会在网络上面留下痕迹，然后通过拿下的PC又进行层层的内部渗透，通过扫描入侵关键终端和服务器，比如渗透AD、OA系统等等，也会在服务器上面留下痕迹。

要想发现这些痕迹必须要有高可见的能力，具体来说高可见包括两个维度：首先是数据的广度，就是对数据安全分析的种类和维度够不够广。腾讯内网每天搜集的安全数据大概是四百五十亿左右，包括两百多个数据维度，比如我们的应用帐号、互联网出口终端。其次是数据的深度，比如刚才说的中国的职业黑客使用的这种木马是没有文件落地的，就是全内存运作，这个时候如果检测还是停留在文件级别是没有办法发现它的，需要把我们的检测下沉到API，看一看内存当中怎么进行系统调用的。

比如Xshell后门，网络层面采用的是DNS的隧道通信，一般企业对HTTP、TCP都会监控得比较好，但基本上认为DNS udp53的通讯请求还是合法的访问，没有这方面的监控规则，所以黑客利用这种工具和我们对抗的时候，我们是没有办法发现它的。

再如Powershell后门在13年被Fireeye曝光以后，这种后门目前非常流行，越来越被黑客青睐，因为它的能力非常强大，同时又是Windows的合法组件，我们的杀毒软件没有办法通过签名、文件检查这种方式识别，所以我们可能要看Powershell执行的日志和函数，要看它调用的系统函数有哪些。

有了这些数据的深度和广度分析，我们需要通过一种可视化的能力把风险推送给安全人员，安全人员可以知道出口出现了什么攻击事件，有多少扫描在内网发生，然后把这种风险分成高中低的级别有效地处置。可视化背后是需要一系列强大的后台支撑，比如大数据计算的能力、机器学习的能力等等。可视化还可以帮助我们安全决策者们第一时间知道我们面临的主要挑战都有哪些，是否需要追加资源辅助进行安全决策。

具体到终端层面，做到什么程度才算是高可见能力达到了呢？我们就拿一个APT木马入侵的过程来分析，一般分为三个步骤：首先是要进来撬门，然后通过完整的后门站稳脚跟，最后就是窃密。进来的时候无非使用两种手段：一种就是通过应用和系统的漏洞，比如常见的IE的UAF漏洞，或者系统的远程代码执行漏洞，另一种可能会利用漏洞的触发技术，比如堆喷或者ROP等，结合这两种技术可以达到执行黑客指定的shellcode执行。其实，漏洞攻击时内存里面是有痕迹可寻的，比如堆喷可能会导致内存空间急剧增长。行业当中已经有很多成熟的工具帮助我们应对这种漏洞利用的攻击，比如微软的EMET、最新的Windows10专业版集成了exploit Guard组件，加上企业及时打补丁，百分之九十的漏洞攻击在这个阶段是可以被杜绝的。

到了第二个阶段，执行shellcode后，shellcode只是一个敲门砖，执行后无非为了让终端感染一个完整的后门木马，常见的方式有2种，1通过互联网下载一个完整木马，比如通过powershell WebClient拉取一个远端木马下载，2直接释放一个小马、比如伪装成txt的一个dll或者exe，这个dll或者exe被拉起来后，会进行explorer等注入、提权、进一步下载更多攻击模块等，变成一个完整后门。这个过程，完全在内存中进行，我们就需要监控Powershell的执行、DLL拉起、注入行为、文件释放等API行为。

第三个阶段，后门窃密，一个完整后门，会具备多种窃密能力，一个后门具备密码、剪贴板、cookie、键盘等多类窃密能力，我们统计过，大约需要40-60个底层API才能完整的监控常见的窃密行为。

木马会有多种不同组合技巧来进行漏洞利用和提权驻留，一旦完成，它肯定会原形毕露做坏事，就是进行窃密，所以窃密监控是非常重要的。

举个窃密的例子：行业非常流行一款企黑客工具，mimikatz，可以在终端窃取多种类型的票据，比如密码、ntlmhash、Kerberos、AESkey等等，甚至可以通过这些窃取的票据，直接入侵AD，获取域控权限，我们看一个典型的PTH攻击，在API层面的表现：

1、提权：需要获取系统权限，或者精确说需要一个debug权限，才可以对核心系统进程进行访问

2、获取凭据：通过以高权限的方式访问lsass进程，用户的票据存在这个进程的内存空间，调用系统解密函数，可以窃取本机和域上的用户票据，票据就是访问各种资源的凭据

3、伪造身份：通过获取的ntlmhash、AES key等票据，可以进行伪造身份登录，比如伪造成pc管理员甚至域控管理员登录，然后可以直接入侵AD

如果我们要监控这种pth窃密行为，就需要监控sedebugprivilege的提权行为，高权限访问lsass进程的行为，以及模拟用户登录的行为。

话说回来，正常的进程也会有这种窃密的行为，IE浏览器也会监控用户的键盘输入，包括用户安全软件也会注入系统进程，应该怎么办呢？需要降低误报，我们的做法就是类似于评分模型。

我们会实时监控一个程序的行为，累积一定的信用评分，在一个程序实施了多个高危操作后，拉响警报。比如一个进程可以有网路访问，也可以在特定情况下获取高权限，甚至来获取键盘记录，但只要他又做了明文密码盗取，这个信用评分立即达到报警阀值，标识成恶意程序。综合这些来看可以降低误报，同时还要考虑父进程、子进程，把整个进程树一起串起来进行评分，基本上可以把误报降到最低，分析维度也是以天、月这样的跨度。

通过上面的分析，这样就比较自然的可以得出一个分层、分时的检测体系：

1、基于已知特征的、单维度的检测：比如hash、pe、证书、c2、url等，这些检测引擎可以有多个来源，比如腾讯自有的电脑管家、业界的多引擎、管家的TAV、包括情报厂商提供的IOC，此类检测通过单一维度就可以报警，可以发现绝大多数的广谱木马，比如流行的挖矿、勒索病毒等；黑客的绕过成本很低，随意编译一行代码就搞定了，所以对于一些高端入侵，这种情况很难对抗；

2、基于行为特征，多维度的检测：分析多个维度的数据和行为，综合做一个评分报警。比如对读写敏感位置的注册表和文件、加载异常DLL、窃密API、异常的内存行为等进行监控，可以发现绕过杀软的一些高级样本，变种后门，比如我们内网会发现一些隐藏很深的挖矿后门（以插件形式存在），甚至一些黑客工具比如前面说的mimikatz等；

3、最后是基于大数据分析的上下文、时间窗的行为评分：这部分对潜伏很久、动作很小的军工木马比较有效，这些木马不是落地就进行各种破坏、敏感操作，而是动静很小，甚至不做操作，只是搜集上报信息，我们遇到过进入内网潜伏一周后，才触发执行远控上线，而且是通过释放多个作恶文件来进行，所以需要关联家族、父子关系等才可以揪住。

针对情报我们是怎么看的？我们认为情报可以帮助企业加速应对行业当中出现的新型病毒布防速度和能力，比如我们所在的行业，如果黑客拿了一个新型的木马病毒攻击同行，这个时候情报供应商监控到了以后可以通过情报共享的方式同步给我们，内网再通过一系列的联动下发给终端的监控，或者下放到网络和出口防火墙，直接提前布防，如果黑客再拿同样工具攻击我们，我们已经具备了监控和防御的能力。

我们认为一个好的情报是有三个方面的特性：情报要是比较开放的，因为腾讯经过这么多年的建设，形成了以自研产品为主的安防体系，如果情报还是一个黑盒产品没有办法和腾讯的安防体系有效对接，进行工程化和自动化融合的话，我们就用不了。我们认为情报应该是比较高效的，给到腾讯的情报应该是在十五分钟到三十分钟反映出来这个行业最新的病毒和木马，如果超过这个时间的话就没有多大价值了，因为腾讯往往是新型病毒木马攻击的第一梯队。我们认为情报的质量非常重要，情报可以有效反映比较高的威胁，不能有太多的误报，我们会有情报的评测库，这里面包括了最新的APT家族，还有一些最新的漏洞利用工具，可以说是少数人才有的库，如果情报对这个库的检出率比较高，我们可能会认为它的质量还不错。

有了情报，我们还需要依靠一个强有力的运营来保障。打个比方，一个平民拿着一把装配精良的狙击枪是没有办法打出职业军人那样百步穿杨、千里之外取敌人性命的效果，关键就是看这把狙击枪怎么用好。

比如出现了一个沦陷指标IOC的报警，我们的团队首先找到报警的机器负责人问是不是他做的，如果确定是他做的肯定是误报，因为腾讯内部有很多安全人员在做分析，同时会有一些安全类的文章提到类似的样本，这些都会触发情报的报警。我们要排除这部分误报，然后就要分析访问对应的进程，看里面是不是有些恶意DLL的挂载，是否有shellcode等，只有做到这样的分析我们才能定性，这个IOC指标的报警到底是误报还是入侵。

极速处置，大家看到我这里列的处置时间比较紧，5、15、30分钟，因为我们遇到职业黑客可以在三十分钟内把一台PC所有的敏感信息拿到，包括密码、内网IP，可以在一百二十分钟内通过拿到的信息对多台PC和服务器入侵，然后把服务器的信息打包出去。经过这么多年的建设，腾讯可以做到五分钟以内把全网的安全数据上报，十五分钟以内通过大数据的分析和海量的专家规则把风险识别出来，三十分钟以内，通过各种平台工具让安全人员把风险第一时间隔离，这也为后面的一两天争取更多的时间，可以分析黑客是怎么进来的，偷了什么东西，我们的对手是谁等等。

我们还有一个比较高的要求，就是对内网终端有一个比较高的覆盖率和策略执行率，腾讯内网有十万台的终端，百分之一的策略没有覆盖到的话意味着一千台机器都是监控盲点，我们这两年的工作重点就是提升零点一个百分点，这样才能跟黑客对抗的过程当中做到全面的普查和清理。

通过云管云控的方式实现轻量级的客户端，简单来说客户端只做两个事情：一个是数据上报，一个是云端的策略执行，这跟传统的安全客户端不太一样，传统安全客户端可能是本地的安全检查执行完了才会上报。

所以，我们的客户端就比较轻比较快，可以做到三秒钟以内让我们的机器从外面接入进来，运行的过程当中只占CPU的百分之一，所以我们的员工是感觉不到终端上有这样的客户端在运行。

另一个是把计算量比较大、数据量比较大的胖的DATA放到私有云进行深度检测和态势感知，然后把数据量和计算量比较小的DATA放在公有云，这样可以实现灵活的架构部署，同时也照顾了用户体验。

腾讯通过大概十五年的安全建设经验沉淀出了比较重要的四款产品：

1、iOA，腾讯内网的PC上面都安装了IOA，它可以支持Windows和Mac，支持终端的防黑加固和APT入侵检测。同时可以和杀毒软件管家进行有效联动，当然也可以跟其他的杀软联动；iOA也是国内首家自研支持MAC入域、安全加固和入侵检测的客户端，可以比较好地满足企业员工的自带Mac设备办公的需求。

2、我们还有一款MDM的产品ITlogin，它是以SDK的形式嵌入到移动办公APP当中，它不需要安装高权限的证书，所以企业的管理者不必担心员工有这种隐私的顾虑，每天通过ITlogin登录的设备有十五万台，它除了可以进行统一的权限验证外，还可以对设备进行远程管理，比如设备丢了以后可以把上面的企业数据远程抹掉，同时回收用户的登录权限，保护企业数据不丢失。

3、第三款是企业云盘，为了公司资料的安全，我们推出企业云盘，即满足员工云存储的需求，也可以满足员工在职场内、外，在PC和移动端进行便利获取云端工作文件的需求。

4、在腾讯内部有一个具备丰富安全大数据的云端，叫TSOC。它收集企业终端、内部网络、应用，以及行为数据，数据进到TSOC以后，里面有对抗模式、专家规则、机器学习，发现问题和风险。通过态势感知将我们的风险可视化，第一时间给到企业安全人员去收敛风险，帮助企业高层管理者对安全风险进行决策。

我们认为腾讯这4款产品对腾讯的企业安全，有非常重要的意义。