基于边界节点链路交互C2流量

作者：风起

前记

大家好，我是风起，相信之前有不少小伙伴了解过《C2设施前置流量控制技术》，本次分享的是基于RedGuard实现的C2流量高级隐匿手法，具体实现也是基于在打点过程中，当已获取到边缘主机权限并以此作为节点从而实现与内网主机进行隐蔽的流量交互，同时赋予域前置、流量控制，沙箱分析规避等效果。通过自定义内网主机交互域名，而边缘主机使用域前置CDN节点交互。达到了两台主机之间交互信息的不对称，使溯源难度更大，难以排查。

本文是C2前置流量控制技术的一种延伸技巧，所以主要也是从效果实现及思考的角度出发，下面我会侧重于技术实现的过程进行讲解并剖析该技巧的相关优异性。

技术实现

在攻防对抗场景下，目前大部分单位网络仍然是边界化防御，这里我们思考一个场景就是当处于DMZ区域的对外服务器在进行正常的业务环境下，往往都会配置相关出入网策略，这时当边缘的对外服务器能够出入网但不能直接访问内网主机，内网的PC或者相关服务器不直接访问公网，但是能够访问DMZ区域的业务服务器，这时我就可以将边缘节点的主机作为一个RG节点，将内网上线流量中转至我们的C2设施上，是不是听起来与常规的代理中转上线很像？但是，这只是技巧实现的一种展现形式，更多的TIPS我们继续往下看。

当我们在打点的过程中拿下一台边缘主机，假设我们已经接管了Shell权限，这时我们将RG部署在这台服务器上以此作为我们的前置节点（实战场景下，配置文件都是写死在程序中的，甚至将木马与RG结合为同一个程序）。

配置文件如下：

具体实现的相关配置我们主要关注箭头所指的地方即可，上面的箭头1为内网主机与边缘节点交互的HOST域名，这里建议根据目标单位具体场景设置相关内网域名，试想一下内网中两台主机关于内网域名的流量交互，BT有没有魄力直接切断交互流量呢，当然如果他们能够判断出是恶意交互流量的话。箭头2所指就是常规域前置的设置，这一个键值对，键对应的是上线的HOST而值则对应了代理的地址，这里我们可以设置为任意使用了相同CDN厂商的HTTPS域名即可（CDN节点IP也可以的，记得带上http(s)://协议即可）。

EdgeHost即为我们云服务厂商的域前置所使用域名，也就是RG边缘节点通过CDN节点至C2交互时所使用的域名，是的，RG会修改合法请求过来的HOST域名并修改为能够正常通信的云服务CDN域名。

EdgeTarget是内网交互的域名，与箭头1需要相同，也只有HOST为这里设置的域名请求的流量才会被认为是合法的，RG才会进一步修改为云服务CDN域名从而进行后续通信。

这里我们总结一下：

就是边缘节点与内网之间主机的交互即通过设置的内网域名，当木马发起请求至RG的边缘节点，会判断请求流量HOST是否为配置文件中设置的内网域名，如果符合则认为是合法的RG会修改HOST为EdgeHost设置的云服务厂商CDN域名进行后续通信将流量中转至C2服务器，实现了整个链路的全隐匿高度混淆。试想一下，内网域名与边缘节点交互的是内网域名，然而边缘节点又进一步更改了实际交互的代理地址及交互HOST，达到了两台主机之间交互信息的不对称，使溯源难度更大，难以排查。

边缘节点与内网主机交互流量，如上图所示

这样方式还有一个好处就是针对云沙箱环境下，由于我们的交互IP是根据内网定制化的，那么沙箱在分析时不可能针对内网IP进行连通性关联分析。

在配置的时候需要注意一点，就是木马请求时的HOST应该是：

HOST：内网域名（RG配置文件中的设置的）
IP：边缘主机内网IP
上线端口：443（与RG配置文件http(s)监听端口匹配）
监听端口：C2实际上线的端口

C2监听器设置如下：

与请求相对的是C2监听器的HOST应该是云服务厂商CDN域名，只要最终流量能够中转到C2服务器即可。

内网节点交互流量，如下图可以看到正常的对DMZ区域的内网IP访问了443端口，内网服务器或者PC与DMZ区域的业务系统有连接也不足为奇吧。

边缘主机的交互流量如图所示，实际场景下不会有大量的TIME_WAIT，这里因为为了测试我把心跳包sleep设置为了0，实战场景下设置较大的心跳包抖动以及sleep时间是比较稳妥地。并且个人觉得实战场景下没有使用HTTP流量的，明文流量这不是给态感白给吗哈哈？所以一般这一端口是不会开启的，我们再将RG的文件名改成Tomcat、Apache，Nginx之类的使其交互看起来更加迷惑一些。

说到了心跳包抖动跟sleep时间的问题，直接在Malleable C2 Profile文件中设置以下字段即可。

set sleeptime "3000";
set jitter    "20";

如果不进行设置的话，则可能出现异常心跳包告警，当然多数情况下研判人员都会认为是误报从而忽略，但是为了稳妥起见，建议配置一下就不会引起异常心跳包的告警了，当时是通过360 NDR设备测试的，具体效果如下：

而对于HTTPS的流量，市面上任何一个流量监测设备都是无法审查流量的，目前的监测设备本质上都是敏感词匹配，甚至于某个厂商设备数据包检测的比赛中，要求使用明文包，不禁让人怀疑在实战场景下真的会有RT用明文流量交互吗？

而除了上面讲到的交互信息不对称，这种方式最大的好处就是将RG节点放置到了边缘节点从而实现前置流量控制，从而赋予与常规RG相同的功能效果。

攻防演练中防守方根据态势感知平台针对C2交互流量的分析溯源
根据JA3指纹库识别防范云沙箱环境下针对木马样本的恶意分析
阻止恶意的请求来实施重放攻击，实现混淆上线的效果
在明确上线服务器IP的情况下，以白名单的方式限制访问交互流量的请求
防范网络空间测绘技术针对C2设施的扫描识别，并重定向或拦截扫描探针的流量
支持对多个C2服务器的前置流量控制，并可实现域前置的效果实现负载均衡上线，达到隐匿的效果
能够通过请求IP反查API接口针对根据 IP 地址的归属地进行地域性的主机上线限制
在不更改源码的情况下，解决分阶段checksum8规则路径解析存在的强特征。
通过目标请求的拦截日志分析蓝队溯源行为，可用于跟踪对等连接事件/问题
具有自定义对样本合法交互的时间段进行设置，实现仅在工作时间段内进行流量交互的功能
Malleable C2 Profile 解析器能够严格根据 malleable profile验证入站 HTTP/S 请求，并在违规情况下丢弃外发数据包（支持Malleable Profiles 4.0+）
内置大量与安全厂商相关联的设备、蜜罐、云沙箱的IPV4地址黑名单，实现自动拦截重定向请求流量
可通过自定义工具与样本交互的SSL证书信息、重定向URL，以规避工具流量的固定特征
……….

而RG节点的后置节点变为了CDN节点转发至C2服务器，常规场景下域前置都是作为第一层请求节点的，而边缘主机上线则放置到了RG之后实现上线，DMZ区域的业务系统与公网CDN IP交互看起来也是那么的和谐。而在这个过程中，内网主机以及边缘主机都没有直接与我们的C2进行交互，也是这种高级隐匿手法优雅所在。

当然除了上面提到比之netsh、iptables代理中转上线更好的因素之外，简易的配置以及不存在配置记录也是优点之一。

后记

已经很久没有写过后记了，还是想写一下后续的一些打算吧。本文大概也是未来一年我的最后一篇文章了，之后我可能会短暂的退圈一段时间，去追逐一些，自己真正需要去做的事情，仍然感谢一些老读者一直以来的关注。

是的，我今年20岁了，在安全圈里也有几年的时间了，也一直偶尔的活跃着。一直以来碰到了很多有意思的师傅，哪怕今年HW也碰到了几个饭友哈哈哈？当然，我也一直都说，出来工作的环境下，好人总是比坏蛋少得多，时至今日仍然吃过不少亏，我也发现，我已经没有当初第一次实习时对工作富有热情且滚热的心了，我是一个很容易就对自己妥协的人，所以哪怕我仍然在学习新的东西，努力的进步提升自己，我觉得更多的是心境上对待事情没那么的滚热了。所以我所说的退圈可能不仅仅是离开视野继续学习，我会放下技术一年的时间，安心复习，可能等再次回来我就该真正的确定自己未来的方向了，针对某个方向侧重的进行研究吧。

期待一年后再次与大家相遇，继续分享我研究的安全技术。

Community

有想要认识一下，或者交流技术的同学，可以通过Wechat联系作者:

（完）

前记

技术实现

相关导读

后记

Community