admin/wikiZ-RedGuard
1
0
Fork 0
mirror of https://github.com/wikiZ/RedGuard synced 2026-06-08 18:18:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update README_CN.md

Browse Source
This commit is contained in:
风起
2024-08-21 01:42:09 +08:00
committed by GitHub
parent 72b3607167
commit 82c96c807b
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/README_CN.md
+4 -4
View File
@@ -86,7 +86,7 @@ HasCert = false
[^腾讯云]: 内容分发网络证书配置
相信看到这里，大家会有所疑问，**配置的证书怎么获得？如果使用自己申请证书是不符合我们预期想达到的隐匿效果。**这里可以使用克隆的证书进行配置，以腾讯云为例，测试中发现其不会对自定义上传的证书进行校验有效性，我们可以使用与加速域名实际站点相同的证书进行伪造。虽然伪造的证书在正常情况下替换CS的默认证书是无法通信的，但是在云服务厂商CDN全站加速和RedGuard上面部署是不会进行校验有效性并且可以正常通信C2交互流量。
相信看到这里，大家会有所疑问，**配置的证书怎么获得？如果使用自己申请证书是不符合我们预期想达到的隐匿效果。** 这里可以使用克隆的证书进行配置，以腾讯云为例，测试中发现其不会对自定义上传的证书进行校验有效性，我们可以使用与加速域名实际站点相同的证书进行伪造。虽然伪造的证书在正常情况下替换CS的默认证书是无法通信的，但是在云服务厂商CDN全站加速和RedGuard上面部署是不会进行校验有效性并且可以正常通信C2交互流量。
**以下为Github已有项目地址**
@@ -102,7 +102,7 @@ https://github.com/virusdefender/copy-cert
以上即为C2服务器伪造的证书效果，可以看到在微步社区的情报中是可信且未过期的状态，而其获取数字证书的主要途径也是在云沙箱进行样本分析时进行提取并实时更新的，但是显然没有经过有效校验，状态值仅对失效时间进行验证，证书可信验证应该是只以是否能够正常通信作为判断依据。
需要注意的是，微步情报并不会对样本请求的SNI及HOST的地址进行标注证书情报，这其实也是出于防止出现误报的考量，**我认为这是正确的，作为辅佐研判人员分析的重要依据，威胁情报宁可不全，也最好不要出现错误指向，对后续分析造成误判。**如果说在全站加速配置证书是伪造通信流量的证书，那么配置RedGuard C2的前置响应证书就是为了针对部署于公网的真实C2服务器的行为特征进行伪造，以实现抗测绘的效果，这是十分必要的。
需要注意的是，微步情报并不会对样本请求的SNI及HOST的地址进行标注证书情报，这其实也是出于防止出现误报的考量，**我认为这是正确的，作为辅佐研判人员分析的重要依据，威胁情报宁可不全，也最好不要出现错误指向，对后续分析造成误判。** 如果说在全站加速配置证书是伪造通信流量的证书，那么配置RedGuard C2的前置响应证书就是为了针对部署于公网的真实C2服务器的行为特征进行伪造，以实现抗测绘的效果，这是十分必要的。
提取证书序列号：`55e6acaed1f8a430f9a938c5`，进行HEX编码得到TLS证书指纹为：`26585094245224241434632730821`
@@ -558,13 +558,13 @@ Redirect = https://market.baidu.com
![image.png](https://github.com/wikiZ/RedGuardImage/raw/main/1660187188707.png)
当我们在打点的过程中拿下一台边缘主机，假设我们已经接管了Shell权限，这时我们将RG部署在这台服务器上以此作为我们的前置节点**（实战场景下，配置文件都是写死在程序中的，甚至将木马与RG结合为同一个程序）**。
当我们在打点的过程中拿下一台边缘主机，假设我们已经接管了Shell权限，这时我们将RG部署在这台服务器上以此作为我们的前置节点 **（实战场景下，配置文件都是写死在程序中的，甚至将木马与RG结合为同一个程序**。
**配置文件如下：**
![image.png](https://github.com/wikiZ/RedGuardImage/raw/main/1660183480032.png)
具体实现的相关配置我们主要关注箭头所指的地方即可，**上面的箭头1为内网主机与边缘节点交互的HOST域名**，这里建议根据目标单位具体场景设置相关内网域名，试想一下内网中两台主机关于内网域名的流量交互，BT有没有魄力直接切断交互流量呢，当然如果他们能够判断出是恶意交互流量的话。**箭头2所指就是常规域前置的设置**，这一个键值对，键对应的是上线的HOST而值则对应了代理的地址，这里我们可以设置为任意使用了相同CDN厂商的HTTPS域名即可**（CDN节点IP也可以的，记得带上http(s)://协议即可）**。
具体实现的相关配置我们主要关注箭头所指的地方即可，**上面的箭头1为内网主机与边缘节点交互的HOST域名**，这里建议根据目标单位具体场景设置相关内网域名，试想一下内网中两台主机关于内网域名的流量交互，BT有没有魄力直接切断交互流量呢，当然如果他们能够判断出是恶意交互流量的话。**箭头2所指就是常规域前置的设置**，这一个键值对，键对应的是上线的HOST而值则对应了代理的地址，这里我们可以设置为任意使用了相同CDN厂商的HTTPS域名即可 **（CDN节点IP也可以的，记得带上http(s)://协议即可**。
EdgeHost即为我们云服务厂商的域前置所使用域名，也就是RG边缘节点通过CDN节点至C2交互时所使用的域名，是的，RG会修改合法请求过来的HOST域名并修改为能够正常通信的云服务CDN域名。