rtf如何打开——RTF用什么打开!

在恶意软件分析过程中，经常可以看到攻击者以创新的方式使用功能传输，混淆恶意软件。

最近我们发现，利用RTF临时文件作为一种传递方法来压缩和删除恶意软件的样本数量有所增加。所以，本文中我们就分析一款利用RTF文件作为传输向量的恶意软件。

0×01 攻击过程

这种攻击使用下面的过程在一个系统中删除并执行payload。

图1 恶意软件攻击过程

1、用户打开Office文档并启用宏。

2、宏将活动文档保存为一个RTF文件。

3、宏静默地打开RTF文档。

4、在打开RTF文档时，将嵌入的对象删除为临时文件。

5、宏执行被删除的文件。

为了更好地理解这个传递方法是如何工作的，我们需要看看二进制文件在RTF文档中是如何压缩的，以及处理这些嵌入的对象时的默认行为。

当打开一个包含内嵌对象(从一个文件中插入的对象)的RTF格式文档时，这些对象就会被提取到用户的临时目录中，如果用户在文档中单击了对象，那么对象就会在这里以默认的处理程序启动。一旦文档关闭，就会通过将它们从用户临时目录中删除而清理掉文件。所以，在文档打开期间，系统中的其他进程都能够访问这些文件。

当一个对象被嵌入到一个文档中时，它将使用Packager对象服务器，OLE1中的一个遗留实现。不幸的是，Packager格式并未以文档形式发布，且微软开放规范中也未包含它的信息。

对象存储在一个文档中的内嵌对象(objemb)部分。头字段定义了对象服务器、大小以及其他有关底层内嵌数据的元数据。

图2 Object头

关于头格式的更多信息可以在MS-OLEDS—2.2.4节ObjectHeader中查看。

0×02 理解OLE1 Packager格式

通过分析大量样本，我们已经能够理解Packager格式的大部分内容，以及它与文档中内嵌对象的联系。下表中列出了遗留Packager数据格式，并可用作解析包数据流的一个指导。

图3 OLE1 Packager格式

除了嵌入的二进制内容，格式中还包括内嵌对象的元数据，这在DFIR中是很有用的。

1、默认情况下，标签值将包含OrgPath中使用的文件名和ObjFile。如果这个值有所不同，表明标签被篡改了。

2、OrgPath将包括内嵌二进制文件的原始路径。

3、ObjFile将包括编写系统% localappdata %的路径，它将包括用户名C:Users …

为了帮助分析可疑的包数据流，我们编写了一个python工具psparser，它会处理数据格式并将输出元数据，并选择性地提取嵌入的对象。使用该工具能够有助于分析最近发现的钓鱼活动中的恶意RTF文件，我们可以看到它与嵌入对象元数据之间具有很多潜在的相似性。

图4 样本分析

使用嵌入的元数据能够给我们一些主要的指标，我们可以使用这些指标来进一步寻找相关的样本进行分析。

0×03 文档转换

为了完成这个传递方法，攻击者以一个RTF文档开始，并嵌入一个恶意可执行文件，然后将该文档转换成一个Word文件(.doc)。一旦在Word中，攻击者增加所需的宏调用来保存、打开和执行压缩在源文档中的payload。

图5 恶意宏

图5展示了利用这种传递向量的恶意宏的一个示例。宏使用函数SaveAs来保存活动的文档，并以格式(wdFormatRTF)和CreateObject打开Word的一个新实例，而该Word静默地打开了文档。一旦RTF文档打开后，宏会执行被提取到用户临时目录的payload。

虽然一旦Word实例被关闭，可执行文件就会被删除，但是宏写入临时目录的RTF文件仍旧存在，并能够在分流或响应活动中用作主机指标。对宏的检查可以快速确认一旦payload被执行，RTF文件是否也被删除。

0×04 RTF到Doc以及反向转换

当Word打开时，虽然默认行为有所不同，嵌入对象不再被提取到临时目录中，但是分析嵌入的Ole10Native流显示，当文件被保存到新的格式时并未被修改。

当恶意宏将文档保存回RTF格式时，整个文档增加了新的字段和格式，但是恶意payload的流保持不变。

图6 原始RTF与保存RTF文档对比

一旦文档转成回原始格式，当文件处于打开状态时，在嵌入的对象被自动提取到临时目录的地方就会发生默认行为。

0×05 结论

我们可以看到，这是一种创新性的方式来使用默认行为压缩和传递恶意二进制文件。另外，我们还看到，攻击者使用混淆(XOR)的附加层来更好地掩盖文档对二进制文件的包含。

看着这些样本中的恶意宏，并没有显式的调用来编写或下载用作payload的二进制文件。当识别恶意二进制文件初始的传递向量时，恶意软件分类过程中这可能会导致一些混乱。