1. 攻击场景还原HR 邮箱里的一封“正常”邮件今年年初我接到一个紧急事件响应请求某企业的 HR 部门有三位同事几乎同时中招。攻击者的整个流程非常丝滑先发送带有恶意附件的定向钓鱼邮件目标明确锁定 HR 团队中的招聘专员和薪酬主管附件仿冒成“候选人简历”或“薪资调整审批表”。有员工点击附件后恶意软件在后台静默执行随后尝试窃取浏览器中保存的会话凭证并且伪造了 HR 部门负责人的名义向内部系统发起敏感数据访问请求。这不是孤例。过去一年里针对 HR 部门的定向攻击爆发式增长。原因不难理解HR 掌握着全员的姓名、身份证号、手机号、薪酬信息、甚至亲属关系等敏感数据而且 HR 团队在处理外部邮件、接收简历方面有开放需求先天就比财务或研发部门更难设防。更要命的是这类攻击已经开始使用 AiTMAdversary-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一个是会话 CookieSession 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. 常见问题与排查技巧实录我挑选了几个实际支持过程中反复出现的问题整理成速查表形式方便你直接排查时对照。问题场景可能原因排查建议用户反馈登录过一次后第二天总是被要求重新认证会话 Cookie 被条件访问策略判定为高风险不断被吊销查看身份平台的登录日志中是否有“会话被中断”的记录检查设备合规状态是否正常员工收到大量正常的 HR 邮件但网关判定为钓鱼邮件头中缺少 SPF/DKIM 签名且邮件包含外部链接检查组织域名的 SPF/DKIM/DMARC 配置优先保证 HR 系统发出的邮件正确配置这三个协议终端报警提示 Office 试图创建 PowerShell 子进程可能为宏恶意行为也可能是内部自动化脚本查看父进程的完整命令行确认 Office 文件是否来自外部邮件如果确实来自邮件先隔离文件再处理某个 HR 账号的活动会话数量异常多但用户本人只开了一台电脑凭证已被窃取并被攻击者用于多个会话立即吊销该账号所有会话强制重新认证同时检查是否有新的应用注册或 API 权限授予日志平台发现同一 Cookie 的 User-Agent 中途改变攻击者在代理层修改了浏览器标识触发高优先级告警并隔离相关会话同时将该终端作为受信设备移除要求重新合规HR 人员在钓鱼链接中输入了真实密码但没有点击恶意附件密码泄露但设备未被植入恶意软件强制重置密码并吊销所有会话检查后续 24 小时内的登录行为是否异常开启身份保护功能在实际排查过程中有两点经验想特别分享。一是不要只看“是否成功登录”更要看“登录后的行为”。成功登录可能只是一个开始真正的恶意行为往往发生在登录后 30 分钟到几天不等所以日志留存时间要足够长。二是构造检测规则时不要追求单条规则的完美。我见过有人为了一条零误报的检测规则调了整整一周其实更好的思路是几条不完美的规则叠加出高置信度的综合信号。单条规则 10% 的误报率看起来不高但你同时跑五条规则交集命中时就只剩不到 1% 的误报了。7. 我踩过的坑和沉淀下来的想法做了这么多年安全运营我最大的体会就是攻击者在改变防御策略也必须在改变。几年前大家还在讨论“别点链接、别开附件”现在的问题是就算你完全不点开邮件里的任何东西AiTM 钓鱼依然可以通过已经感染的同事设备横向渗透到你。单一的防御手段越来越无力纵深防御不再是一个口号而是每一层都要有实际可执行的控制点。如果让我给一个最核心的建议那就是优先确保 HR 部门的会话 Cookie 安全性优先部署身份平台的会话吊销能力优先建立统一日志分析平台。先把这三件事做好了再谈更高级的威胁狩猎。很多企业一上来就想着上大而全的安全平台结果基础的身份控制、会话管理都做得一塌糊涂那才是真正的“木桶效应”。另一个我想强调的点是防御 AiTM 攻击确实需要“假设一定会被绕过”的心态。哪怕你的 MFA 强制开启、条件访问配置精妙、终端防护全部到位依然要假设某个 HR 人员的账号已经沦陷并且提前设计好响应预案。先把最恶劣的场景想清楚再往下推你就能知道哪些检测规则是必须提前跑起来的、哪些数据必须保留足够时长、哪些权限需要提前做好最小化设计。最后分享一个小技巧每个季度抽查一次 HR 人员的活跃会话列表看是否存在明显异常的长会话。这项工作只需要身份管理员在管理后台花十分钟导出数据对比一下上个季度的会话数量变化就能发现大量安全平台都没发现的隐蔽问题。安全管理不是只有大工程很多有效动作就藏在那些不起眼的例行检查里。