大家可能还记得，在2017年5月，WannaCry在150多个国家进行了大规模的攻击活动，许多公司和组织都不幸中招。幸运的是，英国安全研究人员马库斯•哈钦斯(Marcus Hutchins)通过无意间触发WannaCry自带的“自毁开关”，来阻止了这次袭击。

然后很快这位英雄就出事了，根据美国司法部发布的一项起诉书，哈钦斯被指控在2014至2015年间帮助他人创建、传播和维护银行木马Kronos。Kronos是一种可以盗窃信用卡号码和其他银行信息的恶意软件，网络罪犯常常利用假冒邮件中的附件来诱使人们安装它。

不过根据最新的消息，在检察官在对这个案件进行调查的过程中，又指控他单独制造了一个名为UPAS Kit的恶意软件。检察官称，UPAS Kit于2012年创建，并于同年7月由哈钦斯出售给使用假名Aurora123的人。UPAS Kit使用表单采集和Web注入来拦截和收集来自受保护电脑的个人信息，允许攻击者在未经授权的情况下，从被攻击的电脑中盗取信息。根据目前地调查，该恶意软件能够隐秘地安装并且不会触发各种杀毒软件。

请注意：到目前为止，Check Point安全研究人员仅仅是出于研究的需要，对UPAS Kit进行分析，目前还没有确凿的证据表明Kronos和UPAS Kit是否就是由同一人编写。

解析初始化阶段的ntdll.dll函数

UPAS Kit使用了多个低级（low-level ）的ntdll函数，并在运行时解析该函数的地址。虽然ntdll函数可能会成为阻止研究人员分析的手段，但这本身并不是一个非常复杂的技巧。负责此加载操作的过程遍历包含以下结构项目的函数表。

 typdef struct _ntdll_function_entry{
                         CHAR *function_name;
                        PVOID function_address;
            }ntdll_function_entry;

它只需使用每个项目的字符串字段，并使用Win32 API函数GetProcAddress解析相应的地址，如下图所示。

解析UPAS Kit中的ntdll函数

事实上，Kronos恶意软件也使用了类似的方法来防止研究人员对其进行分析。但是，在这种情况下，函数名不会以明文形式保存在二进制文件中，而是作为字符串哈希。此外，一些解析函数可用作系统调用，因此无论是通过沙盒模拟器还是手动检测恶意软件，都会很难检测到恶意软件的活动。不过，与UPAS Kit不同，Kronos利用了一个稍微不同的函数入口结构，如下所示：

 typedef struct _ntdll_function_entry{
                     CHAR *function_name_hash;
                      PVOID function_address;
                       DWORD encoded_syscall_number;
                       DWORD is_used_as_syscall_flag;
 }ntdll_function_entry;

这当然并不意味着后者是第一种方法的扩展机制，但是如果我们比较加载函数的顺序（即位于二进制文件中的表项目顺序），可以看到这两种情况之间有一些相似之处。

加载的ntdll函数顺序的比较

Anti-VM的过程

恶意软件为了避免自己在沙盒环境中运行，采用了两种技术。第一种方法是为了避免ThreatExpert沙盒的检测，即使用函数GetVolumeInformationW检索系统卷序列号，并检查值0xCD1A40（对应于上述沙箱）。ThreatExpert是在线分析文件中可疑病毒、木马、蠕虫等信息，是一个非常优秀的自动化病毒检测工具。第二种技术是众所周知的，那就是对VMWare虚拟机软件的工件进行检查，即对来自来操作系统和主机之间通信的虚拟I/O端口的响应进行检查。值得注意的是，一旦恶意软件检测到不安全的运行环境，它会通过产生一个错误框来阻断响应，如下所示。

UPAS Kit使用的Anti-VM技术

另外，应该注意的是，Kronos所做的等效检查（equivalent check）与UPAS Kit差异很大。这些检查都是为了在UPAS Kit的地址空间中寻找各种存在的进程或加载模块，这可能表明UPAS Kit对其执行环境的检查，要比Kronos的Anti-VM检查所涵盖的内容要多得多，这可能意味着Anti-VM的程序是由不同的作者编写的，或者同一开发者对同一问题采取了不同的方法。

全局互斥（Global Mutex）

木马生成的互斥对象名称是恶意操作的结果——MD5(system_volume_serial ||“LPLl3h3lDh1d3djP7P3”)。如果在互斥对象名称的生成中出现错误，则会为其设置硬编码值（“A5DEU79”）。

生成的互斥对象名称

在这种情况下，Kronos和UPAS Kit在执行MD5函数时存在一定的相似性。但更明显的是，UPAS Kit通过计算MD5（system_volume_serial），以类似的方式创建一个互斥对象名称，并在这种情况下将其分配给MD5（“Kronos”）。

自安装过程

为了保持持久性攻击，UPAS Kit会执行几项常见操作：

首先，它将自己复制到％APPDATA％下的新目录中，命名为“Microsoft”，同样的操作会%TEMP%目录下进行。复制以后的文件名称将是上面描述的％APPDATA％的全局互斥体名称的前七个字符，而％APPDATA％和%TEMP%的前七个字符相同，只是在%TEMP%目录下会附加“_l.exe”和“_a.exe”。

然后，将检查出的当前文件名与新生成的文件名进行比较，如果两个文件名不匹配，那么UPAS Kit则会从％APPDATA％中的新路径开始执行。如果两个文件名匹配，即UPAS Kit在第二次从％APPDATA％路径运行时，则当前文件路径将被写入众所周知的注册表运行项中Software\Microsoft\Windows\CurrentVersion\Run（在HKLM和HKCU），其中运行项的名称与复制文件的名称相同。最后，恶意软件将使用函数IsWow64Process建立当前的系统架构，如果它不可用，则恶意软件将使用GetNativeSystemInfo建立，并将其返回给主函数。

系统架构的检查

UPAS Kit中用于文件、注册表项和互斥对象的命名规定类似于Kronos，也是使用MD5（system_volume_serial）的前8个字符来实现。

进程注入

由恶意软件进行的注入取决于系统架构，在32位系统中，它会创建'explorer.exe'进程并向其中注入自己的映像。而在64位系统中，32位版本的'iexplore.exe'也会执行类似的操作，恶意软件驻留在“%ProgramFiles(x86)%\Internet Explorer”。此时，注入函数就会获得一个PID和目标进程的主线程句柄，以及注入发生后要执行的函数地址。

为了进行成功的进程注入，UPAS Kit使用一个简单的技巧。首先，它将当前的虚拟映像复制到一个缓冲区，然后尝试在远程进程的任意地址分配具有同样映像大小的内存。检索到的分配基地址将用于重定位驻留在复制缓冲区的注入映像，并将其写入目标进程。然后，UPAS Kit将准备一个经过硬编码调用存根并覆盖它的三个DWORD，以便在注入时调用应该执行的函数，这些Word概述如下。

调用存根并替换字节

这些入栈的结构会负责传递一些参数，而这些参数稍后将在hook函数中被用到，这些参数包括。

     typedef struct _config_struct{
                     DWORD whitelisted_process_pid;
                     CHAR whitelisted_run_key_name[16];
                     wchar_t whitelisted_malware_binary_path[260];
                     wchar_t mutex_name[260];
                     DWORD ntdll_load_status;
                     DWORD some_flag;
         }config_struct;

最后，为了触发远程进程中请求函数的执行，UPAS Kit将通过调整上下文结构中的EAX的值来调用远程进程的入口点，然后通过调用NtSetContextThread函数继续执行攻击。如果失败，UPAS Kit将尝试直接使用CreateRemoteThread函数生成目标函数，而不是调用存根。

在注入过程中开始触发远程攻击

与UPAS Kit相反，Kronos的注入方法则完全不同，详情请点此了解。即便有如此不同，研究人员还是发现了Kronos和UPAS Kit两个注入过程的相似之处，这就是两者都试图将恶意软件的进程特权提升到“SeDebugPrivilege”，而这并不是强制注入成功的必要条件。进程特权提升函数的调用以及函数本身（在两个二进制文件中都是相同的）如下所示：

Kronos和UPAS Kit之间的注入比较

在下一篇文章中，我将介绍Kronos和UPAS Ki之间的其他区别，比如恶意有效载荷的注入，Rootkit功能，C2通信过程。