域前置溯源方法思考

 

前言

最近频繁被问到关于域前置溯源的问题，但是在工作中实际遇到的不多，这几天有时间整理了下思路，如有不对的对方，多多包涵，欢迎评论指出。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所示。

图8

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

动态过滤

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

图9

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

图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分析