Redc 红队基础设施多云自动化部署工具

在红队日常作业中，我们可能往往会陷入这样的循环：购买 VPS、登服务器、配置环境、下载脚本、调试报错....

好不容易搭建完，扫描速度一快ip封了，得不停切换，自建的代理池抓的 ip 大部分都用不了，而且访问速度太慢。买的 vps 上面跑了无数个服务，又是 frp 又是 jndi，时不时 nuclei 扫描，还得起 cs/vshell，还得开文件服务，多开几台机器用不上还浪费。部署完的C2/dnslog 才开 3 天就被威胁情报标记了！当项目结束，这些机器要么被遗忘持续扣费，要么被手动销毁，下次项目开始时又得重复配置。

面对高频的攻防演练和愈发严格的防守策略（如 IP 封禁、威胁情报标记），单机基础设施已无法持续对抗体系化防守，必须转向一次性、分布式、多云模式。正所谓“缺一项即断链”，基础设施的完整性是行动成功的基石。

为解决这些痛点，我们开发了一款红队多云部署工具 Redc,实现“基础设施即代码”（IaC）的工程化能力。

Redc在团队内部应用效果不错，得到了很多师傅好评，我们计划将其贡献给社区，结束重复造轮子的时代。

希望通过共建社区生态，完善Redc，拓展更多应用场景

让基建自动化成为红队必备

IaC理念

Redc 基于IaC （Infrastructure as Code） 理念开发，将一切云资源定义为代码，将服务器、网络、存储等基础设施配置写成代码一次编写，长期复用，无人为参与，减少配置错误，轻松实现多云资源调度。Terraform 是一款开源的IaC工具，支持通过配置语言来自动化部署云服务，使用 以 .tf 结尾的配置文件，配置文件使用HCL语言。

# Terraform 代码片段
provider "aws" {
  region = "ap-east-1"
}
resource "aws_instance" "node" {
  count = "${var.node_count}"
  launch_template {
  id = "模板ID"
}
instance_type = "t3.micro"
user_data                   = <<EOF
# 自定义初始化脚本…
EOF
}

Terraform 的场景生命周期可以简化为 (实际上不止，但可仅关注这 3 个)

初始化 → 部署 → 销毁
 Init 		Apply    Destroy

Redc解决什么问题

Redc 基于 Terraform 封装，将红队基础设施的完整生命周期（创建、配置、销毁）进一步简化。

类似f8x等单机环境部署脚本是在服务器启动后运行的初始化脚本，很好用，但没有解决“从 0 到 1 获取并管理资源”的问题。

可以说 Redc 不仅仅是装机工具，更是对云资源的自动化调度器！

我们基于 Redc 实现了：

• 一条命令交付，从购买机器到服务跑起来一条龙，无需人工干预
• 多云部署支持，适配阿里云、腾讯云、AWS 等主流云厂商
• 场景预制封装，红队环境 ”预制菜“，再也不用到处找资源
• 状态资源管理，本地保存资源状态，随时销毁环境，杜绝资源费用浪费

1. 按照 22、23、24 年数据进行统计

2. 场景指： C2、DNSLog、Java 利用、文件投递、协同工具、代理池、扫描工具、内网穿透

节省成本

同时Redc使用了以下方案节省成本

抢占式实例/Spot 实例

利用公有云闲置资源的低成本实例，价格实时浮动，相比按量付费最高节省90%，库存不足或出价低于市场价时会被中断回收。

适合短期、可中断、容错性高的业务,不适用于数据库、长时间稳定运行的任务，而我们的代理池场景、和扫描节点场景刚好适合这种实例。

R2存储全球回源

大量场景需要静态文件的依赖，例如 jdk、c2服务端、前端编译打包等。利用Cloudflare  R2无出口费用的对象存储解决方案，将大文件存储在R2，通过rclone实时更新维护，实现静态资源流量费降至0

安全性配置

aws 场景启用IMDSv2，要求获取元数据时必须携带Token，有效防御SSRF攻击导致的AK/SK泄露。

❝

旧版 (IMDSv1): curl 169.254.169.254  直接访问metadata。

新版 (IMDSv2): 需先 PUT获取TOKEN ，再携带Header访问，显著降低泄露风险。

在user_data初始化完毕后，会通过配置iptables 禁止访问metadata，彻底杜绝 metadata ssrf 风险。

除部分需 ssh 登录使用的机器外，均采用 ssh 密钥配置

应用场景

Redc 并不是一个简单的 Terraform 包装器，我们基于多年的经验针对红队作业场景进行了深度定制。

在Redc中，我们设计了两类场景：基础场景和复杂场景。

基础场景

单一机器可满足需求的场景归类为基础场景，该类场景无需考虑多可用区部署、多机器配置。只需按规格选择 tf 模板，通过user_data 配置即可快速定制好场景

诸如 java 利用，内网穿透服务端（FRP）、文件服务等服务

复杂场景

由基础场景修改而来，兼容了多可用区部署，大量脚本适配。

诸如 dnslog、代理池、c2 前置等

高性价比的自建代理池

传统自建代理池方案，往往采用 fofa 查询来获取 ip 源，或者是各种爬虫爬取，通过本地脚本进行轮训，切换麻烦，维护麻烦，并发速度和可用性难以满足需求。

最关键的，在使用过程中的传输安全性安全无法保证。然而购买商业代理池往往面临 IP 复用率高、带宽受限、不支持 IPv6 等问题 。

为代理池场景，我们设计兼容了多可用区、混合云（阿里云、腾讯云、aws等）混合节点部署方案，在部署完成后自动生成 clash 兼容配置，并将配置传至存储桶在线订阅。实现IP 独享、连接稳定无丢包、无并发数上限！

基于redc我们可以利用云厂商的抢占式实例（Spot Instance），构建极低成本高质量代理池，实现快速启动、自动负载均衡、极致成本。

在实战场景中开启 50 台代理节点仅需 1-2 分钟，部署完成后自动生成 Clash 配置文件，配合负载均衡策略，实现一次请求自动切换一个 IP。以 50 台节点运行 8 小时为例，机器成本仅需约￥9 ，实际一场演练在代理池上投入不超过 ￥500，但使用 IP 量远超 10000。

启动方式也非常简单，一条命令轻松搞定！

# 启动阿里云代理池，指定节点数量为 10
./redc -start aliyun-proxy -node 10

# 启动aws代理池，指定节点数量为 10
./redc -start aws-proxy -node 10

自动化的 C2 设施

C2 设施的部署通常涉及复杂的配置（如隐匿、前置节点、证书等）。redc 采用模板化设计，支持一键部署 CS、Sliver、Supershell 等环境 。

# 启动 CS 场景，指定节点数和伪装域名
./redc -start cs -node 3 -domain www.amazon.com

分布式扫描平台

传统打点扫描往往使用代理或单机 vps 进行扫描，在 vps 上会部署 ARL、nemo 等平台进行自动化信息收集。但随着近年来演练目标逐渐增多，单机扫描在速度和封禁对抗上都严重拖慢打点的步伐，往往是扫出结果，一进主机就看到其他队留下的痕迹。

不妨尝试通过自动部署快速拉起扫描节点，实现低成本的分布式扫描方案。

redc 支持部署分布式扫描集群，扫描节点均采用抢占式实例（Spot Instance），可实现分布式、根据任务量随意扩容，原生支持 ipv6 资产。

通过自动化部署拉起的扫描平台，即平衡成本，又大大提高扫描的速度和结果的时效性，在实际项目中相比单机扫描平均快 30-40 倍，并且由于节点 ip 分散，指纹和探活触发 ip 封禁显著降低，扫描结果更多。

云端被动扫描平台方案

我们参考xray实现了平台化的，团队协同的 saas 被动扫描平台。

服务端+扫描节点全部采用 Redc自动化部署，节点采用抢占式实例（Spot Instance），成本极低。

1. 实现流量卸载，本地正常过站，数据包镜像到云端处理，不会因上级代理造成流量瓶颈。
2. 支持多级子路径+高危组件指纹发现，实现 OneScan、RouteVulScan 的功能。
3. 支持敏感数据包匹配的功能，实现 hae、Keydd 规则，从此不再担心巨型 js 文件导致 bp 卡顿。
4. 多人过站 url 自动去重，不必担心漏点、payload 不齐等情况，拉齐 外网打点能力。
5. 本地、云端两套代理池，被动流量统一走被动代理池出口，不会因为扫描导致本地客户端访问 ip 被封禁。

快速 dnslog 配置

通过CloudFlare的 api 调用和预先配置，在项目前可快速部署 dnslog 后端和 cname 配置

./redc -start dnslog -domain examplednslog.top

LLM自动方案 (WIP)

开放Redc mcp能力，让大模型自主调用云资源进行红队测试

更多场景

如果你有更好的工具和想法欢迎参与到Redc场景建设中~

https://github.com/wgpsec/redc-template

快速上手

redc 是采用 Go 编写的命令行工具，本身安装很简单，但是还需要安装对应云厂商 CLI 工具。

Redc 编译

Redc 编译前 按需从 tf-template 仓库中把你需要的场景 复制到 redc/utils/redc-templates/ 路径下

goreleaser --snapshot --skip-publish --rm-dist

安装 Terraform 及对应云厂商 CLI 工具

brew install aliyun-cli
brew tap hashicorp/tap
brew install hashicorp/tap/terraform
brew install jq

# 配置aliyun-cli访问凭证
aliyun configure set --profile cloud-tool --mode AK --region cn-beijing --access-key-id xxxxxxxxxxxxxxxxxxxxxxx --access-key-secret xxxxxxxxxxxxxxxxxxxxxxxxx

# 安装TCCLI并配置
pip3 install tccli
tccli configure
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxx

# 配置tf插件缓存路径
echo 'plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"' > ~/.terraformrc

# 使用前需初始化redc，将自动下载tf模块依赖
./redc -init

交互

# 开启 file 场景
redc -start file
.........
.........
项目uuid:xxxxxxxxx

# 查看默认项目中指定场景的状态
redc -status [uuid]

# 关闭默认项目中指定场景
redc -stop [uuid]

# 查看默认项目的所有场景
redc -list
uuid        type    createtime      operator
xxxxxxxxx   chat    2022.02.22      system
bbbbbbbbb   file    2022.02.22      system

目前场景名称（最新场景列表请参考官方GitHub仓库 https://github.com/wgpsec/redc-template）

aliyun-proxy
aws-proxy
cs
dnslog
docker
ec2
ec2-1G
ec2-4G
ecs
ecs1c2g
file
frp
interactsh
jndi
md
msf
ressh
sliver
supershell
vshell
xraydnslog

aliyun-proxy

创建完毕会输出一个clash配置，可以直接创建test.yml导入到clash中

./redc -start aliyun-proxy

需要 自定义节点数量,比如开10个节点
./redc -start aliyun-proxy -node 10

Aliyun ECS

开一台阿里云的ecs默认在北京区域 2c4g20g Ubuntu1804

./redc -start ecs

jndi

专门用于启用 jndi 服务的机器

./redc -start jndi

Sliver

./redc -start sliver
# 登录后下载sliver.cfg,本地导入使用
sliver import ./sliver.cfg
# 本地运行 sliver 进行连接

后记

基础设施的完整性是行动成功的基石。从手动运维转向 IaC 自动化运维，不仅是为了“偷懒”，更是为了将红队的时间从重复劳动中解放出来，投入到更具价值的攻防对抗中去。

目前模板库已在团队 github 仓库开源，redc 核心引擎将在完善后开源，结束大家重复造轮子的时代。

• https://github.com/wgpsec/redc
• https://github.com/wgpsec/redc-template