第五章 检测名称重命名方案
如前所述，SiliVaccine使用趋势科技的模式文件，其中包含趋势科技的签名名称。但是，这些名称从未向最终用户透露过，因为它会对检测到的恶意软件名称进行内部重命名，基本上将它们从趋势科技的格式转换为它自己的“专有”格式。此功能由SVMain＆SVDealer模块中的专用功能处理，通过调用SVKernel中的SVFunc016（VSSetProcessFileCallBackFunc）导出设置为回调，并在每次文件扫描后立即触发。如果扫描检测到恶意软件，则将匹配的检测名称显示在模式文件中，并将其转换为自定义格式，如下所述。在整个程序中，仅引用修改的名称格式，正如将在白名单章节中进一步描述的那样。
重命名方法的工作原理如下：
1.通过搜索以下分隔符将模式文件中的检测名称（由SVKernel扫描报告）分为多个部分：“ - ”，“_”，“.”
2.根据下表替换通常指定恶意软件类型/类别的第一部分（前缀）。
其他前缀按原样使用。前缀替换显示在下面的屏幕截图中：
图14: 检测名称前缀替换的代码
3.如果超过2个部分，则最后一部分（后缀）以下列方式替换：
4.如果超过3个部分，则后缀之前的部分用计算的十六进制字符串替换。
5.对于每个部分，第一个字母被转换为大写字母，其他字母转换为小写字母。
6.通过用点（.）分隔符连接各部分来构造新名称：
图15: 创建最终重命名的检测名称
下面是趋势科技名称及其匹配的SiliVaccine名称的几个示例。
第六章 恶意软件白名单
在研究中，我们发现SiliVaccine的作者已经选择了将一个非常具体的恶意软件签名列入白名单，并且有效地忽略了与特定签名匹配的任何文件检测。白名单签名为趋势科技的“MAL_NUCRP-5”，趋势描述如下：
...趋势科技检测可疑文件的行为和特征类似于已知的NUWAR，TIBS和ZHELAT变体。
此签名似乎与任意一种特定的恶意软件无关，但检测到某些恶意软件中常见的特定打包相关特征。此签名中使用的“MAL”前缀表示这是一种通用签名，由趋势科技将其描述为“第二级通用检测名称”，实质上是通过观察现有恶意软件中的常见模式创建的启发式签名。毫不奇怪，查看一组大约20个检测为MAL_NUCRP-5的不同文件，可以发现大量不同的和不相关的恶意软件样本，从假AV安装程序到与中国APT攻击相关的dropper组件。
白名单功能在程序本身的二进制组件中被硬编码，并通过隐式比较来处理，这些比较仅为此目的而添加。这实际上等于完全删除签名。但是，签名本身仍然存在于SiliVaccine附带的模式文件中。这表明作者要么没有直接修改趋势科技的模式文件的方法，要么每次更新趋势科技时都没有兴趣这样做。
深入研究细节，白名单由SiliVaccine的两个主要组件实施; SVMain＆SVDealer——即使用SVKernel调用文件扫描的组件。在整个代码的多个位置中，在调用导出函数SVFunc018（VSVirusScanFileW）后立即将存储最后一次扫描检测名的全局字符串与'Mal.Nucrp.F'进行比较。该字符串实际上是SiliVaccine重命名后的趋势科技检测名称“MAL_NUCRP-5”。如果检测名称与“Mal.Nucrp.F”相同，则代码分支继续，就好像扫描没有找到任何东西（完全忽略检测）。
图16&17:在文件扫描之后将Mall.Crp.Detection列入白名单
这种类型比较的另一个实例可以在SVMain模块中找到，特别是在前面描述的重命名回调函数中。然而，有趣的是，作者这次犯了一个错，并错误地写了'Mal.Nurcrp.F'（中间还有一个'r'）。
图18: 与Mal.Nucrp.F检测的白名单比较中的错字
然而，这不会影响白名单功能，因为在每个扫描实例之后都会进行额外的隐式比较。
有趣的是，所有其他类似命名的签名（MAL_NUCRP- *）都没有列入白名单。扫描趋势科技检测到的一组文件为“MAL_NUCRP-2”（1个唯一文件），“MAL_NUCRP-5”（8个独特文件）和'MAL_NUCRP-6'（3个独特文件）如下所示：
图19: 没有检测到MAL_NUCRP-5，与MAL_NUCRP-2和MAL_NUCRP-6不同
请注意应该检测为'Mal.Nucrp.F'的文件全部缺失，而其他文件（Mal.Nucrp.C和Mal.Nucrp.G）全部正确检测。
第七章 核心驱动
SiliVaccine使用3个驱动程序组件：
· SVHook.sys – 内核模式进程信息收集模块。
· SVFilter.sys –用于实时和AV文件保护的文件系统过滤驱动程序。
· STSTDI.sys – 网络传输驱动程序接口（TDI）驱动程序。
（一）保护机制
通过Detect-It-Easy，SVHook和SVFilter驱动程序都被一个奇怪的加壳程序打包为'BobCrypt2保护程序'。这是一个模糊的检测，看起来像是一个误报，因为在这里使用的加壳程序没有资格成为一名保护者。相反，使用的壳是.text部分的简单XOR，其字节为0x42，在查看时很容易看到：
图20:.text部分使用与0x42简单的XOR加密
二进制文件的EntryPoint位于包含加壳程序代码的“.reloc”部分.
（二）SVFilter
SVFilter.sys组件是SiliVaccine用于两个主要目的的文件系统过滤器驱动程序：
1.实时保护功能，与用户模式组件SVDealer一起使用。
2.保护SiliVaccine的二进制组件不被删除和修改。
实时保护
SVDealer实现了实时保护功能，该功能使用SVFilterdriver钩住文件系统活动并扫描正在被实时访问的文件。SVFilter由SVDealer加载，通过IOCTL与它进行通信和控制。SVDealer指示驱动程序将其自身附加到所有现有文件系统驱动程序堆栈，然后等待来自驱动程序的扫描信号。一旦信号到达，它将读取需要通过单独的IOCTL扫描的文件路径，对其进行扫描，然后向SVFilter报告文件是否被发现是恶意的（而不是白名单）。下面的屏幕截图显示了SVDealer的这一功能：
图21: 通过SVDealer进行扫描，跟随来自SVFilter的信号（来自SVDealer的实时保护）
SVFilter对应的函深藏在漫长而令人困惑的函数之中。在分析这个函数之后，发现它是相当漫长而复杂的，它只是以一种混乱的方式执行上面描述的功能。经过多次重叠和奇怪的检查后，该函数最终达成实时扫描功能。实时文件扫描仅在执行文件时调用。代码检查文件是否被打开执行，如果是，则存储文件路径并向SVDealer发送文件需要扫描的信号。之后，它会检查SVDealer报告的结果。如果该文件被报告为恶意文件，则其名称将存储在一个列表中（其目的不明确，因为它没有以任何明智的方式使用），并阻止对文件的访问。下面的代码片段显示了此功能：
图22: 文件执行的信号SVDealer，处理检索到的扫描结果（来自SVFilter方面的实时保护）
保护内部组件
SVFilter中的相同过滤器功能还通过阻止对SiliVaccine的二进制文件的写入访问来保护磁盘上的二进制文件。以下屏幕截图显示执行相关检查的代码段：
图23: 通过SVFilter保护磁盘上的SiliVaccine文件免受任何写访问的影响
（三）SVHook
SVHook驱动程序是一个奇怪的，有点混淆的组件。名称暗示它用于内核模式挂钩，但它不包含任何此类功能。相反，当SiliVaccine执行系统的内存扫描时，由SVMain加载和利用它来查询来自内核的窗口对象元数据。它实质上是作为内核模式代理来查询只能从内核访问的信息。
关于这个组件的最有趣的事情是作者在代码中留下的调试字符串。SVHook中的函数包含多个DbgPrint调用、描述函数的状态，以函数'sub_800754'为例：
图24: 出现在SVHook二进制文件中特殊的调试字符串
这很可能是由IDA逆向工程工具自动生成的名称，表明该功能可能是由作者从逆向另一个驱动程序复制的。函数本身接收来自用户模式的句柄并返回匹配的对象名称。
同样有趣的是，该驱动程序支持13个IOCTL命令，而用户模式组件（SVMain）仅调用3个命令。此外，该驱动程序包含一些错误和错误，表明该组件被快速打包在一起，而没有完全理解目的。例如，其中一个使用的IOCTL总是会失败，因为作者在其条件语句中犯了一个错误：SVMain在IOCTL中发送的输入缓冲区大小为12个字节（应该可能是这样）：
但是，作者在验证SVHook中的输入大小时混淆了条件，并且在如下所示的情况下返回状态码STATUS_INVALID_PARAMETER：
图25&26: SVHook处理0x83350004 IOCTL时，在缓冲区长度检查中的编程错误
（四）STSTDI
可以在SiliVaccine组件中找到的最终驱动程序是ststdi2.sys。这是一个TDI（传输驱动程序接口）过滤驱动程序，用于拦截TCP连接并将其记录在内部数据结构中。这样做的方式是让与该驱动程序相对应的设备连接到系统的TCP设备之上，从而拦截来自高级内核TCP客户端的IRP（例如HTTP.sys，它使用TDI API与TDI传输驱动程序进行通信）。
观察DriverEntry，可以看到3个调度函数。第一种是默认功能，只是将IRP传递给TCP驱动程序，使TDI驱动程序在大多数情况下“透明”。第二个是处理IRP_MJ_CREATE，IRP_MJ_CLEANUP和IRP_MJ_CLOSE的调度函数，它将拦截任何连接创建或终止的事件。最后，对于IRP_MJ_DEVICE_CONTROL或IRP_MJ_INTERNAL_DEVICE_CONTROL，驱动程序将处理任何特定的IOCTL。
图27: STSTDI的DriverEntry函数，显示主要调度例程和TCP设备的附件
处理连接的调度函数会将它们记录在散列表中，以便包含每个时间点的所有活动连接。在下图中可以看出，在IRP_MJ_CREATE（即连接创建）的情况下，将检查与IRP关联的系统缓冲区，并确定连接地址或上下文是否被附加到散列表。以相同的方式，在拦截IRP_MJ_CLOSE（连接终止）时，相应的连接数据将从散列表中移除。
图28: 由STSTDI处理拦截的数据包
要使用此记录的数据，驱动程序包含一组IOCTL的处理程序，它允许外部实体（另一个驱动程序或用户空间组件）查询和修改基础散列表。奇怪的是，AV中没有其他组件会实际发布这些IOCTL，这使得这个驱动程序显得多余。它可能是一个遗留组件，即之前被合并但仍保留在软件中的组件，即使它没有被使用。
第八章 作者背景
到目前为止，我们已经看到了各种SiliVaccine组件的技术实现细节。然而，通过查看文件元数据可以找到一些有趣的细节。也就是说，如果我们观察AV的PE组件资源部分中的版本信息（只能在解压后的文件版本中访问），我们可以看到两个公司名称--PGI（或Pyonyang Gwangmyong信息技术）和STS Tech-Service。
图29: 公司名称隐藏在SiliVaccine的二进制文件的版本信息中
虽然我们可以从Gwangmyong这个名字猜测，这很可能是Kwangmyong（朝鲜的国家内联网）拼写错误，因为PGI可能是朝鲜的一家公司，STS技术服务仍然有点神秘。这个公司没有互联网网站或者在互联网上有明确的活动记录，留下一些关于其来源和业务线的问号。
尽管如此，网络上公开提供了一些线索，但并没有给出上述问题的明确答案，而是留下了更多思考空间。其中一个例子就是STS Tech-Service被列为多个日本应用程序的共同作者，与两家公司—Silver Star Japan和Magnolia一起编写。诸如麻将或Iron Security（文件加密工具）等程序看起来像这些公司为日本市场开发的合法应用程序。这是否意味着STS Tech-Service实际上在日本？
图30: STS Tech-Service开发的应用示例与日本公司合作
对该公司进行更深入的调查可以证明事实并非如此。查看2006年在朝鲜举行的题为“平壤国际技术和基础设施展览”的活动的邀请手册，我们可以看到STS Tech-Service被列为参与公司之一。该活动的最初目的是鼓励朝鲜企业与其他全球性外国公司进行合作。根据展会主办方提供的信息，尽管本手册中可以看到的很多公司都位于世界各地，但STS Tech-Service确实位于朝鲜境内。
图31: ITIE为2006年在平壤举办的一个展览会的邀请,STS是其中的一家公司
第九章 神秘的补丁文件
如前所述，SiliVaccine安装文件的副本由自由记者Martyn Williams发送给我们，Martyn Williams则从一个带有日文名字的神秘发件人的邮箱收到。
安装程序文件被命名为'SiliVaccine4.0_2014_07_08.exe'，这意味着它是SiliVaccine 4.0版日期为08.07.2014。检查文件显示它实际上是一个WinRAR SFX文件，其中包含一个较旧的安装程序和一个可能的“补丁”文件。
图32: 收到的安装程序文件的内容
执行SFX文件后，将自动执行内部的两个文件。里面的旧版安装程序文件确实是SiliVaccine的合法安装程序。然而，仔细看看补丁文件，却发现它是一个巧妙伪装的JAKU恶意软件，而不是第一阶段的dropper。
有趣的是，该文件由一个与DarkHotel APT行动中使用的证书非常相似的证书签名。这是有道理的，JAKU行动报告指出，JAKU和DarkHotel之间存在“明确的联系”，暗示其背后的攻击者可能是相同的，而卡巴斯基的DarkHotel报告则暗示袭击背后的攻击者已经盗窃了证书。值得注意的是，这些行动都包含朝鲜的链接。
图33: 用于签署JAKU的证书
图34: 卡巴斯基DarkHotel报告中获取的DarkHotel活动中使用的被盗证书
还没有评论，来说两句吧...