当我们分析一个流行的恶意软件家族时,会首先查看其使用的恶意基础设施,从而收集线索,查找幕后的开发者。
本文就以Dridex为例,来说说如何利用恶意基础设施来推测下一次可能的攻击。
Dridex
Dridex银行木马于2014年首次出现,至今仍是最流行的恶意软件家族之一。 2020年3月,Dridex成为最受欢迎的恶意软件之首。
Dridex是由一个名为“Evil Corp”的网络犯罪组织创建的,该组织估计对全球银行系统造成了1亿美元的损失。在本文中,我们提供了迄今为止有关Dridex的关键细节的介绍。探索了Dridex开发的历史,并展示其关键技术特征和传播方法。
Dridex中的关键模块名称:
Evgeniy Bogachev:臭名昭著的ZeuS恶意软件的创建者。
Maksim Yakubets:负责Eride Corp网络犯罪集团的负责人,该集团负责Dridex的运营。
Dridex出现之前,ZeuS最为流行
Zeus是木马恶意软件,它的功能包括将受感染的计算机变成一个僵尸网络节点,窃取银行凭证,下载并执行单独的恶意模块。根据联邦调查局的调查,网络犯罪组织的成员试图利用ZeuS在全球窃取约2.2亿美元。
以下时间线显示了ZeuS发展的关键点:
当ZeuS源代码在2011年泄漏时,此恶意软件的各个分支开始出现。它是非常流行的恶意软件,并发展出了许多不同的恶意软件分支。在撰写本文时,ZeuS与29个不同的恶意软件家族相关联,共有大约490个版本。
2014年5月,美国联邦调查局(FBI)发布了一份公告,其中描述了博加乔夫(Evgeniy Bogachev)的情况,并承诺悬赏300万美元,以获取有助于逮捕和/或定罪的信息。
Dridex时代
ZeuS家族消失后,Dridex就发展起来了。该恶意软件是Bugat演变(于2010年出现)的结果,Bugat v5在2014年被命名为Dridex。据称,Andrey Ghinkul(来自摩尔多瓦)是2015年Dridex僵尸网络背后的管理员之一。Igor Turashev也是Dridex僵尸网络背后的管理员之一。
Denis Gusev是EvilCorp背后的主要投资者之一,更多与Dridex有关的名字可以在美国财政部制裁声明中找到。
下面的时间线显示了Dridex演进的一些里程碑:
Dridex继而从2017年开始使用Bitpaymer产生了许多勒索软件,该分支继续使用2019年开发的DoppelPaymer和2020年开发的WastedLocker。
在2019年,Dridex至少拥有14个活动的僵尸网络,其中一些以前已经被发现,而另一些则是新开发的。僵尸网络通过其ID号来区分。这些是目前最活跃的:10111, 10222, 10444, 40200, 40300。在2019年底,联邦调查局发布了一份公告,其中描述了Dridex的作者,并承诺提供500万美元的奖励(此前为E.Bogachev提供300万美元)。
也有证据表明,马克西姆过着奢华的生活方式,这无疑是由于他的恶意活动所致。
到目前为止,Maksim Yakubets尚未被执法部门逮捕。正如前面提到的,在2020年,Dridex是世界上最流行的恶意软件家族。
感染链
在开始对Dridex样本本身进行分析之前,我们想了解恶意软件背后的基础结构。如何传播?目标是什么?支持文件的初始检测率是多少?
Dridex的传播
当运营商想要传播Dridex时,他们会使用来自不同网络犯罪集团的已建立的垃圾邮件程序,将恶意文件附加到精心制作的电子邮件中。在Dridex生命周期的不同时期,Necurs、Cutwail和Andromeda僵尸网络都参与了Dridex的传播。
当用户下载并打开此类文档(可能是Word或Excel)时,将启动嵌入式宏,以下载并执行Dridex有效载荷。
目标
Dridex的目标是来自世界各地的不同知名机构:
美国银行帐户;
美国信用卡公司;
美国金融投资公司;
欧洲银行帐户;
沙特阿拉伯、卡塔尔、阿曼的政府机构;
诱饵
为了提高Dridex的传播成功率,恶意攻击者将其垃圾邮件伪装成合法的电子邮件。我们可以举出UPS、FedEx和DHL等公司的例子,这些公司的标识和邮寄风格都被用作这类电子邮件的诱饵。
当受害者点击链接时,带有恶意文档的存档或恶意文档本身都会被打开。
最初的检出率
当首次在野外看到Dridex传输文件时,它的检出率非常低。在下面的截图中,我们看到了Dridex的Excel文档的初始检测率:
Dridex传播文件的初始检测率
加载程序和有效载荷
Dridex示例包括加载程序和有效载荷,我们将在下面讨论每个部分的重点。
反调试技术
Dridex加载程序利用OutputDebugStringW函数使恶意软件分析更加困难,不同的加载程序会产生不同的输出(其中“Installing…”字符串非常流行),但该思想在各处都是相同的:创建一个包含大量无意义调试消息的长循环。在下面的图中,我们看到了这样一个循环的示例,该循环的迭代次数约为2亿:
带有0xBEBBE7C(大约2亿次)迭代的循环调用OutputDebugStringW
日志中的输出如下所示:
Dridex调试消息淹没了分析日志
混淆
有效载荷被严重混淆,几乎没有函数被直接调用。调用解析是在标识库及其包含的函数的哈希值的帮助下执行的。下面的截图显示了这样的分辨率示例:
Dridex有效载荷中的调用解析示例
所有对关键Dridex任务重要的函数都是这样调用的。
对Internet函数的解析调用示例
我们使用Labeless工具来解决混淆的函数调用,恶意软件中的字符串使用RC4算法和样本中存储的解密密钥进行混淆。
配置
有效载荷内部的主要关注点是其配置,它包含以下重要细节:
木马ID;
C&C服务器的数量;
C&C服务器本身的列表;
配置示例:
有效载荷内部Dridex配置的示例
本示例中的木马ID为12333,命令和控制服务器包括:
92.222.216.44:443
69.55.238.203:3389
66.228.47.181:443
198.199.106.229:5900
104.247.221.104:443
178.254.38.200:884
152.46.8.148:884
网络活动
Dridex从配置向服务器发送POST请求以获取更多命令,等待200 OK响应。请注意,这些服务器不是真实的C&C服务器,而是连接到真实服务器的代理。
Dridex僵尸网络基础设施
恶意软件发送到C&C服务器的信息包含以下数据:
计算机名;
僵尸网络身份证号码;
请求类型;
操作系统的架构;
已安装软件列表;
这些数据用RC4算法加密,密钥存储在恶意软件的加密字符串中。
至少有6种不同类型的请求;其中有以下几种:
" list ":获取配置;
" bot ":接收bot模块;
使用IOC尽早发现
感染越早被发现,缓解的机会就越大。为了在花费最少资源的情况下尽快捕获感染,我们希望专注于初始传播阶段。
但是,检测只是一个方面。我们可能会自信地说某些东西是恶意的,但我们也想对威胁进行分类。为此,我们必须确保该特定恶意软件确实是Dridex。
让我们再次看看Dridex感染链,并确定我们可以用于检测和识别的不同阶段:
Dridex检测的不同阶段
在Dridex感染的不同阶段,我们可以使用以下指标进行检测。
第一阶段,恶意文件:
文件哈希;
文件内的图片;
文件的内部结构;
内部使用的宏;
第二阶段,服务器:
域;
网址;
第三阶段,加载程序和有效载荷:
样本哈希;
配置文件中的IP地址;
为什么这么多因素很重要?
我们已经看到Dridex的基础设施和指标以及其他流行的恶意软件家族(例如Emotet和Ursnif)之间的关联。当用于传送上述所有恶意软件时,恶意文档具有共同的指标。一些C2服务器,确切地说,是代理服务器——被Dridex和Emotet使用,尽管端口和连接类型是不同的。
因此,在得出结论之前,我们必须分析很多细节。与我们所拥有的特定僵尸网络相关的独特因素越多,就越容易说出另一种攻击是否具有相同的模式。
当然,对恶意软件进行分类的理想方法当然是获取并分析最终的有效载荷:如果是Dridex,则在恶意软件之前启动的所有内容也都归为Dridex。但是,在知道结果之前可能需要一些时间(有时在获得最初的恶意文档之后需要相当长的时间)。通过分析感染链早期阶段的所有指标,我们可以更快、更有信心地进行分类。
另一个有趣的注意事项是利用相同的网络下载Dridex示例,我们分析了用于此目的的域,解析了它们的IP,发现其中很多都位于同一网络84.38.180.0/22中,总共可用地址少于1024个。该网络属于俄罗斯ASN Selectel公司,该公司很少删除恶意内容或垃圾邮件。
我们在84.38.180.0/22网络(以及同一ASN内的其他网络)中看到了以下链接到Dridex域的IP地址,日期显示Dridex域首次指向相应的IP:
尽管仅凭此因素不足以识别Dridex,但这是处理Dridex IOC时要参考的一个很好的辅助细节。
检测
下面的图表显示了不同日期的Dridex峰值
6月29日Dridex感染峰值
7月6日至7月8日Dridex感染峰值
能够尽早拦截Dridex攻击至关重要,在许多情况下,如果7月6日至7月8日之间连续几天都没有发送垃圾邮件,则僵尸网络的活动在第二天就会变慢,并且我们获得的IOC匹配次数不会像高峰期那样多
Dridex的发展
自7月22日以来,我们还没有发现任何新的Dridex垃圾邮件样本。 Dridex在9月7日重新出现,显示其活动峰值连续2天大幅增加:
Dridex运营商更新了Dridex执行的第一阶段:他们添加了更多可从其下载有效载荷的URL,而不是最早版本的恶意文档中的单个URL。现在,在单一文件中,他们的数量可能高达50个。
我们一直在监控这个僵尸网络,并在不同的执行阶段检测它的有效载荷。
本文翻译自:https://research.checkpoint.com/2021/stopping-serial-killer-catching-the-next-strike/如若转载,请注明原文地址: