使用APM破解Imminent rat病毒后我们学到的东西

翻译自：https://blog.talosintelligence.com/2019/01/what-we-learned-by-unpacking-recent.html
翻译：聂心明

在过去两个月的时间里，Cisco Talos一直在追踪一系列Imminent rat病毒感染事件，下面的数据来自思科高级恶意软件防护（AMP）漏洞利用防护引擎。在病毒开始感染主机之前，AMP成功的阻止了病毒，但是在最初的分析中就展示了比较强大的迹象，就是在rat部署之前就已经探测出病毒的存在。让人惊喜的是，amp检测出这个病毒是Imminent RAT，而不是一个合法的商业软件。

这一系列攻击的设计者设计出的病毒可以躲避检测和阻碍分析。从外表来看，这个病毒了用了一个叫Obsidium的商业的加壳工具，这个加壳工具在过去一直被用于保护一些开发者的知识产权。这个Imminent RAT病毒就用了刚才提到的壳来达到使自己合法化的目的。Imminent 是一个商业的rat，它的零售价为$25 到 $100。可以根据客户的需求来改变病毒的体积。虽然它不希望被用于恶意用途，但是在这次案例中，我们依然把他检测为恶意病毒。

尽管现发现潜在恶意应用 (PUA)的方法已经比较成熟了，但并不是每个人都能阻挡住恶意软件。我们还有一些其他的技术，探测潜在漏洞利用引擎，它就非常适合去发现一些潜在的威胁。我希望通过读者在读完这篇文章之后，你能不仅明白攻击者使用了一个非常复杂的壳，还要明白amp是怎样阻挡的这次攻击，而这次攻击者使用的病毒躲过了静态分析和沙箱的动态分析。

当AMP发现软件中包含Imminent后，我们看看这个病毒使用的壳有多复杂，是怎样逃避检测的。我们决定进一步调查这个病毒，下面是病毒动态运行时的调用过程。

我们识别出这个病毒用了商业的壳，通过运行这个病毒，我们来看看它到底究竟用了多少反调试反虚拟机的技术。病毒启动时，会覆盖SEH句柄。技巧是把处理句柄放在FS:0前后，然后把栈指针指向FS:0。可能是因为样本是32位的，且没有用SafeSEH进行编译。代码会故意出错，然后执行流程会跳转到准备好的代码。之后解密病毒代码。

当执行到准备好的代码时，下面用于用户处理异常的代码将会被跳过，大家都知道处理异常时都必须用到ntdll->KiUserExceptionDispatcher，你跳过异常处理到应用程序，如果下面还有异常处理函数或者如果runtime还能继续运行的话，那么你就在条件跳转前面下断点。

最后，ECX存储了一个指向CONTEXT 结构的指针，然后EIP会指向这个结构，这样就会调用上面的NtContinue，在运行时，EIP就会指向ECX地址，并且会在32位环境中应用 CONTEXT结构。

病毒会在同一时间内解密和再加密病毒代码段，如果你没有手动运行每一个代码段，你很难完整的确定完整解密的时间点，加密方式是采用的是AES加密还有其封装的函数。

上面是解密初始化代码，你可以看到一些复杂api的解析，首先类似于二进制文件的其他位置，但是这里会阻止你的分析： junk byte insertion for anti-disassembly

有一种希望就是，依赖现代反编译工具的流程控制图和函数代码块能快速梳理。在几个函数返回的地方下好断点之后，你要开始注意在通用寄存器抛出的api字符串。通过一些实验和试错，你可能不会把断点下在重要的返回地址上，解析api的返回地址一般存储在eax上。程序会在调试器中运行，直到函数返回，但是你将会在代码中遇到一些额外的程序崩溃和访问非法结构的问题。就像下图展示的那样。当病毒开始运行payload时检测到用户使用调试器时，反调试器就会触发崩溃和访问非法结构，这在加壳软件中是非常常见的。

值得一提的是，当病毒运行时，如果你没有运行到函数的返回地址时，程序就不应该在api地址上断下，或者跳转。壳也不总会让函数返回到正常的api地址上。并且，api地址不会被直接使用，而是存在于几个函数中，并且每个api会被改变。最好的方式是在api函数地址上下断，目的是当病毒偶然调用这些api时会看到原始的参数。更重要的是，壳会会提前检测api代码中会不会存在软断点（0xCC 或者 int 3）

当你搞定反调试器时，你就可以正常调试了。这是成功破解的关键步骤。更方便的技术就是让病毒代码运行，然后从内存中导出完整的镜像出来，或者相关的代码，这个病毒似乎没有对这种情况做相关的检测。这个壳有几种反调试的检测，我用用一个列表详细的列举出来。

• 类注册后，传递给CreateWindowsEx，通过CallWindowProc来传递回调参数。回调函数调用NtQueryInformationProcess，并且把发给ProcessDebugPort 的数据设置为ProcessInformationClass类型。
• API调用两次ProcessInformationClass enumerations ProcessDebugObjectHandle 和 ProcessDebugFlags，这些数据都没有文档支持。
• 通过给SystemInformationClass 传递无文档支持的枚举类型来调用NtQuerySystemInformation 。在这一部分中，标准的SYSTEM_BASIC_INFORMATION 结构不会被返回，但是SYSTEM_KERNEL_DEBUGGER_INFORMATION 结构会被返回，这个结构里面包含UCHAR KernelDebuggerEnabled 和 UCHAR KernelDebuggerNotPresent。用户通常用这两个标志绕过调试器的检查。
• 一个错误的句柄去调用CloseHandle ，当你用调试器调试进程时，病毒一般会出现异常，然后退出，而不是无声的退出。在这个例子中，如果程序出现异常则会被调试器捕捉到（EnumWindows->MessageBoxA->“Debugger detected…”），当调试的时候就会丢弃这样的异常从而绕过这样的检查
• CreateFileA 会被调用几次，目的是为了检测主机上是否有与调试器相关的文件

\\.SICE
\\.\NTICE
\\.\NTFIRE

• 下一个检测比较有趣，在程序运行之前，病毒程序解析了超过20给函数。幸运的是，仅仅只有一小部分函数被检测到了(InternalGetWindowText, IsWindowVisible, and EnumWindows)，在早期的讨论中，通常认为在解包之前获取EnumWindows是一种不好的迹象，这样你不会通过调试器的检查。在这个例子则不同，传递给EnumWindows 的回调函数必须通过断点来处理和迭代，检查独立的调试器时，会检测 InternalGetWindowText 和 IsWindowVisible的调用。
• 设置的值直接会传递给SetLastError，但是要遵守内部错误机制。GetLastError 被调用，目的是检查是否有值被设置，如果有就证明有调试器，程序随即崩溃
• GetCurrentThread 会提取当前进程，然后把获取到的值传递给NtSetInformationThread，外加来自于THREAD_INFORMATION_CLASS的ThreadHideFromDebugger enumeration。它会检测是否存在调试进程。
• CheckRemoteDebuggerPresent
• FindWindowW 会寻找与调试器相关的类名称，而不是窗口名称：ObsidianGUI, WinDbgFrameClass, ID, 和 OLLYDBG
• CreateFileW 会检查会不会创建\\.\VBoxGuest

这仅仅是反调试器的一部分功能。不幸的是，我没有足够的时间去介绍病毒反虚拟机的技术，但是希望这篇文章相当于一个抛砖引玉的功能。我们决定继续在 bare-metal主机上破解这个病毒以得到它最终的二进数据。最后我们识别出这是一个商业的RAT病毒。通过分析动态域名，发现其他样本也用了同样复杂的加密壳(Themida等)。但是这个主机不会只控制一个，肯定会同时控制多种RAT（包括我现在破解的）

这一些攻击让检测策略变得更为复杂。最开始，我们使用商业加密壳来保护开发者的知识产权。而现在商业的rat也会用到加密壳。我们的PUA能够检测到病毒，我们的潜在漏洞利用引擎也发现了这次攻击，此外我们使用病毒预防技术对这次事件做了进一步分析。我们发现攻击者最近研究了几种新的技术去绕过病毒检测机制。在这次事件中，商业病毒的能力似乎也不行。攻击者的病毒被Cisco Advanced Malware Protection’s (AMP) Exploit Prevention引擎成功阻止，并且这次攻击给我们提供了更多有用的信息，让我们知道攻击者在攻击目标时用到了什么样的工具。

IOCS

原始病毒：
3bc0ae9cd143920a55a4a53c61dd516ce5069f3d9453d2a08fc47273f29d1cf3
破解之后的病毒：
12cca4fcfe311d1136db6736e7f17854746a5e6c7a284c27ea84a5016bf982d7