夜雨聆风
Outlook插件爆雷:当合法的SaaS服务变成钓鱼工具,我们在信任谁?
大家好，平时咱们给公司小白做安全培训，最常挂在嘴边的一句话就是：“千万别乱下软件，一定要去官方应用商店下载！”毕竟在我们的认知里，App Store、Google Play 或者微软商店，代表着安全审核的标准。
但如果我告诉你，官方商店里的正规应用，也会突然变成窃取你密码的“内鬼”呢？
最近，安全公司 Koi Security 爆出了一个大瓜：他们发现了首个潜伏在 微软官方 Office Store 里的恶意 Outlook 插件。这玩意儿在微软眼皮子底下，利用一种极其巧妙的手法，悄无声息地卷走了超过 4000 个 微软账户凭证。
这不是一次简单的钓鱼，而是一场教科书级别的供应链攻击。今天，咱们就从技术角度扒一扒，黑客是如何玩弄“云原生”架构，实现空手套白狼的。
01 案发现场：一个“僵尸”插件的复活
这次的主角叫 AgreeTo。
这原本是一个非常正经的 Outlook 插件，用来聚合不同日历，方便用户通过邮件分享空闲时间。就像很多中途夭折的 SaaS 创业项目一样，它的开发者在 2022 年 12 月发了最后一个版本后，似乎就“弃坑”了。
但在安全世界里，“弃坑”往往意味着风险的开始。
Koi Security 的研究人员发现，这个已经被开发者遗忘的插件，最近突然“诈尸”了。它开始向用户展示一个假的微软登录页面。用户以为自己在登录 Outlook，实际上密码已经被黑客截获，并通过 Telegram Bot API 实时传到了黑客手里。
这波操作被研究人员命名为 AgreeToSteal。
这就很离谱了对吧？微软的审核团队在干嘛？应用商店不是有定期扫描吗？
别急，这正是这次攻击最“骚”的地方——黑客压根没碰那个插件的代码包，甚至不需要入侵开发者的微软账号。
02 技术拆解：黑客是如何“接管”域名的？
要看懂这个攻击，我们得先复习一下 Office 插件（Add-ins）的架构原理。
跟咱们传统的 .exe 或者手机 App 不同，现在的 Office 插件本质上就是一个 Web 应用。它的核心包含两个部分：
- Manifest 文件（清单文件）：
一个 XML 文件，告诉 Outlook 插件叫什么、要什么权限，以及去哪里加载内容。 - Web 内容：
实际运行的 HTML/JS 代码，通常托管在开发者自己的服务器上。
当你在 Outlook 里打开插件时，Outlook 实际上是开了一个 iframe，去加载 Manifest 里指定的 URL。
漏洞点：云服务商的“资源回收机制”
AgreeTo 的开发者当年是用 Vercel 来部署后端的，Manifest 里写死的 URL 类似于：
https://outlook-one.vercel.app/…
关键点来了：
大概在 2023 年左右，因为项目废弃，开发者删除了 Vercel 上的部署，或者因为长期未活跃、欠费等原因被 Vercel 回收了。于是，outlook-one.vercel.app 这个子域名就变成了互联网上的“无主之地”。
黑客发现了这一点，直接去 Vercel 上注册了一个新项目，并抢注了同一个子域名。
于是，攻击链路完美闭环：
-
🚨 第一步：用户在微软商店下载/打开合法的 AgreeTo 插件。 -
🚨 第二步：Outlook 读取 Manifest，信任并请求 outlook-one.vercel.app。 -
🚨 第三步：此时这个域名已经归黑客所有，返回了精心制作的钓鱼页面。 -
🚨 第四步：用户输入密码 -> 黑客得手 -> 跳转回真页面掩人耳目。
这简直就是现实版的“店铺转让”：招牌还是原来那家经过认证的“老字号”，但后厨已经悄悄换成了黑客。
03 细思极恐：如果你给的是 ReadWrite 权限
这次攻击虽然“只”偷了 4000 多个凭证，但从技术角度看，黑客其实非常“克制”（或者说还没来得及搞大的）。
我特意查了一下这个插件的权限配置，它申请了 ReadWriteItem 权限。
各位搞开发的兄弟都知道这意味着什么。有了这个权限，插件不仅能读取用户的邮件内容，还能修改和发送邮件。
既然黑客已经控制了 iframe 加载的 JS 内容，他们完全可以不搞钓鱼页面，而是直接注入一段恶意脚本：
静默扫描你的收件箱，寻找“合同”、“发票”、“VPN密码”等关键词；或者自动向你的联系人发送带病毒的附件。
这一切，都在 Outlook 内部发生，绕过了防火墙，也绕过了很多基于网关的安全检测。
04 信任危机：静态审核 vs 动态内容
这起事件暴露了现代应用商店（Marketplace）模式的一个结构性硬伤。
Koi Security 的 CTO Idan Dardikman 对此总结得很透彻：“Office 插件不分发静态代码包。Manifest 只是声明了一个 URL，至于这个 URL 下一秒会返回什么，完全是动态的。”
目前的审核机制大多是“一次通过，永久信任”（Approve once, trust forever）：
-
微软在 2022 年审核了 Manifest，当时 URL 指向的内容是干净的。 -
之后几年，只要开发者不更新 Manifest，微软就不会触发重新审核。 -
但 URL 背后的服务器内容，随时可能从“良民”变成“土匪”。
这不仅仅是微软的问题，VS Code 插件、npm 包、浏览器扩展，所有依赖远程动态加载的生态系统，都面临同样的威胁。
05 反思与防范
2026 年 2 月 12 日，微软已经下架了该插件。但作为技术人员，我们得从中学到点什么。
如果你是开发者：
域名资产管理是生死线！ 废弃项目时，千万别只删代码库。如果你的应用依赖特定的云厂商子域名（Vercel, Netlify, Azure, AWS S3 bucket），一定要确保该域名不会被他人抢注，或者在客户端/Manifest中及时移除引用。
Subdomain Takeover（子域名接管） 是目前云原生环境下极易被忽视的漏洞，建议定期自查 DNS 记录。
如果你是企业 IT 管理员：
不要迷信“官方商店”。哪怕是微软商店里的应用，也需要定期审计。对于请求 ReadWrite 这种高敏感权限的插件，如果发现它长期未更新（Abandonware），建议直接禁用。
最后，说一句话：
在万物互联的云时代，信任不能是一劳永逸的，它必须是持续校验的。
今日互动：
你在工作中遇到过类似的“废弃资产”引发的安全坑吗？欢迎在评论区聊聊！
