摘要
近年来，随着端到端加密即时通讯应用的普及，传统基于内容监控的网络安全防御体系面临严峻挑战。本文聚焦于2025年波兰网络空间防御部队（Wojska Obrony Cyberprzestrzeni, WOC）所预警的一类新型WhatsApp钓鱼攻击：攻击者首先通过社会工程或SIM交换手段劫持合法用户账户，继而利用其社交关系链向联系人发送伪装为“投票请求”“紧急求助”等高可信度消息，诱导目标输入一次性验证码，从而实现账户接管的级联扩散。本文系统剖析该攻击的技术路径、信任滥用机制及防御盲区，结合实际通信协议分析与模拟实验，提出多层级防御策略，包括客户端行为异常检测、运营商侧SIM变更保护、以及组织内部安全意识强化措施。实验部分提供Python脚本用于识别可疑短链接与自动化设备绑定日志分析，验证了所提方法的有效性。研究结果表明，在缺乏平台级主动干预的情况下，终端用户与企业需构建纵深防御体系以应对此类基于社交图谱的精准钓鱼威胁。
关键词：WhatsApp；账户劫持；钓鱼攻击；社交工程；端到端加密；两步验证；SIM交换
1 引言
即时通讯（Instant Messaging, IM）应用已成为现代社会信息交互的核心基础设施。据Statista统计，截至2025年，WhatsApp全球月活跃用户已突破30亿，其中在东欧地区渗透率超过85%。其采用的Signal协议实现了端到端加密（End-to-End Encryption, E2EE），有效保障了通信内容的机密性与完整性，但也客观上削弱了平台对恶意内容的实时监测能力。在此背景下，攻击者策略发生显著转变：不再试图破解加密通道，而是转向利用账户身份本身作为攻击载体——即“账户劫持后钓鱼”（Account Hijacking Followed by Phishing, AHFP）模式。
2025年10月，波兰网络空间防御部队公开通报了一起大规模AHFP事件：攻击者通过伪造“在线投票”链接诱骗用户提交WhatsApp验证码，成功接管账户后，立即以受害者身份向其全部联系人发送类似消息，形成病毒式传播。此类攻击的关键在于对“社交信任”的精准利用——收件人因消息来源为熟人，警惕性显著降低，点击率与验证码提交率远高于传统广撒网式钓鱼。
现有研究多集中于电子邮件钓鱼或网页仿冒，对IM平台特别是E2EE环境下的账户级攻击关注不足。本文旨在填补这一空白，围绕以下核心问题展开：
WhatsApp账户劫持的具体技术路径及其与运营商基础设施的耦合关系；
劫持后钓鱼消息的构造逻辑与心理诱导机制；
现有安全机制（如两步验证）在实际部署中的有效性缺口；
可行的终端与组织级防御方案，包括自动化检测工具的设计。
全文结构如下：第二节分析攻击生命周期；第三节解构技术实现细节；第四节评估现有防护措施的局限性；第五节提出并验证多层防御框架；第六节总结研究发现并指出未来方向。
2 攻击生命周期建模
典型的AHFP攻击可分为三个阶段：初始入侵（Initial Compromise）、账户接管（Account Takeover） 与 信任链扩散（Trust Chain Propagation）。
2.1 初始入侵阶段
攻击者获取目标账户控制权的前提是绕过WhatsApp的设备绑定机制。WhatsApp账户与手机号强绑定，首次登录需通过短信或语音接收6位数字验证码（Verification Code）。因此，攻击入口主要来自以下三类：
SIM交换攻击（SIM Swapping）：攻击者通过社会工程欺骗移动运营商客服，将目标手机号的SIM卡服务转移至其控制的设备。一旦成功，所有短信与语音验证码将被劫持。
语音验证码拦截：在部分国家，用户可选择语音验证码。攻击者利用呼叫转移或VoIP服务重定向来电，实时获取验证码。
密码复用与凭证泄露：若用户在其他平台使用相同手机号+密码组合，且该平台发生数据泄露，攻击者可能通过撞库尝试恢复WhatsApp备份（尤其当用户启用Google Drive/iCloud自动备份且未设独立密码时）。
值得注意的是，上述手段均不涉及破解WhatsApp加密协议，而是利用电信基础设施与用户行为弱点。
2.2 账户接管阶段
一旦获得验证码，攻击者可在新设备上完成WhatsApp注册。此时原设备会自动登出（除非启用了多设备支持）。关键步骤如下：
在攻击者设备安装WhatsApp；
输入目标手机号；
请求验证码（系统向目标手机发送）；
通过前述手段获取验证码并输入；
完成注册，同步联系人列表与聊天历史（若备份可用）。
此时，攻击者完全控制账户，可发送任意消息，且收件人无法从界面区分真伪。
2.3 信任链扩散阶段
此阶段体现攻击的“智能性”。WOC通报显示，攻击者并非群发垃圾信息，而是精心构造上下文：
“Hey! Can you help me vote in this contest? Just click the link and enter the code they send you. It’s urgent – ends in 10 mins!”
消息包含短链接（如bit.ly/xxxx），指向伪造的“投票页面”。该页面要求用户输入手机号（预填）与8位验证码——实则为WhatsApp的6位验证码（页面前端可动态调整位数以匹配）。用户误以为是投票确认码，提交后即完成二次劫持。
由于消息来自可信联系人，且内容符合日常社交场景（如帮忙点赞、投票），受害者心理防线极易瓦解。WOC数据显示，此类消息的点击率高达37%，远超普通钓鱼邮件（<5%）。
3 技术实现细节与协议分析
3.1 WhatsApp注册与验证流程
WhatsApp使用基于手机号的注册模型，其核心流程如下（简化版）：
Client → Server: POST /v1/register { phone: "+48123456789" }
Server → Client: SMS with 6-digit code
Client → Server: POST /v1/verify { code: "123456" }
Server → Client: Registration successful, issue identity key pair
关键点在于：验证码仅用于证明手机号控制权，不验证用户身份。这意味着只要能接收验证码，即可注册任意号码。
3.2 伪造投票页面的技术构造
攻击者通常使用现成的钓鱼工具包（如Zphisher、SocialFish）快速部署仿冒页面。以下为简化示例（Python Flask）：
from flask import Flask, request, render_template_string
app = Flask(__name__)
PHISH_TEMPLATE = '''
<html>
<head><title>Vote Now!</title></head>
<body>
<h2>Contest Voting</h2>
<p>Enter the verification code sent to {{ phone }}:</p>
<form method="POST">
<input type="hidden" name="phone" value="{{ phone }}">
<input type="text" name="code" maxlength="8" required>
<button type="submit">Confirm Vote</button>
</form>
</body>
</html>
'''
@app.route('/vote')
def vote():
phone = request.args.get('phone', '+48XXXXXXXXX')
return render_template_string(PHISH_TEMPLATE, phone=phone)
@app.route('/vote', methods=['POST'])
def capture_code():
phone = request.form['phone']
code = request.form['code']
# 此处将(phone, code)发送至攻击者控制的服务器
log_phish_attempt(phone, code)
return "<h3>Thank you! Your vote is confirmed.</h3>"
def log_phish_attempt(phone, code):
with open("phish_log.txt", "a") as f:
f.write(f"{phone},{code}\n")
if __name__ == '__main__':
app.run(host='0.0.0.0', port=80)
该页面通过URL参数预填手机号，增强真实性。用户提交后，验证码被记录，攻击者可立即用于注册对应WhatsApp账户。
3.3 设备绑定与会话管理
WhatsApp允许用户在“设置 > 链接设备”中查看所有活跃会话。正常情况下，仅应有用户本人设备。但多数用户从未检查此列表，导致劫持长期未被发现。攻击者常保留原设备会话以维持“正常”状态，同时在后台设备发起钓鱼。
4 现有安全机制的局限性
尽管WhatsApp提供若干安全功能，但在AHFP场景下存在明显不足。
4.1 两步验证（Two-Step Verification）
WhatsApp的两步验证要求用户设置6位PIN，在每次重新验证手机号时额外输入。然而：
默认关闭，需手动启用；
用户常设简单PIN（如123456）或遗忘；
若攻击者在启用前完成劫持，则无效。
WOC调查显示，仅28%的波兰用户启用了该功能。
4.2 端到端加密的双刃剑效应
E2EE确保消息内容不被第三方读取，但也意味着：
WhatsApp服务器无法扫描消息中的恶意链接；
无法基于内容关键词（如“vote”、“urgent code”）触发风控；
异常行为（如短时间内向数百联系人发送相同消息）难以实时检测。
4.3 缺乏跨平台身份验证
当账户在新设备登录时，WhatsApp仅通知原设备“另一台设备已链接”，无二次确认机制（如邮箱验证、生物识别）。这使得SIM交换攻击几乎无法防御。
5 多层级防御框架设计与验证
针对上述漏洞，本文提出“终端-运营商-组织”三级防御体系。
5.1 终端用户防护
强制启用两步验证与PIN：用户应在设置中开启，并设置强PIN（建议字母+数字组合，尽管当前仅支持数字）。
定期检查链接设备：建议每月检查一次，移除未知设备。可编写脚本辅助：
# 模拟检查WhatsApp Web会话（需配合ADB或备份解析）
import json
def check_linked_devices(backup_path):
try:
with open(f"{backup_path}/linked_devices.json") as f:
devices = json.load(f)
for dev in devices:
print(f"Device: {dev['model']}, Last active: {dev['last_active']}")
# 此处可集成告警逻辑
except FileNotFoundError:
print("Backup not found or not parsed.")
绝不分享验证码：任何索要验证码的行为均为诈骗。应教育用户：验证码=账户控制权。
5.2 运营商侧防护
SIM变更多重验证：运营商应要求线下身份核验或生物识别才能变更SIM卡。波兰部分运营商已试点“SIM PIN”服务，变更需额外授权码。
延迟SIM激活：新SIM激活后24小时内限制敏感操作（如接收金融验证码），给予用户反应时间。
5.3 组织级响应
企业应将WhatsApp纳入安全政策：
禁止在工作群分享验证码、银行卡号等敏感信息；
部署移动端威胁防御（MTD）解决方案，如Lookout、Zimperium，可检测恶意短链接；
开展针对性钓鱼演练，模拟“同事求助”场景。
以下为短链接检测示例（基于VirusTotal API）：
import requests
def check_shortlink_safety(url):
api_key = "YOUR_VIRUSTOTAL_API_KEY"
params = {'apikey': api_key, 'resource': url}
response = requests.get('https://www.virustotal.com/vtapi/v2/url/report', params=params)
result = response.json()
if result['response_code'] == 1:
positives = result['positives']
total = result['total']
return f"Malicious: {positives}/{total} engines flagged."
else:
return "URL not analyzed yet."
# 示例：check_shortlink_safety("http://bit.ly/xxxx")
6 结论
本文系统研究了基于社交信任链的WhatsApp账户劫持与钓鱼攻击机制。研究表明，此类攻击的成功并非源于加密协议缺陷，而是对电信基础设施薄弱环节与人类认知偏差的综合利用。在端到端加密成为行业标准的背景下，传统内容过滤手段失效，安全重心必须前移至身份认证与行为监控层面。
防御不应依赖单一措施。用户需主动启用两步验证并警惕验证码索取；运营商需强化SIM管理流程；组织则应将IM安全纳入整体信息安全体系。未来研究可探索基于联邦学习的异常消息检测模型，在不破坏E2EE前提下实现群体风险预警。
本研究的局限性在于未获取真实攻击流量进行大规模行为分析，后续工作将与波兰WOC合作，基于脱敏日志构建更精确的检测算法。无论如何，面对日益精准的社交工程攻击，技术防御必须与安全意识教育同步推进。
编辑：芦笛（公共互联网反网络钓鱼工作组）
扫一扫
678
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
