微软本周发布了一条九阶段的攻击链：一条来自伪造帮助台的 Teams 消息、一个 Quick Assist 会话、一次借助厂商签名程序完成的 DLL 侧加载、一次横跨网络的 WinRM，再加上一次 Rclone 把数据偷到攻击者的云存储。九个阶段里有八个要求宿主操作系统是一台真正的桌面电脑。跑在一台可随时丢弃的虚拟机里的浏览器标签页，不是这样一台桌面电脑。

2026 年 4 月 20 日，微软的威胁分析团队发布了对一条九阶段攻击链的拆解，多个勒索软件分支组织现在正在生产环境里使用这条链。开场动作是社会工程：一条消息在 Microsoft Teams 里从一个外部租户发来，对方自称是 IT，要求目标开启一次远程支持会话，以处理「账户问题」或「安装一次安全更新」。收官动作是变现：Rclone——一款合法的云同步工具——把文件服务器的内容一路串流到攻击者控制的对象存储里，与此同时勒索软件把剩下的东西加密掉。

微软的原话值得直接引用：「威胁行为者越来越频繁地滥用外部 Microsoft Teams 协作，冒充 IT 或帮助台人员，诱导用户授予远程协助访问权限。」 这里的新意不在社会工程本身——假冒帮助台和帮助台本身一样古老——而在投送面。Teams 是那种装在每一台公司桌面上、始终登录、开机自启、通知 API 让外部消息看起来和内部消息一模一样的协作客户端。在 2026 年，它比电子邮件更适合做钓鱼渠道。

这条链，从头到尾。

下面是这九个阶段在一台 Windows 机器上实际做的事。编号是微软的；白话描述是我们的。

微软记录的这条链。第 1 阶段是一条来自陌生人的、出现在公司聊天客户端里的消息。第 2 到第 9 阶段是一串在 Windows 宿主上执行的操作——Quick Assist、PowerShell 侦察、一个由合法签名的 Adobe 或 Autodesk 程序加载的 DLL、在加入域的机器之间横移的 Windows 远程管理，以及用 Rclone 把文件服务器的数据偷出去。勒索软件的加密动作发生在数据已经流出之后。

这条链高效而无聊，这正是 2026 年一份称得上称职的勒索软件手艺应有的样子。这里没有任何一个零日漏洞。Quick Assist 是随 Windows 一起交付的、微软自家的远程支持工具。PowerShell 是微软自家的管理外壳。DLL 侧加载——把一个攻击者控制的库放到一个合法签名程序旁边，让签名程序把恶意代码加载进来——这种手法已经有二十年历史。WinRM 是域管理员本来就应该用来管理 Windows 机群的手段。Rclone 是一个开源的云同步工具，你可以从 Homebrew 装上。整个攻击，是由受支持的、有签名的、IT 部门认可的原语拼出来的。这正是它难以被传统终端防护工具发现的原因：每一个单独的步骤，看起来都像 IT 团队有意在做的事。

正面论点：在第一步把这条链斩首。

现在再设想一下，如果第一阶段不再是一个在原生 Windows 桌面客户端里弹出的通知，而是一个在浏览器标签页里弹出的通知，这条链会是什么样子。在一个 Bromure 标签页里弹出的通知。在一台没有持久磁盘、没有加入域、没有 Windows 可执行文件、没有 WinRM 监听器、没有 Rclone、没有可以被侧加载的 Adobe Reader、跟宿主不共享文件系统、窗口一关就会被销毁的一次性 Linux 虚拟机里弹出的通知。

阶段 1 仍然会落地。外部的 Teams 租户仍然能把那条 DM 发出来。用户仍然能看到那条消息。社会工程的压力仍然在那里。Bromure 并不会阻止一个陌生人，声称自己是帮助台，在聊天窗口里输入「我要在你电脑上装一次安全更新，让我开一个 Quick Assist 会话吧」。

但阶段 2 在这里就停住了。浏览器标签页没法启动 Quick Assist，因为 Quick Assist 是一个原生的 Windows 程序，而这个标签页是一个跑在 Linux 虚拟机里的 Chromium 窗口，里面没装 Quick Assist，也装不上，也没有 IPC 通道去触达运行 Bromure 的那台设备另一侧的 Windows 机器。并且因为这条链是严格顺序的——每一个后续阶段都依赖上一个阶段留下的工件——在第二步斩首，意味着第 3 到第 9 阶段根本就不会发生。

同样的一条链，从两种用户习惯看过去。上：Teams 作为宿主操作系统上的原生桌面客户端——每个阶段都有它需要的东西。下：Teams 在一个 Bromure 标签页里以 teams.microsoft.com 打开——阶段 1 落在那台临时虚拟机里，之后的每一个阶段，都是这台虚拟机在结构上没办法做的事。

这张图有一种很诱人的、但走得太远的读法：「用 Bromure，对勒索软件免疫。」这不是我们的主张。主张要窄得多，而这个更窄的版本更诚实，也更有用。

这条边界到底是什么。

在这里真正起作用的，并不是什么针对 Teams 的聪明过滤器。它是 Bromure 运行网页内容这件事本身的一个结构性属性。Bromure 里的每一个标签页，都在你 Mac 上自己的一台可随时丢弃的 Linux 虚拟机里运行。用户看到的那个浏览器是 Chromium，跑在那台 Linux 客户机里面。标签页的边界就是这台虚拟机。宿主的边界是虚拟机监视器（hypervisor）。你关掉标签页，这台 VM 就被销毁。你打开一个新标签页，一台新的 VM 就从一份干净的磁盘镜像里创建出来。

这条边界在哪儿。冒充帮助台的人仍然能往那个聊天窗口里打字（阶段 1）。之后的每一个阶段，都需要在 macOS 宿主上做点什么——启动一个原生程序、把东西写进一个文件系统、跨着局域网横移。虚拟机监视器的边界就夹在攻击者和所有这些东西之间。聊天窗口在一侧；攻击者想要用的那套帮助台工具，在另一侧。

当处在阶段 2 的攻击者说接受我的 Quick Assist 会话时，他们想调用的那个机制，在边界的另一侧根本不存在。Linux 客户机里没有 Quick Assist。一个网页——哪怕用户完全信任它——也没有任何办法从客户机里伸出去、触达宿主，启动一个 macOS 或者 Windows 的原生程序。没有这样的桥；有这样的桥，整个架构就白做了。攻击者的这条链依赖一组能力——启动原生应用、写入一个持久文件系统、在签名厂商程序旁边加载一个 DLL、打开一个 WinRM 会话、读取宿主凭据——而从结构上讲，标签页 VM 这些全都不具备。

这不是我们专门为 Teams 帮助台威胁加的一项功能。这就是那套让 Bromure 对浏览器零日漏洞、恶意扩展和各种信息窃取程序普遍有用的同一个属性。阶段 1 是这条链里唯一在乎用户点了什么的部分。之后的每个阶段都需要用户的桌面。把浏览器放到另一台电脑里、和桌面分开，那这条链就不再是关于用户的选择，而变成关于机器架构的事情了。

这件事解决不了什么。

如果同一个用户把 Microsoft Teams 装成了原生桌面客户端——macOS 上的 Microsoft Teams.app，或者 Windows 桌面客户端，两者都跑在 Bromure 之外，又都登录的是同一个用户账号——那么这条外部租户发来的 DM 就会直接落在宿主上。到这一步，我们又回到了图里的第 A 行。阶段 1 是一个原生通知。阶段 2 是用户在自己真实的桌面上接受一个 Quick Assist 会话。标签页虚拟机根本没有进入故事。Bromure 保护不了不在 Bromure 里跑的东西。

同理：如果你们组织的 IT 策略是在租户层面屏蔽外部 Teams DM——微软的通报也建议这么做——那阶段 1 在哪种情况下都碰不到用户，架构这档子事也就没啥好讨论的了。那才是第一道该修的地方。Bromure 是一道为以下这些情况而生的防线：第一道没被修上；用户在用的是个人设备；策略有个豁免口子；或者攻击者找到了一个没把这条策略强制住的租户。

浏览器习惯改变了什么

在一个 Bromure 标签页里以 teams.microsoft.com 打开 Teams，会把阶段 1 挪到你 Mac 上的一台临时 Linux 虚拟机里。如果你点了冒充者发过来的「接受支持」链接，他们想要的那个工具根本不在点击落地的地方。请求因为能力不存在而失败。

原生客户端改变不了什么

如果你已经装好了 Teams 桌面应用并且登录了账号，DM 会直接到那里，宿主的暴露情况就和微软描述的一模一样。卸掉桌面客户端，或者把它降级到一台专门的工作电脑上，是 Bromure 让这种行为改变成为可能——而不是 Bromure 要求你这么做。

Bromure 拦不下什么

一个被劝着把公司密码输进 Bromure 标签页里的表单的用户，还是会丢掉那个密码。浏览器的反钓鱼检查会试着拦下这个表单，但一个下定决心的社会工程目标，可以打穿任何这类防护。凭据钓鱼和虚拟机边界防御，是两个不同的问题。

这个主张的诚实形状

对一个工作习惯是浏览器 Teams 的用户来说，Bromure 把一次九步入侵变成了一次一步对话。对一个工作习惯是原生客户端的用户来说，面对这次攻击 Bromure 什么都没改变。这就是我们选择发这一篇、而不是一篇更短、更喧闹的文章的全部理由。

为什么浏览器习惯值得捍卫。

大多数企业聊天客户端——Teams、Slack、Discord、Zoom——都会同时以原生桌面应用和网页应用的形式发布，网页版用的是同一个 URL。网页版的功能完整度，对绝大多数人用它们做的事来说已经够用：读消息、写消息、搜索、上传文件、打电话。网页版不会开机自启。网页版不会在宿主上维持一个常驻进程让攻击者去刺探。网页版也不附带一条更新通道——而过去，这样的更新通道本身就当过供应链事件的载体。而且，只有在浏览器是 Bromure 的情况下，独有一点：网页版活在一台跟用户真正那台电脑不共享文件系统的计算机里。

这里要推销的，不是每个用户明天就该卸掉 Teams 桌面应用。而是：网页优先这个选项存在、多年来一直默默地可以用，并且——鉴于 4 月 20 日微软描述的那些事——对任何不是非得用桌面客户端某个独占功能的用户来说，现在实质上是更安全的那一个。Bromure 让这个选择有分量。一次跑在普通 Chrome 窗口里的网页版 Teams 会话，仍然是一次和你 Mac 上所有其他程序共享文件系统的会话。一次跑在 Bromure 标签页里的网页版 Teams 会话，不是。

一个故事，它改变了什么。

微软这份九步通报不会是最后一份同类报告。这种形状——外部社交渠道 → 远程访问工具 → 侦察 → 签名程序持久化 → 横向移动 → 数据外传——就是现在绝大多数由人工操作的勒索软件入侵所采取的形状，不管它们从哪个聊天客户端开始。协作客户端，就是新的电子邮件收件箱。「点一下接受这次支持会话」，就是新的「点一下启用宏」。之后的人工操作，就是攻击本身。

如果用户的日常工作发生在一台聊天客户端和文件服务器共享同一个操作系统的机器上，攻击者只要把一只脚伸进这个操作系统，就可以完成另外八步。如果用户的日常工作发生在一个跑在虚拟机里、聊天客户端跑不出来的浏览器里，攻击者就需要另一套完全不同的原语去把活干完——而这套原语，不在当下这一代勒索软件剧本里。

那不是免疫。那是在第一步就把攻击链斩首。装上 Bromure，在里面用 teams.microsoft.com 而不是原生客户端来处理你工作聊天中能搬过去的那部分，然后让下一条九步链，成为攻击者自己的麻烦。