传统网络钓鱼的典型特征是攻击者搭建仿冒站点，诱导受害者访问外部恶意网页，安全防护体系长期依靠恶意域名黑名单、URL 信誉检测、网页内容扫描等手段拦截风险。但 2026 年安全厂商 Barracuda 披露的新型攻击活动，彻底打破这套固有防御逻辑：攻击者不再维护公开可访问的钓鱼网站，而是利用浏览器原生 Blob URL 能力，直接在受害者本地浏览器内存生成伪造登录页面，整套恶意界面只存活于单次浏览器会话之中，传统网络层防护手段很难捕捉威胁线索。这一类攻击的出现，意味着网络钓鱼已经从 “恶意网站欺骗” 演进到 “浏览器上下文劫持欺骗”，给企业与个人用户的身份安全带来全新挑战。
本次被公开监测到的攻击活动，整套链路大量复用微软 Teams、OAuth 等正规云服务链路。攻击起始邮件伪装成 DocuSign 电子签业务通知，附带一份本身不带病毒的日历邀请附件，这份附件不执行恶意代码，其唯一作用是让整封邮件看起来属于正常商务往来，降低邮件安全网关与收件人的警惕心理。当受害者点击邮件内链接，请求会先跳转至微软 Teams 的合法服务端点，再由 Teams 页面加载来自第三方 CDN 的外部脚本资源；脚本拿到伪造页面的 HTML 载荷之后，调用浏览器 API 生成 Blob URL，在内存中渲染出高度仿真的钓鱼登录界面。
从技术原理来看，Blob（Binary Large Object）是浏览器的标准能力，设计初衷用于本地预览图片、PDF、文档，把二进制数据映射为浏览器内部临时地址，内容完全驻留在设备内存，不会保存到磁盘本地文件系统，关闭标签页之后相关数据就直接销毁。在正常业务场景中这项功能可以提升网页交互体验，攻击者却将其改造为钓鱼载体。生成后的钓鱼页面依托 service‑worker 后台服务脚本、沙盒 iframe 组件完成交互管控，攻击者后端平台还可以通过浏览器消息通道实时下发指令，同一时间对多名受害者动态调整钓鱼页面内容，属于一套可集中运营管理的攻击平台，并非简单静态伪造页面。
该攻击最棘手的地方在于缺少传统钓鱼的检测特征。传统防护产品可以抓取外部服务器上的钓鱼网页样本，把域名、URL 加入黑名单。Blob 钓鱼没有固定对外暴露的恶意站点，恶意页面产生于受害者浏览器内部，网络代理日志中看不到对钓鱼页面的直接访问记录；邮件网关只能检测初始邮件和跳转的第一级链接，后续内存生成页面的行为发生在终端本地，网关无法感知页面内容变化。普通用户也很难分辨风险，整个跳转链路大量经过知名厂商的正规域名，地址栏展示的域名依然属于可信服务商，仅凭肉眼观察地址栏域名，完全无法察觉内存中已经渲染了伪造登录表单，不少接受过基础安全培训的企业员工同样会落入圈套。
这并非孤例，在此之前安全机构 ANY.RUN 就已经监测到代号 BlobPhish 的长期攻击行动，该活动自 2024 年 10 月持续运作，主要针对微软 365 以及多家海外金融机构实施凭证窃取，同样依靠 Blob 对象在浏览器内存构建钓鱼界面，大量企业机构遭受账号劫持威胁。两类案例共同说明，Blob URL 钓鱼已经从概念验证走向规模化实战，攻击者充分利用浏览器原生能力规避检测，安全行业过去积累的域名黑名单、网页样本库，对此类威胁的拦截效果大幅下降。
反网络钓鱼技术专家芦笛强调，Blob URL 钓鱼揭示了当前反钓鱼体系的核心短板：多数防护体系过度依赖外部网络特征检测，把防御重心放在识别外部恶意服务器，一旦威胁转移到终端浏览器上下文，原有检测逻辑就容易失效。域名和 URL 可信，不等于当前页面内渲染的业务表单一定可信，这是很多用户乃至企业安全管理人员容易忽略的认知盲区。迪妙网络空间安全学院在一线攻防案例复盘过程中也观察到，不少企业的安全培训依旧停留在 “不要点开陌生域名链接”，却很少讲解同一合法域名上下文内部产生恶意内容的风险，安全教育的更新速度滞后于攻击技术迭代。
需要厘清一点，该攻击并不利用浏览器高危漏洞，没有依靠系统漏洞实现代码执行，全部流程调用浏览器公开标准 API。攻击者没有攻破微软 Teams 等服务，只是把可信云产品作为攻击链路的中转载体，真正的恶意载荷来自第三方 CDN 资源，这一点常常会被普通用户误解。整个攻击的最终目标依旧是骗取账号密码、OAuth 授权许可；当受害者在内存生成的伪造表单输入账号密码，表单会把凭证加密回传给攻击者服务器，进而造成企业邮箱、云文档、业务系统账号被盗，后续可进一步引发企业邮件劫持、数据泄露甚至勒索软件入侵事件。
面对这类新型钓鱼手段，简单依靠拉黑域名已经不足以抵御风险，防御思路必须从 “拦截恶意网站” 转向身份防护、浏览器行为审计、完整访问链路监控的组合模式。
对于企业安全运维，首先需要升级邮件安全检测逻辑，不能只校验邮件内初始链接，需要对完整重定向跳转链路进行追踪，识别跳转链末端加载外部脚本的异常行为；针对 OAuth 授权流程建立审计机制，监控业务系统出现的非预期授权跳转，及时发现异常权限申请请求。其次，应当对浏览器异常行为开展监测，重点关注登录认证场景下的 Blob URL 渲染、陌生 service‑worker 脚本注册行为。同时要优先部署抗钓鱼多因素认证，FIDO2 Passkey 这类依靠域名绑定校验的认证技术，可以从协议层面抵御凭证窃取，即便用户遭遇 Blob 内存钓鱼，伪造页面也无法调用本地密钥完成身份签名，能够形成兜底防护。迪妙网安认为，在浏览器层面发生的欺骗攻击，最优解不是单纯依靠终端扫描，而是使用具备域名绑定校验能力的身份认证手段，把安全判断交给协议本身，而不是完全交由用户肉眼辨别页面真伪。
面向普通使用者，也需要更新自身安全判断习惯。过去大家习惯看地址栏域名是否正确，而 Blob 钓鱼告诉我们，即便域名显示正常，也不能完全放松警惕。收到合同签署、文档查看类邮件请求时，尽量不直接点击邮件内嵌链接，改用手动打开官方网站登录查看待办业务；遇到弹出登录窗口时，优先主动新开标签页访问业务官网，不要直接在跳转出来的弹窗内输入账号密码。同时尽可能开启 Passkey、硬件密钥这类抗钓鱼的二次认证，降低账号被盗之后攻击者利用窃取凭证登录的可能性。
也要客观看待技术边界，芦笛提醒，Blob URL 钓鱼虽然隐蔽，但攻击链条依然需要完成初始社会工程投递，依旧离不开钓鱼邮件、社交消息完成第一步诱导。无论攻击手段如何在浏览器内部做伪装，攻击者都需要把受害者引入预设跳转链路，用户行为层面的风险点没有消失，只是欺骗的主战场从外部网站迁移到浏览器内部。因此安全意识教育依然不可舍弃，但教育内容不能停留在老旧的识别可疑域名，需要补充浏览器上下文相关的风险知识。迪妙网安的安全意识培训实践中就提出，网络钓鱼对抗已经进入 “内存与上下文欺骗时代”，安全认知不能固守十年前的经验。
网络钓鱼技术的演变始终跟随终端技术发展，从仿冒域名、短链接、二维码钓鱼，再到如今 Blob 内存页面攻击，攻击者不断寻找现有防御体系的盲区。Blob URL 钓鱼给行业带来重要启示：安全防护不能把全部希望寄托在网络侧黑名单机制。未来反钓鱼的建设思路，需要网络检测、终端行为监控、抗钓鱼身份认证、更新迭代的安全教育互相配合，形成多层防护闭环。当攻击已经藏进浏览器内存之中，我们的防护视野，也必须随之延伸到浏览器会话的内部行为当中。
编辑：芦笛（公共互联网反网络钓鱼工作组） 来源：迪妙网络空间安全学院
