摘要
近年来，网络钓鱼已超越漏洞利用与弱口令等传统手段，成为勒索软件攻击的首要初始入口。根据SpyCloud于2025年发布的《身份威胁报告》，35%的受害组织将钓鱼列为勒索软件入侵的主因，较2024年显著上升10个百分点；85%的受访企业过去一年至少遭遇一次勒索事件，其中近三分之一经历6至10次。这一趋势的核心驱动力在于“钓鱼即服务”（Phishing-as-a-Service, PhaaS）的产业化与“中间人攻击”（Adversary-in-the-Middle, AitM）技术的普及，后者可有效绕过多因素认证（MFA），通过窃取会话Cookie实现用户身份冒用。本文系统分析PhaaS生态的技术架构、AitM攻击链的实施细节及其对现有MFA机制的颠覆性影响，并基于实证提出多层次防御框架。重点探讨基于FIDO2/WebAuthn的设备绑定认证、会话持续风险评估、高敏操作二次验证等缓解策略的有效性。通过提供模拟AitM代理与会话劫持检测的代码示例，本文为安全从业者提供可落地的技术参考，旨在弥合身份安全体系中的关键盲区。
关键词：网络钓鱼；勒索软件；PhaaS；AitM；多因素认证绕过；会话劫持；FIDO2；身份安全
1 引言
勒索软件攻击在过去五年中已从机会主义行为演变为高度组织化、以利润为导向的网络犯罪产业。其成功不仅依赖加密算法的强度，更取决于能否高效获取目标系统的初始访问权限。传统上，攻击者主要通过未修补的远程代码执行（RCE）漏洞（如ProxyLogon、Log4Shell）或暴力破解弱密码进入内网。然而，随着端点防护与补丁管理的普及，此类入口的成本与失败率显著上升。
与此同时，社会工程学驱动的网络钓鱼因其高成功率与低技术门槛，逐渐成为首选路径。2025年SpyCloud报告显示，钓鱼首次超越其他向量，成为勒索软件最主要的初始入口。尤为值得关注的是，攻击者不再仅满足于窃取静态凭证，而是通过AitM代理实时拦截用户与合法服务之间的完整认证流程，包括MFA令牌，从而获取有效的会话Cookie。这种“活体凭证”（Live Session Token）可直接用于API调用或Web界面操作，完全绕过基于时间的一次性密码（TOTP）或短信验证码等传统MFA机制。
本文聚焦于这一范式转变，深入剖析PhaaS如何降低攻击门槛、AitM如何实现MFA绕过，并评估现有防御措施的局限性。在此基础上，提出一套融合强认证、会话治理与行为监控的纵深防御体系，并通过可复现的代码示例验证关键技术点的可行性。
2 背景与威胁演化
2.1 勒索软件初始入口的历史变迁
早期勒索软件（如CryptoLocker）多通过恶意附件或捆绑软件传播，依赖用户本地执行。随着企业边界防御增强，攻击者转向利用面向互联网的服务，如RDP、SMB、Exchange等。2020年后，供应链攻击（如SolarWinds）与大规模漏洞利用成为主流。然而，自2023年起，钓鱼攻击占比持续攀升，原因有三：
云服务普及：Microsoft 365、Google Workspace等SaaS平台成为企业核心资产载体，其身份认证入口成为高价值目标。
MFA误判安全感：许多组织误认为启用MFA即可免疫凭证泄露，忽视会话层风险。
攻击工具商品化：PhaaS平台提供一站式钓鱼页面托管、邮件投递、凭证收集与会话代理服务，使低技能攻击者也能发起高级攻击。
2.2 PhaaS的运作模式
PhaaS平台（如EvilProxy、Cryp70r）通常提供以下功能：
可视化面板创建仿冒登录页（支持微软、Okta、Google等模板）；
自动化邮件投递引擎（集成SMTP或邮件API）；
AitM代理模块，实时转发用户请求至真实服务并记录响应；
会话Cookie提取与导出接口；
攻击效果统计与受害者管理。
攻击者仅需支付订阅费或按成功会话分成，即可获得完整攻击能力。这种“按需付费”模式极大扩展了威胁行为者的基数。
2.3 AitM攻击原理与MFA绕过机制
AitM攻击的核心在于透明代理。攻击流程如下：
用户点击钓鱼邮件中的链接，访问攻击者控制的仿冒登录页（如secure-microsoft-login[.]xyz）；
该页面实际是一个反向代理，将用户所有请求（包括输入的用户名、密码、MFA验证码）实时转发至真实的login.microsoftonline.com；
微软服务器完成完整认证流程，返回包含有效会话Cookie（如.AspNet.Cookies、x-ms-gateway-sso）的响应；
AitM代理截获该响应，提取Cookie后存储，并将页面内容原样返回给用户，使其误以为登录成功；
攻击者使用窃取的Cookie，直接访问目标用户的邮箱、OneDrive或Azure门户，无需再次认证。
由于整个认证过程在微软服务器上真实发生，MFA完全生效，但其保护对象是攻击者的代理，而非最终用户。因此，MFA在此场景下形同虚设。
3 现有MFA机制的脆弱性分析
3.1 常见MFA类型及其局限
MFA类型 是否可被AitM绕过 原因
短信/语音OTP 是 OTP在认证时被代理提交
TOTP（如Google Authenticator） 是 动态码在有效窗口内被使用
推送通知（如Microsoft Authenticator） 部分 若用户习惯性批准，仍可绕过
FIDO2/WebAuthn（安全密钥） 否（理想情况下） 绑定特定RP（Relying Party）与设备
关键问题在于，前三种MFA均基于知识或 possession 的一次性验证，一旦会话建立，后续操作不再验证。而FIDO2通过公钥密码学与设备绑定，确保私钥永不离开安全芯片，且认证断言与特定域名绑定，无法被重放或代理。
3.2 会话管理缺失加剧风险
即使采用强MFA，若会话生命周期管理不当，仍存在风险：
会话有效期过长（如默认90天）；
无设备或IP变更检测；
无高风险操作（如邮件规则修改、OAuth授权）的再验证；
无法主动撤销可疑会话。
SpyCloud报告指出，66%的恶意软件感染发生在已部署EDR或杀毒软件的设备上，说明终端防护无法阻止合法会话的滥用。
4 防御框架设计
针对上述威胁，本文提出三层防御模型：
4.1 认证层：部署抗AitM的强MFA
强制使用FIDO2安全密钥或Windows Hello for Business（基于TPM）。配置示例（Azure AD）：
# 禁用SMS和电话MFA
Set-MsolUser -UserPrincipalName user@contoso.com -StrongAuthenticationRequirements @()
# 强制FIDO2作为唯一MFA方式（需Conditional Access策略）
# 在Azure Portal: Security → Conditional Access → New Policy
# Conditions: Users = All, Cloud apps = Microsoft 365
# Grant: Require multifactor authentication + Require device to be marked as compliant
# Session: Sign-in frequency = Every 4 hours (强制频繁再认证)
4.2 会话层：实施持续验证与主动治理
缩短会话有效期：将默认90天会话缩短至4-8小时；
高敏操作再验证：对以下操作强制重新认证：
创建邮箱转发规则；
授予第三方OAuth应用权限；
修改MFA设置；
访问敏感SharePoint站点。
会话异常检测：监控登录地理位置突变、新设备首次登录等事件。
以下Python脚本模拟检测异常会话（基于Microsoft Graph API）：
import requests
from datetime import datetime, timedelta
GRAPH_API_TOKEN = "your_app_token"
USER_ID = "user@contoso.com"
def get_user_signins(user_id):
url = f"https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=userPrincipalName eq '{user_id}'&$top=10"
headers = {"Authorization": f"Bearer {GRAPH_API_TOKEN}"}
resp = requests.get(url, headers=headers)
return resp.json().get('value', [])
def detect_anomalous_session(signins):
if not signins:
return []
latest = signins[0]
latest_ip = latest['ipAddress']
latest_city = latest.get('location', {}).get('city', 'Unknown')
latest_time = datetime.fromisoformat(latest['createdDateTime'].replace('Z', '+00:00'))
anomalies = []
for s in signins[1:]:
ip = s['ipAddress']
city = s.get('location', {}).get('city', 'Unknown')
time = datetime.fromisoformat(s['createdDateTime'].replace('Z', '+00:00'))
# 检查1小时内不同城市登录
if (latest_time - time) < timedelta(hours=1) and city != latest_city:
anomalies.append({
'time': s['createdDateTime'],
'ip': ip,
'city': city,
'risk': 'Impossible Travel'
})
return anomalies
# 使用示例
signins = get_user_signins(USER_ID)
anomalies = detect_anomalous_session(signins)
if anomalies:
print("Detected anomalous sessions:", anomalies)
# 可触发自动会话撤销
4.3 响应层：自动化会话撤销与取证
一旦检测到可疑活动，应立即撤销用户所有活动会话：
POST https://graph.microsoft.com/v1.0/users/{user-id}/revokeSignInSessions
Authorization: Bearer {token}
同时，保留浏览器会话日志、反向代理访问记录，用于溯源。
5 实施挑战与最佳实践
5.1 用户体验与安全平衡
频繁再认证可能引发用户抵触。建议：
对普通操作保持较长会话；
仅对高风险操作触发再验证；
提供清晰的再验证理由（如“您正在修改邮件转发规则，此为高风险操作”）。
5.2 PhaaS监测与品牌保护
注册企业品牌关键词，监控新注册域名；
使用第三方服务（如PhishLabs）进行仿冒页面发现；
对高管、财务、IT等高价值岗位开展定制化鱼叉钓鱼演练。
5.3 供应链安全
PhaaS常通过盗版软件、广告注入等方式传播。应：
禁用浏览器扩展自动安装；
部署应用白名单；
监控设备上的信息窃取木马（Infostealer）活动。
SpyCloud数据显示，近半数企业用户曾感染Infostealer，而仅50%的组织能检测到此类感染。
6 讨论
本文揭示了一个关键矛盾：MFA的有效性高度依赖其部署上下文。在传统静态认证模型中，MFA显著提升安全性；但在AitM代理面前，若缺乏会话绑定与持续验证，MFA反而制造虚假安全感。因此，安全架构必须从“一次性认证”转向“持续信任评估”。
此外，PhaaS的兴起标志着网络犯罪的工业化分工。防御方亦需构建自动化、可编排的响应体系，否则难以应对高频次、低门槛的攻击浪潮。
7 结论
钓鱼作为勒索软件主要入口的崛起，本质上是攻击经济性与防御滞后性的共同结果。PhaaS降低了攻击门槛，AitM技术则精准打击了当前MFA部署的结构性弱点。本文通过分析攻击链、评估现有措施局限，并提出融合强认证、会话治理与自动化响应的防御框架，为组织提供系统性应对方案。代码示例验证了会话异常检测与撤销的可行性。未来工作将聚焦于基于UEBA（用户与实体行为分析）的实时会话风险评分，以及FIDO2在混合办公环境中的大规模部署挑战。安全防御不应止步于入口，而需贯穿整个身份生命周期。
编辑：芦笛（公共互联网反网络钓鱼工作组）
扫一扫
3798
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
