|
摘要： 微软在 Microsoft Teams 中引入基于会话上下文的钓鱼检测，把判定依据从链接与附件的信誉转向对话中的关系与意图。这一变化的实质不是增加一种检测手段，而是改变了钓鱼判定所依赖的证据类型：可复现的载荷特征让位于只能概率评估的语义线索。本文以微软通告 MC1519866、路线图条目 575288 与官方支持文档为一手依据，结合微软季度邮件威胁数据、反网络钓鱼工作组统计及公开的生成式内容效能研究，讨论三个问题：载荷信誉体系在协作平台上为何失效；会话级证据能够支撑何种强度的判断；当判断由机器给出而后果由人承担时，责任如何在供应商、组织与员工之间分配。研究认为，会话检测填补了无载荷社会工程的识别空白，但其证据强度只够生成风险提示，不足以构成事实认定；若组织不建立独立的第二证据源与留痕机制，检测带来的只是把判断成本向一线转移，而未真正降低事件的期望损失。 关键词： 网络钓鱼；协作平台；会话上下文；证据强度；责任分配；安全治理 1 引言 微软在 2026 年 10 月 21 日发布通告 MC1519866，说明 Teams 将启用由人工智能驱动的钓鱼检测，识别对话中的钓鱼、冒充与欺骗意图，包括不携带任何链接与附件的消息。配套的路线图条目 575288 把这一定位写得更直接：该能力用于 “风险较高的消息场景”，主要是与外部联系人的首次接触；在特定区域或情形下可能附加额外保护；功能仅用于安全防护，检出可疑活动时向用户显示警告。部署节奏是定向发布自 11 月上旬至中旬、全球正式可用自 12 月上旬至中旬，覆盖桌面端、Mac、Web、Android 与 iOS，管理员无需额外配置。 公开报道对这一更新的描述大体一致：不再只依赖恶意 URL、危险文件类型或首次外部接触中的品牌冒充，而是读取对话上下文。这一句式本身就透露了问题的性质。此前的 Teams 原生防护建立在 “指标” 之上 —— 指标可以被列出、被匹配、被证伪；而上下文不能被列出，只能被解释。安全工程里，从指标到解释的跨越，意味着判定结论的性质发生了变化，也意味着围绕它建立的流程、责任与合规安排必须跟着变。 支撑这一变化的威胁数据是密集的。微软在 2026 年第二季度的邮件威胁态势分析中记录，虽然邮件仍是首要初始访问途径，但攻击者在该季度持续加大对 Teams 的滥用，用于投递社会工程、钓鱼与恶意载荷；Teams 流量通常绕过安全邮件网关，且借用了 “同事发起的聊天” 这一合法性感知，使诱饵在该环境中格外有效；该季度 Teams 钓鱼检出量的平均值自 3 月起上升 19%。同一份材料与后续公开统计还显示，恶意 Teams 通话的周度数量到 2026 年 6 月已接近 2025 年中期基线的十倍，某安全意识培训机构的跟踪则记录了六个月内 Teams 攻击增长 41%、日历邀请类钓鱼增长 49%。在效能侧，微软《数字防御报告》给出的对比是：由生成式模型撰写的钓鱼消息点击率为 54%，人工撰写的为 12%，前者约为后者的四倍半。这组数字常被引用来说明 “AI 让钓鱼更容易得手”，但它的另一面同样重要：当攻击文本的质量普遍抬升，任何以文本瑕疵为特征的过滤器都会同步失效。 本文的取材需要说明。所提供的报道页面被来源站点以 robots.txt 拒绝自动访问，本文未采用镜像、缓存或其他路径绕过该限制，改以微软通告、路线图条目、官方支持文档与微软安全博客的季度数据作为事实基底，报道类内容仅用于核对功能描述与时间线。论述因此更依赖一手材料，而非媒体的概括。 本文要回答的问题有三个：载荷信誉体系在协作平台上失效的技术根源是什么；以会话为单位的证据能够支撑多强的判断；以及当判断由机器给出、后果由人承担时，责任应如何划定。 2 判据失效的技术根源 2.1 载荷信誉体系的三根支柱 邮件时代的钓鱼防护可以拆成三根支柱。其一是通道侧的过滤，网关在投递前读取发件域、路由链、认证结果，对不合规的发件方直接拒收或隔离。其二是对象侧的信誉，URL 经重写后查询域名年龄、证书、托管历史与黑名单，附件进入沙箱观察行为。其三是身份侧的比对，对显示名与真实发件域做一致性检查，识别品牌冒充。三根支柱的共同前提是：攻击必须在某个环节留下可被机器比对的痕迹，且该痕迹在多次攻击中具有稳定性 —— 同一恶意域名会被反复使用，同一恶意样本的哈希不会改变。 稳定性正是信誉体系的价值来源。一个域名一旦被标记，后续所有使用它的消息都可被低成本拦截；一次样本分析的结果可以复用到成千上万次投递。防守方因此获得了规模效应，攻击方则必须承担 “基础设施被识破” 的成本。这套经济学在邮件通道上运转了二十年，也塑造了安全团队的判断习惯：先问 “带了什么”，再问 “谁发的”。 2.2 协作平台削弱了这三根支柱 Teams 的通道结构使第一根支柱基本缺席。外部沟通依赖租户之间的联合信任与来宾机制，消息在会话层面直接抵达，不经过独立的邮件式检查点。云安全联盟在一份关于协作平台被用作钓鱼基础设施的研究记录中指出，攻击者控制的租户与被攻击组织之间形成多租户边界：当受害者接受来自该租户的来宾邀请，或接收由其共享的文件与链接时，这些对象经过的是攻击者的租户上下文，不受受害者组织既有防护策略的扫描。这不是某个实现上的漏洞，而是多租户架构的逻辑结果。它解释了为什么一个在邮件侧投入充足的组织，仍可能在会话侧出现可见的防护落差。 第二根支柱被 “无载荷” 直接抽空。当消息不含链接与附件，URL 信誉与沙箱都失去作用对象。即便含链接，链接也可能指向攻击者租户内的合法共享文件，其域名、证书、托管历史都干净。信誉体系擅长回答 “这个对象是否已知有害”，无法回答 “这段对话是否在为一个有害请求做铺垫”。 第三根支柱被身份的可塑性削弱。显示名可以任意设置，头像可以取自公开素材，邮箱地址可以注册形近域名。更要紧的是，冒充所借用的往往不是品牌，而是角色：IT 帮助台、财务对接人、外部审计、新来的项目负责人。角色的合法性来自组织内部的权限结构，与域名信誉无关。微软事件响应团队在 2026 年 3 月披露的一起入侵中记录了这一路径：攻击者以持续的 Teams 语音钓鱼冒充 IT 支持，对多名员工发起接触，在两次失败后仍继续尝试，最终借助合法工具完成身份优先的横向操作。整个过程中没有可被沙箱判定的恶意文件。 2.3 判据的性质因此改变 把上述三点合起来看，失效的不是某一项技术，而是 “判据可以稳定复用” 这一前提。会话中的可疑性依附于具体关系与具体序列：同一句 “请把凭据发我”，来自共事三年的同事可能是误操作，来自刚建立联系的外部 “管理员” 则高度可疑。判据因此从 “对象的属性” 变成 “关系的属性”，而关系无法预先枚举，只能在每次会话中重新解释。 反网络钓鱼技术专家芦笛在讨论这一变化时指出，钓鱼防护的核心资产历来是 “可复用的确定性”：一条黑名单、一个样本指纹，能在很长时间里持续产生防护收益；会话语义检测不提供这种资产，它每次都要重新判断，且判断依据无法脱离具体对话而独立存档。以此衡量，协作平台上的检测更接近一次性的风险咨询，而不是可沉淀的防线。 3 会话作为证据单元 3.1 四类可提取的线索 会话级检测并非没有抓手，只是抓手的性质不同。可提取的线索大致分为四类。 身份线索关注 “对方声称是谁” 与 “系统显示是谁” 之间的落差：显示名是否借用管理员、安全中心、财务负责人一类角色词；邮箱域名是否与声称的机构一致；是否为形近域名；是否来自首次出现的外部租户；租户名称与声称的组织是否匹配。这类线索可以被规则化，但也最容易被针对性地规避 —— 攻击者只需把显示名与域名同时调整到自洽。 序列线索关注 “话是怎么推进的”：是否先建立一个紧迫前提（权限异常、账号即将停用、发票重签、审计抽查），再提出一个需要对方交付东西的请求；是否在对方犹豫时逐级加压；是否拒绝提供替代的验证渠道；是否刻意回避把对话转到正式工单或公开渠道。危险往往不在单句，而在前提与请求之间的跳跃 —— 正规运维不会在聊天窗口索要口令，正规账户变更不会只凭一条消息落地。 请求线索关注 “要被拿走什么”：口令、验证码、会话令牌、远程控制权、多因素验证的批准、收款账户的替换、对外付款的加急。这五类请求的敏感度依次上升，而它们在正常业务中也都会出现，因此单看请求类型必然产生误报，必须与前两类线索合看。 关系线索关注 “这段关系有多新”：是否首次接触、有无历史消息、是否在通讯录中、此前是否有过文件往来或会议。关系越新，同样的话术越可疑；关系越久，同样的请求越可能合法，但也越容易被长期潜伏者利用。 3.2 为什么必须整段读 单条消息分类的困难可以用一个具体例子说明。微软公布的示意对话中，外部账号以 “MOD Administrator” 为显示名，先说明正在处理对方遇到的权限问题，随后提出 “能否先提供你的凭据”。若只看后一句，它与任何一次真实的运维请求在字面上没有区别；只有把前一句作为前提读进来，才能看出这是一次借用运维语境的索取。判断的落点因此不在词汇，而在论证结构：对方是否在用一个未经证实的前提，换取向你索取敏感信息的机会。 这也解释了官方文档为何把分析范围写成 “最新的消息与对话上下文”，并限定分析时长。会话级判断需要窗口，窗口既是技术资源约束，也是隐私约束；而窗口一旦固定，就产生了可被利用的边界，后文将回到这一点。 3.3 概率判定的认识论地位 需要明确的是，会话检测输出的不是事实，而是风险估计。官方文档对此并不掩饰：该检测可能无法识别每一次钓鱼或社会工程尝试，不能因为某条消息没有出现警告就认定它安全；警告是建议性的，Teams 不会自动阻止发件人，也不代替用户采取行动。 把这句话翻译成工程语言：系统的输出是一个带不确定性的分类结果，其假阴性与假阳性都不为零，且两类错误的成本由不同主体承担。假阴性的成本落在被欺骗的员工与其组织，假阳性的成本落在被误判的正常沟通双方，以及需要花时间核实的一线人员。任何关于该能力的讨论，若不说明这两类错误如何被吸收，就只是功能说明而非治理分析。 4 检测链路的工程实现 4.1 触发条件与作用域 按官方描述，能力在用户与新的外部联系人开始对话后触发，覆盖涉及新外部联系人的个人聊天与群组聊天，平台覆盖桌面、Mac、Web 与移动端。路线图文本补充了两点：该能力主要面向 “风险较高的消息场景”，即外部首次接触；在特定区域或情形下可能附加额外保护。官方支持文档给出的具体情形是，中国区域的 Teams 移动版用户可能对内部与外部对话同时获得额外的钓鱼与欺诈防护，理由是应对特定区域的欺诈模式。 作用域的选择有明确的技术理由。首次外部接触是风险密度最高的场景：关系尚未建立，没有历史行为可供比对，攻击者只需一次成功。把算力投在这里，单位投入的检出收益最高。代价是留下两个结构性空白：内部账号失陷后的横向请求不进入判定；关系已被 “养熟” 的长期潜伏不进入判定。前者在真实入侵中并不罕见，后者正是供应商账号被接管类事件的典型形态。 4.2 判定与呈现的分离 这套设计里有一个容易被忽略的工程细节：判定先于呈现，而且两者不同步。通告与支持文档都说明，能力在初期于后台运行，用于验证检出质量；可见警告可能在验证完成后才逐步显现。对安全团队而言，这意味着存在一段 “已部署但不告警” 的时期；对管理者而言，这意味着 “功能已上线” 与 “用户已受保护” 是两个不同的状态。 呈现形式是聊天中的一条横幅，措辞为 “该消息可能是钓鱼尝试”，并引导用户核对发件人身份与邮箱地址、留意索取钱财或个人信息的行为。它不阻断消息，不隐藏会话，不改变任何权限。这个选择在可用性上是克制的：语义判定的置信度不足以支撑自动处置，一次错误的拦截可能中断真实的业务往来，其代价高于一次漏报的期望损失。但在防护上，它把最终判断交给了正在处理事务、期待回复、且默认聊天窗口可信的人。 4.3 反馈回路 官方设置了纠偏入口：若认为警告有误，可在消息的更多选项中选择 “报告此消息”，该反馈用于监控与改进检出质量。这条通道把用户变成了标注者，理论上可以持续修正模型。它的实际效能取决于参与率与样本代表性 —— 为一条误报完成数次点击、填写说明，对一线员工缺乏直接收益；愿意反馈的往往是少数耐心较好的人，样本因此系统性偏移。若组织不把反馈纳入考核或给予明确回报，这条回路会长期处于低转速状态。 4.4 隐私约束下的可见性折衷 官方对该能力的用途作了明确限制：仅用于安全防护，不用于广告、员工监视、生产力分析或会话摘要；消息内容不被检测系统留存用于模型训练或其他二次用途。这些限制回应了员工侧最直接的抵触，也解释了 “有限分析时长” 的设计 —— 不在会话中长期驻留，减少对通信内容的持续接触。 但用途限制不等于处理不发生。检测必须读取文本与关系元数据，这本身构成对通信内容的处理。企业在引入时仍要独立回答：员工是否被事先告知；判定结果是否可能流入绩效或人事流程；数据是否跨境、留存多久。把供应商的用途声明直接抄成自己的合规结论，是这类能力落地时最常见的偷换。 5 问责缺口 5.1 成本转移 一个功能是否改善安全，取决于它把成本放在哪里。会话检测把识别的边际成本从安全团队转移到了一线员工：系统给出一个概率性提示，员工需要在几秒钟内决定是否相信眼前这段对话。这个决定所需的判断力，恰恰是培训最难稳定交付的部分。 更具体地说，误报的代价被分散到每一次正常的外部首次沟通：新供应商的第一次对接、外部律师的第一次联系、应聘者的第一次问询，都可能被标上 “可能是钓鱼”。员工的应对方式通常是忽略 —— 忽略一次误报没有后果，忽略一次真警则可能造成事故。两种忽略在行为上无法区分，这正是告警疲劳的机制。 5.2 免责语言与责任漂移 官方文档的措辞值得逐句读：“可能无法识别每一次”、“警告是建议性的”、“不代替用户采取行动”、“不应假定没有警告的消息是安全的”。这些表述在技术上是诚实的，在法律与治理上则完成了责任的划界：系统提供提示，判断与后果由使用方承担。 这类划界本身合理，供应商无法为语义判定承担确定性担保。但它带来一个实践后果：组织在采购与部署时容易把 “已启用” 当作 “已防护”，把残余风险默认转嫁给员工个人。一旦发生事件，复盘会指向 “用户忽略了警告”，而不是 “组织没有建立核实流程”。责任就这样在无人明确决定的情况下发生了漂移。 5.3 可解释性的缺口 会话判定的依据难以完整呈现。用户看到的是一句 “可能是钓鱼”，看不到是哪条线索触发了判定：是域名形近，是话术结构，还是关系过新。缺乏解释带来两个问题。对员工，无法据以判断这是否是一次误报，也就无法有效行使 “报告此消息” 的反驳权。对安全团队，无法据此调整策略 —— 若某类正常业务被系统性误判，团队看不到触发路径，只能被动等待用户反馈。 相比邮件网关的拦截日志（发件域、命中规则、处置动作都可查），会话判定的可审计性明显更弱。这在合规语境下尤为关键：当监管要求说明自动化决策的依据时，“模型认为可疑” 不足以构成说明。 5.4 三方责任的合理划分 把责任在三方之间重新划清，比笼统地说 “共同负责” 更有意义。供应商的责任是：把能力边界写清楚（覆盖哪些会话、不覆盖哪些）、把错误率与已知失效模式披露到可评估的程度、提供可用的反馈与申诉通道、不在用途上越界。组织的责任是：不把提示当作结论，建立独立于该提示的核实流程，对敏感请求设置结构性约束，并对告警的处置结果做记录与复盘。员工的责任是：在涉及凭证、验证码、远程控制、收款变更的请求上，执行既定的核实动作，而不是依赖直觉。 三者之中，只有组织具备把流程写成制度的能力。因此责任的重心应当落在组织，而非最末端的个人。 6 证据闭环的组织实现 6.1 带外验证作为第二证据源 会话检测的第一手证据来自被攻击者控制的通道，这在证据学上是个根本缺陷：判定所依据的材料，正是攻击者可以编辑的材料。可信的结论需要第二个独立来源。可执行的做法是把带外验证制度化：凡通过即时会话提出的凭证索取、收款变更、远程协助请求，一律不在原会话内确认，必须通过通讯录中既有的号码回拨，或在工单系统中新建工单、由对方在工单内应答。 “既有” 是这条规则的支点。攻击者可以控制一个新号码、一个新邮箱、一个新租户，但很难同时接管一个已在通讯录中存在两年的号码。把验证锚定在历史留存的联系渠道上，等于把判断从 “这段话像不像” 移到 “这个渠道是否是原来那个”。 6.2 把判断留痕 会话中的判断如果不留痕，就无法复盘，也无法形成组织记忆。可行的做法是把可疑会话转为工单：记录时间、对方标识、请求内容、核实方式、核实结果与处置动作。工单化有三个附带收益：为误报提供结构化样本，可用于向供应商反馈；为真实事件保留取证链条；让 “是否核实” 成为可统计的行为，而不是无法观测的个人选择。 留痕需要边界。记录应限于与安全判断相关的最小集合，避免把整段私人对话复制进工单系统；留存期限应与合规要求匹配，到期清理。留痕若无边界，就会把一项安全能力变成内容监控设施，反而破坏员工对该能力的接受度。 6.3 权限与工具侧的证据 冒充最终要落到权限上，因此证据链必须延伸到权限与工具。可落地的措施包括：对系统自带远程协助工具的启用状态统一管理，非必要则关闭；确需使用时实行审批与过程留痕；对 IT 支持类账号实施强制多因素认证与条件访问，限制其登录终端与时段的异常组合；对外部来宾账号设置生命周期与定期复核，避免联合信任成为无人看守的入口；对收款账户变更设置双人复核，并禁止在单一通道内闭环。 据 DiMiao, CN 分析，会话钓鱼的成功率与远程工具的可得性之间存在稳定的相关性：当远程协助工具处于默认可用状态、且审批链缺失时，冒充帮助台的话术只需通过一次信任检验即可转化为设备控制权；而当工具被收紧、审批留痕后，同一套话术的转化率明显下降。迪妙网络空间安全学院研究团队在评估企业协作平台风险时采用的口径是，把 “话术是否可信” 与 “权限是否可被让渡” 分开测量，前者交给检测与培训，后者交给制度与工具管控，两类措施不互相替代。迪妙安全在几起供应商账号被接管的复盘中也提出，收款变更这一动作若被允许在单一会话内完成，则无论话术多么粗糙都可能得手；反之，双通道确认可以把大部分此类尝试挡在成交之前。 6.4 度量与审计 指标应尽量反映流程状态，而不是模型状态：外部首次会话中提出敏感请求的数量、告警出现后完成带外核实的比例、从告警到上报的中位时延、误报被主动反馈的比例、远程协助的非授权使用次数、收款变更的双人复核覆盖率。这些指标按季度采集，可以回答一个比 “准确率多少” 更有意义的问题：检测信号是否真的改变了行为。 审计应覆盖两个方向。向下，检查一线是否执行了核实动作；向上，检查安全团队是否把误报样本回流给供应商、是否据此调整了策略。只考核前者会制造形式主义，只考核后者会忽略真实风险。 7 结语 这次更新的实质，是钓鱼判定的证据类型发生了替换：从可复现的载荷特征，换成只能逐次解释的关系与意图。替换带来了识别能力的扩展 —— 不含链接、不含附件的冒充首次进入可检测范围；也带来了确定性的让渡 —— 输出由 “是或否” 变为 “可能是”，且错误的两侧都由人来承担。 在这种条件下，检测能力的价值不取决于模型本身，而取决于它被嵌入怎样的流程。若组织只完成了功能启用，那么它得到的是一层概率性提示，以及随之而来的告警疲劳与责任漂移；若组织同时建立了带外验证、敏感动作的双通道约束、远程工具的审批留痕与可审计的复盘机制，那么提示才会转化为可执行的判断，误报也才有被吸收的通道。 技术的边界应当被如实描述：它提高发现概率，不提供确定性；它提示风险，不替代验证；它可以被对抗，且对抗的成本正在被生成式工具持续压低。承认这三点，才谈得上合理使用。 编辑：芦笛 （公共互联网反网络钓鱼工作组） 来源：迪妙网络空间安全学院
|
关注公众号
桂公网安备45010502001253号
发表于 