域前置溯源方法思考

阅读量    180038 | 评论 2

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

前言

最近频繁被问到关于域前置溯源的问题,但是在工作中实际遇到的不多,这几天有时间整理了下思路,如有不对的对方,多多包涵,欢迎评论指出。2017年火眼爆出APT29至少在2015年就已经使用域前置技术规避流量审查。所以域前置已经不是新技术了,但在今年的HW中着实火了一把。有效的域前置溯源方法是一个很值得研究的问题。

 

域前置原理

域前置是什么?怎么用?参考1和参考2的两位小哥已经说的很清楚了,我就不再赘述了。为了更清楚的阐述域前置溯源思路,重点介绍一下域前置在使用部署过程中的几个关键点。

图1

如图1所示,结合Cobalt Strike,简要分析域前置利用过程。首先图1中有5个Host,Host1和Host2都是白域名,要保护的是Host4和Host5,当然Host5不是必须的,也不是所有的CDN服务商都可以自定义回源Host。

1、受控端的Payload根据Host1 DNS解析得到Host1的CNAME,CDN根据CNAME和地理位置返回一个CDN的IP,并通过Host1的SSL证书建立Https通信。
2、受控端的payload中Http Header中的Host为Host2。在CDN配置的时候Host2要和Host3一致,根据Host2匹配得到Host3对应的回源地址Host4。
3、CDN向Host4发送回源的http(https)请求,http header中的host为Host5。
4、主控端根据Host5确定响应的服务。Cobalt Strike的默认配置中没有设置代理,直接监听的80或443端口,Host5没有发挥作用。

 

域前置溯源思路

首先要说明的是,域前置溯源的前提是拿到了样本,也就是运行在受控端的Payload。先介绍下整体的思路,溯源目的就是为了找到Host4,因为样本是基于白名单域名的Https协议进行通信的,从流量的角度是无法获取Host4。说到这不得不提APT网络资产测绘的方法,如图2所示。

图2

APT网络资产测绘的过程如下:

1、根据已经拿到的资产获取Web指纹(开放的服务及版本、端口等)、Banner信息,分析获取测绘特征。
2、根据测绘特征在Zoomeye、Fofa、Shodan等平台搜索,通过时间、地区等条件初步筛选,获得资产列表,这个列表可能很大。
3、通过分析样本,获取通信特征(Uri、回包大小、Header等)向资产列表发通信包,动态过滤;根据已有资产规则(IP段分布、IDC服务商、域名构造特征、证书服务商等)人工静态过滤,得到较精确的网络资产列表。

写到这感觉跑题了,这跟域前置有啥关系?客官稍等,马上域前置就出来了。
在域前置的情况下,无论是从样本还是从流量中都无法获取Host4,所以只能从反面,也就是通过扫描探测获取信息与正面访问得到的Banner信息进行匹配,具体过程如下:

1. 根据样本中获取到Host1与Host2,发请求包获取C2的Banner信息。
2. 根据Banner信息Zoomeye、Fofa、Shodan等平台搜索,通过时间、地区等条件初步筛选,得到一个IP列表。
3. 根据样本中特有的通信特征,向IP列表发包,根据返回确定是不是要找的Host4。

其实这个思路就是借鉴APT资产测绘的思想。

 

实验验证

CDN注册

一共测试了三个主流CDN厂商,分别叫A、B、C吧。A厂商需要验证域名归属,Host2所以无法使用白域名,自己注册域名后,还是可以实现域前置的,只不过无法隐藏Host2。

图3 A厂商

C厂商要求最严,需要备案接入。

图4 C厂商

图1中的就是B厂商,不在另外贴图了。参考2和参考3的两位老哥使用的都是B厂商,目前已经在B厂商的SRC上提交了。

CS上线

根据图1,使用的Host1是ask.qcloudimg.com;Host2用的是参考3的老哥使用的域名的一个子域名img.xxx.com;Host3在配置成Host2;Host4是C厂商的云服务器;Host5是helloworld.com。
正常配置CS的Listener、Payload可正常上线。

图5

值得一提的是:

1. 参考1和参考3都提到需要将amazon.profile中的header host修改为host2,其实不用(经过测试),因为在配置Listener的时候已经设置了header host(如图1)。
2. 在CDN回源的时候,其实没有必须要采用Https,那样的话,需要自签证书,在实验的时候,用Https的payload,CDN http回源,使用Http的Listener可成功上线(如图5所示)。

获取测绘特征

如图6所示,首先获取Banner信息。

图6

测绘特征(ZoomEye的语法):

"HTTP/1.1 404 Not Found Content-Type: text/plain Date:" +"GMT Content-Length: 0"

这里只是简单的写了下,举个例子,如用攻击者通过配置文件是可以改变Client和Server端的Banner信息。结果如下:

图7

通过时间过滤可以发现,规模为10000+。通过Zoomeye找CS后端参考4说的比较详细,有兴趣的同学可以看下。验证了下列表中的第一个IP,如图8所示。

image.png

图8

有的同学可能会问:使用Zoomeye等平台的时效性能保证吗?毕竟很多时候攻击者搞完一梭子就撤了,这个问题下一节会提到。

动态过滤

首先通过分析样本,获取通信特征,如图9。我只是简单看了下通信过程,参考5分析详细分析了CS Http payload的样本。

图9

从图9中可以看到payload访问的uri为/h6Qm,下一步就是向列表发包,这一步由于CS控制端是刚部署且测试完后就关了服务器,Zommeye应该扫不到,直接向host4发uri为/h6Qm的包,结果如图10 所示。应该是下一步的shellcode。

image.png

图10

只要给Zoomeye搜索获取的IP列表发包获取图10的结果,具有较大可能为Host4。在分析样本的过程中,可能还会有会话相关的数据,带上这些数据可能会得到更丰富的结果。
Zoomeye的时效性,一般为天的数量级,所以时效性确实是一个问题,如果能缩小Host4的范围,如参考1中提到,Host4必须为CDN服务商自己的云服务器,那么可以直接跳过Zoomeye搜索,直接向缩小了且可承受的IP列表的http(https)端口发包,根据返回结果确定是否是Host4。
图11为通过Host1和Host2发包的结果。

图11

 

域前置使用的改进

一般APT的C2不会直接使用CS的Listener,还有图1中的Host5一直没有使用,确实浪费,配置的是helloworld.com。

图12

在B云上部署了另外一个白域名的CDN,Host5设置为helloworld.com,在host4上配置了一个Nginx反向代理,并创建了一个站点host为helloworld.com, 从外部是无法通过helloworld.com访问该站点,因为helloworld.com并没有解析到Host4上。Host4上通过Nginx代理在80端口上有多个站点。

图13

通过域前置访问结果如图14所示。

图14

从结果可以得出,如果在只知道Host4前提下,是无法访问到Host4上的Host5站点,其实说到这一切都显得那么美好,与必须通过Host1+Host2才能找到回源的站点,原理其实是一样的,CDN不过是云服务商提供的多级路由的反向代理系统,所以CDN具有负载均衡、隐藏业务系统真实Host等Nginx也具有的功能。
绕了这么大一圈,其实就是想说,在CS控制端的前面加上一个反向代理,并通过Host5将请求转发给CS的Listener,这样的话,ZoomEye等平台是无法通过扫描的方式获取Listener的Banner信息。即使分析出样本的通信规则,也无法通过IP列表扫描的方式访问CS的Listener,原因是无法获取Host5(暴力猜解除外)。

 

总结

终于写完了,不知道有没有说清楚。通过Banner信息测绘与基于样本通信特征扫描的方式获取域前置的真正Host。不知道为啥图片上传后看不清。

 

参考

1. 暗度陈仓:基于国内某云的 Domain Fronting 技术实践
2. 域前置,水太深,偷学六娃来隐身
3. cobaltstrike域前置
4. 利用 ZoomEye 追踪多种 Redteam C&C 后渗透攻击框架
5. 深度分析CobaltStrike(一)—— Beacon生成流程及Shellcode分析

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多