【快讯】
1月13日， incaseformat病毒在全网集中爆发，中毒用户C盘以外所有文件被删除。火绒工程师在该事件首次报告的逆向分析中，推测病毒程序制作存在错误，导致其爆发时间推迟到今年1月13日。而同行厂商也在后续报告中表明一致观点。但是，通过火绒威胁情报系统以及样本分析，火绒工程师再次对病毒深度溯源发现，该病毒蛰伏至今才爆发，或为攻击者的精心策划。
根据火绒工程师分析，该病毒存在至少两个变种。推测第一个变种为原作者所做的原始病毒，最早可追溯至2009年，其爆发时间为2010年4月1日。从仅一年的潜藏时间和选择的爆发日期（愚人节）来看，不排除是原作者测试病毒的可能性。第二个则为黑客篡改后的变种，最早可追溯至2014年，并被设置在2021年1月13日爆发。
对比两个变种病毒可以发现，两者在核心代码逻辑中仅有一处数据被篡改。这种篡改的方式极其细微隐蔽，更像是精心策划，目的或是为了引导病毒分析人员误以为病毒程序出现bug，增加潜伏的机会，以便继续扩散危害。
同时，通过深度溯源可以发现，在此前关于该病毒事件的众多分析报告中，不同厂商对该病毒的追溯日期偏差（包括2009年、2014年等）实际上源自对该病毒两个不同变种的混淆。实际上，火绒基于自主反病毒引擎，能够同时查杀两个变种的全部样本。
被篡改的病毒利用文件名获得用户信任躲避查杀，加上超长潜伏期的传播积累，导致感染量持续增长，并于在今年1月13日突然大范围爆发，达到了严重程度。而根据“火绒终端威胁情报系统”监测，也证实在2020年5月以后，被篡改的病毒样本的传播量有显著上升趋势。
一个隐藏七年的老病毒，在攻击者预期的时间里集中爆发，并企图隐瞒、误导对其追溯分析的病毒分析人员，这也给广大安全从业者敲响警钟，在与病毒、黑客的对抗中，需要更加严谨和全面，才能给用户提供可靠的保障。
一、 详细分析
通过对incaseformat病毒的溯源，我们发现之前分析报告中推测的该病毒之所以潜伏数年并在2021年1月13日触发删除文件的攻击逻辑，或并非bug导致，而是攻击者精心设计。
通过对火绒捕获的incaseformat病毒同源样本进行梳理，我们发现该病毒至少有两个变种在野进行传播。其中一个变种最早可以追溯到2009年，该病毒变种会在2010年4月1日（愚人节）触发删除文件逻辑；而另一个变种则目前可追溯的出现时间为2014年，该变种为黑客在原始变种基础上通过人为篡改得到，该变种通过人为篡改推迟了攻击逻辑，可在时隔7年后的2021年1月13日触发攻击逻辑。
由于被篡改后的病毒样本在之后一直处于潜伏状态，且不易被用户发现，导致该病毒大肆传播，并在2021年1月13日集中“发作”造成了大范围不良影响。两个变种病毒传播与病毒行为触发时间线，如下图所示：
通过对火绒捕获的全部incaseformat同源样本进行梳理，我们发现被篡改样本的数量远大于原始样本数量，两者相差将近79倍。即在野传播的该蠕虫病毒样本中，有接近99%的样本均为被篡改后样本。相关样本数量情况，如下图所示：
通过排除被感染型病毒感染或带有感染型残留数据等无效样本情况后发现，被篡改的病毒样本数量从2014年开始整体呈波动上升趋势且于2020年5月开始出现“井喷”式增长。该病毒数量增长趋势与其潜伏期长、集中“发作”、破坏性强等特性，使得此次事件受波及用户广且用户感知强烈。病毒增长趋势，如下图所示：
通过二进制对比两个病毒变种，发现在核心代码逻辑中仅有一处数据被篡改且极有可能是直接通过二进制的方式进行修改。篡改的位置为Sysutils::DateTimeToTimeStamp库函数所使用的全局变量IMSecsPerDay（一天的总毫秒数），从而影响最终触发删除文件逻辑的时间点。
分析人员在分析病毒样本时，通常会信任库函数代码，而把注意力集中用户代码上。因此这样的运行时库函数篡改很容易被分析人员忽视，从而掩饰病毒的真正意图。被篡改前后的病毒样本代码及数据对比，如下图所示：
被篡改前后的病毒样本在判断触发日期代码相同，具体如下图所示：
二、 附录
本文始发于微信公众号（火绒安全实验室）：追根溯源：incaseformat病毒数年蛰伏或源于精心策划
评论