钓鱼攻击进化：内存里"凭空变出"假登录页

「浏览器里能凭空生成一个完整的钓鱼页面，而且硬盘上找不到任何痕迹。」——这不是科幻设定，是安全研究员对BlobPhish攻击链的复盘。

2024年10月首次出现，持续运行超过18个月，2026年2月活动量显著激增。这组时间线勾勒出一个成熟、长期维护的威胁运营体系，而非短期 opportunistic 攻击。微软365用户、美国大型银行、金融平台——目标清单精准指向高价值凭证。

攻击者为何抛弃传统服务器托管

传统钓鱼的致命弱点是"有迹可循"。假登录页必须托管在攻击者控制的服务器上，通过标准HTTP协议传输。安全工具的三板斧——域名黑名单、流量分析、文件落盘检测——都能奏效。

BlobPhish的解法简单粗暴：不让钓鱼页"来过"。

整个攻击负载在受害者浏览器内存中生成，利用的是浏览器原生支持的Blob（二进制大对象）接口。这是网页开发中常见的技术，用于在客户端处理文件数据。攻击者将其武器化，把恶意代码的传输、解码、执行、销毁全流程压缩在数秒内完成。

结果是零文件落盘、零缓存残留、零可疑HTTP请求可供代理日志标记。传统安全架构的检测盲区被系统性利用。

拆解BlobPhish的杀伤链：四步无痕

第一阶段：入口伪装。钓鱼邮件伪装成财务警报、发票或文档共享通知，链接指向DocSend等可信服务，或使用t.co短链。能源 sector 的定向攻击中，还观察到携带二维码的PDF附件，扫码后跳转至恶意JavaScript页面。

第二阶段：加载器执行。用户点击后，被重定向至攻击者控制的HTML页面。页面内嵌的JavaScript加载器使用jQuery库，执行以下操作序列：

——创建隐藏的锚点元素（a标签）
——使用atob()函数对捆绑的钓鱼负载进行Base64解码
——构造text/html类型的Blob对象
——调用window.URL.createObjectURL()生成blob:https://格式的URL
——强制浏览器导航至该URL

全程无需用户可见交互。

第三阶段：证据销毁。导航完成后立即调用window.URL.revokeObjectURL()，并从DOM中移除锚点元素。内存中的操作痕迹被主动清除。

第四阶段：凭证收割。受害者看到高度仿真的微软365、Chase、Capital One等金融服务平台登录页。浏览器地址栏显示blob:https://前缀的URL，对非专业用户具有欺骗性。攻击者设置失败登录计数器，迫使用户重复输入凭证以提高采集准确率。捕获数据通过HTTP POST外泄至攻击者控制的端点，URL模式匹配*/res.php、*/tele.php或*/panel.php——这些端点主要托管于被攻陷的合法WordPress站点。

技术选型背后的攻防博弈

Blob对象并非新发明。它是浏览器为支持客户端文件操作而设计的原生API，允许JavaScript直接操作二进制数据。window.URL.createObjectURL()为其生成临时访问链接， revokeObjectURL()则用于释放资源——标准到不能再标准的开发工具链。

攻击者的聪明之处在于：把"临时性"变成"不可追溯性"。

blob:https://URL的生命周期完全绑定于当前页面会话。页面关闭即失效，不进入历史记录，不写入磁盘缓存，不触发传统杀毒软件的文件扫描逻辑。代理服务器看到的是用户对初始HTML页面的单次请求，后续所有"页面跳转"发生在浏览器内部，不产生新的网络流量特征。

这种设计精准打击了企业安全架构的结构性弱点。SOC（安全运营中心）依赖的三类数据源——网络流量日志、终端文件系统监控、邮件网关过滤——在BlobPhish面前集体失效。攻击负载的"存在时间窗口"被压缩到秒级，且完全驻留于浏览器进程的内存空间。

jQuery的选择同样耐人寻味。这个一度统治前端开发的库，如今在新项目中已显老旧。但攻击者持续使用，说明其目标用户群体的浏览器环境——企业办公场景下的标准配置——仍广泛支持。技术选型服务于"兼容性优先"的投放策略，而非炫技。

18个月运营周期透露的商业模式

2024年10月至2026年2月的时间跨度，排除了"脚本小子"临时起意的可能。持续迭代、基础设施维护、目标清单更新——这些都需要稳定的资源投入和组织协调。

攻击目标的高度聚焦值得注意：微软365代表企业邮箱与协作平台的入口凭证；Chase、Capital One等美国大型银行指向直接金融资产的访问权限。能源 sector 的PDF+二维码投放，则暗示存在行业特定的情报收集或供应链渗透需求。

凭证外泄端点的命名规律（res.php/tele.php/panel.php）指向成熟的钓鱼面板生态。这类工具通常以订阅制或分成制在地下市场流通，攻击者可能并非原始开发者，而是购买服务的运营方。WordPress站点的广泛被利用，反映出内容管理系统的漏洞治理滞后于攻击者的自动化利用工具。

2026年2月的活动量激增，可能对应季节性因素（税务季、财报季）、新漏洞武器化、或运营方扩大了投放规模。无论哪种解释，都说明该威胁运营具备弹性扩缩容的能力。

防御侧的结构性困境

BlobPhish暴露的不仅是技术漏洞，更是安全架构设计哲学的代际落差。

网络边界防御假设"看见即安全"——流量经过网关即可被检测、被阻断、被审计。但现代浏览器是一个完整的操作系统，具备代码执行、存储管理、网络通信的完整能力。攻击者在浏览器内部完成的操作，对网络层而言是黑箱。

终端安全软件假设"文件即威胁载体"——扫描磁盘、监控注册表、挂钩系统调用。但内存驻留攻击不创建持久化文件，进程注入和代码执行完全在浏览器沙箱内完成。

用户安全意识培训假设"识别可疑URL"——但blob:https://的协议前缀对普通用户而言缺乏辨识度，且地址栏显示的内容与真实域名无直接关联。

三重假设同时失效。

更深层的问题在于：Blob对象是浏览器功能设计的必要组成部分，无法简单禁用。企业安全团队面临的选择是，要么接受功能阉割（阻断JavaScript执行、限制Blob API），要么寻找新一代的检测维度。

可能的防御演进方向

浏览器厂商侧：增强地址栏对非标准协议的可视化区分，对blob:URL的临时性特征进行风险提示，或限制跨域导航至blob:URL的行为模式。

企业安全侧：从"网络流量分析"转向"浏览器行为遥测"。监控JavaScript的Blob对象创建频率、createObjectURL/revokeObjectURL的调用时序、DOM元素的异常增删模式。这要求EDR（端点检测与响应）产品深入浏览器进程的内部状态。

身份架构侧：推动FIDO2/WebAuthn等无密码认证的 adoption，降低凭证本身的价值。即使钓鱼页完美复刻界面，没有可窃取的静态密码，攻击链自然断裂。

邮件安全侧：强化对DocSend等文档共享服务的链接改写与实时扫描，缩短"从点击到检测"的时间窗口。二维码在邮件附件中的出现，应触发额外的验证流程。

一个关于"可见性"的隐喻

BlobPhish的命名精准捕捉了攻击的本质：像一滴墨水落入清水，形状变幻、边界模糊、难以捕捉。它利用的是现代计算架构中"用户便利性"与"安全可见性"之间的永恒张力。

浏览器厂商为了让网页应用更像原生应用，开放了越来越强大的客户端能力。攻击者只是比防御者更早地绘制了这张新地图的暗角。

18个月的持续运营，2026年2月的活动激增，能源 sector 的定向投放——这些事实拼凑出的图景，不是某个天才黑客的炫技作品，而是一个工业化、可复制的攻击商业模式。凭证窃取只是入口，后续的资金转移、数据勒索、供应链渗透才是完整价值链。

对于25-40岁的科技从业者，BlobPhish的真正启示或许是：当你在设计产品的"无缝体验"时，攻击者正在研究如何让恶意代码同样无缝。安全不是功能的对立面，而是需要被重新定义的底层架构假设。

数据收束：持续18个月的运营周期，2026年2月活动量激增，目标覆盖微软365及美国主要金融机构，外泄端点主要托管于被攻陷的WordPress站点——这组事实构成的威胁画像，指向一个需要被纳入长期风险监测清单的成熟攻击体系。