关于 performing-adversary-in-the-middle-phishing-detection
面向安全评估和事件响应的 AiTM 钓鱼检测指南，介绍抗钓鱼 MFA、条件访问、SIEM 告警及代理日志监控。
主要功能
- 01部署抗钓鱼 MFA
- 02配置条件访问策略
- 03构建 AiTM 检测规则
- 04监控 Web 代理指标
- 05检测入侵后的活动
适用场景
- 01调查可疑登录和会话重放
- 02验证 MFA 与条件访问控制
- 03检测钓鱼后的邮箱和云盘活动
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/performing-adversary-in-the-middle-phishing-detection确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
LICENSEassets/template.mdreferences/api-reference.mdstandards.mdworkflows.mdscripts/agent.pyprocess.py详细介绍
执行中间人钓鱼检测
概述
中间人（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 的工作原理
- 受害者收到包含指向攻击者控制域名的链接的钓鱼邮件
- 攻击者域名运行反向代理，镜像合法登录页面
- 受害者在代理页面上输入凭据；凭据在传输过程中被捕获
- 反向代理将凭据转发给真实的身份验证服务
- MFA 质询发送给受害者；受害者在代理页面上完成 MFA
- 攻击者捕获合法服务返回的会话 Cookie
- 攻击者重放会话 Cookie 以访问受害者账户，无需 MFA
主要 AiTM 工具包（2025 年）
| 工具包 | 类型 | 主要目标 | 规避方式 |
|---|---|---|---|
| Tycoon 2FA | PhaaS | Microsoft 365、Google | CAPTCHA、Cloudflare turnstile |
| EvilProxy | PhaaS | Microsoft 365、Google、Okta | 随机 URL、IP 轮换 |
| Evilginx | 开源 | 任何 Web 应用 | 自定义 phishlets |
| Sneaky 2FA | PhaaS | Microsoft 365 | 反机器人检查 |
| NakedPages | PhaaS | 多个 | 最小化基础设施 |
检测指标
- 来自与用户画像不匹配的异常 IP 的身份验证
- 会话 Cookie 从与身份验证不同的 IP/设备重放使用
- 登录页面由非 Microsoft/非 Google 基础设施提供
- 从钓鱼域名向合法身份验证提供商发起的 CDN 请求
- 身份验证和会话使用之间的不可能旅行
工作流
步骤 1：部署抗钓鱼 MFA
- 为高价值账户实施 FIDO2 安全密钥或 Windows Hello for Business
- 配置条件访问，要求管理员使用抗钓鱼 MFA
- 在可能的情况下启用基于证书的身份验证
- 为特权账户禁用短信和语音 MFA
- AiTM 无法拦截 FIDO2，因为身份验证绑定到源域名
步骤 2：配置条件访问策略
- 要求访问敏感应用时使用合规/受管设备
- 阻止来自匿名代理和 Tor 出口节点的身份验证
- 强制执行令牌绑定以限制会话 Cookie 重放
- 配置持续访问评估（CAE）以实现实时令牌撤销
- 实施登录风险策略，要求对风险登录重新进行身份验证
步骤 3：构建 AiTM 检测规则
- 对登录后 10 分钟内来自不同 IP 的会话发出警报
- 检测代理 IP 与用户预期位置不匹配的身份验证
- 监控会话使用中的不可能旅行模式
- 对身份验证后立即创建的收件箱规则发出警报（常见的入侵后行为）
- 检测来自可疑登录的新 MFA 方法注册
步骤 4：监控 Web 代理以发现 AiTM 基础设施
- 记录并分析针对新注册域名的 DNS 查询
- 检测与已知 PhaaS 基础设施 IP 的连接
- 对通过代理域名从合法 CDN 加载的认证页面背景发出告警
- 监控为仿冒企业登录页面的域名签发的 SSL 证书
- 通过威胁情报阻止对已知 EvilProxy/Evilginx 基础设施的访问
步骤 5：实施失陷后检测
- 对可疑认证后创建的邮箱转发规则发出告警
- 检测 AiTM 登录后的 OAuth 应用授权
- 监控表明 BEC 后续活动的邮件发送模式
- 对会话劫持后 SharePoint/OneDrive 的大规模下载发出告警
- 跟踪来自失陷账户的横向移动
工具与资源
- Microsoft Entra ID Protection：基于风险的条件访问
- Azure AD Sign-in Logs：认证事件分析
- Okta ThreatInsight：IdP 层面的 AiTM 代理检测
- Sekoia TDR：AiTM 活动跟踪与情报
- Evilginx（防御用途）：理解攻击机制以进行检测
验证
- 防钓鱼 MFA 在测试场景中阻止 AiTM 会话捕获
- 条件访问拒绝来自不同设备/IP 的会话重放
- SIEM 告警在模拟的 AiTM 登录模式上触发
- Web 代理阻止与已知 PhaaS 基础设施的连接
- 失陷后规则检测到可疑认证后的收件箱规则创建
评论
支持 Markdown