AiTM钓鱼攻击与HR定向恶意软件：会话Cookie窃取及MFA绕过防护实践

1. 攻击场景还原：HR 邮箱里的一封“正常”邮件

今年年初我接到一个紧急事件响应请求，某企业的 HR 部门有三位同事几乎同时中招。攻击者的整个流程非常丝滑：先发送带有恶意附件的定向钓鱼邮件，目标明确锁定 HR 团队中的招聘专员和薪酬主管，附件仿冒成“候选人简历”或“薪资调整审批表”。有员工点击附件后，恶意软件在后台静默执行，随后尝试窃取浏览器中保存的会话凭证，并且伪造了 HR 部门负责人的名义向内部系统发起敏感数据访问请求。

这不是孤例。过去一年里，针对 HR 部门的定向攻击爆发式增长。原因不难理解：HR 掌握着全员的姓名、身份证号、手机号、薪酬信息、甚至亲属关系等敏感数据，而且 HR 团队在处理外部邮件、接收简历方面有开放需求，先天就比财务或研发部门更难设防。

更要命的是，这类攻击已经开始使用 AiTM（Adversary-in-the-Middle，中间人攻击者）钓鱼技术。传统的钓鱼邮件即使骗到了账号密码，也会被多因素认证（MFA）拦下。但 AiTM 攻击直接把用户“请”进一个代理隧道，攻击者在用户和真实认证服务之间实时转发流量、窃取会话 Cookie，从而让合法会话在自己手中复活。这意味着你辛辛苦苦搭建的 MFA 防线，在 AiTM 面前可能形同虚设。

这篇文章我想完整拆解 AiTM 钓鱼的技术链路，再结合 HR 定向恶意软件的实际攻击场景，给出我实际验证过的检测规则、防御配置和应急响应流程。如果你正负责企业的身份安全、邮件安全，或者想搞懂为什么 MFA 不是终点，这篇文章应该能帮你省下不少踩坑的时间。

2. AiTM 钓鱼攻击的技术机理拆解

2.1 传统钓鱼与 AiTM 的本质差异

我们先说清楚 AiTM 到底是什么。传统钓鱼攻击的典型路径是：用户收到钓鱼邮件、点击链接、在仿冒的登录页面输入账号密码，攻击者拿到明文密码。这种攻击有几个明显的缺陷：一是仿冒页面很难做到与真实页面完全一致；二是即便拿到了密码，如果用户开启了 MFA，攻击者没有第二个因子依然无法登录；三是现代浏览器和邮件网关对已知钓鱼域名的拦截效果越来越好。

AiTM 完全绕开了这些问题。攻击者部署一个反向代理服务器，这个服务器作为“中间人”同时连接用户浏览器和真实的企业身份认证平台。用户访问的看似是正常的登录页面（实际上页面确实是从真实平台转发而来的），用户输入的密码、收到的 MFA 推送、甚至硬件令牌的动态验证码，都会经过代理服务器并被攻击者实时观察和提取。用户完成认证后，代理服务器把认证过程中生成的会话 Cookie 同步转发给攻击者，攻击者等于“复制”了一个合法会话。

可以这么理解：传统钓鱼是伪造证件，AiTM 是给攻击者配了一把实时复制的钥匙。你正常开门进去了，攻击者在你背后也同步走进去了，而且他手里拿的是你刚用过的原版钥匙。

这里有个关键点值得强调：AiTM 钓鱼过程中，用户往往感觉不到任何异常。登录页面是真实的、MFA 推送也是正常的、登录后的跳转也顺畅，唯一的异常可能是页面加载比平时慢了几百毫秒，但绝大多数人不会注意到这个延迟。攻击者要做的只是安静地做一个“中间商”，不赚差价，只赚凭证。

2.2 会话 Cookie 窃取与 MFA 绕过的完整链路

要理解 AiTM 为什么能绕过 MFA，需要先弄清楚 Cookie 在认证体系中的角色。现代企业身份平台（比如基于 Microsoft Entra ID 或类似 IdP 的统一认证体系）在用户完成多因素认证后，会在浏览器中写入两个关键 Cookie：一个是会话 Cookie（Session Cookie），用来标识“这个浏览器已经认证过”；一个是刷新令牌（Refresh Token），用来在会话过期时静默续期。这两个凭证都存储在浏览器端，通常有加密和 HttpOnly 属性保护，普通脚本无法直接窃取。

但 AiTM 攻击者不需要执行恶意代码，他们直接在代理层截获这些 Cookie。攻击链路大体分五个阶段：

• 阶段一：构造钓鱼链接。攻击者搭建钓鱼域名，配置反向代理指向真实身份平台的登录端点，同时生成一个形如https://security-portal.xxx.com/auth/verify的高仿链接。
• 阶段二：投递诱饵。通过邮件、即时通讯或搜索引擎广告投递链接，HR 场景常把链接伪装成“候选人背景调查系统”、“入职材料上传门户”。
• 阶段三：实时代理认证。用户点击链接后，代理服务器将真实登录页面转发给用户，用户输入凭证、通过 MFA，整个过程的数据流都经过代理服务器。
• 阶段四：会话 Cookie 提取。用户在认证成功后会被重定向至真实业务系统，但此时代理服务器已经从流量中提取了会话 Cookie，并同步建立了一条“影子会话”。
• 阶段五：利用会话。攻击者利用窃取的 Cookie，直接访问用户有权限的企业资源，无需再次认证，甚至可以在用户注销后继续使用一段时间。

从实际攻击案例来看，攻击者利用窃取到的会话 Cookie 后，最常见的行为是修改 HR 系统中的银行账号信息（用于工资盗领）、导出员工个人信息表、向内部通讯录大规模发送后续钓鱼邮件。整个过程中的横向移动速度非常快，有报告显示从 Cookie 窃取到数据外传的中位时间不超过 40 分钟，留给防御方的响应窗口极短。

2.3 为什么 MFA 不是终点

很多人有个误区：只要开了 MFA 就安全了。实际不是这样。MFA 的设计目标是验证“当前操作者知道密码且拥有第二因子”，但 AiTM 攻击的核心思路是让合法用户自己完成全部认证，攻击者只是“借用”最终成果。因为认证流程确实走完了，MFA 的判定是“通过”，所以从身份平台的角度看，没有任何异常。

这也是 AiTM 钓鱼最难防御的根源：安全系统无法区分“用户本人完成认证”和“攻击者借用用户认证结果”。如果在认证过程中注入风控检查，比如检测设备指纹、IP 地理位置、登录时间、浏览器特征，AiTM 的攻击流量和正常用户流量几乎完全一致，因为这些指标都来自用户真实环境。

那是不是说 MFA 没用了？也不是。MFA 仍然可以有效拦截传统钓鱼和撞库攻击。但如果你把安全感全部押在 MFA 上，就相当于把家门钥匙交给搬运工后还坚信保险箱是安全的——搬运工确实有钥匙，而他本身正是窃贼。真正有效的做法是把 MFA 当成纵深防御的一层，而不是唯一防线。

3. HR 定向恶意软件活动的攻击链分析

3.1 攻击者为什么偏爱 HR 部门

HR 部门之所以成为定向攻击的高价值目标，核心原因是“数据价值密度高、访问控制相对宽松”。一份员工薪酬表的价值远高于一套普通业务系统的登录凭证。攻击者用最小投入换取最大收益的典型路径，就是先攻击 HR，再通过 HR 拿到的敏感数据横向渗透其他系统。

另外一个常被忽视的原因是 HR 团队的“信息开放性”。招聘专员每天需要处理来自陌生人的邮件和附件，这就给了攻击者天然的投递入口。你不可能要求 HR 不接收简历，也不可能让招聘系统完全隔离外部邮件。相比之下，财务部门通常有更严格的邮件隔离和审批流程，研发部门有专门的代码托管权限体系。攻击者做了一次比较后，自然会把 HR 当作最容易突破的缺口。

还有一层原因是 HR 业务流程的“信任特性”。HR 掌握所有员工的入职、离职、调岗信息，因此他们向 IT 部门申请权限、重置账号、修改信息等操作是高频且合理的。攻击者一旦控制了 HR 账号，可以很自然地向 IT 运维提出各种听起来完全正常的请求，例如批量导出通讯录、申请临时访问特定系统等。在 SOC 团队眼里，HR 账号的高频操作本来就不寻常，反而更难从中识别出真正的恶意行为。

3.2 恶意软件投递与执行的关键路径

HR 定向恶意软件活动的投递方式，和我最早提到的那起事件基本一致。常见路径有三种：

• 第一种是带附件的钓鱼邮件。附件通常是压缩包或 Office 文档，文件名具有很强的业务欺骗性。比如“候选人简历.zip”“员工绩效评估表.docx”“2025年调薪方案.doc”。Office 文档利用宏或外部对象（OLE 对象）触发恶意代码执行，压缩包则内嵌可执行文件或脚本。
• 第二种是链接式钓鱼。邮件正文中嵌入一个指向恶意下载站的链接，点击后下载伪装成“简历查看器”或“PDF 阅读器”的恶意程序，这类程序常用合法的数字签名伪装提高可信度。
• 第三种是存储型攻击。攻击者先在第三方简历平台或企业公开邮箱中投递恶意文件，等待 HR 主动下载查看，这种方式更多的发生在 HR 使用个人邮箱处理招聘业务的场景中。

恶意软件在执行后，通常会经历四个动作：进程注入（将恶意代码注入合法进程以规避检测）、持久化安装（注册计划任务或服务）、凭证收集（扫描浏览器存储和系统内存中的口令）、回连外部服务器。HR 定向攻击中的恶意软件还有个显著特点：回连的 C2 地址通常使用合法云服务的动态域名或内容分发网络，普通 EDR 的域名信誉检查很难命中。

3.3 从恶意软件到数据窃取的转化路径

一旦攻击者拿到了 HR 人员设备上的控制权，接下来的动作往往呈现高度模板化。先用内置的信息收集模块扫描本机网络共享、浏览最近访问的文件服务器、检查是否有挂载的内部系统入口。然后利用窃取到的服务器凭据尝试访问人事管理系统或企业资源规划系统，优先寻找与“薪酬”“社保”“银行账号”相关的模块。

在这个过程中有一个节点容易被防御方忽略：攻击者不一定直接从 HR 系统导出数据。很多事件中，攻击者先把恶意软件植入 HR 人员设备，然后在夜间通过该设备上的 Teams 或企业微信等办公工具，向其他员工发送包含恶意附件的消息。这样即使用户的邮件网关拦截了外部钓鱼邮件，内部办公通讯工具之间的文件传输却没有经过同等强度的检测。这种“借壳扩散”的策略，让攻击者借助 HR 人员身份将恶意软件传播给更多部门。

4. 检测与防御体系设计

4.1 事前防御：缩小攻击面

防守 AiTM 钓鱼和 HR 定向恶意软件活动，单靠某一类安全产品是不够的。需要把身份平台、邮件网关、终端防护、网络边界四个层面打通。

身份平台层面，首要任务是收缩认证入口。不用的旧域名要彻底停用，第三方应用集成要清理，每个用户只允许在受管设备上使用密码登录。条件访问策略需要做到“设备合规 + 位置可信 + 风险评分”三者联动。注意，不要把条件访问的判定条件设得太宽松，很多企业在配置时只校验了“是否来自可信 IP”，这等于告诉攻击者：只要拿到 Cookie，任何网络位置都能畅通无阻。

邮件安全层面，要在邮件网关配置以下优先级检查项：附件类型黑名单（可执行文件、压缩包、脚本文件直接隔离）、外部发件人伪造检测（用 DMARC 策略拒收伪造 HR 域名的邮件）、链接实时信誉检查（对邮件中的链接在点击时做沙箱检测）。HR 部门要单独建一条邮件安全策略，对所有含附件的外部邮件做渲染预览，而不是直接放行下载。

终端防护层面，建议默认启用攻击面减少规则，比如禁止 Office 应用创建子进程、禁止脚本解释器直接执行混淆代码、阻断从互联网下载的文件在内存中直接执行。不需要纠结具体品牌，市面上成熟 EDR 都有类似功能，关键是你要真正打开并测试这些规则，而不是只安装了终端却保留了默认关闭状态。

4.2 事中检测：在攻击链路上设置哨兵

AiTM 钓鱼最难防，但如果把检测点前移，依然能在攻击链的某些节点拦住攻击。我总结了一套比较有效的检测规则，不需要太高深的技能，有基础日志采集能力就能落地。

重点检测以下信号：

• 认证事件中的异常登录：同一个用户账号在短时间内出现不同地理位置或不同设备的登录记录，特别是登录成功后的行为包含了配置修改、邮件转发规则创建等操作。
• 高风险的钓鱼链接特征：URL 中包含真实域名关键词但顶级域名是全新注册的，页面标题与登录页面一致但证书有效期极短（低于 24 小时）。
• Cookie 异常使用模式：单个会话 Cookie 被用于访问多个不相关系统，或 Cookie 的 User-Agent 在会话中途发生变化。
• 内部可信设备发起的外部流量：HR 人员终端上出现频繁访问已知文件共享服务或短链接域名的情况。

我建议在身份平台的登录日志中加一条自定义检测规则：当某个用户在 10 分钟内连续完成两次相同方式的 MFA 验证时，触发中级告警。这条规则的逻辑是：AiTM 代理在转发用户认证时，有可能出现一次认证事件被代理和用户端各记录一次的情况，虽然不绝对准确，但在实际事件中命中率不低。

4.3 事后响应：拆弹之后还要防二次引爆

当确认发生 AiTM 钓鱼或恶意软件感染后，响应动作要果断、彻底。第一步是立即吊销所有活跃会话和刷新令牌，这需要身份管理员在身份平台中操作，不只是让用户改个密码那么简单。这里指出一个常见失误：很多人认为改了密码就完事了，但 AiTM 攻击中会话 Cookie 是独立于密码存在的，密码改了旧 Cookie 依然有效。所以必须吊销 Cookie，强制全设备重新认证。

第二步是隔离受影响终端并采样取证。采集范围包括：浏览器历史记录、临时文件、系统日志、网络连接记录。在这个阶段优先关注 HR 人员设备中是否有恶意软件回连的进程残留，因为如果恶意软件已经在设备内持久化，单纯吊销会话无法阻断后续二次感染。建议直接从内存镜像和启动项入手，快速定位持久化机制。

第三步是排查同一时间段内所有认证成功的非交互式登录。攻击者在拿到 Cookie 后常会创建一个合法的服务主体或应用注册，用来代理解析和导出数据。检查身份平台中的应用注册日志，确认没有新增的权限较高的应用。在真实事件中，这一步往往能发现被忽略的“后门”。

4.4 为什么一套全托管的 SEIM 比想象中重要

我见过不少中型企业，安全设备上了不少，但日志都分散在各自的控制台上，没有一个统一的分析入口。遇到 AiTM 或定向恶意软件这种需要跨日志关联的事件，排查效率极低。你从 EDR 看到终端有恶意行为，但不知道这个终端在身份平台上的登录情况；你从身份平台看到异常认证，但不知道对应的设备是什么状态。这种情况下，所有检测规则都变成了“单点盲人摸象”。

强烈建议部署一套统一的日志分析平台，至少把四类日志收进来：身份认证日志（包括条件访问结果）、邮件网关日志、终端 EDR 日志、DNS/代理日志。不需要上特别贵的商业产品，开源的 ELK 或简易的数据管道也能满足基本需求。关键是保证日志时间对齐、字段标准化、留存至少 90 天。实战中你会发现，能够在 30 分钟内把一次钓鱼事件的完整时间线拼出来，与花大半天翻各控制台之间的差距，才是真正的检测能力差距。

在日志平台上，建议把下面几条规则做成持续运行的实时告警，而不是事后查询：

• 账号在同一小时内，分别从两个不同的地理位置成功登录。
• 某个 HR 相关服务账号在非工作时间大量导出数据或访问薪酬模块。
• 终端上新出现的进程，其文件哈希从未在企业资产库中出现过，且进程名与 HR 常用软件名称高度相似。
• 一次 MFA 验证成功后 5 分钟内，存在从该登录会话发起的高权限 API 调用。

这几条规则不是凭空写的，前两条对应 AiTM 钓鱼成功后的典型后遗症，后两条对应恶意软件植入后的行为基线偏离。虽然会有误报，但在 HR 定向攻击的高风险场景下，多一点噪声好过一次漏报。

5. 实操中的关键配置与踩坑记录

5.1 条件访问策略的三条“保命”配置

很多企业虽然配置了条件访问，但实际效果堪忧。我在评估过多个企业的身份安全状态后，发现最常见的三个配置漏洞是：对旧版认证协议未加限制、对设备合规状态未做强制、对高风险登录未配置阻断动作。

保命配置一：在条件访问策略中，把“旧版身份验证”明确设为阻断。旧版协议（比如 POP、IMAP、SMTP 基础认证）不支持 MFA，是攻击者绕过现代认证控制最便利的通道。只要把这个开关关上，攻击者就无法利用脚本通过旧协议自动登录。

保命配置二：所有涉及高价值数据的应用（人事系统、财务系统、合同管理系统），必须要求“设备标记为合规”才能访问。这不是可选项，而是必要条件。很多攻击者虽然拿到了会话 Cookie，但该会话对应的设备无法通过合规检查时，条件访问会自动阻断后续访问。需要注意，合规检查依赖终端管理组件，防病毒状态必须实时上报，否则设备会一直处于灰色状态。

保命配置三：登录风险策略设置为“中等及以上风险时阻断”。这一步的作用是让身份平台自己的风险引擎参与决策。AiTM 攻击时的某些异常特征（比如匿名代理 IP、新设备、异常地理位置）会被风险引擎标记为中等风险，虽然不一定完全准确，但作为拦截项能显著提高攻击成本。前提是你不能把风险策略设为仅报告，现实中很多企业担心误伤员工，犹豫之下选择了“仅报告”，结果就是告警一大堆，但没有任何实际拦截作用。

5.2 统一认证平台监控项的落地参数

说几个我在实际项目中验证过的具体监控参数，你可以直接拿来作参考。这些参数的阈值不是拍脑袋定的，而是来自对多起钓鱼事件日志的回溯分析。

会话持续时间监控：正常员工在办公网络内的平均登录会话时长大多在 5 到 9 小时之间，但考虑到夜间和周末的例外情况，阈值不要设得太死。我建议将“单次会话持续超过 16 小时”作为可疑项。攻击者窃取的 Cookie 往往在用户正常会话结束后继续存活，这是判断 Cookie 是否被滥用的一个重要信号。

异常登录频率监控：同一账号在 30 分钟内登录次数超过 5 次，且每次的客户端类型不同（如先通过浏览器登录、再通过移动端 App 登录、然后又有 PowerShell 调用），这类行为强烈提示凭证正在被多个工具同时使用。将阈值定为 5 次，误报率大约控制在 3% 以内。

管理员操作审计：HR 部门的普通员工账号如果出现了修改密码、修改 MFA 设置、创建邮箱转发规则等操作，多半是账号已被控制。建议将所有 HR 账号的管理员操作设置为高优先级告警。这个规则需要微调的是，有些企业的 HR 系统管理员账号就是 HR 部门内部人员，要单独模块来处理这种特殊情况。

5.3 终端防线的具体配置建议

终端层面，我通常建议按以下顺序配置。这里不绑定具体厂商，只说通用的安全功能。

• 开启文件信誉分析：下载的可执行文件在上传至沙箱分析完成前，不得在本机运行。对于 HR 邮箱收到的简历附件，这条规则可以极大减少恶意软件直接执行的概率。
• 开启内存扫描：恶意软件常通过压缩工具或 Office 漏洞在内存中释放代码，内存扫描对这种行为有较好的检出效果。
• 配置应用控制白名单：HR 人员的终端上，允许运行的软件是相对固定的（浏览器、Office 套件、PDF 阅读器、招聘系统客户端）。把终端设置为仅允许白名单内的应用运行，能大幅缩小恶意软件的生存空间。这条规则在推行初期会有阻力，因为员工偶尔会用 U 盘或下载一些小工具。可以通过“先审计后强制”的方式，先记录所有未授权应用的运行情况，两周后把高频合法工具加入白名单，再强制执行。
• 启用凭证保护：Windows 终端的凭据保护功能可以将 NTLM 哈希隔离在受保护的区域，攻击者即使获得系统权限，也无法轻易提取用户凭证。

5.4 员工演练的正确打开方式

关于安全意识培训，我见过太多企业做成“一年一次填问卷”的形式化流程。针对 HR 定向攻击，培训必须从“知道什么是钓鱼”升级为“在真实场景中做对操作”。

这里提供一个我自己用的演练方法。每个季度做一次模拟 AiTM 钓鱼演练，把钓鱼链接做成一个模拟的认证中转页面。员工点击链接、输入账号密码后，页面跳转至提示页告知这是一次钓鱼演练，然后系统记录哪些员工在页面中提交了凭证。重点不是批评那些提交了凭证的员工，而是分析他们在提交前是否关注了 URL 域名、是否有异常证书提示、页面加载速度是否明显变慢。

演练结果要分级处理：首次点击的做即时培训，再次点击的加强抽查频率。特别需要注意，演练本身不要过度制造恐惧感，否则员工会对外部简历完全封闭，这会影响正常业务。更有效的方式是定期发送“技术小贴士”，告诉 HR 团队成员：“简历附件的正确打开方式是什么”“遇到外部发送的可疑链接时，应该先使用预览功能还是直接下载”。把安全行为融入日常工作流程中，而不是站在员工对面拿着制度的皮鞭。

6. 常见问题与排查技巧实录

我挑选了几个实际支持过程中反复出现的问题，整理成速查表形式，方便你直接排查时对照。

在实际排查过程中，有两点经验想特别分享。一是不要只看“是否成功登录”，更要看“登录后的行为”。成功登录可能只是一个开始，真正的恶意行为往往发生在登录后 30 分钟到几天不等，所以日志留存时间要足够长。二是构造检测规则时，不要追求单条规则的完美。我见过有人为了一条零误报的检测规则调了整整一周，其实更好的思路是几条不完美的规则叠加出高置信度的综合信号。单条规则 10% 的误报率看起来不高，但你同时跑五条规则，交集命中时就只剩不到 1% 的误报了。

7. 我踩过的坑和沉淀下来的想法

做了这么多年安全运营，我最大的体会就是：攻击者在改变，防御策略也必须在改变。几年前大家还在讨论“别点链接、别开附件”，现在的问题是：就算你完全不点开邮件里的任何东西，AiTM 钓鱼依然可以通过已经感染的同事设备横向渗透到你。单一的防御手段越来越无力，纵深防御不再是一个口号，而是每一层都要有实际可执行的控制点。

如果让我给一个最核心的建议，那就是：优先确保 HR 部门的会话 Cookie 安全性，优先部署身份平台的会话吊销能力，优先建立统一日志分析平台。先把这三件事做好了，再谈更高级的威胁狩猎。很多企业一上来就想着上大而全的安全平台，结果基础的身份控制、会话管理都做得一塌糊涂，那才是真正的“木桶效应”。

另一个我想强调的点是，防御 AiTM 攻击确实需要“假设一定会被绕过”的心态。哪怕你的 MFA 强制开启、条件访问配置精妙、终端防护全部到位，依然要假设某个 HR 人员的账号已经沦陷，并且提前设计好响应预案。先把最恶劣的场景想清楚，再往下推，你就能知道哪些检测规则是必须提前跑起来的、哪些数据必须保留足够时长、哪些权限需要提前做好最小化设计。

最后分享一个小技巧：每个季度抽查一次 HR 人员的活跃会话列表，看是否存在明显异常的长会话。这项工作只需要身份管理员在管理后台花十分钟导出数据，对比一下上个季度的会话数量变化，就能发现大量安全平台都没发现的隐蔽问题。安全管理不是只有大工程，很多有效动作就藏在那些不起眼的例行检查里。