本文仅供安全研究学习使用
前言
早先找实习的时候了解了一下玄武实验室，再读了一遍玄武那篇域前置的文章，这里贴一下链接
https://xlab.tencent.com/cn/2021/05/14/domain-borrowing
这是篇老老老文章了，这篇文章里提出了利用公共 CDN 服务来做 C2 通信的隐藏的一种手法
在防火墙来看，高可信域名+高可信 IP，唯一瑕疵就 DNS 对不上。即使是专门部署 TLS 解密设备来针对这一类的，一看 Host 对的上，也大概率放行。所以走这种 TLS 的 c2 流量是非常难去识别的，因为他伪装得实在是太好了。
但是想要用这个手法做隐蔽通信有个前提，就是需要在 CDN 厂商那边创建这个高可信域名的资源。
大多数的 CDN 供应商，他们的 CDN 往往都会有一个所有权校验，只有你证明你拥有这个域名，你才能创建这个域名的一个 CDN 资源。
在做 DNS 校验的 CDN 厂商创建 CDN 资源比较困难，DNS 污染是运营商层面的东西了。
不过在规模比较大的提供 CDN 服务的云厂商中，AWS 的验证方式是少数不同于其他的，他需要的是一个域名下的TLS证书用作所有权校验，因此利用这个手法做隐蔽通信的一个最低门槛，就是必须要有一个来自高可信域名的证书。
原文提到这点时，建议利用漏洞获取证书，但是这并不容易，越是高可信的域名，他背后的公司组织可能其实做的防御越强，所以域前置就有了这样的一个硬门槛。
那么，有没有办法以较低的代价得到一个来自高可信域名的证书呢？
PCDN 与证书
PCDN 中文又称点对点内容分发网络，你可能没实际玩过，但是肯定也听说过运营商封杀 PCDN 的事情。
PCDN 的出现是因为正常的 CDN 和商业宽带的价格比较高昂，尤其国内这种宽带金贵的地方，所以就出现了利用用户闲置的上传带宽做内容分发的应用，他被称之为 PCDN，对企业而言 PCDN 最最显著的特点就是廉价。
既然上面提到，PCDN 是用户在扮演CDN做内容的上传，那么当他跑 HTTPS 流量的时候，他是怎么实现 TLS 加密的呢？
没有什么花活，他就是单纯地把相应的 TLS 证书交给了用户，然后做了一些加密，不让用户能够简单获取到证书。
那么既然证书都给我们了，而且在我们本地做到解密，我们肯定是可以解密出证书的原始内容的
无论有些是有现成的脚本，有些可能需要你做一点点逆向，总归是有办法拿到原证书的，这里就不具体阐述证书是怎么拿到的了。
这就是我拿到的 fullchain 证书和 key，有这个 key，我们就可以过AWS的域名所有权校验从而获取一个 CDN 资源了
验证
AWS cloudfront 就是其 CDN 服务，需要证书,key,fullchain(可选)来创建一个 CDN 资源
AWS 有自己的证书托管服务，叫做AWS Certificate Manager (ACM)，给 CDN 用的证书首先需要在上面导入
证书正文需要费点心思从fullchain里拆出来，一般就是fullchain里的第一个证书，至于私钥和fullchain应该已经从PCDN那边解密出来了，具体的格式不是pem的openssl转换一下再上去就可以了，AWS只接受PEM格式
添加一个备用域名(即证书的域名)然后导入证书，最后关闭所有CDN缓存，仅转发。
具体的C2就不演示，我们让cloudfront指向另一个网站，再改一下本机hosts（毕竟你是改不了DNS的），看看能不能访问到，如果能访问到那么这个信道就其实是可用的
很对，符合预期。
防御&检测方案
这个方案最大的缺陷就是域名和 IP 对不上，完全可以通过校对域名和 IP 是否匹配来阻断连接。但是与此同时，所有的 PCDN 连接都会被阻断，因为他们也具备域名和 IP 不匹配的特性，不过这其实有点杀敌一千自损八百的感觉了，还是部署 TLS 流量劫持和解密设备或许来的比较稳妥。
在 PCDN 提供商的方面，为了防止证书滥用，可以考虑给不同的用户签发不同的证书，签发时给证书中加入一些用户身份字段，当这个证书被滥用时，可以轻易找到证书泄露的源头。不过 PCDN 个人感觉另一边运营商在打击，显得有点灰了，可能也不太好去做这件事。