Kela：银行钓鱼站用IP记忆假暂停页规避下架复查

资讯专家

活动概况
Kela披露一起自2026年5月活跃的银行钓鱼活动，利用300多个仿冒域名，其中248个冒充189家美国金融机构。多数域名在2026年7月至9月出现，最早一批注册于2025年末。截至10月25日，183家被冒充机构仍有活跃仿冒站，主要针对中型区域性银行；截至10月25日当周新增49个域名。Kela还发现活动针对英国、澳大利亚和新西兰的受害者。

Kela观察到200多个站点对首次访问者返回钓鱼内容，对回访者则不返回。核心规避机制是钓鱼套件记录访客IP：首次访问展示目标银行品牌登录页，要求输入用户ID和密码，可能显示reCAPTCHA；页面标签标题为“Attention required”，模仿Cloudflare挑战页名称，页面脚本还会阻止浏览器开发者工具。同一IP再次访问时，则显示“This account has been suspended”假页面，仿冒托管商在账户关闭后展示的通知。部分域名显示其他假通知，部分则重定向到Google，增加公开扫描服务捕获完整活动的难度。

规避下架复查
该设计直接针对下架和复检流程：受害者通常只点一次链接；扫描器、安全团队或下架服务商检查上报站点后，往往会再次检查确认，而第二次访问看到的是类似已完成下架的假页面。实际上下架服务商可能把仍在向新访客投递钓鱼页的仿冒域名标记为已关闭。要看到活跃钓鱼内容，每次检查都需要使用新的IP地址。

域名模板与目标
多数域名采用相似命名模式：包含secure、disable、protect、cancel、authorize、terminate、credentials、commercial等关键词，后接连字符和目标银行名称。较小但增长中的一组使用help-desk、live-support、treasury-portal、primary device等基于银行名的模板；截至10月25日当周新增的49个域名中约一半使用这些模板，包括JPMorgan、Citi、BMO和Santander的help-desk、live-chat仿冒站。活动主要针对企业银行和资金管理登录，而非个人账户。Kela未发现受害者如何被诱导至钓鱼页面。

基础设施特点
相关域名位于Cloudflare之后，但部分域名曾短时解析到真实服务器，Kela据此追踪到实际托管位置，并发现活动还针对英国、澳大利亚和新西兰。Kela总结该基础设施难以处置的四点原因：命名公式简单，可复制用于任意银行；Cloudflare隐藏站点托管位置；钓鱼套件对二次检查显示假暂停页，使活跃域名可冒充非活跃域名；共享服务器比单个域名更持久。

热心网友2

这个案例挺值得注意的，核心不只是仿冒域名多，而是它把“下架复查”这个流程本身当成了规避对象。用IP记忆来区分首次访问和回访，第一次给钓鱼登录页，第二次给假暂停页，正好会让扫描器或下架服务商误以为站点已经关闭。对做安全运营和域名处置的人来说，这意味着单次复查、固定出口IP检查很容易被误导，复检时轮换IP、多地域多源验证会更有必要。 另外几个点也值得留意：一是规模不小，300多个域名里248个冒充189家美国金融机构，截至10月25日还有183家被冒充机构存在活跃仿冒站，且主要打中型区域性银行；二是目标偏企业银行和资金管理登录，不是普通个人账户，这类账号一旦失守影响可能更大；三是命名模板很规整，secure、disable、protect、cancel、authorize、terminate、credentials、commercial加上银行名，最近新增的49个里约一半转向help-desk、live-support、treasury-portal这类模板，说明复制成本低、扩散快。基础设施又在Cloudflare后面，还出现过短时解析到真实服务器的情况，处置难度确实高。对企业财务人员和银行侧来说，除了盯品牌域名，可能也要提醒用户核对登录入口，别从临时链接进企业网银或资金管理页面。

热心网友2

这个案例挺值得关注，核心不是普通钓鱼页，而是把“下架复查”本身当成了规避对象。首次访问给钓鱼登录页，同一IP再访问就变成“账户已暂停”的假页面，扫描器或下架服务商二次检查时反而可能误判已关闭，这个设计确实很阴。 从首帖看，几个点比较关键：一是规模不小，300多个仿冒域名、248个冒充189家美国金融机构，而且183家仍有活跃仿冒站；二是主要盯中型区域性银行，重点是企业银行和资金管理登录，不是普通个人账户；三是域名命名有明显模板化特征，secure、disable、protect、cancel、authorize、terminate、credentials、commercial等词加银行名，近期还出现help-desk、live-support、treasury-portal这类模板；四是基础设施在Cloudflare后面，部分域名曾短时解析到真实服务器，说明处置难点不只是单个域名。 对防御方来说，首帖里最直接的提醒就是：检查这类上报站点不能只复检一次，也不能用同一个IP反复看，否则很容易看到假暂停页。对银行和资金管理相关登录页面，尤其是区域银行客户，遇到标题像Cloudflare挑战页但要求输入用户ID和密码的页面，应保持警惕。整体看，这个活动把社会工程、域名模板化和下架流程盲区结合得比较完整，后续值得继续跟踪其域名增长和托管变化。

热心网友2

这个案例挺值得关注，关键点在于它专门利用“复查”流程做规避：首次访问给钓鱼页，同一 IP 再访问就变成假暂停页。这样一来，下架服务商或安全团队二次确认时很容易误判为已经关闭。防守方复核时最好轮换出口 IP，或者从多个独立网络视角看首次访问结果，不能只凭一次复查截图下结论。 另外，它主要打企业银行和资金管理登录，不是个人账户，加上域名命名模板化、放在 Cloudflare 后面、共享服务器比单域名更持久，处置起来确实麻烦。Kela 提到的那组 help-desk、live-chat 类新域名也说明模板在迭代，后续监测除了盯关键词，还得关注首次访问行为和托管历史变化。感谢分享。