域名前置(Domain Fronting)

作者:{ XHJ, Anice }@ArkTeam

1 前言概述

域名前置(Domain Fronting)的设计初衷是逃避网络审查,但因其良好的网络穿透性,很适合应用于APT/Malware远控之中。本文用M代表普通的Malware,DFM代表支持Domain Fronting的Malware,cc.com代表由攻击者控制的C&C服务器域名,S代表部署在网络边界的内容审查系统/异常检测系统等安全设备。

2 恶意代码远控模型

图1.1 M运行流程(1)

M运行时会直接联系硬编码的C&C服务器(cc.com)。一般情况下,cc.com是一个十分生僻的域名(多数知名APT事实上都在访问生僻域名),此时,部署在网络边界的S可能会发现该异常流量进而进行预警或阻断。而且,随着S智能化程度的提高,检出能力也与日俱增。一旦cc.com被阻断,M便会失控。即便M支持Domain flux(ArkName即将推出),可生成cc2.com、cc3.com,面临的命运也并无两样。

图1.2 M运行流程(2)

为绕过S的限制,攻击者可通过白名单服务(如Google App Engine、Amazon)来转发客户端M和C&C服务器之间的流量。以Google App Engine为例,攻击者需配置生成一个以appspot.com结尾的子域名(如test.appspot.com),再部署一个Web程序用于转发流量,该Web程序会硬编码“cc.com”字符串。这样,所有发往test.appspot.com的流量都会被Web程序转发给cc.com。因此,对于客户端M来说,可通过test.appspot.com与cc.com取得联系。然而,当S发现test.appspot.com存在恶意行为时,依然可将其添加到黑名单之中,问题并未得到有效解决。

3 支持Domain Fronting的恶意代码远控模型

图2 DFM的运行流程

对于DFM而言,当其开始运行时,会直接与支持Domain Fronting的服务联系。以Google为例,其支持Domain Fronting的服务有www.google.com、gmail.google.com、maps.google.com、youtube.com、ssl.google-analytics.com等。DFM运行时直接联系https://www.google.com,并将Host字段设置为test.appspot.com。因为流量经过TLS加密,S无法看到Host明文。www.google.com将收到的流量解密、转发给test.appspot.com,最终该流量会被转发到cc.com。在整个远控过程中,只有Google知道cc.com的存在,对M样本的逆向分析只能看到test.appspot.com。对防御人员而言,即便知道Google有可能承载、转发恶意流量,但也不能轻易封锁。

发表评论

电子邮件地址不会被公开。 必填项已用*标注