译者:ForrestX386
预估稿费:200RMB
投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿
0x00. 前言
在这边文章中,我们将和读者一起近距离地剖析著名的、强大的、多才多艺的后门 软件:CARBANAK (又名Anunak)。具体来说,我们将着重介绍过去几年中关于CARBANAK 后门的一些使用细节,包括后门的配置,不同样本间的细小变化,以及后门的演变史。 通过对这些细节的分析,我们将对CARBANAK后门的幕后操纵者进行一些总结。有关CARBANAK后门的更多的详情信息,请参阅卡巴斯基、Group-IB与Fox-It公司的相关报告。
0x01. 技术分析
在正式切入本篇文章的主题之前,我们有必要对这个后门进行一个简要的技术分析,以便我们对这个后门的前前后后有个大致的了解。CARBANAK后门基于插件化的架构进行开发,功能完备且具备数据窃取能力,其中的一些功能模块包括:键盘记录,桌面录屏,VNC连接,HTTP 表单抓取,文件系统管理,文件传输,TCP 隧道,HTTP 代理,操作系统破坏,SHELL反弹,POS和Outlook数据窃取等。大部分的数据窃取模块自最早的CARBANAK 后门版本开始便已具备, 当然,随着后门变种的演变,后续的变种后门也增加了一些其他的数据窃取模块。
1)后门的监控进程
CARBANAK后门会启动(可通过后门配置文件可选地启动监控进程)一到多个监控进程进行持续的监控,不同的监控进程有着不同的目的。具体如下表所示:
表1
2)后门指令
除了后门自带的文件系统管理功能,后门的数据窃取模块支持多达34种指令,这些指令通过命令控制服务器下发给后门。经过解密之后,我们找到了34种指令相关的所有明文内容,这些指令都会跟着相应的参数,这些参数以空格隔开,看起来就像我们平时用的命令行命令。这些指令和参数的名字都会被计算成hash值,然后后门会去校验这些hash是否和预期一致,只有和预期一致才会执行,这就给我们恢复指令和参数明文内容的工作带来了很大的困难。
表2
3)后门配置
后门的配置文件位于后门的安装目录,以.bin为后缀,配置文件中包含了若干指令,这些指令拥有和表2中所示指令一样的格式,当后门启动的时候,这些配置文件中的指令都会被自动执行。当然,当后门接收到loadconfig指令的时候,也会自动执行这些位于配置文件中的指令。你可以把后门的配置文件当作是后门的启动脚本。配置文件中包含一个名为state的指令(当然是以16进制hash值表示的),这个指令会设置一个包含了一串布尔值(用ASCII码中的0 或1'表示)的全局变量。这一串布尔值中某些值表示后门和命令控制服务器之间的通信协议,有的值表示后门是否已经安装, 有的值表示PST监控进程是否已启动。不仅仅是state 指令,其他的所有指令都是以16进制hash值而不是明文名字被保存在配置文件中的,某些指令在执行时会自动将自己添加到配置文件中,以便它们在后门重启后自动生效(有的指令不需要重启后门)。loadconfig指令和state 指令在后门初始化期间就被执行,如果发现后门配置文件不存在,则重新创建一个,并将state指令写入配置文件中。
图1和图2 描绘了一些我们在调查中遇到的解码后的配置文件内容。
图1:增加一个新的命令服务器地址,强制数据窃取模块使用这个新的地址和命令服务器通信
图2:新增3个TCP隧道,指示后门进行桌面录屏
4)指令与控制
CARBANAK 后门和命令服务器之间的通信协议要么是伪HTTP协议,要么是自定义二进制协议
关于伪HTTP协议
伪HTTP协议中的消息字段被 '|' 字符分割开来,消息主体从主机ID开始,该主机ID由两段组成,其中一段是一串hash,这个hash 由主机名和主机MAC值计算而来,另一段是一个可能是标识活动代码的字符串, 一旦消息被格式化完成,然后就会有额外的个字段(这两个字段值由随机的大小写字符组成)包裹住这个消息内容。
图3和图4向您描绘了命令控制服务器轮询后门,获取进程列表信息的消息:
图3:命令控制服务器轮询后门,获取进程信息的消息
图4:后门响应后门消息
传输中的消息都会先经过RC2_CBC_PKCS5Padding (微软实现版)加密处理,然后再进行Base64编码, Base64编码的目的是将RC2_CBC_PKCS5Padding 加密结果中的'/' 和 '+' 分别替换成'.' 和 '-'. ,然后由随机的大小写字母组成的8位初始化向量值会增加到经过加密和编码后的消息前面。
然后后门会向载荷内的随机位置插入随机数量的'/'字符,这样会使得命令载荷看起来像一个URI,再然后后门会在载荷末尾增加一个携带参数的脚本后缀或一个不携带参数的文件名,如果是脚本后缀(比如php,bml,cgi等)这个脚本后缀会携带若干数量的名称和值都随机的参数值对;如果是一个文件名,这个文件的后缀名一般是gif, jpg, png, htm, html, php。
最后,这个看起来像URI的命令载荷会通过HTTP 的GET 或者POST 请求发送出去。如果是POST请求,那么POST请求body中可能会包含cabinet 格式的文件,图5是一个简单的通过HTTP GET 请求发送命令请求的例子。
图5
这个伪HTTP 协议会使用HTTP 代理监控进程发现的的任何代理配置 或者由adminka 指令配置的代理信息。 后门也会在注册表(HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings )和Mozilla Firefox 配置文件(%AppData%\Mozilla\Firefox\<ProfileName>\prefs.js)中搜索可用的代理配置信息.
自定义二进制协议
图6描绘了后门所使用的自定义二进制协议中的消息格式。 如果指令消息大于150字节, 它就会被一个目前还无法识别的的压缩算法压缩。 如果指令消息大于4096字节,它就会被分割成多个压缩块。后门所使用的这款自定义二进制协议这些年也发生了一些变化, 新的版本都会在旧的版本上做一些小调整, 二进制协议中的这些变化可能会使得现有网络签名无效,使得签名创建更加复杂和困难。
图6:二进制协议中的消息格式
版本1
在二进制协议的最早版本中,消息body内容会与主机ID进行异或运算,然后将结果保存在<chunkData>字段中,而且,初始化的消息是没有被加密的,这个初始化消息中就包含了主机ID。
版本2
这个版本不再使用主机ID作为异或key值, 这个版本会在每一个session中重新生成一个大小在32 到 64之间字节的随机key值,这个key值用于和消息body进行异或运算。
版本3
版本3给消息头进行了加密, 消息头的前19个字节(从消息内容开始位置直到<hdrXORKey2>字段为止)会与5个字节的随机key值进行异或运算然后被存储在<hdrXORKey2>字段中, 这5个字节的随机key值在每一个消息中都是不一样的。如果消息头中<flag>字段数大于1,用于加密消息体的异或key在加密和解密消息时反向进行迭代。
版本4
这个版本中,消息头的加密模式增加了一点小复杂度,首先会使用<hdrXORKey1>字段存储的异或key与消息头内容进行异或运算,然后再使用<hdrXORKey2>字段存储的异或key进行异或运算,最后将两次异运算的结果组合在一起并反转得到最终加密结果。
版本5
版本5算是我们遇到过的最复杂的二进制协议了,这个版本的协议中会用到256位的AES 会话密钥去分别加密消息头和消息body。在后门初始化的时候,这个256位的会话密钥会和整个的消息体一起用RSA交换加密算法加密,然后发给命令控制服务器。 后续的所有的消息都会被AES(CBC模式)加密,没有命令控制服务器的私钥,我们是无法获取用于加解密消息的会话密钥。
0x02. 综述
我们已经收集了220个CARBANAK 后门的样本,并编制了一张表,在这张表格中,我们突出显示了一些我们可以提取的有趣的细节。应该注意的是,在大多数情况下,后门被嵌入到另一个可执行文件或某种武器化的文档文件中。 表格中的MD5值是那些最终执行了CARBANAK后门的二进制文件最开始的计算值,但是有关CARBANAK后门的详细信息是我们在这些二进制文件运行期间从内存中提取出来的,这些提取的数据给我们提供了一些独特的视角,能够帮助我们去理解CARBANAK 运营方面的东东。这些提取的后门数据可以在这里被下载
不断进化的二进制协议
正如前文所述,CARBANAK后门的二进制协议这些年发生了一些重大的变化。基于我们搜集样本的编译时间数据,我们粗略地描绘了一下CARBANAK后门所用的二进制协议这些年的时间演进表(如图7所示)
图7:二进制协议的演进时间表
也许这张时间演进表并不准确,因为我们的视角也并不完整,但是它能够提供给我们一个大致概念,让我知道什么时间点开始,后门的二进制协议发生了变化。 通过我们的观察,我们发现一些带有数据窃取模块的后门构建版本中使用了过时的二进制协议,这可能表明,有多个独立构建的数据窃取后门在同时活动。
*注:* 很可能我们缺少早期构建的版本3样本
后门构建工具
为了使分析变得更加困难, 大部分CARBANAK后门中的字符串都被加密了,据我们的观察,在我们遇到的所有样本中,用于加密后门二进制文件中字符串的加密密钥和加密套件都是不同的, HTTP 伪协议中用到的RC2 密钥在不同的样本中也是不一样的,虽然一些样本的编译时间都是一样的。通过这些观察结果,再对比后门样本中必须配置的活动代码信息,我们推测,很有可能存在一个后门构建工具。
快速迭代的后门
尽管存在一个后门构建工具的可能,我们发现在我们的后门样本集合中有57个不同的编译时间,其中一些样本的编译时间相当接近。举个栗子,2014年5月20号,有两个编译时间相差4个小时的后门版本被构建,这两个版本都配置了相同的命令服务器地址。无独有偶,2015年7月30号, 也有两个编译时间相差12小时的版本被构建。
如此短的时间内,有哪些代码的修改是我们可以观察到的,而这些变化在构建工具中是无法呈现的?有一种可能,比如,有两个编译时间相近的后门,其中一个执行了runmen指令。从命令控制服务器下载了一个可执行文件wi.exe, 然后直接将这个可执行文件注入到进程中,而另外一个没有。还有一种可能,其中一个后门版本去检查IE浏览器的可信站点列表中是否存在blizko.net 这个站点,但是另外一个后门版本没有这么做。Blizko 是一个在线的内存传输服务。 我们已经发现, 在不同的后门中,启用的监控进程数也是不同的。 这些监控进程的变化也表明,为了适应特定的目标或者操作,后门的代码可以被快速的修改和编译。
活动代码和编译时间的关联
在某些情况下,我们发现CARBANAK 后门的的编译时间和后门的活动代码中的月份很相近,图8中展示了我们所观察到的,这两者之间的一些关联。
图8
CARBANAK 后门近期更新
最近,我们发现了一些64位版本的CARBANAK后门变种,我们已经在最近的博客中分享了有关这个变种的详细细节。某些后门变种默认一直处于潜伏状态,只有在指定的配置日期才会激活。
历史回顾
Carbanak 集团
大量公开的关于CARBANAK 恶意软件的报告所指向的就是Carbanak 集团,一群很可能是从事数据窃取等恶意代码活动的幕后黑手。 FireEye 公司已经追踪了若干个使用了CARBANAK后门 和其他关联后门工具的恶意活动,比如DRIFTPIN (又名Toshliph)。 仅靠目前掌握的数据来看,我们还无法确定这些恶意活动之间的关联, 是否他们都是出自于同一个犯罪集团之手, 或者这些恶意活动通过一些松散的附属原因共享了这些恶意软件与技术。
FIN7组织
迄今为止,Mandiant 公司所有的和CARBANAK后门有关的调查信息显示,这些恶意活动的都归功于FIN7威胁小组,FIN7组织自2015年中期以来一直非常积极地反对美国餐厅和酒店业。
FIN7组织将CARBANAK工具作为后期渗透工具,CARBANAK可以帮助他们立足于受害者网络,维持对受害者网络的访问,FIN7组织通过频繁地使用video指令去监控用户行为,并了解受害者的网络环境,通过使用tunnel指令建立隐秘的代理通道,使其隔离与受害者的网络环境。FIN7组织一直使用合法购买的代码签名证书来签署他们所用CARBANAK后门的有效载荷。 最后需要说明的是,FIN7组织所用的CARBANAK后门采用了一些新的技术,这些技术我们并未在其他涉及CARBANAK后门的恶意活动中有所发现。
我们已经在以前的公开博客文章中介绍了FIN7组织近期的相关活动:
FIN7发起的针对SEC档案的人员的钓鱼诈骗活动
FIN7组织的演进历史和钓鱼相关的链接
FIN7组织利用Shim数据库漏洞进行持久化攻击
FireEye iSIGHT 威胁情报服务门户MySIGHT网站中包含了有关我们对FIN7组织所从事的恶意活动的其他一些调查信息。
针对位于美国、亚洲和中东的银行的广泛攻击活动
Proofpoint公司最先报道了2016年初针对美国和中东地区银行与金融机构的广泛攻击活动。我们锁定了这个地区其他几个与此次攻击活动有关的组织,此外,东南亚和亚洲西南部的银行与金融机构也被同一个攻击者攻击过。
这一系列攻击活动从2014年年底开始持续到2016年初,最特别的一点是,这次攻击活动中所使用到基础设施也被其他恶意软件使用过,比如LAZIOK,NETWIRE等
DRIFTPIN 后门
DRIFTPIN(又名Spy.Agent.ORM和Toshliph),它的身影早在以前和CARBANAK后门有关的攻击活动中就多次出现过,我们发现早在2016年上半年的一次钓鱼诈骗攻击活动中,FIN7组织就曾经使用过它。此外,在2015年年底,ESET报告了与CARBANAK后门相关的攻击事件,详细介绍了针对俄罗斯和东欧银行的钓鱼诈骗活动,这些攻击事件中就曾使用DRIFTPIN 后门作为恶意代码载荷。Cyphort实验室还透露DRIFTPIN 后门的变种已经在一系列的攻击活动中被发现,我们在两个被攻击过的乌克兰银行网站山发现,DRIFTPIN 后门的变种通是通过RIG 漏洞攻击套件被植入到受害者系统上的。
来自FireEye iSIGHT威胁情报分析服务的结果显示,这一大波的钓鱼诈骗活动的目标包括美国金融机构和与比特币交易与采矿活动相关的公司。到现在为止,这一波钓鱼诈骗活动仍在进行,有关这次攻击活动的最新消息,请参考FireEye iSIGHT威胁情报服务MySIGHT的门户网站。
早期的CARBANAK 攻击活动
2014年12月,Group-IB和Fox-IT公司发布了一份关于一个有组织犯罪集团的报告,该犯罪组织使用了一个名为"Anunak"的恶意软件,对东欧、美国和欧洲的银行的POS系统进行攻击,卡巴斯基于2015年2月发布了一份名为“Carbanak”的类似报告。"Carbanak"的名字首次被卡巴斯基提出来,而恶意软件作者将此后门称为Anunak。
这次攻击活动与2014年针对乌克兰银行ATM 系统的攻击活动有关, 早期的这种攻击活动和当下FIN7组织的某些行为比较类似。
0x03. 总结
从CARBANAK 后门样本中提取的详细信息为我们提供了一个独特的洞察视角,通过这个视角,我们可以发现用于窃取数据的恶意软件背后的一些操作细节, 通过上面的分析和讨论,我们可以得出以下几个结论:
通过我们所分析得到的信息,我们相信
1)至少有一些CARBANAK 后门的操控者要么可以直接访问和修改后门源码,要么就和CARBANAK 后门的开发者有着密切的联系。一些CARBANAK 后门的操控者甚至可以独自编译相应的后门版本。
2)这些攻击者可能正在使用一种构建工具,这种构建工具允许后门的操控者配置后门,比如配置命令控制服务器的地址, 命令控制服务器的加密密钥和活动代码,这种构建工具会在每一次进行后门版本构建的时候都会使用新的加密密钥去加密后门二进制文件中的字符串。
3)不同的活动代码暗示, 独立或者松散附属的犯罪分子正在使用CARBANAK 后门对各行各业,尤其是对全球金融机构以及美国境内的餐饮和酒店业,进行广泛的入侵攻击。
本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:https://www.fireeye.com/blog/threat-research/2017/06/behind-the-carbanak-backdoor.html
还没有评论,来说两句吧...