Cisco Talos 于 4 月 22 日发布了其 2026 年第一季度事件响应报告。两项发现，一个故事。钓鱼在第一季度重新夺回了初始访问向量的头把交椅——占所有参与事件的三分之一以上——这是自 2025 年第二季度以来的首次。而在这条头条数字内部，埋藏着 Talos 首次归因于 AI「氛围编程」构建器的一个案例。攻击者使用无代码应用平台 Softr，在一个 *.softr.app 子域名上架起了一张真实可用的 Outlook Web Access 仿冒页面，把窃取的凭据写入一个一次性的 Google Sheet。整张页面没有写过一行代码。URL 信誉系统完全看不到它来了。

Talos 的2026 年第一季度事件响应趋势报告于 4 月 22 日发布，其头条数字是那种防御方会把它当作风向标去读的内容。钓鱼再一次成为最常见的初始访问向量——在所有能确定向量的事件中占比超过三分之一——这是自 2025 年第二季度以来的首次。MFA 方面的弱点出现在百分之三十五的事件里，比第四季度上升。公共管理与医疗保健并列最受攻击行业，各占百分之二十四。这些数字单独拿出来，都谈不上特别令人意外。

真正令人意外的，是报告中间的一则案例研究。Talos 以中等置信度记录了它所认为的一起首次观察到的具体 AI 应用案例——Softr，一款无代码「氛围编程」应用构建器——被用来托管一张真实运行的凭据窃取页面。这张页面模仿 Microsoft Exchange 和 Outlook Web Access，把用户提交的凭据收集到一个一次性的 Google Sheet 里，并在有新的凭据被捕获时给操作者发邮件提醒。Talos 评估这种手法最早可以追溯到 2023 年 5 月，但在 2025 年末直至第一季度持续加速。Trend Micro 的同步追踪显示同样的技术也出现在 Lovable、Netlify 和 Vercel 上：伪造的 CAPTCHA 页面被架设在 AI 构建器的子域名上，真正的凭据表单则藏在验证挑战的背后加载。

单独看这一张页面，平平无奇。真正的故事在于它的托管方式。

这条链条实际的样子。

像 Softr 这类无代码构建器，从设计上就是一条从提示词到上线 Web 应用的极短路径。你描述想要什么，它生成 HTML 和 JavaScript，把结果部署到它自己的基础设施上，再送你一个免费子域名。这个子域名与每一位其他 Softr 客户的子域名互为兄弟：something.softr.app。托管、TLS 证书、CDN、可用性——Softr 全包了。如果你是一名想要运行一张凭据窃取页面的攻击者，又不想注册域名、买证书、租 VPS，或者跟任何人解释你托管的是什么，这是一个极其诱人的提议。

Talos 记录下的这条链条。除了第一个环节以外，其余每一环都是一个正规 SaaS 在做自己产品页上所宣传的事情。一个域名信誉系统沿着这条链看下去，看到的是应用构建器的输出、来自主流证书颁发机构的 TLS、以及流入 Google 基础设施的外发数据。整条链条里真正由攻击者掌控的，只有起点处操作者的提示词，和终点处收警报的那个收件箱。

让这条链条特别耐人寻味的，是除了攻击者自己的提示词和攻击者自己的收件箱以外，每一环都是一家主流 SaaS 产品，在做着自己产品页上所宣传的事情。Softr 建起了页面。softr.app 把它放在一个子域名下托管。Google Sheets 存下了窃取到的凭据。Gmail 通知了操作者。一个自动化防御系统从上到下走一遍这条链，看到的只是一群信誉良好的第三方。这条链条并没有躲藏。它披着的，是防御系统被训练着去归类为「良性」的那层伪装。

URL 信誉系统的盲区。

大多数 URL 信誉系统——那些在你的浏览器还没完成 TLS 握手之前，就把一个链接打上「安全」「可疑」或「恶意」标签的系统——工作方式类似一家征信机构。它们给域名建立一份档案：它有多老了、它有多有名、它的 TLS 证书是有很长历史的还是刚从 Let's Encrypt 签来的、它是否曾经出现在拦截名单上、它所属的母公司是否声誉良好。档案得出一个分数，分数得出一个结论，结论得出一种颜色。

把 something.softr.app 丢进这条流水线。

给一个刚刚架起来的 Softr 子域名打出的一张 URL 信誉评分卡。信誉系统所依赖的每一项母域级别信号，回答它的都是那个正规的母域，而不是真正在窃取凭据的那个子域。下半部分那张登录表单，是同一张页面上人类所看到的——而信誉分从不去看它。

信誉层所依赖的每一个信号，都是母域 softr.app 的属性，而母域给出的每一个答案，又都恰好是正确的。它有六年历史。它的证书有效。它不在任何拦截名单上。它提供 HTTPS。它属于评分器已经分类过的某个类别。子域名并不能实质性地改变其中任何一项。这个子域名之上的页面可以是一张生日贺卡，也可以是一张凭据窃取表单——评分器既无法分辨，从 URL 信誉系统的设计结构上讲，也没有理由去看。

Talos 的观察是，攻击者早就想明白了这一点，而现在正在把它产品化：在一个正规 SaaS 上建页面，把凭据收进另一个正规 SaaS，通过第三个正规 SaaS 发送警报。不给防御方留下任何可以拒绝的东西。

正确的那一层是页面，不是 URL。

防御必须向技术栈的下层推进。一旦托管本身被洗过一遍，剩下唯一仍然可靠的信号，就是页面本身声称自己是什么、以及它实际上是什么。onboarding-portal-8xq.softr.app 上的一张 Outlook 登录表单，是钓鱼。login.microsoftonline.com 上的一张 Outlook 登录表单，则不是。同样的表单，不同的源，不同的判定。一个能读懂表单并将其与源做对比的系统，对这张页面有话可说；一个只读 URL 的系统，则没有。

这正是 Bromure 的反钓鱼检测器早已工作的那一层。在每一个 Bromure 标签页内部，一个内容脚本会在页面加载时对其进行观察，提取出人类判断页面声称自己是什么时会使用的那些信号——可见文字、标题、logo 的来源、表单的形态、被索取的字段——并通过一条 vsock 通道把这份打包数据送到一个小型模型那里，由它用通俗的语言给出判定。「这张页面声称是 Microsoft Outlook，但托管在 softr.app」——这是一个受过训练的读者一瞬间就能给出的句子。模型也能得到同样的结论，而用户看到的横幅，会用一句话、用与判定相匹配的颜色，把它说出来。

两位防御者看着同一个 URL。URL 信誉评分只看母域，其他一概不看，返回绿色。内容检测器则去读页面实际上是什么，注意到其中的错位——一张 Microsoft 品牌的登录表单出现在一个应用构建器的子域名上——于是返回红色。底下那张页面，在两种情况下是同一张。

内容检测器不是魔法，也不是什么「证明」。它是一位受过训练的「第二意见」，回答的是一个 URL 信誉系统在结构上就回答不了的问题：这张页面声称自己是什么？ 这个问题在 softr.app、vercel.app 或 lovable.app 这样的子域名上比在互联网上几乎任何其他地方都来得更锋利，因为在那些子域名上，页面内容几乎是唯一留存下来的信号。其他所有东西，都已经通过母域被洗过一遍了。

Bromure 仍然拦不下的东西。

内容检测器、它所绘出的横幅、它能施加的拦截，是第一道防线。第一道防线并不总能守得住。一位被一封令人信服的邮件先「预热」过、正处于工作日中段、早已习惯了点开 Outlook 登录界面如家常便饭的用户，是有可能点过警告横幅的。用户也可能落到一个检测器尚未评估过的页面上，或者落到一个被评估为「可疑」而非「明确钓鱼」的页面上，于是判断可疑已经足够接近大概没事。

这种情况一旦发生，用户就会往表单里输入密码，而表单就会捕获这个密码。世界上没有任何一种浏览器架构能关掉「打字」这件事。这是本文最朴素也最重要的一条注脚。Bromure 并不能阻止用户向攻击者的表单里输入真实的密码。它能塑造的，是之后发生的事；而之后发生什么，取决于这位用户工作的其余部分栖身何处。

浏览器的使用习惯能改变什么，不能改变什么。

坦白地说，如果一次凭据钓鱼越过了横幅，Bromure 的架构会改变一些事情：

密码管理器不会在错误的源上自动填充。 密码管理器会把保存的凭据与源做匹配，而这里的源是 softr.app——用户的密码库从未见过这个源。自动填充不会被触发。用户必须自己敲。这是一条真实、便宜、毫不花哨的防御——在 Chrome 里和在 Bromure 里一样有效；之所以值得一提，只是因为这是一种不依赖判断力的防御，而恰恰是判断力被钓鱼击败。
钓鱼标签页里没有持久化的配置文件。 装着那张钓鱼页的标签页，是一台临时的 Linux 虚拟机。它关闭时，里面加载过的任何东西——cookie、存储、缓存、指纹——都不会留下来。这并不能把用户输入的凭据「收回去」。但这确实意味着，这张页面无法悄悄在一个长期存留的配置文件里埋下标记，用来跨会话追踪用户。
想触达宿主机的页面够不着。 Talos 的这则案例是纯粹的凭据窃取。Trend Micro 追踪的更大范畴里，则包括 Lovable 和 Vercel 上那种还会接着上演下一步的页面——一次 ClickFix 粘贴、一句「运行这个安装程序」、一张最终变成原生应用弹窗的伪造 CAPTCHA。如果钓鱼页试图把交互交接给宿主操作系统，标签页虚拟机会在虚拟机监控器的边界上把这次交接切断。架构上的原因，与这个博客里每一篇其他文章完全一样。

有一些事情，Bromure 并不能改变：

来自攻击者基础设施的凭据重放。 一旦攻击者拿到了用户名和密码，他们就可以从自己的基础设施上登进真正的 Outlook。受害者机器上的任何东西——包括 Bromure——都不会参与那一场会话。MFA 有帮助。抗钓鱼的 MFA——硬件密钥、通行密钥——帮助更大。禁止传统身份验证的租户级策略，帮助最大。这些才是这条攻击分支的正解，本文不会假装一种浏览器架构能够取代它们。
中继实时会话的「中间人」工具包。 Talos 记录的这起 Softr 案例，是一张静态的凭据窃取页面，而不是一个 AiTM 反向代理。更高端的那一类工具包——Tycoon、Evilproxy 及其同源——会把受害者的 MFA 挑战通过钓鱼页面中继到真实的服务提供方，从而捕获一条活跃的会话 cookie。那条会话 cookie 从被捕获的那一刻起，就活在攻击者的基础设施里。浏览器端的「用完即弃」对此后的会话卫生有帮助；它无法在事后作废一条已经离开大楼的 cookie。服务端的 cookie 绑定——DBSC 及其同类——才是能做到这一点的那种修复。

检测器能抓到的

*.softr.app、*.vercel.app 或 *.lovable.app 上带有 Microsoft 品牌的登录表单，正是内容检测器被专门设计来标记的模式。URL 不是信号。真正的信号，是品牌声明与主机之间的错位。

标签页虚拟机能抓到的

钓鱼页想要交接给宿主操作系统的任何动作——粘贴到 Terminal 或 Spotlight、安装程序弹窗、协议处理程序——都会失败，因为这个标签页与桌面不共享同一个操作系统。钓鱼留在虚拟机里。

仍然得靠判断力的

如果横幅被错过或被关掉，一串被敲出来的密码就会从表单发出去。内容检测器是多一双眼睛，不是键盘上多一只手。在这条具体的攻击路径上，抗钓鱼的 MFA 才是最后的兜底，而 Bromure 并不替代它。

得靠服务端去接住的

来自攻击者基础设施的凭据重放、通过 AiTM 实现的实时会话劫持、以及长期存活的令牌——这些都在身份提供方的环境里决出胜负，而不是在浏览器里。Cookie 绑定、条件访问、硬件支持的密钥，才是能在那一侧生效的手段。

为什么这是分水岭，而不是一时风潮。

Talos「首次归因」的措辞是谨慎的；而其中等置信度的评估——认为这种手法可以追溯到 2023 年 5 月——则暗示，在有人给它贴上标签之前，它已经悄悄加速了将近两年。最好的攻击技术就是这样登场的——不是以一纸宣告的方式，而是作为某人终于画出来的那张图上的一条曲线。Trend Micro 于 2025 年 9 月发布的关于 AI 构建器托管钓鱼的文章，从另一个方向勾画出了同一条曲线。两条曲线的交点就在这里。任何一位以为自家用户永远不会点开一个指向 *.softr.app、*.vercel.app、*.lovable.app 或 *.netlify.app 链接的防御者，所假设的，是一个上个季度就已经终结的世界。

成本结构才是背后的原因。十年前，架起一张可信的钓鱼页面，要么需要能力、要么需要金钱：一个域名、一张证书、一台服务器、一张不会立刻暴露自己出身的页面。今天，一款无代码构建器只需要换取一次免费套餐注册，就把四项全包了。再多做一个冒名页面的边际成本，以分钟级的提示词时间来衡量。被下架的边际成本——因为每一张页面都住在一个正规服务商的子域名下，而不是自己的域名上——比过去更高。这两条曲线对防御方来说指向了错误的方向，而主流回应「培训用户识别坏 URL」到了现在这个时点，已经是成本项，不是控制项。

一款号称在保护用户的浏览器，诚实的立场应当是：它必须去做 URL 信誉系统做不了的工作。它必须真的去读页面。它必须对每一个出现在非登录外观域名上的登录外观表单，判断这张表单是与域名相匹配，还是在对域名撒谎。它必须用一句人能读懂的话说出来，并且说对的次数要多到让那一句话值得被读。

一个故事，以及它所预示的。

Talos 写的是一张页面。这张页面建在一个 SaaS 上，把凭据收进另一个 SaaS，又通过第三个 SaaS 给操作者发出警报。在这条链条里，每一个环节，对一个信誉评分器而言，都是一位好邻居。Talos 讲的这个故事，将在今年年底之前不再是例外。「氛围编程」出来的钓鱼，不是一个给新鲜玩意儿贴的标签；它是从现在起，持证上岗的攻击者搭建攻击页面的默认方式的名字，因为这种方式最便宜、也最宽容。

如果你的浏览器对钓鱼的唯一答案，就是一个 URL 信誉分数，那它就没有对这件事给出答案。信誉分会是绿色的。页面会是红色的。安装 Bromure ——把那多出来的一双眼睛，放到真正的错位所在的那张页面上。