一次对恶意邮件分析并拿下其赎金服务器的溯源

简介: 本文讲的是一次对恶意邮件分析并拿下其赎金服务器的溯源,在这个案例里面,我们通过分析垃圾邮件,进而劫持其赎金服务器,并且告知每个人关于发现的这一威胁。然后我会尝试寻找攻击者身份,并且将有关信息告诉执法部门。不过这一部分就不在文章中公开了。
本文讲的是 一次对恶意邮件分析并拿下其赎金服务器的溯源在这个案例里面,我们通过分析垃圾邮件,进而劫持其赎金服务器,并且告知每个人关于发现的这一威胁。然后我会尝试寻找攻击者身份,并且将有关信息告诉执法部门。不过这一部分就不在文章中公开了。

对这一附件解压缩之后发现里面有一个vbs脚本文件,这就比较有趣了,通过双击vbs脚本文件,受害者将会通过微软wscript.exe来运行它,这样就会启动感染进程。邮件是通过一个复杂的垃圾邮件集群进行发布的,这一集群经常在美国活动,前几天目标对准了欧洲。

vb脚本是是经过混淆处理的,不过混淆程度是非常弱的,你可以在下图中看到脚本的内容。实际上,代码只进行了一次包装,而且明文字符串都是可以看到的。

一次对恶意邮件分析并拿下其赎金服务器的溯源

这一后门引入了一个比较有意思的技术,首先,为了让逆向的过程变得困难,它在代码中加了很多无害的内容。非常有趣的是这样一串代码很显然是从后门代码的一部分,但是它并没有和要分析的代码相关联。另外一处很有意思的是"user-agent"的值是对是否下载真实恶意payload的关键因素。后门本身没有什么好分析的,它会通过wscript.exe执行'MZ'文件从受感染的网站中被下载到本地。这一后门文件会直接在http返回包显示,并且保存到用户临时文件夹中,以saToHxy.exe命名。然后对vb对象以及函数进行重命名,使溯源变得困难起来。

一次对恶意邮件分析并拿下其赎金服务器的溯源

获取到后门网址如下:

castillodepalazuelos.es/rf734rgf?
2010.sggt-wh.de/rf734rgf?
ctt.gr/rf734rgf?

之前有提到的Shell.run会执行后门攻击载荷。攻击载荷(sha356:6a51d0cd9ea189babad031864217ddd3a7ddba84)看起来是很容易分析,既没有进行很难的加密,也没有分成多个文件执行,在启动的调试头可以清楚直观的看到用户功能。

一次对恶意邮件分析并拿下其赎金服务器的溯源

一次对恶意邮件分析并拿下其赎金服务器的溯源

启动IDA,通过异或操作会显示小部分攻击载荷内容,并且它采用了一些反调试的技巧,比如时间控制,以及性能监控.如下图所示:

一次对恶意邮件分析并拿下其赎金服务器的溯源

在分析之后,它的设计逻辑变得清楚了,采用了使用了安全处理器异常链技术。攻击者通过触发异常调用修改过的异常处理函数,然后会对攻击载荷进行解码,并且将其分配到新的内存中,最后执行"call eax"部分,下图展示了解码过程中的循环:

一次对恶意邮件分析并拿下其赎金服务器的溯源

如下是通过0x03001220处的函数进行解码的一些内存:

一次对恶意邮件分析并拿下其赎金服务器的溯源

通过动态分析可以看到勒索软件的攻击载荷。实际上,通过解码后的内存,我们可以看到勒索页面,如下图,我将他提取了出来,而不是通过16进制进行展示,文件hash:(sha256: cdb3fef976270ab235db623d6a4a97ea93c41dd1)

一次对恶意邮件分析并拿下其赎金服务器的溯源

特别有趣的是,攻击者在勒索页面中将TOR浏览器写成了TOP浏览器,所以我就将这个勒索软件叫做TOP勒索木马。2333,TOP勒索软件会对机器上的文件进行加密,并且修改文件的拓展名,通常是三个字符(为什么是通常,因为在攻击者的数据库中发现大部分都是3个字符)。修改后的拓展名作为勒索页面的一个隐藏的参数,下方图片就展示了攻击者用于将信息发送到服务端的隐藏参数:

一次对恶意邮件分析并拿下其赎金服务器的溯源

隐藏的输入类型名称为"FB",就像稍带两个信息到命令行以及控制器中。比如将拓展名名以及一些十六进制包含在精心设置的标签中。通过点击"Yes I want to buy"这一按钮的用户会发送之前的数据,并且提示到下方地址支付0.18BTC,以便对文件进行解密:

一次对恶意邮件分析并拿下其赎金服务器的溯源

通过更改FB类中第一个隐藏变量,你会观察到不同的比特币钱包地址,并且勒索金额不等。如下是不同的勒索页面:

一次对恶意邮件分析并拿下其赎金服务器的溯源

这就使得这一系统具有一定的漏洞。事实上,我可以对比特币钱包进行枚举,如果不存在,就新建一个新的比特币钱包,填补攻击者为剩余钱包保留的空间。这样可能会阻止攻击者进行新感染。所以,我写了一个比较邪恶的python脚本去强制创建新的钱包,和金钱映射:

一次对恶意邮件分析并拿下其赎金服务器的溯源

接下来通过FB参数进行进一步分析,我发现这一参数很容易受到sql注入攻击,简直了!!
注入点是被叫做<pre>的一个标签,如下图:

一次对恶意邮件分析并拿下其赎金服务器的溯源

所以我们试试攻击这一网站,像上图中,你会发现一个Mysql爆出来的不是拉丁字符的错误,google翻译提示这是俄语,现在我们可以推断出攻击者有非常大的可能性是俄罗斯人。只有用TOR浏览器才可以访问到数据库,并且速度还非常非常慢,不过我发现了一些自动化的进程,请查看增量ids,试图想象一下这个网络到底有多大。

一次对恶意邮件分析并拿下其赎金服务器的溯源

另外一个有趣的话题就是攻击者是谁呢?换句话说,使用这一勒索平台的用户就是攻击者,因为这看起来像一台勒索服务器,所以我下一个目标就是看看攻击者已经获得了多少钱。下图我展示了我发现的用户名以及密码,和用于收钱的钱包。

一次对恶意邮件分析并拿下其赎金服务器的溯源

我将注意力集中到了god.true@xmpp.jp这一用户上面,他与私人钱包:1P3t56jg5RQSkFDWkDK3xBj9JPtXhSwc3N有关。

钱包类型有两种:
一种是公共钱包,这种钱包会将受害者的钱存起来,每个人都可以访问到这一钱包,这些钱包用于受害者支付他们的赎金。
另外一种是私人钱包,攻击者会将公共钱包得到的赎金转移到这类钱包里面,这个过程中,交易平台会收取一定的费用。

拥有私人钱包就意味着可能会找到交易记录,有了交易记录就可以确定攻击者在几个月内从事了多少违法活动。通过调查go.true@xmpp.jp的私人钱包,我们找到了很多有趣的东西:

一次对恶意邮件分析并拿下其赎金服务器的溯源

在交易记录中可以看到在2017-4-23和2017-4-20号从此钱包中转出了81.87个比特币。再加上我们目前了解到的勒索数量13个比特币,加起来已经接近了100比特币。在4月份你还记得爆发了什么勒索攻击了吗?这一攻击者看起来是一个惯犯,从事这种勒索活动肯定不只一次。通过对电子邮件的调查,发现这一邮箱和https://vlmi.su/这一出售攻击工具,信息的俄罗斯市场有密切的联系。
通过sql注入,我提取除了"inst"表的内容,字段名称如下:

ID, IP, FB, OS, TIMED, TIMEIN. COUNTRY, BRWSER

表中记录的是受害者的信息,让我们看看能不能帮助他们!
从目前来看,就这一个简单的数据库中包含的受害者信息是2000多个,受害者分布来自世界各地。到目前未知,提取出的受害者国家分布如下:

一次对恶意邮件分析并拿下其赎金服务器的溯源

我不会透露受害者的ip地址,不过另外一个有趣的事情是用户使用浏览器的种类比例,奇怪的是chrome竟然占绝大部分。不过恶意软件是通过双击打开vbs脚本,然后利用wscript.exe进行感染的,这和浏览器关系并不大,难道是巧合?

一次对恶意邮件分析并拿下其赎金服务器的溯源

在这篇文章中,我一直在描述从电子邮件附件中获取恶意软件,将整个攻击者的数据库放在我称为TOPransom的服务平台上。我试图枚举攻击者的收入,并通过写一个快速和持久的python脚本填充每个用户的钱包,阻止新的勒索钱包创建,进而阻止勒索软件的蔓延。




原文发布时间为:2017年8月4日
本文作者:xnianq
本文来自云栖社区合作伙伴嘶吼,了解相关信息可以关注嘶吼网站。
目录
相关文章
|
11天前
|
机器学习/深度学习 弹性计算 缓存
阿里云服务器经济型e实例与通用算力型u1实例对比分析与选择指南
在阿里云服务器的实例规格中,经济型e实例和通用算力型u1实例是很多个人和普通企业级用户常见的选择,经济型e实例与通用算力型u1实例的主要区别在于性能、应用场景及价格策略。本文将详细对比这两种实例的性能、应用场景及价格策略,以供参考。
|
13天前
|
算法 数据挖掘 Linux
服务器数据恢复—EXT3文件系统下邮件数据恢复案例
服务器数据恢复环境: 邮件服务器中有一组由8块盘组成的RAID5阵列, 上层是Linux操作系统+EXT3文件系统。 服务器故障: 由于误删除导致文件系统中的邮件数据丢失。
|
5月前
|
监控 关系型数据库 MySQL
|
24天前
|
人工智能 运维 Kubernetes
87cloud案例分析:阿里云国际服务器如何支持在线教育
87cloud案例分析:阿里云国际服务器如何支持在线教育
|
22天前
|
弹性计算 安全 Linux
阿里云国际版ECS云服务器ping不通的原因分析
阿里云国际版ECS云服务器ping不通的原因分析
|
14天前
|
域名解析 弹性计算 缓存
阿里云国际云服务器全局流量分析功能详细介绍
阿里云国际云服务器全局流量分析功能详细介绍
|
2月前
|
存储 安全 算法
服务器数据恢复—Raid磁盘阵列的安全性分析及常见故障
出于尽可能避免数据灾难的设计初衷,RAID解决了3个问题:容量问题、IO性能问题、存储安全(冗余)问题。从数据恢复的角度讨论RAID的存储安全问题。 常见的起到存储安全作用的RAID方案有RAID1、RAID5及其变形。基本设计思路是相似的:当部分数据异常时,可通过特定算法将数据还原出来。以RAID5为例:如果要记录两个数字,可以通过再多记录这两个数字的和来达到记录冗余性的目的。例如记录3和5,同时再记录这2个数字的和8。在不记得到底是几和5的情况下,只需要用8-5就可以算出这个丢失的数字了,其余情况依此类推。
|
3月前
|
前端开发 大数据 数据库
🔥大数据洪流下的决战:JSF 表格组件如何做到毫秒级响应?揭秘背后的性能魔法!💪
【8月更文挑战第31天】在 Web 应用中,表格组件常用于展示和操作数据,但在大数据量下性能会成瓶颈。本文介绍在 JavaServer Faces(JSF)中优化表格组件的方法,包括数据处理、分页及懒加载等技术。通过后端分页或懒加载按需加载数据,减少不必要的数据加载和优化数据库查询,并利用缓存机制减少数据库访问次数,从而提高表格组件的响应速度和整体性能。掌握这些最佳实践对开发高性能 JSF 应用至关重要。
63 0
|
3月前
|
存储 设计模式 运维
Angular遇上Azure Functions:探索无服务器架构下的开发实践——从在线投票系统案例深入分析前端与后端的协同工作
【8月更文挑战第31天】在现代软件开发中,无服务器架构因可扩展性和成本效益而备受青睐。本文通过构建一个在线投票应用,介绍如何结合Angular前端框架与Azure Functions后端服务,快速搭建高效、可扩展的应用系统。Angular提供响应式编程和组件化能力,适合构建动态用户界面;Azure Functions则简化了后端逻辑处理与数据存储。通过具体示例代码,详细展示了从设置Azure Functions到整合Angular前端的全过程,帮助开发者轻松上手无服务器应用开发。
25 0
|
4月前
|
前端开发 JavaScript Java
文本----简单编写文章的方法(中),后端接口的编写,自己编写好页面就上传到自己的服务器上,使用富文本编辑器进行编辑,想写好一个项目,先分析一下需求,再理一下实现思路,再搞几层,配好参数校验,lomb
文本----简单编写文章的方法(中),后端接口的编写,自己编写好页面就上传到自己的服务器上,使用富文本编辑器进行编辑,想写好一个项目,先分析一下需求,再理一下实现思路,再搞几层,配好参数校验,lomb