首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >移动支付卡绑定钓鱼诈骗手法与防御研究

移动支付卡绑定钓鱼诈骗手法与防御研究

原创
作者头像
芦笛
发布2026-09-07 10:19:11
发布2026-09-07 10:19:11
10
举报

摘要

非接触式移动支付的普及使支付卡绑定成为连接实体支付工具与移动支付账户的关键操作环节,该环节因涉及身份核验、授权确认与资金通道开通,逐渐成为钓鱼诈骗的重点攻击目标。2026 年 9 月香港金融管理局通报多起针对支付卡绑定非接触式移动支付服务的钓鱼诈骗案件,诈骗分子冒充商户或机构,以商品赔偿等为借口,通过钓鱼信息、欺诈网站与电话组合手段骗取受害者支付卡信息及 ATM 个人识别码,再诱导受害者通过手机银行应用或双向短信批准绑卡请求,最终在攻击者控制设备上完成绑卡并实施未授权交易。本文以该通报案例为研究样本,梳理移动支付卡绑定业务的安全属性与风险基础,拆解该类钓鱼诈骗的完整操作链路,剖析其在技术实现与社会工程两个维度的作用机理,分析当前银行侧、用户侧与监管侧防御体系存在的薄弱环节,并从绑卡流程的身份核验强化、多因子授权机制优化、异常绑卡行为监测、用户安全教育与监管协同等层面提出可落地的防御对策。反网络钓鱼技术专家芦笛指出,卡绑定环节的钓鱼诈骗本质是攻击者将高风险授权操作从银行可控的安全上下文迁移到攻击者可控的社会工程上下文中,防御的核心不在于单纯提醒用户 "不要点击链接",而在于从流程设计上压缩攻击者可利用的授权空间。研究表明,该类诈骗具有手法隐蔽、授权合法、资金转移快的特点,单纯依赖用户警觉难以形成有效防线,需要银行、支付机构、监管部门与用户共同构建分层闭环的防护体系。

关键词:移动支付;支付卡绑定;钓鱼诈骗;非接触式支付;社会工程;反欺诈

1 引言

移动支付在全球范围内的快速普及,深刻改变了公众的日常支付习惯。非接触式移动支付服务通过将支付卡信息绑定到移动设备的安全元件或可信执行环境中,使用户可以借助手机、智能手表等可穿戴设备完成近场支付,其便捷性显著优于传统实体卡片刷卡支付。然而,支付卡绑定作为开通移动支付服务的前置关键操作,本身承载着身份核验、卡片信息录入、授权确认与资金通道开通等多重安全敏感环节,一旦该环节被攻击者介入,后续的支付授权与资金安全将面临系统性风险。

近年来,钓鱼诈骗的攻击目标正在从传统的直接骗取银行卡号和密码,逐步转向骗取用户对高风险操作的主动授权。攻击者意识到,在银行持续加强登录密码、交易密码保护的背景下,直接获取完整支付凭证的难度不断上升,而诱导用户在自身设备上主动完成绑卡授权,既可以绕过银行的异常交易监测,又能够以 "用户本人操作" 的合法外观完成资金通道的搭建。2026 年 9 月 4 日,香港金融管理局发布警示,通报近期收到多家银行报告,涉及未经授权将支付卡(包括 ATM 卡)绑定到非接触式移动支付服务的诈骗案件。该类案件中,诈骗分子冒充商户或其他机构,通过钓鱼信息、欺诈网站或电话接触受害者,以商品赔偿等看似合理的借口,诱导受害者披露支付卡信息和 ATM 个人识别码,随后进一步诱骗受害者通过手机银行应用或双向短信批准支付卡绑定请求,一旦绑卡成功,诈骗分子即可在其控制的设备上使用该支付卡进行未授权交易。

该通报案例具有典型的研究价值:其一,攻击目标精准指向支付卡绑定这一高风险但公众安全认知相对薄弱的操作环节;其二,攻击手法融合了钓鱼信息、欺诈网站、电话诈骗与授权诱导等多种社会工程手段,形成了完整的攻击闭环;其三,攻击最终利用的是用户本人的合法授权操作,使得银行侧基于异常行为的传统反欺诈模型难以直接识别。当前公开研究更多聚焦于传统钓鱼网站的技术检测与银行卡盗刷的交易监测,针对 "卡绑定" 这一特定环节的钓鱼诈骗手法的系统性分析相对有限。本文以 HKMA 通报案例为核心材料,结合移动支付卡绑定的业务流程与安全机制,对该类诈骗的手法、机理与防御对策进行系统研究,旨在为银行优化绑卡安全流程、监管部门完善治理机制、公众提升安全防范意识提供参考依据。

2 移动支付卡绑定业务的安全属性与风险基础

2.1 非接触式移动支付卡绑定的业务流程

非接触式移动支付服务的卡绑定流程,是将一张实体支付卡(包括借记卡、信用卡、ATM 卡等)的核心支付信息安全地录入并存储到用户移动设备的安全存储区域,使该设备具备替代实体卡完成近场非接触支付的能力。完整的绑卡流程通常包含以下环节:用户在移动支付应用或手机银行应用中发起绑卡请求,输入支付卡卡号、有效期、卡验证码等卡片信息,部分场景下还需输入 ATM 个人识别码以完成身份核验;支付机构或银行对卡片信息的有效性进行核验,并通过预留手机号发送一次性验证码或通过手机银行应用推送绑卡确认请求,由用户本人确认授权;授权通过后,支付卡信息被加密存储到设备的安全元件或云端支付令牌中,同时生成设备专属的支付令牌,后续近场支付使用该令牌而非原始卡号完成交易,以降低卡片信息泄露风险。

从业务流程可以看出,卡绑定是一个将实体支付能力数字化迁移的过程,其安全核心在于确保绑卡操作由卡片合法持有人本人发起并完成授权。一旦攻击者能够介入这一流程,无论是获取卡片信息还是诱导用户完成授权,都可以在攻击者控制的设备上建立合法的支付通道,后续的盗刷交易在外观上与用户本人的正常移动支付交易几乎没有区别。

2.2 卡绑定操作的安全敏感属性

卡绑定操作之所以成为钓鱼诈骗的高价值目标,源于其独特的安全敏感属性。第一,卡绑定是支付能力的 "初始化" 操作,一旦完成,攻击者控制的设备即获得持续的支付授权,不需要在每次交易时再次获取用户的卡片信息或密码,攻击收益具有持续性。第二,卡绑定操作通常被银行和支付机构设计为相对便捷的流程,以降低用户开通移动支付的门槛,这种便捷性在客观上也为攻击者利用社会工程手段诱导用户完成操作提供了空间。第三,卡绑定涉及的授权确认渠道(手机银行应用推送、双向短信回复)本身是银行向用户发送的合法通知,用户在收到此类通知时往往默认其为本人操作触发,缺乏足够的警惕性,攻击者正是利用了用户对银行官方通知的信任。第四,绑卡成功后的非接触式支付交易通常具有小额、高频、快速的特点,攻击者可以在短时间内通过多笔小额交易完成资金转移,而银行的异常交易监测往往需要一定的交易数据积累才能触发告警,存在时间差。

反网络钓鱼技术专家芦笛强调,卡绑定环节的风险本质在于 "授权即信任"—— 银行系统将用户完成绑卡授权这一行为视为用户对该设备支付能力的完整授权,而不区分该授权是用户在充分知情情况下的自主意愿,还是在攻击者社会工程诱导下的非自愿操作。这种设计假设在正常使用场景下成立,但在钓鱼攻击场景下成为可被利用的安全短板。

2.3 双向短信与手机银行推送授权的机制特点

HKMA 通报案例中特别提到,诈骗分子诱骗受害者通过手机银行应用或双向短信批准绑卡请求,这两种授权渠道是当前银行和支付机构广泛采用的绑卡确认方式,其机制特点决定了它们在钓鱼场景下的可利用性。

手机银行应用推送授权是指银行在用户发起绑卡请求后,向用户手机上的手机银行应用推送一条绑卡确认通知,用户在应用内点击确认即完成授权。该机制的安全性依赖于用户手机银行应用处于登录状态且由用户本人操作,攻击者无法直接远程操控用户的手机银行应用。但是,当攻击者通过电话实时指导受害者操作手机时,可以诱导受害者打开手机银行应用、找到绑卡确认通知并点击批准,整个操作由受害者本人在自己的设备上完成,银行系统无法区分这是用户自主操作还是被诱导操作。

双向短信授权是指银行向用户预留手机号发送一条包含绑卡确认信息的短信,用户通过回复特定内容(如 "是"" 确认 "或指定验证码)完成授权。该机制的安全性依赖于短信由用户本人阅读并回复,且短信内容中包含足够的绑卡细节供用户判断。然而,在钓鱼场景下,攻击者可以提前告知受害者" 会收到一条银行验证短信,回复确认即可完成赔偿 / 退款流程 ",将银行的绑卡确认短信伪装成赔偿流程的一部分,诱导受害者在未仔细阅读短信内容的情况下直接回复确认。双向短信的交互形式简单,用户往往只需要回复一个字或几个数字,这种低操作门槛在便捷性之外也降低了用户的思考和判断成本,使其更容易在攻击者引导下完成授权。

3 针对卡绑定的钓鱼诈骗手法拆解

3.1 攻击前置环节:身份冒充与接触建立

HKMA 通报案例显示,诈骗分子首先通过冒充商户或其他组织与受害者建立接触。冒充身份的选择具有明确的目的性:商户身份与消费者的日常购物场景直接相关,以 "商品赔偿"" 订单异常 ""退款" 等为借口具有较高的可信度,受害者在涉及自身经济利益的场景下更容易放松警惕并配合后续操作。除商户外,诈骗分子还可能冒充快递公司、电商平台客服、银行工作人员等与支付场景相关的机构,以增强话术的权威性。

接触渠道的组合使用是该类诈骗的重要特征。诈骗分子并非单一依赖某一种渠道,而是通过钓鱼信息(短信、即时通讯消息)、欺诈网站和电话三种渠道形成协同攻击。钓鱼信息通常作为初始触达手段,以简短的文字和链接引导受害者访问欺诈网站或回拨电话;欺诈网站用于模拟商户或机构的官方页面,收集受害者的订单信息、支付卡信息等敏感数据,并进一步增强骗局的可信度;电话则用于建立实时的语音沟通,由诈骗分子扮演客服人员,通过一对一的话术引导逐步控制受害者的操作节奏。三种渠道的组合使得攻击不再是静态的钓鱼链接点击,而是一个动态的、有人员实时参与的社会工程过程,受害者在整个过程中始终处于被引导和被操控的状态。

3.2 信息骗取环节:支付卡信息与 ATM 密码的获取

在建立信任并获得受害者配合后,诈骗分子进入信息骗取环节,目标是获取受害者的支付卡信息和 ATM 个人识别码。HKMA 通报明确指出,诈骗分子以商品赔偿等为借口,欺骗受害者披露支付卡信息和 ATM 个人识别码。这一环节的关键在于诈骗分子将敏感信息的索取包装在赔偿或退款流程中,使受害者认为提供这些信息是获得赔偿的必要步骤。

支付卡信息通常包括卡号、有效期、卡验证码等,这些信息本身已经足以支持部分线上交易,但在卡绑定场景下,诈骗分子还需要 ATM 个人识别码,因为部分银行和支付机构在绑卡流程中要求输入 ATM 密码以完成持卡人身份核验。ATM 密码作为持卡人在 ATM 机上取款和进行账户操作的核心凭证,其安全等级通常高于普通的查询密码,受害者在正常情况下不会轻易向他人透露。诈骗分子通过 "退款需要验证账户身份"" 赔偿款需要打入您的账户,需验证 ATM 密码 " 等话术,将 ATM 密码的索取合理化,利用受害者对赔偿流程的不熟悉和对资金到账的期待,突破其心理防线。

值得注意的是,这一环节中诈骗分子获取的信息并非直接用于盗刷,而是用于后续的绑卡操作。也就是说,支付卡信息和 ATM 密码是绑卡的 "输入材料",而真正完成绑卡还需要用户的授权确认,这就引出了攻击的下一个关键环节。

3.3 授权诱导环节:绑卡请求的批准操纵

获取支付卡信息和 ATM 密码后,诈骗分子开始在自己控制的设备上发起支付卡绑定请求。此时银行系统会向受害者预留的手机号或手机银行应用发送绑卡确认通知,要求用户批准该绑卡请求。这是整个攻击链路中最关键的环节,因为绑卡请求的最终批准权仍然掌握在受害者手中,诈骗分子无法绕过这一步直接完成绑卡。

HKMA 通报指出,诈骗分子通过不同渠道诱骗受害者批准绑卡请求,包括手机银行应用和双向短信。在手机银行应用场景下,诈骗分子通过电话实时指导受害者打开手机银行应用,找到绑卡确认通知,并点击批准。诈骗分子通常会将该通知描述为 "赔偿款到账确认"" 账户验证通知 "等,诱导受害者在不仔细阅读通知内容的情况下点击确认。在双向短信场景下,诈骗分子提前告知受害者" 银行会发一条验证短信,您回复确认即可 ",当受害者收到银行的绑卡确认短信时,在诈骗分子的引导下直接回复指定内容完成授权,而未注意到短信内容实际是绑卡确认而非赔偿验证。

这一环节的欺骗性在于,受害者收到的绑卡确认通知确实来自银行官方,通知本身是真实的,诈骗分子并没有伪造银行通知,而是操纵了受害者对通知内容的理解和对授权操作的决策。受害者认为自己是在配合赔偿流程,实际上是在批准将自己的支付卡绑定到诈骗分子控制的设备上。这种 "真实通知 + 虚假解释" 的组合,使得受害者在授权完成后往往仍未意识到自己已经遭受诈骗,直到后续出现未授权交易时才发现异常。

3.4 攻击后置环节:未授权交易与资金转移

一旦支付卡成功绑定到诈骗分子控制的设备,攻击进入后置环节,即利用绑定的支付卡进行未授权交易。非接触式移动支付的特点决定了这一环节的操作具有快速、分散、难以拦截的特征。诈骗分子可以在支持非接触支付的商户 POS 机上使用绑定了受害者支付卡的设备完成近场支付,也可以通过支持该移动支付服务的线上商户完成消费。由于绑卡操作由受害者本人授权完成,且支付令牌与设备绑定,这些交易在银行系统中显示为用户本人移动支付设备发起的正常交易,传统的基于异地登录、异常设备、大额交易的反欺诈规则难以直接触发告警。

诈骗分子通常采用小额、多笔、快速的交易策略,在短时间内完成资金转移。非接触式移动支付往往设置有免密小额支付额度,在该额度内的交易不需要输入支付密码,仅需设备靠近 POS 机即可完成,这进一步加快了诈骗分子的盗刷速度。当受害者发现账户异常并联系银行冻结卡片时,诈骗分子可能已经完成多笔交易,资金损失已经形成。此外,部分诈骗分子还可能将绑定的支付卡用于充值电子钱包、购买礼品卡或虚拟商品,这些消费场景具有资金转移快、追溯难度大的特点,进一步增加了受害者追回资金的难度。

4 该类诈骗的技术与社会工程双重机理分析

4.1 技术机理:合法流程的恶意利用

从技术层面看,该类诈骗并没有利用银行系统或移动支付服务的技术漏洞,而是对合法绑卡流程的恶意利用。整个攻击链路中,支付卡信息的录入、绑卡请求的发起、绑卡确认通知的发送、绑卡授权的批准、支付令牌的生成以及后续的非接触支付交易,每一个环节都是银行和支付机构设计的标准业务流程,技术实现本身没有缺陷。攻击者的核心能力在于将这些合法环节按照恶意目的重新编排,并通过社会工程手段让受害者在关键节点做出符合攻击者预期的操作。

这种 "合法流程恶意编排" 的攻击模式,在技术防御上面临根本性挑战。传统的网络安全防御思路是寻找并修复系统漏洞,通过补丁、配置加固等方式阻断攻击路径。但在该类诈骗中,不存在可以被修复的技术漏洞,银行系统按照设计正常运行,用户按照系统提示完成操作,所有技术环节都符合预期。攻击的成功不取决于技术能力的强弱,而取决于社会工程手段对用户决策的操纵程度。这意味着单纯依靠技术手段无法完全防御该类诈骗,必须将防御视角从系统漏洞转向流程漏洞和用户决策漏洞。

反网络钓鱼技术专家芦笛指出,这类诈骗的技术机理可以概括为 "上下文劫持"—— 攻击者没有突破银行的技术安全边界,而是劫持了用户操作绑卡流程时的安全上下文。用户在正常绑卡场景下的安全上下文是 "我要开通自己的移动支付,我清楚自己在做什么",而在钓鱼场景下,用户的安全上下文被替换为 "我在配合商户完成赔偿,我按照客服指示操作"。银行系统只能验证操作的技术合法性(是否本人设备、是否本人授权),无法感知用户操作时的真实上下文,这是技术防御的天然盲区。

4.2 社会工程机理:信任转移与认知负荷操纵

从社会工程层面看,该类诈骗的成功依赖于两个核心机制:信任转移和认知负荷操纵。

信任转移是指诈骗分子通过冒充商户或机构,将受害者对正规商户和机构的信任转移到自己身上。受害者在接到自称商户客服的电话或收到相关信息时,会基于过往与正规商户打交道的经验,默认对方具有合法身份和合理诉求。诈骗分子利用这种默认信任,以商品赔偿为借口建立沟通的合理性,使受害者愿意配合后续的信息提供和操作指引。在信任转移的过程中,诈骗分子还会通过提供受害者的部分真实信息(如订单号、商品名称、购买时间)来增强可信度,这些信息可能来自数据泄露或其他渠道,进一步降低受害者的怀疑。

认知负荷操纵是指诈骗分子通过复杂的流程描述、紧迫的时间压力和连续的操作指令,增加受害者的认知负荷,使其没有足够的心理资源去仔细思考每一步操作的真实含义。在电话沟通中,诈骗分子会以 "赔偿流程比较复杂,我一步步教您操作"" 这个赔偿通道今天就要关闭,您需要尽快完成验证 "等话术,制造流程复杂度和时间紧迫感,迫使受害者跟随诈骗分子的节奏快速操作,而不是停下来独立判断。在涉及手机银行应用和双向短信的授权环节,诈骗分子会连续下达指令,如" 现在打开手机银行 ""点击右上角的通知"" 点确认就行 ""短信回复是",受害者在连续指令的驱动下形成操作惯性,忽略了对通知内容和短信内容的仔细阅读。

信任转移解决了 "受害者为什么愿意听诈骗分子的话" 的问题,认知负荷操纵解决了 "受害者为什么不会在关键授权环节停下来思考" 的问题。两者结合,形成了完整的社会工程攻击闭环,使受害者在整个过程中始终处于被引导、被操控的状态,最终在不知情的情况下完成了高风险的绑卡授权。

4.3 双重机理的协同效应

技术机理与社会工程机理并非独立发挥作用,而是形成了协同效应,使该类诈骗的防御难度显著高于单一维度的攻击。技术机理提供了攻击的 "可行路径"—— 合法的绑卡流程使得攻击者不需要具备高超的技术能力即可实施攻击,降低了攻击的技术门槛;社会工程机理提供了攻击的 "执行能力"—— 通过信任转移和认知负荷操纵,攻击者能够让受害者在关键节点主动完成授权,解决了合法流程中用户授权这一不可绕过的安全控制点。

两者的协同还体现在攻击的隐蔽性上。由于所有技术操作都是合法的,银行系统的技术监测不会产生告警;由于受害者是在被诱导的情况下主动操作,受害者自身也不会立即意识到遭受诈骗。这种 "技术上合法、用户上无觉" 的双重隐蔽,使得攻击从实施到被发现之间存在较长的时间窗口,诈骗分子有充足的时间完成未授权交易和资金转移。当受害者最终发现异常时,往往已经造成了实质性的资金损失,且由于绑卡授权由用户本人完成,在责任认定和资金追回方面也面临更多复杂因素。

5 现有防御体系的薄弱环节

5.1 银行侧:绑卡流程的安全设计缺陷

银行和支付机构作为绑卡流程的设计者和执行者,其现有安全设计在面对该类钓鱼诈骗时存在若干薄弱环节。

第一,绑卡授权通知的信息呈现不够充分。当前多数银行的绑卡确认通知(无论是手机银行推送还是双向短信)在内容上较为简洁,通常只包含 "您正在发起绑卡操作,请确认" 之类的提示,而缺少关键的上下文信息,如绑卡设备的型号、设备所在地理位置、绑卡请求的发起时间、绑定的移动支付服务名称等。受害者在收到通知时,如果没有足够的信息判断该绑卡请求是否为本人发起,就更容易在诈骗分子的引导下误判为赔偿流程的一部分。特别是双向短信,由于短信长度有限,信息呈现更加简略,用户往往只看到 "回复确认" 的指令而忽略了绑卡的实质内容。

第二,绑卡操作缺乏 "冷静期" 或二次确认机制。当前多数绑卡流程在用户批准授权后立即生效,没有设置延迟生效期或二次确认环节。这种设计在正常使用场景下提升了用户体验,但在钓鱼场景下,受害者一旦在诈骗分子诱导下完成授权,绑卡立即生效,诈骗分子可以立刻开始盗刷,银行和受害者都没有反应和拦截的时间窗口。如果设置绑卡延迟生效(如授权后 30 分钟或 1 小时才正式开通支付功能),并在延迟期内向用户发送再次提醒,可以为受害者发现异常并撤销绑卡提供机会。

第三,异常绑卡行为的监测能力不足。现有反欺诈系统更多关注交易环节的异常行为(如大额交易、异地交易、高频交易),而对绑卡环节的异常行为关注不够。实际上,绑卡操作本身具有丰富的行为特征可供分析,如绑卡请求发起的设备是否为新设备、设备地理位置是否与用户常驻地一致、绑卡请求发起时间是否在用户活跃时段、绑卡后是否立即发起多笔小额交易等。如果银行能够建立针对绑卡环节的异常行为监测模型,对高风险绑卡请求触发额外的身份核验或人工复核,可以在绑卡生效前阻断攻击。

第四,对 ATM 密码在绑卡流程中的使用缺乏风险提示。部分银行在绑卡流程中要求输入 ATM 密码以完成身份核验,但在用户输入 ATM 密码的界面和环节,没有充分提示该操作的高风险性,也没有提醒用户 "任何情况下不要在他人指导下输入 ATM 密码"。这种设计使得用户在钓鱼场景下,将输入 ATM 密码视为绑卡或赔偿流程中的普通步骤,而没有意识到其安全敏感性。

5.2 用户侧:安全认知与操作习惯的不足

用户作为绑卡授权的最终决策者,其安全认知和操作习惯直接决定了钓鱼诈骗能否成功。HKMA 通报中提醒公众的四点注意事项 —— 不点击未知来源链接、不泄露支付卡信息和密码、不遵循陌生人指示批准请求、仔细阅读银行通知并拒绝非本人发起的绑卡请求 —— 恰恰反映了当前用户在这些方面存在普遍不足。

第一,用户对支付卡绑定操作的风险认知不足。多数用户能够意识到银行卡号、密码、验证码的敏感性,但对 "绑卡授权" 这一操作的高风险性缺乏足够认识。用户可能认为绑卡只是将卡片信息录入手机,是一个普通的设置操作,而没有意识到一旦绑卡成功,绑定的设备即获得完整的支付能力,其风险等级等同于将银行卡和密码交给他人。这种认知不足使得用户在诈骗分子以赔偿为借口诱导绑卡时,没有产生足够的警惕。

第二,用户在电话引导下的独立判断能力不足。该类诈骗的核心环节是诈骗分子通过电话实时引导用户操作,用户在一对一的语音沟通中容易形成对 "客服" 的服从心理,放弃独立思考。特别是当诈骗分子使用专业的话术、提供准确的个人信息、制造时间紧迫感时,用户的独立判断能力进一步下降,容易按照诈骗分子的指令连续操作,而不仔细核对每一步的真实内容。

第三,用户对银行官方通知的阅读习惯存在问题。许多用户在收到银行短信或手机银行推送时,习惯于快速扫一眼标题或操作按钮,而不仔细阅读完整内容。在双向短信场景下,用户甚至可能在未阅读短信正文的情况下直接按照诈骗分子的指示回复确认。这种 "不读内容直接操作" 的习惯,使得银行通过通知内容进行风险提示的努力失效,用户无法从通知中获取足够的信息来判断操作的真实性。

第四,用户对 "赔偿"" 退款 "等经济利益场景的警惕性不足。诈骗分子选择商品赔偿作为借口,正是利用了用户在涉及自身经济利益时的心理弱点。用户在面对" 可以获得赔偿 "的场景时,关注点集中在" 能不能拿到钱 "上,而对" 为什么需要提供银行卡信息和 ATM 密码 ""为什么需要在手机银行里确认" 等异常环节缺乏质疑。这种对经济利益的过度关注和对流程异常的忽视,使得诈骗分子的话术更容易奏效。

5.3 监管侧:协同治理与信息共享的不足

监管部门在防范该类钓鱼诈骗中承担着规则制定、行业协调和公众教育的重要职责,现有监管体系在协同治理和信息共享方面仍有提升空间。

第一,跨机构的诈骗信息共享机制不够完善。该类诈骗往往涉及银行、支付机构、电信运营商、电商平台、公安机关等多个主体,诈骗手法的变化和新型骗局的出现需要各主体及时共享信息。但当前各机构之间的诈骗信息共享存在壁垒,银行发现的新型诈骗手法可能无法及时传递给支付机构和电信运营商,导致防御措施存在滞后性。HKMA 在收到银行报告后向银行业共享了作案手法并提醒银行加强防范,这是行业内部信息共享的良好实践,但跨行业的信息共享仍需加强。

第二,对电信诈骗和钓鱼信息的源头治理力度有待加强。该类诈骗的初始触达依赖钓鱼短信和欺诈电话,电信运营商在拦截异常短信和骚扰电话方面具有技术能力,但当前的拦截精准度和覆盖率仍有不足。部分钓鱼短信通过改号软件或伪基站发送,能够绕过基础的号码拦截;欺诈电话则通过网络电话或境外号码拨打,增加了拦截和溯源的难度。监管部门需要推动电信运营商提升技术拦截能力,同时加强对改号软件、伪基站等非法工具的打击力度,从源头减少诈骗信息的触达。

第三,公众安全教育的针对性和实效性不足。当前的反诈骗宣传更多采用通用化的提醒方式(如 "不要轻信陌生电话"" 不要泄露银行卡信息 "),缺乏针对特定诈骗手法的精细化教育。对于" 卡绑定钓鱼诈骗 " 这类相对新型的手法,公众的认知度较低,通用化的宣传无法覆盖其具体特征和防范要点。监管部门和行业机构需要根据诈骗手法的演变,及时更新公众教育内容,通过案例解析、情景模拟等方式提升公众对特定手法的识别能力。

6 分层防御与治理对策

6.1 银行侧:绑卡流程的安全强化

银行和支付机构是防范卡绑定钓鱼诈骗的第一道防线,应从流程设计、授权机制、行为监测和用户提示四个层面强化绑卡安全。

第一,优化绑卡授权通知的信息呈现。绑卡确认通知应包含足够的上下文信息,帮助用户判断该请求是否为本人发起。手机银行推送通知应显示绑卡设备的型号、设备名称、大致地理位置、绑卡请求发起时间、绑定的移动支付服务名称,并在通知界面显著位置标注 "如非本人操作请立即拒绝"。双向短信应在有限篇幅内明确说明 "您正在将尾号 XXXX 的支付卡绑定到 XX 设备的 XX 支付服务,如非本人操作请勿回复",避免使用模糊的 "验证"" 确认 " 等措辞。通知内容应使用用户能够理解的通俗语言,避免技术术语,确保用户在快速阅读时能够准确把握操作实质。

第二,建立绑卡延迟生效与二次确认机制。对于高风险绑卡请求(如新设备绑卡、异地绑卡、非活跃时段绑卡),应设置延迟生效期,在用户批准授权后不立即开通支付功能,而是在 30 分钟至数小时后生效,并在延迟期内向用户发送再次提醒短信,告知 "您的支付卡将于 XX 时间后绑定到 XX 设备,如非本人操作请点击链接撤销"。延迟生效期为受害者发现异常并撤销绑卡提供了时间窗口,也为银行的异常行为监测和人工复核留出了处理时间。对于所有绑卡操作,可考虑在授权批准后增加一次语音外呼确认,由银行系统自动向用户预留手机号拨打语音电话,播报绑卡详情并要求用户通过按键确认,语音外呼的独立渠道可以增加诈骗分子操纵的难度。

第三,构建绑卡环节的异常行为监测模型。银行应将反欺诈监测的重心从交易环节前移到绑卡环节,建立针对绑卡操作的行为特征分析模型。监测维度应包括:绑卡设备是否为用户历史使用过的设备、设备地理位置是否与用户常驻地或近期活动地一致、绑卡请求发起时间是否在用户历史活跃时段、绑卡操作前是否有异常登录或查询行为、绑卡后是否立即发起多笔小额非接触支付交易、同一支付卡是否在短时间内被多次尝试绑定到不同设备等。对于命中高风险特征的绑卡请求,应触发额外的身份核验(如人脸识别、客服电话回呼)或人工复核,在确认安全前暂缓绑卡生效。

第四,强化 ATM 密码使用环节的风险提示。在绑卡流程中要求输入 ATM 密码的界面,应在输入框上方显著位置标注风险提示,如 "注意:ATM 密码是您的核心支付凭证,任何正规机构不会以赔偿、退款、验证为由要求您提供 ATM 密码。如您是在他人电话指导下操作,请立即停止并挂断电话。" 同时,应在用户输入 ATM 密码前增加一个确认弹窗,要求用户主动勾选 "我确认此操作为本人自主发起,未受他人指导" 后才能继续输入,通过增加操作步骤和用户承诺,提升用户的风险意识,也为后续责任认定提供依据。

反网络钓鱼技术专家芦笛强调,银行侧的安全强化不能以牺牲用户体验为代价,而应通过 "风险分级" 的方式实现安全与便捷的平衡。对于用户在常用设备、常用地点、活跃时段发起的绑卡请求,保持现有便捷流程;对于命中高风险特征的绑卡请求,增加额外核验步骤。这种差异化处理既不会影响绝大多数正常用户的使用体验,又能针对性地提升钓鱼攻击场景下的安全防护能力。

6.2 用户侧:安全认知提升与操作习惯养成

用户是绑卡授权的最终决策者,其安全认知和操作习惯是防御体系的关键环节。用户应从以下几个方面提升自身防范能力。

第一,充分认识支付卡绑定操作的高风险性。用户应建立明确的安全认知:将支付卡绑定到移动支付服务,等同于将该设备变为一张可以直接消费的 "虚拟银行卡",一旦绑定到非本人控制的设备,对方即可直接使用该卡进行消费,其风险与将银行卡和密码交给他人相当。因此,绑卡操作必须由本人在完全知情的情况下自主发起,任何情况下都不应在他人(尤其是自称商户客服、银行工作人员的陌生人)的电话指导下完成绑卡授权。

第二,严格保护支付卡信息和 ATM 密码。用户应牢记:任何正规机构(包括商户、银行、支付平台、快递公司)都不会以 "赔偿"" 退款 ""验证"" 升级 " 等理由,通过电话或短信要求用户提供完整的支付卡卡号、有效期、卡验证码和 ATM 密码。遇到此类要求时,应立即挂断电话,并通过官方渠道(如银行客服热线、商户官方 APP)核实情况。ATM 密码作为核心支付凭证,其保护等级应高于普通密码,任何情况下都不应向他人透露,也不应在他人注视下输入。

第三,养成仔细阅读银行通知的习惯。用户在收到银行的绑卡确认通知(手机银行推送或短信)时,必须完整阅读通知内容,重点确认以下信息:通知是否明确说明是 "绑卡" 操作、绑定的设备是否为本人设备、绑定的支付服务是否为本人正在使用的服务、绑卡请求发起时间是否与本人操作时间一致。如果任何一项信息与本人操作不符,应立即拒绝授权并联系银行核实。在双向短信场景下,用户应在阅读完整短信内容后再决定是否回复,绝不在未阅读短信正文的情况下按照他人指示直接回复。

第四,对 "赔偿"" 退款 "等经济利益场景保持高度警惕。用户在接到自称商户客服的赔偿或退款电话时,应首先通过官方渠道核实对方身份和赔偿事宜,不要仅凭对方提供的订单信息就轻信其身份。正规的赔偿和退款流程通常会通过原支付渠道原路退回,不需要用户提供支付卡信息和 ATM 密码,也不需要用户在手机银行中进行任何" 验证 ""确认" 操作。如果对方要求进行这些操作,应立即意识到可能是诈骗并终止沟通。

6.3 监管侧:协同治理与生态建设

监管部门应在行业协调、规则制定、源头治理和公众教育方面发挥主导作用,构建多方协同的反诈骗治理生态。

第一,建立跨行业的诈骗信息共享与协同响应机制。监管部门应牵头建立银行、支付机构、电信运营商、电商平台、公安机关之间的诈骗信息共享平台,实现新型诈骗手法、涉案号码、涉案域名、涉案账户等信息的实时共享。当某一机构发现新型卡绑定钓鱼诈骗手法时,应立即通过共享平台通报其他机构,各机构同步更新防御规则和拦截策略,缩短防御响应时间。同时,应建立跨机构的协同处置机制,对于已确认的诈骗案件,银行冻结账户、支付机构暂停服务、电信运营商拦截号码、公安机关立案侦查等环节应高效协同,最大限度减少受害者的资金损失。

第二,加强对钓鱼信息和欺诈电话的源头治理。监管部门应推动电信运营商提升钓鱼短信和骚扰电话的技术拦截能力,利用人工智能和大数据分析技术识别异常短信内容和异常呼叫行为,对疑似钓鱼短信和欺诈电话进行精准拦截。同时,应加强对改号软件、伪基站、网络电话等非法工具和渠道的打击力度,切断诈骗分子的通信渠道。对于钓鱼网站,监管部门应协调域名注册商、云服务提供商和浏览器厂商,建立快速发现和封禁机制,对仿冒商户和银行的欺诈网站及时下架和屏蔽,减少用户访问的可能性。

第三,制定针对卡绑定等高危操作的行业安全规范。监管部门应在总结现有诈骗案例的基础上,制定针对支付卡绑定、大额转账、密码重置等高风险操作的行业安全规范,明确银行和支付机构在身份核验、授权确认、异常监测、用户提示等方面的最低安全要求。规范应包括:高风险操作必须采用多因子认证、授权通知必须包含充分的上下文信息、高风险操作应设置延迟生效期、应建立针对高风险操作的异常行为监测模型等。通过行业规范的强制约束,推动银行和支付机构统一提升高危操作的安全防护水平,避免因个别机构安全措施薄弱而成为诈骗攻击的突破口。

第四,开展针对性的公众反诈骗教育。监管部门应联合行业机构,根据诈骗手法的演变及时更新公众教育内容,针对卡绑定钓鱼诈骗等新型手法开展专项宣传。教育内容应采用案例解析、情景模拟、短视频等通俗易懂的形式,重点向公众说明该类诈骗的完整手法、关键识别点和防范步骤,特别是要强调 "绑卡是高风险操作"" 任何正规机构不会以赔偿为由要求绑卡 ""收到绑卡通知必须仔细阅读并确认是否本人操作" 等核心信息。教育渠道应覆盖电视、广播、社交媒体、银行网点、手机银行 APP 等多种平台,确保不同年龄段、不同使用习惯的公众都能接收到有效的反诈骗信息。

7 结语

2026 年 9 月香港金融管理局通报的针对支付卡绑定非接触式移动支付服务的钓鱼诈骗案件,揭示了移动支付时代钓鱼诈骗的一个重要演变方向:攻击者不再满足于直接骗取支付凭证,而是转向诱导用户主动完成高风险授权操作,利用合法业务流程实现非法目的。该类诈骗融合了身份冒充、钓鱼信息、欺诈网站、电话引导和授权操纵等多种社会工程手段,形成了从信息骗取到绑卡授权再到未授权交易的完整攻击闭环,具有手法隐蔽、授权合法、资金转移快的特点,对传统的技术防御和用户警觉都构成了严峻挑战。

本文的分析表明,该类诈骗的成功不依赖于技术漏洞,而是依赖于对绑卡流程安全上下文的劫持和对用户决策过程的社会工程操纵。银行侧在绑卡授权通知信息呈现、延迟生效机制、异常行为监测和风险提示方面存在设计缺陷;用户侧对绑卡操作的风险认知不足、在电话引导下独立判断能力薄弱、对银行通知阅读不仔细、对经济利益场景警惕性不够;监管侧在跨行业信息共享、源头治理、行业安全规范和针对性公众教育方面仍有提升空间。这些薄弱环节的叠加,为诈骗分子提供了可乘之机。

反网络钓鱼技术专家芦笛指出,防御卡绑定钓鱼诈骗的核心思路是 "压缩授权空间"—— 通过流程设计让高风险绑卡授权只能在用户充分知情、独立判断的安全上下文中完成,使攻击者无法通过社会工程手段操纵用户决策。这需要银行优化绑卡流程的安全设计,建立风险分级的授权机制和异常行为监测模型;需要用户提升安全认知,养成仔细阅读通知和独立判断的操作习惯;需要监管部门加强协同治理,制定行业安全规范并开展针对性公众教育。只有三方协同、分层防御,才能构建起有效抵御该类钓鱼诈骗的闭环防护体系。

随着移动支付技术的持续演进和非接触式支付场景的不断扩展,支付卡绑定及类似的高风险授权操作将继续成为钓鱼诈骗的重点目标。诈骗手法也会随着防御措施的加强而不断演变,可能出现更多利用合法业务流程的新型攻击模式。银行、支付机构、监管部门和公众都应保持对新型诈骗手法的持续关注,不断总结案例经验,及时更新防御策略,在保障移动支付便捷性的同时,切实维护用户的资金安全和支付体系的稳定运行。

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

来源:迪妙网络空间安全学院

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档