电话是从帮助台内部打来的

4 月 24 日,BleepingComputer 报道了一个出于经济动机的攻击集群,Palo Alto 的 Unit 42 将其追踪为 CL-CRI-1116,也称作 BlackFile,也称作 UNC6671;CrowdStrike(分别地、但很可能是同一拨人,至少是表亲)称之为 Cordial Spider。分类法乱七八糟。行为则不然。

下面是那行为,按它发生在你身上的顺序排列:

1. 你接到一个电话。来电显示是公司内部 IT,或者足够接近——伪造的 VoIP,或者欺骗性的 CNAM(电话网络在号码旁显示的那个人类可读名称,事实证明它的认证不算特别严格)。电话另一端的人友善而略带歉意。他非常抱歉打扰你。你的账号有个小问题。
2. 为了解决你账号上的这个小问题,他希望你登录一个公司页面,链接他会通过短信发给你,有时则直接口头引导你到那里。页面看起来很对。它有公司的标志。它的措辞也对。它不是那个对的页面。
3. 你输入密码。页面要求输入你身份验证器中的一次性验证码。你也输入了。
4. 页面说了声谢谢,可能还显示个旋转加载图标。你挂了电话。
5. 攻击者在他自己的某台笔记本上、在某个其他地方,用你刚刚输入的密码和你刚刚输入的六位数代码,在接下来的九十秒内登录你真正的 SSO 门户,然后——这是优雅的部分——在你的账号上注册他自己的 MFA 设备。
6. 他现在就是你了。他口袋里有一个永久的第二因素。你的第二因素也仍然有效,所以没人会注意到。
7. 他打开 Salesforce、打开 SharePoint,搜索文件名或内容里带有 "confidential" 或 "SSN" 字样的文件,把能下载的都下载走。一周后,你的 CEO 会收到一封来自某个 Gmail 地址、写着七位数赎金的邮件。有时,根据 BleepingComputer 的报道,员工还会收到 swatting 威胁——这是大多数勒索团伙懒得提供的一种"客户服务"水准。

总之。

攻击究竟发生在何处

值得精确地搞清楚这条链条的每一段在哪里运行,因为整条链条并不在同一个地方。

电话走的是电话。电话是电话形状的。任何浏览器、任何笔记本、任何你能打补丁的操作系统,对电话本身都做不了什么,因为电话不在笔记本上。(你可以培训人员,你可以在休息室张贴标语,你可以让真正的帮助台在每次合法通话后再发一封后续邮件,所有这些都有帮助。但电话,正如业内所说,是一个"人形"的问题。)

伪装的登录页面在浏览器里运行。具体来说,它运行在那个员工此刻在工作笔记本上恰好开着的任何一个浏览器里、在她最后使用的任何一个配置文件里,带着她碰巧随身携带的任何会话、cookie 和保存的密码自动填充。这一部分是一个"电脑形"的问题。

针对真账号的 MFA 注册,运行在攻击者的笔记本上,在他的浏览器里,对着合法的 SSO 门户。这根本不是用户浏览器中的问题;这是一个关于 SSO 门户在某人知道密码和当前 OTP 的情况下如何处理 MFA 注册的问题。你的 IdP(运行 SSO 的身份提供商——Okta、Entra ID、Google Workspace,无论是哪一家判定你密码正确的)把"我有密码和一个新鲜的 OTP"当作足以添加另一个因素的证明。这是一项策略选择,而且是大多数企业默认发货时所采用的策略,因为换一种做法就意味着用户在更换手机时把自己锁在门外。

Salesforce 和 SharePoint 上的窃取同样运行在攻击者的笔记本上,对着你真实的 SaaS,使用他刚铸成的第二因素。严格意义上,这一部分并不是"对员工浏览器的攻击"。这只是攻击者像普通人那样登录,因为到这一步他就是普通人。在最后这三步里,你员工的浏览器只是一旁观望。

所以,如果你想找一根可以从头到尾阻止 BlackFile 的技术杠杆——没有这种东西。攻击分散在一部电话、一个伪造页面、一项 IdP 策略和一台攻击者的笔记本上。

存在的——也是浏览器厂商唯一能可信地置喙的链条部分——是第二步,即伪造的登录页面。这个页面必须在某处被渲染。无论它在哪里被渲染,员工都会在里面输入真实的凭据和真实的 OTP。所以问题只是:你想让这件特别的事情发生在什么样的容器里?

页面必须在某处被渲染

好吧。所以页面在某个浏览器中被渲染。是哪个?

如果你什么都不做,它就会在那个员工恰好正在用的任何浏览器中渲染——个人笔记本上的 Chrome,公司笔记本上的 Edge,手边那台 iPad 上的 Safari。无论是哪一个浏览器,它都已经被使用过一段时间。它有一个用了一段时间的配置文件。这个配置文件里,可能已经有真实的公司 SSO 门户的 cookie,因为员工每天早上上班都要登录。它有保存的密码。它会贴心地给出一个自动填充建议——内容刚好就是真正的公司密码——除了在钓鱼域名上,自动填充会正确地不触发(浏览器在这一点上做得不错),所以用户只能手动输入,这她也做得很好,因为她已经做过一万次。

伪造的页面并不需要那些 cookie 中的任何一个。伪造的页面只需要用户的手指继续做"页面要求输入密码时手指会做的事"。伪造的页面收走密码。伪造的页面收走 OTP。伪造的页面就完事了。

但有一个问题一直在我脑子里转。为什么员工的个人浏览器——带着它那个用了很久的配置文件,以及她登录过的每一个网站的合集——会一开始就成为伪造企业登录页面被渲染的地方?这个页面声称自己是公司页面。用户在工作。从用户自己的视角看,她正在做工作的事。为什么"公司登录页面"会和"表妹的 Spotify 分享链接""2018 年的一个 Etsy 账号"在同一个软件环境里渲染?

我觉得,这就是关键问题。

把"受管理浏览器"的论点缩小到最小

下面是 Bromure 针对这次攻击,小而窄、又诚实的版本论点。

IT 部门可以把 Bromure 作为指定的企业浏览器部署。它不是笔记本上的唯一浏览器——用户仍然可以保留 Chrome 和 Safari 用于个人浏览——而是唯一一个被配置过、注册过、并被显眼地标记为"企业 SaaS 应该住在这里"的浏览器。Bromure 在设置里有一个 Enterprise 标签页,它的全部职责就是这个:一个 HTTP 代理字段,以及一个内部根证书的位置。两项设置。它就只做这些,而且故意只做这些。组织把这两样东西配置一次,把一个预配置好(信任企业 CA 并通过企业代理路由)的 Bromure 配置文件交给员工,让这个配置文件显眼地成为企业 SaaS 落脚的地方。

(我们并没有声称 Enterprise 标签页是一个完整的 MDM 控制平面。它就是两个文本框。两个挑得好的文本框,有时已经够了。)

在 Bromure 内部,每个标签页都是它自己的一次性 Linux 虚拟机,有自己短暂的配置文件。所以当公司的 Salesforce 标签页打开时,它在一个知道公司代理、信任公司 CA 的受管理虚拟机中打开。当员工在另一个标签页打开她表妹的 Spotify 分享链接时,那个会在一个不同的虚拟机、用一个完全没有这些设置的不同配置文件中打开。

现在,电话仍然以同样的方式进来。用户仍然被引导到一个链接。变化的是这些:

• 这个链接被点开时,它会在某个 Bromure 虚拟机里打开。默认情况下,它不会在和员工真实 Salesforce 会话相同的那个虚拟机里打开。(Bromure 的配置文件不会悄悄合并。一个加载在"一次性链接"配置文件里的页面无法读取"公司 Salesforce"配置文件里的 cookie,因为它们活在不同的虚拟机里,带着不同的网络栈和不同的磁盘。)
• 用户仍然可能把真实的公司凭据和真实的 OTP 输进这个页面。**Bromure 不会阻止打字。**这是诚实的部分。
• 这个页面捕获到的会话令牌(或者根据钓鱼套件的不同,有时只是 cookie)生活在一个用户即将关闭的配置文件里、一台即将被擦掉的虚拟机里,和任何企业资源都没有特权关系。在这个意义上,被截到的令牌质量很低——它只是从一个标签页里带出来的一件纪念品。

关于最后这一点,我想小心一些,因为这正是容易吹得过头的那种话。

在已被记录的 BlackFile 链条中,被捕获的令牌实际上并没有被用来登录真正的 Salesforce——攻击者用的是凭据和 OTP,从他自己的笔记本上登录到真正的 SSO 门户,然后注册他自己的 MFA 设备。被捕获的 cookie 反正也不会被回放到真正的公司会话上,因为它们是钓鱼域的 cookie,而不是真实域的。Bromure 按虚拟机隔离真正派上用场的地方,是伪造页面之后的那一段:任何标签页侧的恶作剧(把令牌偷走发到攻击者的端点、试图读取其他 cookie 的后续脚本、丢下额外有效载荷的重定向链)都被关在一台虚拟机里,这台虚拟机的文件系统、网络和进程树都和笔记本的其他部分、以及真正的公司浏览器会话彻底隔开。伪造的页面就是伪造的页面。它只是被允许在一个盒子里做一个伪造的页面而已。

特别是这个可见提示,它在这张图里承担了大量工作,值得大声说出来。一个受管理的浏览器部署,如果它唯一的功能只是"公司的 Salesforce / SharePoint / Workday 标签页看起来,在视觉上,跟随便点开的链接标签页明显不一样",这本身就已经是非简单的防御措施。因为典型的 BlackFile 受害者,是一个在某个星期四下午 4:45 接到电话的疲惫的人。这个可见的区分不是 UI 上的小花样;它就是整场比赛。

这不会解决什么

我想继续在这件事上保持诚实,因为这里的失败模式就是某个厂商先告诉你"我们的产品本来就能挡下这次攻击",你仔细一读,发现他描述的是另一种攻击。

**它不会让电话停下来。**电话在电话上。Bromure 不在电话上跑,看不到电话,也不对电话发表任何意见。如果用户接起电话,被一个友善的声音说服她账号上有个小问题,她就会去看一个伪造的登录页面。我们能改变的是页面在哪个浏览器里渲染。我们改变不了她到底要不要去看。

**它不会让打字停下来。**如果用户把真实的凭据和真实的 OTP 输进了伪造页面,无论页面在哪里被渲染,这些凭据和 OTP 现在都在攻击者手里。页面跑在一个一次性虚拟机里,这一事实没法让用户刚刚输入的内容自动消失。

**它不会阻止 MFA 注册。**MFA 注册这一段发生在攻击者的笔记本上,对着合法的 IdP。Bromure 没有跑在攻击者的笔记本上,Bromure 也不是 IdP。这里的缓解措施在 IdP 一侧,而且非常无聊:打开"新 MFA 注册要求强化身份验证",把注册行为限制在公司网络或受管理设备上,对新增因素注册告警,并接受这样的代价——用户换手机时会把自己锁在门外。这是今天每一个 Okta 和 Entra ID 管理员都可以做出的配置选择,而许多管理员并没有这么做,这——说得客气点——才是这个故事里更应该让 CISO 失眠的部分,而不是浏览器的部分。

**严格意义上,它也无法阻止实时 AiTM 代理攻击。**另一类钓鱼套件(Evilginx、Modlishka、Caffeine,以及那些每次出租 2,500 美元的 AiTM-as-a-service,如今已成为针对 Microsoft 365 的主流攻击模式)走的是实时中继路线:用户输入的页面会实时把请求代理到合法的 IdP;IdP 颁发的会话 cookie 走到代理那里,代理再把它递给攻击者。如果你想象一下 BlackFile 风格的电话把用户引向那种页面——这并不是 BlackFile 现在被描述的样子,但这一类攻击正朝那个方向去——那么被截获的 cookie 就是合法 IdP 颁发的真正的会话 cookie,问题就变成它能不能从别的地方被回放。那是另一篇文章了,而且是更难的一篇,诚实的回答涉及会话绑定相关的控制(DBSC、mTLS 绑定的令牌),而这些在很大程度上是 IdP 的工作,只有一部分是浏览器的工作。我们不打算对那一块挥魔法棒。

受管理的 Bromure 实际上做的、范围窄一点的事情是:让伪造页面在一个未受管理的、短暂存在的、并且和受管理的企业环境视觉上有明显区别的地方渲染。它把套件可能在页面之后玩的把戏(扩展安装、对宿主文件系统的写入、持久化)的爆炸半径,限制在一台正要消失的虚拟机内。在 BlackFile 被描述出的那条链上,它本身并不能阻止攻击者继续注册自己的 MFA 设备——那是 IdP 的工作。我们缓解的是这条链上四台机器中的一台,而那是我们唯一在跑的那一台。

为什么从长期看,这是唯一的路

总之。哎,你想想看。退一步看。

BlackFile 这件事真正特别的地方在于,它是一门效率惊人的生意。他们挑零售和酒店业,因为零售和酒店业有大量员工、分散的班次、夜班排班,有真正会主动给员工打电话的 IT 帮助台团队,以及一大群压力极大、绝对不想成为"收银台瘫痪原因"的员工。他们挑语音钓鱼,因为语音钓鱼能规模化(电话另一端的一个人,一个小时可以打十几个目标,而成功率按这个行业的标准已经高得离谱),也因为电话是这条链上你没法打补丁的那一段。他们去抓凭据和 OTP,是因为凭据和 OTP 在 2026 年仍然是大多数企业的正门——尽管已经过了十年的演讲在解释为什么不该这样。

浏览器能影响的链段很小。它是四台机器中的一台。你不该因为某款浏览器声称从头到尾击败了 BlackFile 而买它。你应该买一款浏览器,因为它能把它能做好的那一件事做好——把企业会话留在一个受管理的、可识别的地方,把"随便点开的链接"会话留在一个一关闭就不复存在的地方——然后再把它和那些无聊、不性感的 IdP 侧控制配合起来,真正把这个圈合上。

电话还会响。页面还会加载。问题只是,它究竟在哪里加载,加载的时候它身边都有些什么。事实证明,这一点你是可以改的。

来源:

• BleepingComputer — New BlackFile extortion gang targets retail and hospitality orgs (2026-04-24)
• CrowdStrike — Cordial Spider adversary profile
• Help Net Security — Attackers use AiTM phishing kit, typosquatted domains to hijack AWS accounts (2026-03-10)(用以引用更广的 AiTM-as-a-service 市场背景,而非具体指 BlackFile)