# Performing Adversary In The Middle Phishing Detection

> 检测和响应中间人（AiTM）钓鱼攻击，这类攻击使用 EvilProxy、Evilginx 和 Tycoon 2FA 等反向代理工具包绕过 MFA 并窃取会话令牌。

- Skill: `killvxk/performing-adversary-in-the-middle-phishing-detection` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add killvxk/performing-adversary-in-the-middle-phishing-detection`
- Raw SKILL.md: https://api.skillmd.com/api/skills/killvxk/performing-adversary-in-the-middle-phishing-detection/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: killvxk (https://skillmd.com/u/killvxk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/killvxk/performing-adversary-in-the-middle-phishing-detection

---

# 执行中间人钓鱼检测

## 概述

中间人（AiTM）钓鱼攻击使用反向代理基础设施介于受害者与合法认证服务之间，实时拦截凭据和会话 Cookie。这使攻击者能够绕过多因素认证（MFA）。2025 年最流行的钓鱼即服务（PhaaS）工具包包括 Tycoon 2FA、Sneaky 2FA、EvilProxy 和 Evilginx。仅在 2025 年 1-2 月就检测到超过 100 万次 PhaaS 攻击。这些攻击已从使用二维码演变为使用 HTML 附件和 SVG 文件进行链接分发。

## 前置条件

- Azure AD / Entra ID 条件访问策略
- 具备认证日志摄入能力的 SIEM（Azure AD 登录日志）
- 具备 SSL 检测和 URL 分类的 Web 代理
- 端点检测与响应（EDR）解决方案
- FIDO2/抗钓鱼 MFA 能力

## 核心概念

### AiTM 工作原理

1. 受害者收到含有攻击者控制域名链接的钓鱼邮件
2. 攻击者域名运行反向代理，镜像合法登录页面
3. 受害者在代理页面上输入凭据；凭据在传输过程中被捕获
4. 反向代理将凭据转发至真实认证服务
5. MFA 挑战发送给受害者；受害者在代理页面上完成 MFA
6. 攻击者捕获合法服务返回的会话 Cookie
7. 攻击者重放会话 Cookie，无需 MFA 即可访问受害者账户

### 主要 AiTM 工具包（2025）

| 工具包 | 类型 | 主要目标 | 规避技术 |
|---|---|---|---|
| Tycoon 2FA | PhaaS | Microsoft 365、Google | CAPTCHA、Cloudflare turnstile |
| EvilProxy | PhaaS | Microsoft 365、Google、Okta | 随机 URL、IP 轮换 |
| Evilginx | 开源 | 任意 Web 应用 | 自定义 phishlet |
| Sneaky 2FA | PhaaS | Microsoft 365 | 反机器人检查 |
| NakedPages | PhaaS | 多目标 | 最小化基础设施 |

### 检测指标

- 来自与用户配置文件不符的异常 IP 的认证
- 与认证时不同 IP/设备的会话 Cookie 重用
- 从非 Microsoft/非 Google 基础设施提供的登录页面
- 从钓鱼域名向合法认证提供商发出的 CDN 请求
- 认证与会话使用之间的不可能旅行

## 实施步骤

### 步骤一：部署抗钓鱼 MFA

- 为高价值账户实施 FIDO2 安全密钥或 Windows Hello for Business
- 配置条件访问，要求管理员使用抗钓鱼 MFA
- 尽可能启用基于证书的认证
- 为特权账户禁用 SMS 和语音 MFA
- AiTM 无法拦截 FIDO2，因为认证绑定到源域名

### 步骤二：配置条件访问策略

- 要求使用合规/受管理设备才能访问敏感应用
- 封锁来自匿名代理和 Tor 出口节点的认证
- 强制令牌绑定以限制会话 Cookie 重放
- 配置持续访问评估（CAE）以实现实时令牌撤销
- 实施登录风险策略，对高风险登录要求重新认证

### 步骤三：构建 AiTM 检测规则

- 对登录后 10 分钟内来自不同 IP 的会话发出告警
- 检测代理 IP 与用户预期位置不匹配的认证
- 监控会话使用中的不可能旅行模式
- 对认证后立即创建的收件箱规则发出告警（常见入侵后行为）
- 检测来自可疑登录的新 MFA 方法注册

### 步骤四：监控 Web 代理中的 AiTM 基础设施

- 记录并分析对新注册域名的 DNS 查询
- 检测与已知 PhaaS 基础设施 IP 的连接
- 对通过代理域名从合法 CDN 加载的认证页面背景发出告警
- 监控颁发给模仿企业登录页面域名的 SSL 证书
- 通过威胁情报封锁对已知 EvilProxy/Evilginx 基础设施的访问

### 步骤五：实施入侵后检测

- 对可疑认证后创建的邮箱转发规则发出告警
- 检测 AiTM 登录后的 OAuth 应用授权
- 监控表明 BEC 后续行动的邮件发送模式
- 对会话劫持后 SharePoint/OneDrive 批量下载发出告警
- 追踪来自已入侵账户的横向移动

## 工具与资源

- **Microsoft Entra ID Protection**：基于风险的条件访问
- **Azure AD 登录日志**：认证事件分析
- **Okta ThreatInsight**：IdP 级别的 AiTM 代理检测
- **Sekoia TDR**：AiTM 活动追踪和情报
- **Evilginx（防御用途）**：了解攻击机制以用于检测

## 验证

- 抗钓鱼 MFA 在测试场景中封锁 AiTM 会话捕获
- 条件访问拒绝来自不同设备/IP 的会话重放
- SIEM 告警在模拟 AiTM 登录模式时触发
- Web 代理封锁与已知 PhaaS 基础设施的连接
- 入侵后规则检测到可疑认证后创建的收件箱规则