如何缩短人工分析样本的时间

安全研究与恶意软件分析，这是两种不同的方向，属于大类与子类的关系。安全研究的目的是提供一种应对方法，例如恶意文件检测或者威胁检测的方法，提供战略能力，而恶意软件分析是一种动作，这种动作是有具体对象的，具体对象是恶意文件，属于战术能力。有时候我们会搞混这些概念，认为恶意软件分析就是安全研究，其实从严谨角度看不太算，安全研究的目的在于最终需要提供一种方法或方案（不管能不能落地或实现），而期间可能需要利用恶意软件分析的技能来达成这个目的。恶意软件分析是大部分情况会具体分析某个特定的恶意文件，通过目的的不同有不同的分析策略与方式。例如接下来会写到的，我们需要解决的是“沙箱行为释放不全”的问题，而不是在恶意软件分析过程中刻意分析各种技巧或技术来“炫技”，“炫技”对解决“沙箱行为释放不全”这个问题确实没有什么帮助，我们需要避免。

在分析一个样本时，我们需要考虑投入与产出是否合理或者划算，为什么需要考虑呢？真实的情况是每天都有不少的银狐木马或者其他类型的钓鱼样本出现，我们不可能每个样本都得人工去分析，都得走完样本分析的整个流程，这是不现实的。那么现实的情况又是如何呢？举个例子，需要针对某些在沙箱内分析后未跑出网络行为的样本进行原因分析，那么我们只需要专注于具体问题即可。

例如每天都有不少中文名的钓鱼样本出现在公网云沙箱中，如下： 

这里的问题是“为什么没有在沙箱中跑出网络行为？”而不是通过技术视角会想到的“这个样本用到了什么比较厉害的技术或手法？”。针对这个问题我们依据自身的经验可以简单地得出一些可能性原因如下：

1、样本存在反沙箱策略，或者说样本检测到了沙箱环境然后不愿意按照正常流程执行。

2、样本本身属于测试文件，还未正式投入攻击，这里是说我们拿到的恶意文件实质并不是真正用于攻击的文件，而是攻击者不小心泄露出来的测试文件。

3、监控该恶意文件执行的沙箱系统存在缺陷或者bug，导致分析出现异常，导致样本释放的行为不完整。 

我们先假设可能性，之后通过实验来一一验证。举一个案例样本0892792dc7783184451c6621b6e4a87c，该恶意文件在沙箱环境执行后并没有跑出任何网络请求行为，那么这是为什么呢？

首先我们已经获取了上述提到的初步问题“这个样本为什么没有在沙箱中跑出网络行为？”，但这个问题还不够具体，不利于我们排查得到最终的原因，因此还需要不断地深入剖开这个问题的外壳。假设这个样本存在反沙箱策略，那么存在这类对抗策略的样本是比较多的，最近分析沙箱跑不出较多行为的几个样本，发现比较好的状态是尽量不要手工分析样本，因为时间成本不划算，尽量利用效率类工具发现对抗的原因与细节，然后设计反对抗的策略或方案然后考虑是否能落地，我们首先要抓住问题的核心。

首先第一步就是选择其他可用的沙箱环境，测试是否能跑出网络行为：

1、如果其他沙箱环境能跑出网络行为，那么证明了该样本本身不属于测试文件，而且很有可能当前使用的沙箱环境存在缺陷或者存在对抗策略导致行为释放不全。

2、如果其他沙箱环境也不能跑出网络行为或特定行为，那么证明了我们当前的假设还无法完全排除，需要更多的方法来逐一排除。

在始终考虑“尽量不要手工分析样本”的思想指导下，我们需要继续进行实验来验证我们的假设是否成立，遵循“大胆假设小心求证”。

由于上面不断地提及沙箱这个名词，我们有必要介绍下沙箱的工作原理：

恶意软件分析沙箱通过隔离环境运行可疑程序，具体技术细节为通过API hook拦截并记录系统调用，也可能使用内核监控会捕获一些比较底层的操作，监控其行为如文件修改、网络活动等，分析其对系统的潜在威胁。沙箱会提供一个安全的测试环境，避免恶意软件对真实系统造成损害。

上面沙箱的核心技术点是hook与监控调度，这是我们需要提前了解的常识。有了相关的背景知识后，我们继续实验刚刚提出的假设是否成立。

第一次实验过程：

既然沙箱会通过API hook记录运行过程中调用的API信息，那么我们需要确定沙箱监控的API记录是否完整或正常，通过比对来判断具体存在的问题，因此我们这里选用DBI工具帮助我们获取样本运行过程中调用的API记录，DBI工具是一类可以帮助我们实现恶意软件分析自动化的工具。例如通过成功跑出网络请求的环境将drltrace记录的api调用日志与沙箱记录的api调用日志进行比对分析来找到不同的地方，然后人工介入调试，缩短定位具体问题的时间。当然我们也可以利用API Monitor工具实现类似的效果，但是API Monitor工具比较臃肿，记录的API调用信息输出需要进行一些精简。

实验过程中发现drltrace记录的api调用日志与沙箱记录的api调用日志差别不大，都是枚举了进程信息然后获取域名的解析IP最后退出进程，两者都没有较大异常点，因此结合其余沙箱的输出信息和现在本地做实验得到的信息综合分析后可以认为沙箱监控过程并没有出现较大错误。但为了定位更具体的问题（发现更具体的问题是解决“沙箱行为释放不全”这个核心问题必经之路），我们还是需要人工介入分析，但是由于我们可以提前发现异常的API调用记录，在定位具体问题时可根据API调用的上下文信息直接进入问题点。

最后经过对其人工分析后发现并没有发现反沙箱策略，只是因为该文件执行过程中通过实现C++自定义异常处理程序来隐藏实际的代码流（导致静态分析过程中会存在一些阻碍，不过这属于比较简单的对抗，下一篇文章会介绍银狐木马利用C++异常处理恶意手法），但请求的域名内容是错误的内容，无法网络请求成功，经过判断与分析大概率属于测试程序，对系统无害。

本次分析就结束了，统计了下花费的时间，确实缩短了分析样本的时间，也解决了定位具体问题的目的，希望这类解决问题的思路能真的授人以渔。 

平时只有晚上的时候才有时间整理思绪写东西，纯爱好写作与分享，如果觉得内容有用可以分享或者转发，不胜感激。有喜欢讨论或交流网络安全相关主题或恶意文件相关主题等不吹水的内容的读者可以加入交流群，该群无门槛免费永不收费，如遇到需要验证可以先联系我后邀请进群。

原文始发于微信公众号（OnionSec）：如何缩短人工分析样本的时间