0x01 前言：
这两天和某位师傅交流c2通信隐藏技术的时候，对于通过https隐藏通信中的https里面sni（server name indiication）的看法出现了一些分歧，于是有了此文，此文是对这个sni在c2通信隐藏技术细节上的一些详细分析，以及对新技术的探讨。
首先聊到通信隐藏，还有sni，那么我们先回顾了下域前置技术。
0x02 域前置技术
域前置这个技术20、21年hw的时候是非常火的，当时的红队基本上用过这个技术，技术的原理就是被大家都熟知的，“利用一些cdn节点在解析https报文的时候，会根据https内部的http报文中hostname字段来转发流量；”
那么域前置的技术就是利用这个点，将外层的https报文中的由客户端发起的clienthello中servername字段设置为一个白域名，然后内部的http报文中的host设置为c2的黑域名；最后在受害者的机器上看，流量其实就是访问正常白域名的流量，并且目的IP就是对于白域名所属cdn厂商的cdn节点；
大致就是如下图，其中abc.com是白域名，eval.com为攻击者注册同属A厂商cdn下的恶意域名；其实就是利用sni搭了个顺风车；
那么为什么近些年，这个技术被见到的变少了呢？
我们不妨从att&ck的角度看这个技术的对抗来综合分析，大致3年前，笔者在之前在奇安信攻防社区的发文中就提到过，原文如下：
其实说这么多，从原理看，用户侧就一个方法即解密https流量，核对sni和hostname是否一致；想要解析https流量这个就比较复杂了，就解密https流量，笔者曾就相关原理专门发过一文:一文搞懂加密流量检测的解决方法和技术细节 其中部分章节提到了这个解密方法；感兴趣的读者可以看下；简单说就是旁路做的话局限性比较强；只能串路做，这种要求就更高了（并且很多客户是不会使用的，因为串路做就是在中间人劫持，那么对于一些金融等相关敏感的https访问不可能让你解密的）；
在笔者看来：真正让这个技术“不再流行”的真正原因是，和上面提到的检测原理一致，就是核对sni和hostname是否一致，但是这个不是用户侧去检出了，而是大部分cdn厂商们对这个做了一些防御（用户侧不好解密，但是到了cdn节点都得解密），即cdn节点在做https报文解析的时候，如果发现sni和hostname不一致的情况，那么就丢弃这个请求，或者当成异常请求；
聊到这里我和那个师傅聊的都挺认可的；
0x03 借助sni的新技术？
于是此时我引入了一个新的技术点，我说近两年我发现的，对于域前置技术目前其实也出现了迭代更新，有些组织在使用；我陈其为“指定cdn节点的域名后置技术”；
他表示不解，这是个什么技术？
我大致说了下原理：
其实就是和之前一样，区别在于这里我们不再使用前置域名，即不再使用对应的白域名，也就是说https的客户端发起的clienthello报文里面不设置sni 即不设置域名；不设置域名之后，我们在给其指定cdn节点，即流量发向对应的cdn节点（其实我们不妨想一下，前面提到的域前置技术利用白域名的原因之一不就是为了让流量到对应的cdn节点嘛），这里我们直接给其指定目的IP为对应厂商的cdn节点同样也可以解决问题。
一切看起来是多么的天衣无缝；这里面真没问题吗？
其实细看还是有的，细心的师傅肯定能够一眼看到核心问题，即cdn节点遇到了没有sni请求流量的时候会怎么处理，他能握手成功吗？https会话能建立起来吗？
和域前置一样，核心是要看cdn厂商对这种流量的处理策略。
如果cdn厂商在对应的cdn节点会对sni和hostname进行校验，那就没有域前置技术的事情了；
同样的如果cdn厂商在对应的cdn节点会对不存在sni的https_clienthello直接当成异常报文抛弃，那么我们上面提到的这个”基于指定cdn节点的域名后置技术”就没用了；
然而现实中cdn厂商对此类流量（不存在sni的https_clienthello 流量）一般做两种处理：
-
1、直接丢弃
-
2、使用内置的默认证书和其建立后续的连接
那么当是后者的时候，就为该技术的利用创建了条件；
如下是笔者通过py脚本，实现了发送一个没有sni的https请求，并且在内部的http报文中指定对应的域名，最后相关资源被成功访问的案例：
此时我们截取流量，可以看到clienthello中没有提供域名，sni
同时如果看回来的流量，通过server的回包，我们可以看到，其使用的证书式xx厂商的证书，其实就是内置某厂商的一个默认证书；
如下是一个正常的存在sni的https_clienthello报文:
0x04 新技术的价值
最后那么我们不妨思考下，这种技术的价值是什么，对于c2的通信流量隐藏来说。
这里我们对比域前置来说：
先来看域前置，对于域前置技术来说，其可以伪装流量为向安全白域名访问的流量，从而使受害者不好对其进行封禁，也不好开展排查；因为一个对于的安全域名使一个使用率比较高的域名，日常办公都会使用到，那么此时的如果封禁，就会导致访问对于域名的业务中断；即正常访问对于域名的流量也会出不去；
那么这个“基于指定cdn节点的域名后置”技术能给用户排查带来哪些麻烦呢？
首先这个技术可以使用一批cdn节点，只要这些节点都是一个cdn厂商就行的；
从受2害者侧来看，其实就是有一个流量去了一个白的cdn节点，如下图
那么想要阻隔或者缓解以及检出 该怎么做呢，有两种方式：
1、如果在串路有对https流量做解析的设备，当发现sni不存在的https_clienthello流量时候，就丢弃；
2、直接封禁cdn节点，但是这里就会出问题，如果封禁了这个cdn节点，那么可能所有使用了该厂商cdn的域名就都访问不了了（技术实现的时候样本中可能会去内置n个指定cdn节点），这个受影响级别就非常非常大了；对于域名前置来说如封禁了其实就是影响对应域名提供上使用的某个三级域名的相关业务；而这里如果封禁了cdn，那影响范围就变成了所有使用了某个cdn厂商的服务商的所有域名的业务，影响范围不言而喻。
同时相比域前置来说，这个技术也有个短板，就是用户侧不需要对https解密，直接检测https的sni有没有就行，没有就抛弃（这里有一个隐式问题，就是是否存在一些奇怪的正常流量也没有sni，待考究，如果有，那么也不能这么做）
总之，笔者认为这个技术还是可圈可点的；并且近些年，在做威胁分析以及样本分析的时候，笔者也发现这项技术为一些组织持续在使用（顺便一提上面给的案例其实就是前两天分析的一个样本中提取出来的前置节点和后置域名）；
