Security

fscan 可能是国内最早最知名的内网端口扫描器之一了，最早知道这个扫描器是因为他的速度，比起 nmap 来说是真的快了不少。 听说 fscan2 快要出了，想到自己还没学习过鼎鼎有名的 fscan 的源码，略感惭愧。于是心血来潮决定来对比学习一下第一代 fscan 和即将发布的 fscan2 之间。 略有困意 我们先看看经典的老版本 fscan 吧，看看多年实战历练的代码是什么样子的。 这个项目结构很简洁啊，一眼望去可以看到 Plugins WebScan common main.go 没了，就这 4 个，大小写略有混乱无伤大雅，一眼望过去 common 就是我们的核心了，Plugins 明显是各种协议，设计成 Plugins 单独提出来，非常阳间，WebScan 是针对于 http 的一些专用探测和 poc，太简洁了，牛逼。 对的对的，那我们这就打开 common 看看吧，整体主逻辑肯定就在里面了跑不掉，非常符合我们的幻想啊，太棒了。 Parse.go ParseIP.goo ParsePort.go config.go flag.go log.go proxy.go 这对吗，我的 Scanner 呢？ （沉默片刻） 或许我应该看看 main.go … func main() { start := time.Now() var Info common.HostInfo common.Flag(&Info) common.Parse(&Info) Plugins.Scan(Info) fmt.Printf("[*] 扫描结束,耗时: %s\n", time.Since(start)) } 原来 Scanner 的主逻辑也是一个 Plugins，super 插件化，狠狠插拔，一切皆为插件，我的我的，太兴奋了没有先看该看的东西。...

本文仅供安全研究学习使用 前言 早先找实习的时候了解了一下玄武实验室，再读了一遍玄武那篇域前置的文章，这里贴一下链接 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 证书交给了用户，然后做了一些加密，不让用户能够简单获取到证书。 那么既然证书都给我们了，而且在我们本地做到解密，我们肯定是可以解密出证书的原始内容的 无论有些是有现成的脚本，有些可能需要你做一点点逆向，总归是有办法拿到原证书的，这里就不具体阐述证书是怎么拿到的了。...