人机协同实时驱动钓鱼框架威胁研究 —— 以 JWR 工具包为样本

简介: JWR是新型交互式钓鱼框架,突破传统静态模式,通过加密WebSocket双向长连接,实现实时观测用户输入、动态切换44类仿冒页面,绕过多因素认证,批量窃取金融凭证与身份信息。主要通过短信钓鱼在东南亚、中东落地,凸显PhaaS产业化威胁。

摘要

传统静态钓鱼工具仅能够采集受害者提交后的表单数据,攻击流程固定、缺少动态应变能力。Cisco Talos 披露的 JWR 钓鱼框架突破该模式,依靠加密双向长连接实现攻击者与受害者浏览器会话的实时交互,攻击者可以实时观测受害者输入行为,动态调度 44 类仿冒页面,完成多轮诱导,针对 PayPal、Apple 等主流平台开展金融凭证、二次验证令牌、身份证件材料的批量窃取,相关攻击主要通过短信钓鱼在东南亚、中东地区落地。本文以 JWR 钓鱼框架公开技术分析报告为实证样本,梳理该 PhaaS(钓鱼即服务)工具的技术架构、攻击全链路与现实落地场景,对比其与传统静态钓鱼工具的能力差异,解析实时人机协同模式绕过多因素认证的内在机理。研究发现,JWR 的威胁核心不在于系统漏洞利用,而是通过双向会话通道将社会工程的灵活性植入钓鱼网页流程,对依赖短信、软件令牌的二次身份验证体系形成显著冲击,现有基于静态特征库的钓鱼检测手段存在明显短板。本文结合反网络钓鱼技术专家芦笛的研判,从犯罪产业化动因、技术迭代逻辑、用户认知缺陷、安全防护体系短板等维度剖析威胁形成诱因,从网络流量检测、身份认证体系升级、终端侧风险感知、PhaaS 黑产治理、用户安全认知迭代多个维度提出分层防御路径。研究表明,钓鱼攻击已经从静态页面阶段演进至人机实时交互阶段,防护思路需要跳出传统黑名单拦截的固有路径,兼顾技术检测、身份机制优化与社会工程风险干预,以此应对交互式钓鱼带来的新型安全挑战。

关键词:交互式钓鱼;钓鱼即服务;JWR 框架;多因素认证绕过;短信钓鱼;金融凭证窃取

image.png 1 引言

网络钓鱼长期是互联网用户凭证泄露、金融财产损失的主要诱因,过去相当长一段时间,主流钓鱼工具以静态页面模板为核心,预设仿冒登录、支付页面,等待受害者主动填写信息并点击提交之后,才将表单数据回传攻击者服务器。整套攻击流程完全预定义,受害者每一次访问页面看到的内容完全一致,攻击者无法干预会话过程,一旦受害者出现偏离预设流程的操作,攻击链条就容易中断。随着黑产 PhaaS 商业模式不断成熟,犯罪群体开始追求更高攻击成功率,传统静态钓鱼工具的局限性逐步凸显。

Cisco Talos 安全团队披露的 JWR 钓鱼框架代表钓鱼工具新一轮迭代方向,该工具属于 PhaaS 体系下的新型产物,能够建立加密双向通信通道,让攻击者在后台实时观察受害者的输入动作,不等待表单提交就可以捕获正在录入的账号、银行卡、验证码信息,并且依据受害者行为动态切换仿冒页面,推送定制化报错提示,循环诱导受害者提交多张银行卡、身份证件照片以及二次验证验证码。该工具预置 PayPal、Apple、Shopify、银行机构等大量高流量平台的仿冒页面模板,现实攻击主要依托短信钓鱼渠道投放诱饵,以交通规费催缴、快递物流通知作为伪装,面向东南亚、中东地区用户开展攻击活动。现有情报中等置信度判断 JWR 是知名 PhaaS 平台 “The Outsider” 的衍生变体,代表黑产已经规模化掌握交互式实时钓鱼能力Cisco Talo...。

现有网络钓鱼相关研究更多聚焦静态钓鱼页面、邮件钓鱼、普通短信钓鱼场景,针对这种攻击者实时介入浏览器会话的交互式钓鱼的实证分析相对有限。传统防护手段的设计前提是钓鱼页面为静态资源,依靠域名黑名单、页面文本特征匹配开展识别,面对可以动态调整页面内容、加密传输交互数据的 JWR 类框架,检测识别效能出现明显下降。同时普通用户普遍形成认知:开启多因素认证就能够抵御钓鱼窃取,但是 JWR 的攻击实践证明,短信、软件令牌类二次验证在实时中间人交互钓鱼场景下存在被绕过的现实风险。

本文核心研究问题为:以 JWR 为代表的人机协同交互式钓鱼框架技术逻辑与完整攻击链路如何运转;相较于传统静态钓鱼,其威胁升级点体现在哪些层面;为什么常规多因素认证机制难以完全抵御该类攻击;技术、产业、用户认知层面存在哪些助推该威胁扩散的因素;应当构建何种适配交互式钓鱼特征的综合防御框架。本文依托公开技术还原材料完成事件复盘,解构攻击机理,结合反网络钓鱼技术专家芦笛的专业观点梳理风险根源,提出分层可落地的治理对策。研究结论可为金融平台安全建设、网络安全检测设备迭代、普通互联网用户风险教育、PhaaS 黑产治理提供现实参考。

2 JWR 交互式钓鱼框架事件与攻击链路复盘

2.1 JWR 框架基础概况

JWR 框架由开发者自行命名,属于未被早期安全厂商捕捉的新型 PhaaS 产品,黑产使用者通过租用该框架服务,快速搭建高度仿真的 PayPal、Apple、电商商户、银行等平台登录与结算页面,不需要从零开发钓鱼网页代码。和以往售卖固定模板的钓鱼工具不同,JWR 核心创新在于浏览器与攻击者控制台之间建立加密 WebSocket 双向长连接,全程维持会话连通,数据采用加密算法完成传输,网络链路层面无法直接读取交互的具体内容。

传统静态钓鱼页面属于单向数据传输,只有受害者点击提交按钮,信息才会发送至攻击者服务器。JWR 框架下,受害者在表单内每一次键盘输入,都会实时流式回传至攻击者操作控制台,攻击者在受害者点击提交之前就能够看到正在录入的账号片段、银行卡号、验证码字符。攻击者控制台内置四十余条可下发指令,对应 44 套不同业务场景仿冒页面,操作者可以根据受害者的实时行为,动态切换页面、推送伪造报错信息,例如伪造 “银行卡被拒绝” 提示,诱导受害者提交第二张银行卡信息;或者跳转至二次验证页面,索要短信、软件令牌生成的一次性验证码;还可以诱导受害者上传护照、驾驶证照片、社保编号等高敏感身份材料,同时自动采集浏览器指纹、IP 地址、设备标识、Cookie 会话信息,实现多维度数据批量窃取。

在现实攻击活动当中,JWR 的初始访问入口大多来自短信钓鱼,攻击者发送伪装成交通管理部门、邮政快递服务商的短信,短信内嵌入钓鱼链接。用户点击链接之后跳转至 JWR 搭建的仿冒站点,完整交互式攻击会话正式启动。攻击完成之后,页面通常会将受害者重定向至真实官方站点,降低受害者的警觉心理,很多受害者全程不会意识到刚刚完成的操作已经将金融与身份信息交付给黑产团伙。Cisco Talos 基于代码脚本、功能逻辑的相似性,中等置信度评估 JWR 是 “The Outsider” PhaaS 平台的衍生版本,该平台过去已经参与多起跨境大规模短信钓鱼活动。

2.2 JWR 框架完整攻击流程拆解

结合安全机构技术还原,JWR 驱动的攻击活动完整流程分为诱饵投放、会话建立、实时观测与动态干预、多轮敏感数据采集、凭证利用、攻击收尾六个阶段,整套流程实现人在回路的动态社会工程欺骗。

第一阶段,诱饵投放,完成初始访问触达。攻击者借助短信渠道向目标用户推送钓鱼短消息,短信文本伪装成交通罚款、快递异常、账户受限等贴近普通人生活的业务场景,附带 JWR 钓鱼站点链接。用户点击链接之后,浏览器加载 JWR 前端页面资源,完成攻击入口触发。该阶段是整个攻击的流量来源,大量攻击样本依托短信钓鱼开展,不需要邮件载体,移动端浏览器是主要访问环境。

第二阶段,加密双向长连接建立。受害者浏览器加载前端脚本之后,主动向攻击者后台服务器建立加密 WebSocket 长连接,浏览器与攻击者控制台之间形成持续双向通信通道。该通道全程保持开启,不会随着页面局部跳转断开,所有键盘输入事件会被前端脚本捕获,经过加密之后实时推送至攻击者控制台。网络安全设备只能观测存在 WebSocket 流量,无法解密获取内部交互内容,难以直接识别攻击行为。

第三阶段,攻击者实时观测用户行为,动态调度页面与提示。攻击者后台可以实时看到受害者每一次键盘录入行为,不需要等待表单提交动作。根据受害者输入的账号类型、银行卡号片段,操作者下发指令,切换至适配的仿冒页面。如果受害者输入银行卡之后,攻击者可以推送伪造报错弹窗,提示卡片校验失败,诱导受害者提供另一张银行卡;当受害者完成账号密码录入,攻击者推送二次验证页面,索要一次性验证码。整个过程不是固定脚本播放,而是由人类攻击者根据受害者反应实时调整欺骗话术与页面形态。

第四阶段,多维度敏感信息采集。在攻击者动态引导之下,受害者依次提交账号密码、银行卡完整信息、CVV 校验码、一次性验证码,部分场景下被诱导上传身份证、护照、驾驶证照片。同时前端脚本自动采集设备指纹、IP 地址、时区、浏览器 Cookie 等环境数据,全部信息加密回传攻击者服务器。不同于传统钓鱼只收集表单填写字段,JWR 可以完成支付凭证、身份凭证、设备环境信息的一体化采集。

第五阶段,凭证即时利用。攻击者拿到账号密码以及受害者提交的一次性二次验证验证码,依托中间人会话逻辑,实时完成目标平台账号登录劫持。拿到的银行卡、身份证件材料可以直接流入黑产交易链条,用于电信诈骗、账户注册、资金洗钱等下游犯罪活动。实时交互模式最大优势就是验证码可以即时复用,避免传统模式下验证码存在时效过期的问题。

第六阶段,攻击会话收尾,消除受害者怀疑。完成信息窃取之后,攻击者下发重定向指令,浏览器跳转至真实的 PayPal、Apple 或者其他正规网站。受害者会误认为刚刚完成的是一次正常的官方业务操作,多数受害者不会立刻察觉自己已经遭遇信息泄露,进一步拉长受害者发现被攻击的时间窗口。

反网络钓鱼技术专家芦笛指出,JWR 代表钓鱼攻击的范式迁移,传统钓鱼是工具等待受害者提交数据,而交互式钓鱼实现人在回路干预,把社会工程的灵活性嵌入网页会话当中,黑产团伙不再受限于预设页面脚本,能够针对受害者的不同反应灵活调整欺骗策略,直接拉高攻击的成功率。

2.3 JWR 交互式钓鱼对比传统静态钓鱼的差异化威胁特征

传统静态钓鱼工具在过去数十年被广泛使用,JWR 并不是简单升级页面模板,而是从交互模式层面发生改变,二者的差异直接造成防护难点的变化,可以从数据采集时机、攻击流程可控性、绕过多因素认证能力、流量特征、欺骗迷惑性、PhaaS 使用门槛六个维度进行区分。

第一,数据采集时机差异。静态钓鱼工具必须等待受害者点击提交表单,表单数据才会回传服务器。JWR 依靠前端脚本捕获每一次键盘敲击,在点击提交之前就能够看到受害者正在输入的内容,攻击者可以提前判断受害者填写信息类型,提前切换对应的欺骗页面。

第二,攻击流程可控主体不同。静态钓鱼的页面跳转、报错提示全部是工具预先写死,受害者行为一旦偏离预设路径,攻击流程就容易失效。JWR 由后台人类攻击者实时下发指令驱动页面流转,面对受害者的各类意外反馈,攻击者可以动态调整欺骗逻辑,攻击流程具备高度弹性。

第三,绕过多因素认证的能力存在本质区别。传统静态钓鱼页面拿到密码之后,需要等待受害者提交验证码,整个过程存在时间差,验证码存在过期风险。JWR 交互式会话当中,受害者输入验证码的瞬间攻击者即可获取,同步完成登录操作,充分利用一次性验证码短暂的有效时间,实现对短信、软件令牌类 MFA 机制的中间人绕过。硬件密钥类绑定域名的认证手段才可以抵御该类绕过行为。

第四,网络流量特征发生变化。静态钓鱼主要是浏览器向服务器提交表单的普通 HTTP 提交请求。JWR 大量流量是加密 WebSocket 双向长连接,交互数据被加密处理,网络侧安全设备无法解析会话内部内容,基于明文关键词匹配的检测手段基本失效,增大流量侧识别攻击的难度。

第五,欺骗迷惑性更强。攻击结束后将受害者跳转至真实官方站点,大幅降低受害者怀疑。攻击者还可以根据受害者输入的银行卡归属地区、账号特征,推送贴合用户实际场景的报错信息,整个欺骗过程更加接近真实业务系统交互。

第六,黑产使用层面,JWR 作为 PhaaS 服务,使用者不需要掌握深度开发能力,只需要租用服务,配置钓鱼域名,即可拥有完整交互式攻击能力,技术门槛被转移到平台开发者,下游黑产执行者只需要操作控制台,降低交互式钓鱼的使用门槛,有利于该威胁进一步扩散。

3 JWR 交互式钓鱼威胁的多层诱因解析

3.1 PhaaS 黑产产业化推动钓鱼工具向高成功率迭代

钓鱼即服务 PhaaS 商业模式的成熟,是 JWR 这类工具诞生的产业底层动因。传统钓鱼工具开发、调试、模板制作需要攻击者具备网页开发、后端服务部署能力,技术门槛较高,限制攻击团伙规模扩张。PhaaS 模式将复杂技术全部封装,平台开发者完成框架研发、模板更新、服务器运维,下游黑产使用者只需要付费租用服务,通过可视化控制台开展攻击,不需要理解底层代码逻辑。

黑产市场存在竞争关系,不同 PhaaS 平台之间比拼攻击成功率。传统静态钓鱼攻击成功率有限,黑产团伙有强烈动力迭代工具,引入实时交互能力提升欺骗效果。JWR 被评估为 “The Outsider” 平台衍生变体,也印证同一个黑产生态内部在持续迭代产品功能。PhaaS 模式把交互式钓鱼这种过去只有高级攻击者可以实现的能力,转化为可以租赁采购的标准化服务,使得中等水平黑产团伙也能够开展人机协同钓鱼攻击,放大威胁的波及范围。同时短信钓鱼的投放渠道已经高度产业化,短信网关、伪基站、第三方短信接口可以批量推送诱饵短信,形成 “工具平台 + 流量投放 + 下游销赃” 完整黑产链条。

3.2 Web 前端技术给交互式钓鱼提供实现基础

WebSocket 技术本身属于正常 Web 技术,设计初衷用于在线聊天、网页实时通知、网页游戏等合法业务场景,但是黑产将该技术挪用于钓鱼攻击,构建浏览器与攻击者控制台的持久双向通道。前端 JavaScript 脚本可以捕获页面内部表单的键盘输入事件,这是浏览器开放给网页开发者的标准能力,该能力本身用于表单校验、输入提示等正常业务,却被 JWR 前端脚本用于实时采集受害者每一次按键输入。

值得说明的是,该攻击路径不依靠浏览器高危漏洞,完全使用浏览器开放的标准 Web 接口实现功能,受害者浏览器不需要存在未修复安全漏洞,只要访问钓鱼网页,前端脚本就可以在沙盒环境内捕获页面表单输入,不需要获取系统更高权限。这就意味着,无论用户是否及时更新浏览器版本,都无法单纯依靠补丁修复抵御该攻击,这和传统漏洞利用型攻击存在显著区别。反网络钓鱼技术专家芦笛强调,这是交互式钓鱼防护最棘手的一点:攻击者大量复用浏览器标准能力,不是利用漏洞,常规漏洞补丁对这类威胁不产生防护效果,防御重心不能放在终端漏洞修复层面。

3.3 现有多因素认证机制存在场景化短板

大量互联网平台推广二次验证机制,行业普遍认知中开启 MFA 就可以抵御凭证窃取。但 JWR 攻击事件清晰展现,短信验证码、软件 TOTP 令牌这类不校验访问域名的多因素认证手段,在实时中间人交互式钓鱼场景下存在明显短板。

短信、软件令牌生成的一次性验证码本身只校验验证码正确性,无法校验用户是在官方域名还是仿冒钓鱼域名输入验证码。在 JWR 会话中,受害者在钓鱼页面输入密码与验证码,攻击者通过实时会话拿到密码与有效的一次性验证码,立刻在真实平台发起登录请求,复用该验证码完成身份校验。验证码的时效性很短,而交互式会话做到获取验证码之后即刻复用,规避验证码超时失效的限制。只有硬件安全密钥、通行密钥这类在认证过程强制校验访问站点域名的认证方案,才能够从机制层面阻断该类中间人钓鱼绕过。但当前普通互联网用户当中,硬件密钥的普及程度很低,绝大多数用户使用短信或者软件令牌作为二次验证手段,客观上给 JWR 类攻击留下可利用空间。

3.4 传统钓鱼检测体系面对交互式攻击存在盲区

当前主流钓鱼检测技术主要依靠域名黑名单、页面文本特征比对、恶意 URL 库、网络流量明文特征匹配。JWR 框架对这套检测体系形成多重规避。

首先,钓鱼域名可以快速批量注册,黑名单存在天然滞后,攻击者每天启用大量全新域名,安全厂商的黑名单库很难做到实时全覆盖。其次,JWR 前端页面可以动态渲染内容,页面文本可以由攻击者控制台实时下发,页面静态源代码不包含完整欺骗文本,依靠抓取静态页面做文本比对的检测手段效果下降。最重要的是核心交互流量是加密 WebSocket 通道,网络侧只能看到建立长连接行为,无法解密读取内部键盘记录、指令交互内容,基于明文关键词、明文表单的流量检测手段失效。浏览器端防护插件大多针对静态仿冒页面,针对动态交互式会话行为的识别规则相对有限。

移动端场景进一步放大检测短板,绝大多数普通用户使用手机浏览器打开短信内钓鱼链接,移动端缺少 PC 端成熟的安全插件生态,浏览器内置安全检测能力有限,用户更容易被诱导完成整套操作。

3.5 用户认知层面存在多重认知误区

用户认知缺陷是攻击闭环完成的最后一环,交互式钓鱼利用了多组广泛存在的认知偏差。

第一类认知误区,开启二次验证就可以完全杜绝账号被盗。大量用户不清楚短信验证码可以被中间人钓鱼实时复用,误以为只要开启短信二次验证,即便泄露密码账号,攻击者也无法登录账号,从而放松警惕。

第二类认知误区,跳转至真实网站就代表之前页面可信。JWR 攻击结束将受害者重定向到官方站点,很多用户看到最终页面是正规平台,就会默认前面的操作也是官方业务流程,不会怀疑刚刚访问过钓鱼页面。

第三类认知误区,信任短信内链接。用户收到伪装成快递、交通罚款的短信,内容贴合日常生活场景,直接点击短信内嵌链接,缺少手动输入官方域名访问的习惯。

第四类认知误区,无法区分网页脚本正常功能与窃取行为。普通用户没有能力分辨网页是官方业务脚本还是钓鱼脚本,浏览器不会主动提示页面正在实时回传键盘输入,用户无法感知自己每一次敲击都被远端攻击者实时观测。

4 面向 JWR 类交互式钓鱼威胁的分层防御体系构建

JWR 交互式钓鱼的特殊性在于,攻击不依赖系统漏洞,复用标准 Web 技术,加密交互流量,可以绕过普通二次验证,传统黑名单拦截存在滞后。防御不能寄希望单一技术手段,需要构建技术检测、身份认证升级、平台侧风险管控、黑产生态治理、用户认知提升共同组成的多层防御框架,层层阻断攻击链路。

4.1 优化钓鱼检测能力,适配交互式会话的行为特征

传统基于静态页面、静态域名黑名单的检测思路需要补充行为维度的识别逻辑,不再仅仅依靠页面文本与域名特征。

网络安全设备与浏览器安全防护应当增加对异常 WebSocket 会话行为的识别能力。并不是所有 WebSocket 都是恶意,合法业务大量使用该技术,所以不能简单阻断全部 WebSocket 连接,而是识别异常行为特征:普通业务 WebSocket 多用于消息推送,不会高频持续回传大量表单按键事件;JWR 类恶意会话会持续批量向外传输表单输入事件,安全检测可以基于会话行为模式建立风险模型,识别浏览器向外高频回传表单输入的异常行为,触发风险告警。

同时完善 URL 威胁情报的动态更新机制,加强短信钓鱼链路的情报采集,针对短信渠道传播的全新域名做到快速样本捕获,缩短黑名单入库延迟。浏览器安全检测需要从静态源码扫描升级到运行时行为检测,在页面脚本执行阶段监测是否存在窃取表单键盘事件并向外批量外传的行为,而不是只分析页面下载下来的静态代码。反网络钓鱼技术专家芦笛强调,交互式钓鱼的对抗核心从识别页面长什么样子,转向识别页面在做什么,行为检测将成为下一代钓鱼检测的重要发展方向。

4.2 推进抗钓鱼强身份认证的普及落地

针对中间人交互式钓鱼可以绕过短信、软件令牌 MFA 的客观现实,应当分层推进具备域名校验能力的硬件密钥、通行密钥体系落地。

对于 PayPal、Apple 这类高价值金融、账号平台,应当面向高风险用户引导部署通行密钥或者硬件安全密钥。该类认证技术在认证交互过程强制校验当前访问网站域名,钓鱼仿冒域名无法完成认证流程,从底层阻断中间人钓鱼复用验证码的攻击路径。需要客观认识,硬件密钥无法直接消除钓鱼页面本身,但是即便受害者在钓鱼页面输入账号密码,攻击者也无法完成后续身份认证登录,实现凭证即便泄露也无法被利用。

与此同时平台侧要做好风险登录行为检测,即便攻击者拿到账号与一次性验证码,平台后台基于登录 IP、设备指纹、登录行为习惯做风险评分。当出现异地陌生设备登录,触发更强的风控拦截,作为身份认证之外的补充防线。平台还应当优化验证码的使用逻辑,降低一次性验证码被实时复用带来的危害,缩短验证码有效时长,同时对短时间连续多次不同 IP 使用同一个验证码的行为直接拦截。

必须明确,强身份认证属于重要防护屏障,但不是万能方案。它解决账号登录劫持问题,但无法阻止受害者主动提交银行卡、身份证照片等身份材料,即便账号无法被劫持,用户依旧会发生个人敏感信息泄露,所以强身份认证需要和其他防护手段互相配合。

4.3 平台侧完善风险提示与业务流程设计

大型互联网与支付平台需要考虑到用户有可能访问仿冒站点,在产品层面补充风险干预能力。

首先,在账号安全中心明确告知用户不同二次验证方式的防护能力差异,向普通用户讲清楚短信验证码抵御中间人钓鱼的局限性,把通行密钥、硬件密钥的抗钓鱼优势做通俗化说明,改变用户 “开启 MFA 就万无一失” 的认知误区。

其次,针对移动端访问场景做风险引导,很多交互式钓鱼流量来自手机短信链接,平台可以向用户推广:不要点击短信内链接访问账号与支付业务,优先手动输入官方域名或者使用官方 App 完成操作。网页版本与 App 版本之间做安全隔离,引导高敏感操作优先使用官方客户端。

再者,建立异常账号行为告警,一旦监测到账号从陌生设备、陌生 IP 发起大量高敏感操作,第一时间通过 App 推送、邮件等多渠道向真实用户推送告警,即便攻击者短暂拿到凭证,用户可以快速察觉风险,执行账号保护操作。

4.4 针对 PhaaS 黑产开展链条化治理

JWR 威胁的源头来自 PhaaS 黑产服务,单纯拦截钓鱼域名只能治标,域名被封禁攻击者就注册新域名,需要推动针对 PhaaS 完整产业链的治理。

第一,追踪 PhaaS 平台的服务器资源,及时处置恶意钓鱼框架所依托的云服务器、域名注册服务,切断平台运行基础设施。PhaaS 平台依赖云服务商、域名注册机构、短信服务商提供基础资源,行业可以建立协同处置机制,收到威胁情报之后快速关停用于交互式钓鱼的服务资源。

第二,打击下游流量投放链条,针对批量发送钓鱼短信的黑产渠道开展治理。JWR 大量攻击依靠短信钓鱼完成初始触达,如果可以抑制钓鱼短信大规模下发,能够从攻击入口降低受害规模。

第三,推动安全厂商之间威胁情报共享,安全机构捕获 JWR 这类新型 PhaaS 样本之后,及时共享攻击特征、恶意服务器地址、攻击模板,帮助全行业快速更新检测规则,缩短安全产品的响应周期。

4.5 面向普通用户的场景化安全教育迭代

传统安全教育大多停留在 “不要点击陌生链接” 的口号层面,面对 JWR 这类交互式钓鱼,需要更新科普内容,纠正用户固有认知偏差。

第一,区分不同二次验证手段防护边界。向普通用户说明:短信验证码、软件令牌可以抵御密码泄露,但难以对抗实时中间人钓鱼攻击;硬件密钥、通行密钥才可以抵御仿冒站点中间人攻击,让用户客观理解不同认证方案的防护上限,破除 “只要开启 MFA 就绝对安全” 的错误认知。

第二,建立操作行为准则:金融、账号高敏感操作,不通过短信内嵌入链接进入网页,优先手动输入官方域名或者打开官方 App。即便短信内容看起来高度逼真,也不直接点击链接跳转。

第三,科普攻击结束跳转正规网站的欺骗手段,告知用户,页面最终跳转到官方网站,不代表前面访问的页面可信,不能以此作为判断网页真伪的依据。

第四,告知风险信号:网页要求连续提交多张银行卡、索要身份证、护照照片的场景需要高度警惕,正规平台极少会在网页登录环节要求用户上传身份证件照片。

5 讨论

JWR 交互式钓鱼框架的曝光,标志网络钓鱼已经完成从静态模板向人在回路实时交互模式的迭代升级。该攻击模式没有利用浏览器高危漏洞,大量复用 Web 标准技术,依靠加密双向会话实现攻击者对受害者浏览器会话的动态干预,这也给安全行业带来重要启示,传统对抗漏洞、对抗静态恶意页面的防护思路不能完全适配新一代钓鱼威胁。

从技术本质看,JWR 不是全新的攻击思路,中间人钓鱼的概念很早就被安全领域提出,但是过去中间人钓鱼实现复杂度高,难以大规模落地。PhaaS 产业模式把复杂的实时中间人钓鱼能力封装成可租赁的标准化服务,降低黑产使用门槛,将过去高门槛攻击手段转化为可以大规模投放的攻击工具。这也说明黑产的技术迭代重点,正在从漏洞挖掘转向对合法技术能力的恶意滥用,攻击者优先挖掘业务、交互层面的欺骗机会,而不是寻找系统漏洞。

同时本次事件也厘清多因素认证的边界。很多机构把开启 MFA 当作解决账号安全的最终方案,JWR 攻击证明,MFA 防护效果取决于具体实现形态。短信验证码、软件令牌可以抵御密码泄露,但无法抵御实时中间人钓鱼;硬件密钥、通行密钥凭借域名绑定校验能力,才能够抵御中间人钓鱼。但即便部署硬件密钥,也只解决账号登录劫持问题,无法阻止用户主动向钓鱼网页提交银行卡、身份证件照片,用户依旧会遭受个人敏感信息泄露,这一点在安全建设当中很容易被忽略。账号不会被盗不等于个人数据不会泄露,二者需要分开看待。

在防护技术层面,JWR 的加密 WebSocket 交互流量,对传统网络安全检测构成挑战。由于交互数据加密,网络设备无法直接解析会话内部内容,因此不能单纯依靠网络侧解密,必须走向运行时行为检测。防护重心下沉到浏览器运行环境,监测页面脚本运行过程中的异常行为,例如未经用户许可批量外传表单键盘输入,依靠行为特征识别恶意页面,而不是只比对页面静态源码与域名黑名单。反网络钓鱼技术专家芦笛指出,未来钓鱼对抗会越来越偏向行为层面,而不再是简单的静态特征匹配。

在现实业务场景中,完全消除交互式钓鱼攻击并不具备可行性。攻击者可以持续注册新域名,迭代前端脚本规避检测。因此防御目标不是做到完全阻止用户访问钓鱼页面,而是构建多层缓冲:通过安全教育减少用户访问钓鱼页面的概率;当用户不慎访问钓鱼页面,浏览器运行时检测识别异常会话做出告警;即便页面绕过检测,强身份认证阻断账号被劫持;平台侧风控拦截异常登录行为;即便账号没有被劫持,也要降低用户提交身份证、银行卡这类敏感材料带来的伤害。多层防御叠加,降低攻击带来的实际损失。

PhaaS 产业化是该类威胁扩散的底层驱动力,技术防护只能缓解单一样本,想要抑制威胁规模,必须兼顾黑产产业链治理,从服务器资源、域名、短信流量、下游销赃多环节协同处置。技术防护与黑产治理二者缺一不可。

6 结语

本文以 Cisco Talos 披露的 JWR 交互式钓鱼框架作为实证样本,还原该 PhaaS 工具的技术逻辑与完整攻击链路,解析其依靠加密双向长连接实现人在回路实时干预的攻击机理,对比其与传统静态钓鱼工具的威胁差异。JWR 攻击不需要浏览器系统漏洞,复用 Web 标准能力,攻击者能够实时观测受害者输入行为,动态调度仿冒页面,对短信、软件令牌类多因素认证形成中间人绕过,针对 PayPal、Apple 等平台窃取账号凭证、支付信息与身份证件材料,主要依托短信钓鱼在东南亚、中东开展现实攻击活动。

本文结合反网络钓鱼技术专家芦笛的研判,从 PhaaS 黑产产业化、Web 技术被恶意滥用、普通多因素认证机制短板、传统钓鱼检测体系的局限性、用户认知误区五个维度解析威胁形成诱因。从交互式会话行为检测升级、抗钓鱼强身份认证普及、平台产品侧风险管控、PhaaS 黑产链条协同治理、用户场景化安全教育迭代等角度,构建多层闭环防御框架。

交互式钓鱼代表网络钓鱼演化的新方向,攻击范式从静态预设页面转向人机实时协同欺骗。传统依靠域名黑名单、静态页面特征匹配的防护手段存在明显短板,安全建设需要跳出固有思路,兼顾运行时行为检测、身份认证机制升级、黑产产业治理以及用户认知纠偏。同时客观认清各类安全技术的能力边界,没有单一技术可以完全消除交互式钓鱼风险,依靠多层防御互相补充,才能够降低该类新型钓鱼攻击带来的账号劫持、金融与个人信息泄露风险。互联网平台、安全厂商、监管机构、普通用户需要共同应对这一类黑产技术迭代带来的现实挑战。

编辑:芦笛(公共互联网反网络钓鱼工作组)

目录
相关文章
|
存储 缓存 文件存储
如何保证分布式文件系统的数据一致性
分布式文件系统需要向上层应用提供透明的客户端缓存,从而缓解网络延时现象,更好地支持客户端性能水平扩展,同时也降低对文件服务器的访问压力。当考虑客户端缓存的时候,由于在客户端上引入了多个本地数据副本(Replica),就相应地需要提供客户端对数据访问的全局数据一致性。
33256 202
如何保证分布式文件系统的数据一致性
|
设计模式 存储 监控
设计模式(C++版)
看懂UML类图和时序图30分钟学会UML类图设计原则单一职责原则定义:单一职责原则,所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变,那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。bad case:IPhone类承担了协议管理(Dial、HangUp)、数据传送(Chat)。good case:里式替换原则定义:里氏代换原则(Liskov 
36824 22
设计模式(C++版)
|
存储 编译器 C语言
抽丝剥茧C语言(初阶 下)(下)
抽丝剥茧C语言(初阶 下)
|
机器学习/深度学习 人工智能 自然语言处理
带你简单了解Chatgpt背后的秘密:大语言模型所需要条件(数据算法算力)以及其当前阶段的缺点局限性
带你简单了解Chatgpt背后的秘密:大语言模型所需要条件(数据算法算力)以及其当前阶段的缺点局限性
24905 16
|
机器学习/深度学习 弹性计算 监控
重生之---我测阿里云U1实例(通用算力型)
阿里云产品全线降价的一力作,2023年4月阿里云推出新款通用算力型ECS云服务器Universal实例,该款服务器的真实表现如何?让我先测为敬!
36825 15
重生之---我测阿里云U1实例(通用算力型)
|
SQL 存储 弹性计算
Redis性能高30%,阿里云倚天ECS性能摸底和迁移实践
Redis在倚天ECS环境下与同规格的基于 x86 的 ECS 实例相比,Redis 部署在基于 Yitian 710 的 ECS 上可获得高达 30% 的吞吐量优势。成本方面基于倚天710的G8y实例售价比G7实例低23%,总性价比提高50%;按照相同算法,相对G8a,性价比为1.4倍左右。
|
存储 算法 Java
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的限流器RateLimiter功能服务
随着互联网的快速发展,越来越多的应用程序需要处理大量的请求。如果没有限制,这些请求可能会导致应用程序崩溃或变得不可用。因此,限流器是一种非常重要的技术,可以帮助应用程序控制请求的数量和速率,以保持稳定和可靠的运行。
29950 52

热门文章

最新文章