谷歌发现新骗局：用垃圾邮件钓鱼Teams用户

你刚清空完邮箱里99+封垃圾邮件，Teams突然弹出一条消息——"IT部门"说注意到你的账户异常，需要立即处理。这不是巧合，是一场精密设计的连环陷阱。

一场"先轰炸后救援"的社交工程实验

谷歌威胁情报团队最近追踪到一个从未被记录过的攻击组织UNC6692。他们的手法让见惯风浪的安全研究员也感到新鲜：不是直接发送钓鱼链接，而是先制造问题，再扮演解决问题的人。

攻击时间线通常这样展开：

第一阶段，目标邮箱在短时间内被海量垃圾邮件淹没。这不是骚扰，是铺垫——让受害者产生真实的焦虑感。

第二阶段，攻击者通过微软Teams的跨租户功能（cross-tenant）主动联系目标，自称IT或帮助台人员。台词很具体："我们注意到你的邮箱遭受垃圾邮件攻击，奉命前来修复。"

第三阶段，他们发送一个"修复页面"链接。受害者点击后，被要求输入邮箱密码进行"健康检查"。谷歌注意到一个细节：第一次登录必定失败，这是故意设计的——既显得系统"真实"，又能确认受害者输入的是有效密码而非随意乱打的字符。

谷歌在报告中将这种策略描述为「战术上的有趣演变」——攻击者不再依赖伪造的紧急感，而是先创造真实的混乱，再以权威身份介入。

三重恶意软件的"雪球"框架

谷歌给这套攻击基础设施起了个代号："雪球"（Snow）。这个名字暗示攻击的递进特性——从一个小触点开始，越滚越大。

一旦初始凭据到手，攻击会进入更深阶段。页面会执行所谓的"邮箱完整性检查"，随后提示用户下载一个"修复工具"。这个工具实际上是恶意软件下载器，负责部署三种不同的恶意程序：

第一种是信息窃取器，专门收割浏览器中保存的密码和会话令牌。第二种是远程访问木马，让攻击者持续控制受害设备。第三种是持久化后门，确保即使前两者被发现清除，攻击者仍能重新进入系统。

谷歌没有公开这三种恶意软件的具体家族名称，但强调它们分工明确：窃取器负责短期变现，木马支持中期操作，后门保障长期访问。这种"三位一体"的结构表明UNC6692不是 opportunistic 的散户，而是有资源、有耐心、有规划的团体。

跨租户功能是Teams允许不同组织用户互相通信的机制，本意是方便企业协作。攻击者利用的是配置疏漏——许多企业未限制外部租户的联系权限，或者员工根本不清楚Teams消息可以来自组织外部。

这意味着防御难点不在技术漏洞，而在认知盲区：当一条消息出现在工作常用的Teams界面里，人的警觉性天然低于面对陌生邮件。

为什么选Teams？界面信任的红利

钓鱼攻击的历史是一部"信任迁移史"。早期攻击者伪造银行邮件，后来转向更日常的快递通知、发票确认。现在，他们把阵地搬到了企业协作工具。

Teams的界面设计强化了这种信任。消息气泡、已读回执、组织架构显示——这些元素共同构建了一个"官方感"场域。攻击者不需要完美模仿企业IT部门，只需要比邮件钓鱼稍微像一点，就能利用用户对工作平台的默认信任。

微软今年早些时候已发布过类似警告，指出攻击者冒充外部IT支持人员进行Teams钓鱼。但谷歌此次追踪的UNC6692展现了更完整的攻击链：垃圾邮件轰炸制造焦虑，Teams接触建立权威，三重恶意软件确保收益最大化。

这种"全渠道"设计反映了企业安全的一个结构性难题。邮件安全网关已经相当成熟，但协作工具的安全监控往往滞后。员工被训练成"看到陌生链接要警惕"，但很少有人被提醒"Teams上的外部联系人也可能是假的"。

更隐蔽的是攻击者的耐心。谷歌观察到，从垃圾邮件轰炸到Teams接触，中间可能间隔数小时甚至一天——这不是自动化脚本的高速运转，而是人为判断时机、调整话术的结果。

防御的裂缝：当安全培训追不上攻击进化

传统的钓鱼防御框架建立在几个假设上：攻击者急于求成、伪造品总有破绽、用户经过培训能识别异常。UNC6692的策略逐一打破这些假设。

他们不急。先让垃圾邮件自然发酵，再择机介入。他们不依赖伪造破绽——Teams消息确实来自真实的Teams基础设施，只是发送者身份是假的。他们甚至不害怕用户犹豫：第一次登录失败的设计，本身就是筛选机制，筛掉警惕性最高的人群，留下最容易操控的目标。

对企业安全团队来说，这意味着需要重新校准防御重心。技术层面，限制Teams跨租户通信权限、强制外部联系人标识、监控短时间内大量外部消息的模式。人员层面，需要把"协作工具也可能被用于钓鱼"纳入常规培训——不是作为补充知识，而是作为核心场景。

谷歌的报告没有透露UNC6692的具体目标行业或地理分布，但提到攻击者展现出"对目标环境的熟悉度"——他们能准确判断哪些组织使用了Teams，哪些配置可能存在疏漏。这种情报收集能力本身，就是区分业余与专业的标志。

一个值得注意的细节是攻击者的"服务心态"。他们在Teams对话中表现出的耐心、对"修复流程"的详细解释、甚至允许用户"稍后完成"的宽松态度——这些都是精心计算的心理操控。真正的IT支持往往匆忙粗暴，而攻击者有动力让你感到被重视、被理解。

事件还原：一次典型攻击的72小时

根据谷歌披露的时间线，我们可以拼凑出一次完整攻击的轮廓。

第0小时：目标邮箱开始收到垃圾邮件，频率从每小时数封迅速攀升至每分钟数封。发件人地址随机，内容混杂，目的是制造混乱而非直接钓鱼。

第6-12小时：垃圾邮件持续涌入，目标可能已联系内部IT或自行设置过滤规则。焦虑感建立。

第18-24小时：Teams消息到达。发送者显示为外部租户用户，但名称和头像经过设计，模仿常见的IT服务商或企业内部支持团队。消息内容提及"监测到你的邮箱异常"，与受害者刚刚经历的真实情况形成呼应。

第24-30小时：若目标回应，攻击者发送"诊断门户"链接。页面设计简洁，模仿微软风格，要求输入企业邮箱凭证。第一次提交后显示"验证失败，请重试"——这是关键筛选步骤。

第30-36小时：凭据到手，页面转向"邮箱完整性检查"，诱导下载"修复工具"。恶意软件部署完成，三种组件依次激活。

第36-72小时：信息窃取器开始工作，远程访问木马建立连接，后门完成持久化。攻击者获得长期立足点，可根据目标价值决定后续行动——勒索、商业间谍、或作为跳板攻击供应链。

整个链条中，唯一需要受害者"主动配合"的是输入密码和下载文件。但攻击者通过前置的焦虑制造和权威的Teams界面，大幅降低了配合的心理门槛。

产品视角：协作工具的安全设计债务

从产品设计角度，Teams的跨租户功能是一个典型案例：便利性优先，安全后果后置。

跨租户通信的默认设置、外部联系人的视觉标识不足、组织边界在界面中的弱化——这些设计选择服务于"无缝协作"的愿景，却为身份冒充创造了条件。这不是微软独有的问题，Slack、Zoom、飞书等工具都面临类似张力。

谷歌的报告实际上提出了一个产品问题：当协作工具成为工作基础设施，它们的安全模型是否跟上了这种地位变化？邮件系统花了二十年才建立起相对完善的钓鱼防御生态（SPF、DKIM、DMARC、用户培训、邮件网关），而企业协作工具的安全建设明显滞后。

一个可能的改进方向是"上下文完整性"——当外部租户用户联系内部员工时，系统应主动提示"此人不属于你的组织"，而非依赖用户自行查看个人资料。另一个方向是行为异常检测：短时间内大量外部联系尝试、结合近期邮箱流量异常，应触发安全告警。

但这些改进都有成本。更严格的默认设置可能阻碍合法协作，更频繁的警告可能引发"告警疲劳"。产品团队需要在安全与体验之间找到新平衡点——而攻击者正在利用这个平衡尚未达成的窗口期。

行动号召

如果你负责企业安全，本周就做三件事：检查Teams的跨租户访问策略，确认外部消息是否有明显标识；回顾近三个月的安全培训内容，确认协作工具钓鱼是否被当作核心场景；在内部IT渠道发布简短提醒，描述这种"先轰炸后救援"的攻击模式。

如果你是普通用户，记住一个简单原则：真正的IT支持不会通过Teams主动联系你处理安全问题，不会要求你在第三方页面输入密码，不会发送需要下载的"修复工具"。当"帮助"来得太及时，本身就是一种警告。

UNC6692的战术演变表明，攻击者正在系统性地挖掘企业协作工具的设计债务。防御的窗口期不会太长——当这种攻击模式被广泛认知，他们会转向下一个信任盲区。但在那之前，每一个未受保护的Teams租户都是潜在目标。