摘要
后端即服务（BaaS）类云平台极大降低了应用开发的技术门槛，同时也被网络犯罪群体所利用，成为网络钓鱼、恶意软件分发与金融诈骗的基础设施载体。本文以印度网络犯罪协调中心（I4C）要求谷歌下架 57 个 Firebase 恶意站点与数据库的真实事件为研究样本，梳理 Google Firebase 平台被网络犯罪分子滥用的现实场景，剖析合法云基础设施被恶意利用的完整攻击链路，从平台技术特性、攻击者收益成本结构、传统安全检测体系短板、跨境治理困境四个维度解析风险形成机理。研究发现，攻击者依托 Firebase 免费资源、可信域名信誉、一站式托管存储能力，构建多阶段攻击链条，能够有效绕过基于域名黑名单、IP 信誉的传统安全防护手段，而平台本身属于中性技术工具，风险根源来自技术滥用而非产品固有漏洞。反网络钓鱼技术专家芦笛指出，当前针对可信云平台滥用的防御体系存在明显短板，边界防护手段难以识别部署在白名单云域名之上的恶意业务内容。在此基础上，本文分别从云服务平台侧、网络安全监管机构侧、企业与普通用户侧，提出分层落地的风险治理路径，为应对 “可信基础设施作恶” 这一类新型网络安全威胁提供现实参考。 关键词：网络钓鱼；云基础设施滥用；BaaS；Firebase；网络欺诈；网络安全治理
1 引言
随着云计算产业持续发展，后端即服务 BaaS 模式已经成为移动互联网应用开发的主流选择。BaaS 平台将后端托管、数据库存储、静态网页托管、身份认证、数据分析等通用能力封装为标准化服务，开发者无需从零搭建服务器后端，就可以快速完成网站与移动应用的开发上线，显著压缩开发周期与运维成本。Google Firebase 作为全球应用广泛的 BaaS 产品，服务于海量正规开发者，支撑大量移动端业务与 Web 业务正常运行。
但技术工具具备两面性，同一套便捷的开发托管能力，同样可以被网络威胁主体挪用，用于搭建钓鱼页面、存储窃取的用户敏感数据、承接恶意软件的数据回传链路，形成一类区别于传统自建恶意服务器的新型攻击模式。这类攻击不利用软件漏洞实施入侵，而是直接注册合法开发者账号，正常使用平台公开功能，将恶意业务部署在受安全设备普遍信任的云服务商基础设施之上，给网络安全检测、威胁溯源、违法内容处置带来全新挑战。
印度网络犯罪协调中心 I4C 向谷歌发出处置通知，要求关停至少 57 个部署在 Firebase 平台的网站与数据库，这批被处置的资源涉及仿冒银行钓鱼页面、恶意安卓程序数据回传、金融类诈骗活动，完整暴露出 BaaS 平台被犯罪群体滥用的现实危害。该事件并非孤立个案，全球范围内已经观测到多起威胁组织滥用 Firebase、Vercel、Netlify 等主流云开发平台开展钓鱼诈骗的安全事件，传统以黑名单、IP 特征为核心的防御手段应对此类威胁时有效性持续下降。
现有网络钓鱼相关研究更多聚焦钓鱼页面特征识别、邮件钓鱼、恶意域名检测等方向，针对中性云平台被合法账号恶意使用这一特殊场景的系统性分析相对有限，很多安全实践依旧默认恶意站点一定运行在可疑域名或者黑产控制的服务器之上，忽略可信云二级域名下的恶意内容风险。本文立足于该真实公开事件，完整还原攻击运作模式，厘清风险生成逻辑，客观区分平台产品缺陷与技术滥用问题，不做夸大化推演，从技术、管理、治理多个层面展开分析，探索适配该类威胁的治理方案。
2 Google Firebase 平台基础能力与滥用事件事实梳理
2.1 Firebase 平台核心业务能力
Firebase 是谷歌推出的面向 Web 与移动端的云开发平台，归属于谷歌云业务板块，定位为后端即服务产品。它对外提供的核心能力包含静态网站托管服务、实时云数据库、用户身份认证接口、云端存储、应用数据分析等模块。普通用户注册谷歌账号之后，就可以创建 Firebase 项目，免费额度内即可完成网页部署、数据库创建、数据读写等全套操作。
对于正规开发者而言，这套工具的价值在于屏蔽服务器底层运维细节。开发者只需要完成前端业务逻辑编写，网页托管、数据持久化存储、多终端数据同步、CDN 全球分发全部交由平台完成，大幅降低中小开发者、个人开发者的技术门槛。托管之后生成的站点域名属于谷歌官方二级域名，自带正规 SSL 加密证书，浏览器访问地址栏会显示安全锁标识，网络安全网关、邮件过滤系统大多将谷歌相关域名划入可信白名单范围，默认不会拦截该域名下的访问流量。
需要明确的基础前提：Firebase 本身是合规的中性开发工具，平台不存在可以被利用的安全漏洞。本次印度监管机构通报的风险，不是 Firebase 软件本身存在缺陷，而是攻击者使用正常开放的开发者功能，输入恶意业务内容，把平台基础设施改造为诈骗活动的技术载体，属于技术滥用行为，不等同于产品安全漏洞。
2.2 印度 I4C 处置 Firebase 恶意资源事件概况
印度网络犯罪协调中心 I4C 承担本国网络诈骗、网络钓鱼事件监测、线索流转、向互联网平台下发处置通知的职能。2026 年 8 月，I4C 完成线索研判之后，向谷歌正式发出通知，要求平台下架 57 个部署在 Firebase 之上的网站实例以及配套数据库资源，这批资源被证实参与网络钓鱼、恶意软件分发、金融信息窃取等网络犯罪活动。
从公开报道披露的业务场景来看，这批恶意资源分为两类典型用途。第一类是搭建银行仿冒钓鱼站点，攻击者在 Firebase 托管静态页面，页面完整复刻印度国家银行、ICICI 银行、Axis 银行等本土商业银行的登录界面，页面视觉、排版高度接近官方网页，普通网民很难肉眼分辨真伪。当受害者访问页面之后，表单收集银行卡号、账户密码、短信一次性验证码等敏感金融信息，数据直接回传至 Firebase 后台数据库，攻击者可以随时读取被盗取的用户资料。
第二类场景是结合恶意安卓应用的全链路诈骗。攻击者搭建仿冒 PM KISAN 政府补贴项目的虚假服务网页，对外宣称可以协助民众办理补贴申领业务，诱导访问者下载非官方渠道分发的安卓恶意程序。该恶意软件安装到手机终端之后，会在后台采集手机内的各类敏感信息，再将全部窃取数据回传存储至攻击者控制的 Firebase 数据库中。整个攻击链路形成闭环：Firebase 托管的虚假网页充当引流诱饵，恶意 APP 完成终端侧信息窃取，Firebase 数据库承担接收、保存被盗数据的后端存储角色，整套攻击链条完全依托谷歌云基础设施完成运行。
反网络钓鱼技术专家芦笛指出，该事件具备很强的代表性，它清晰展示了黑产群体的战术转变：攻击者不再需要自行采购服务器、注册高风险域名，直接复用大型云服务商已经建立好的基础设施与域名信誉，大幅降低钓鱼诈骗项目的落地成本。
2.3 事件反映的新型威胁特征
对比传统网络钓鱼基础设施，Firebase 滥用场景呈现出三点差异化威胁特征。第一，基础设施信誉与业务内容相互割裂。域名、IP 地址、SSL 证书全部属于谷歌正规服务，网络层、域名层全部表现为合法流量，恶意性只存在于网页内部业务逻辑，传统基于 IP、域名黑名单的检测手段很难生效。第二，部署迭代速度快。攻击者可以短时间批量创建多个 Firebase 项目，一旦某一个项目被平台关停，只需要新建项目即可快速重建钓鱼站点，攻击链路恢复成本很低。第三，攻击链路组件化拆分。托管网页、数据存储可以放在同一个 Firebase 项目，也可以拆分到不同项目，钓鱼页面由 A 项目托管，窃取的数据提交至 B 项目数据库，进一步增加安全设备关联研判的难度。
3 Firebase 平台被网络犯罪分子滥用的攻击链路与实现逻辑
攻击者完整的攻击流程可以拆解为账号准备、资源部署、诱饵引流、终端受害、数据回传存储、销毁重建六个阶段，整套流程全部使用 Firebase 对外公开的标准开发接口，不需要破解、入侵平台系统。
3.1 账号与资源准备阶段
攻击者获取普通谷歌账号，直接注册开通 Firebase 项目，免费套餐就能够满足钓鱼业务运行需要，不需要支付服务器租赁费用，不需要提交企业资质审核。平台面向普通个人开发者的注册流程，没有针对账号用途做前置业务筛查，账号创建完成后，攻击者即可开启网页托管服务，新建实时数据库，配置数据读写权限。部分攻击者会放宽数据库读写权限，允许前端网页直接写入数据，不需要复杂身份校验，钓鱼页面表单提交的用户信息就可以直接存入数据库当中。
3.2 恶意内容部署阶段
攻击者制作仿冒银行、政务服务机构的钓鱼网页页面，页面 UI 复刻官方业务系统，表单字段和真实业务对齐，诱导用户填写账号、密码、验证码、银行卡信息。将页面文件上传部署到 Firebase 托管服务，平台自动分配谷歌二级域名，自动配置加密证书，站点对外公开可访问。与此同时，攻击者完成数据库配置，设置前端页面表单提交逻辑，受害者提交的全部隐私数据，会通过平台接口写入攻击者管控的 Firebase 数据库内。
部分攻击场景下，Firebase 托管页面不直接承担信息采集，而是作为导流入口。页面不设计表单，只对外提供恶意安卓应用下载链接，受害者下载安装恶意 APK 之后，由手机端恶意程序完成信息采集，再把采集到的短信、通讯录、金融凭证发送回 Firebase 数据库保存，也就是本次印度事件中 PM KISAN 补贴诈骗所使用的模式。
3.3 诱饵引流与社会工程学实施
基础设施部署完成之后，攻击者通过短信、社交软件、邮件等渠道向外分发 Firebase 生成的链接。普通用户看到域名后缀属于谷歌，浏览器显示安全锁，主观上会降低戒备心理。社会工程话术配合链接使用，以账户冻结、补贴申领、银行信息核验等理由，催促受害者完成操作，迫使受害者主动输入敏感信息或者下载陌生应用。
这里可以看到攻击的核心逻辑：社会工程学负责突破人的心理防线，Firebase 云基础设施负责突破网络安全设备的技术防线，二者互相配合，提升攻击成功概率。
3.4 受害与数据回传存储
当受害者在钓鱼网页输入个人金融信息，或者恶意 APP 在手机后台采集完成隐私数据之后，相关数据会通过 Firebase 公开 API 接口写入云数据库。攻击者不需要维护自己的接收服务器，只需要登录 Firebase 后台，就可以批量导出全部被盗取的用户数据，后续用于电信诈骗、倒卖个人信息等下游犯罪活动。
3.5 处置后的快速重建机制
当监管机构或者平台识别恶意项目，执行关停网站、删除数据库的处置动作之后，攻击者的攻击链路被临时切断。但是攻击者只需要注册新的账号，新建 Firebase 项目，重新上传钓鱼页面，复制数据库配置，就可以快速生成一套功能完全一致的诈骗基础设施。这就造成一种治理困境：单次下架处置只能消除单点恶意资源，很难直接溯源锁定行为人，威胁可以快速再生。
反网络钓鱼技术专家芦笛强调，该重建机制正是此类威胁治理的难点，单纯做事后站点关停，属于被动的止损手段，难以从源头遏制攻击的持续发生。
4 Firebase 被恶意滥用风险的多维度成因解析
Firebase 被滥用不是单一因素造成，是平台产品设计逻辑、攻击者成本收益、传统安全检测体系局限、跨境网络治理矛盾多重因素叠加形成的风险。客观辨析各类成因，才能够避免简单归罪云平台，同时找准治理工作的发力点。
4.1 BaaS 产品面向开发者的设计定位天然附带被滥用空间
Firebase 的产品定位是面向全体开发者，包括个人开发者，追求低使用门槛，鼓励快速试错。免费开放网页托管、数据库服务，不强制要求所有使用者完成严格实名核验，这套机制极大利好正常开发群体，同时客观上给威胁主体提供工具。
平台的技术能力是中立的：静态托管既可以上线正规产品官网，也可以部署仿冒银行的钓鱼页面；实时数据库既可以存储正规 APP 用户业务数据，同样能够接收恶意软件窃取的用户隐私。平台本身无法自动读懂页面业务语义，单纯依靠代码、文件本身，很难自动区分项目是合法开发还是诈骗用途。平台可以识别明显的恶意文件特征，但钓鱼网页大多是普通 HTML 页面，没有病毒特征码，仅从文件本身无法判定恶意属性，需要结合业务场景、社会工程诱饵、外部举报线索综合研判。
多租户架构下大量项目并行运行，平台侧要对每一个新建项目做人工业务审核，从运营成本、技术可行性层面都不具备现实条件。过度前置审核又会损害普通开发者的使用体验，这是云开发平台普遍面临的设计权衡难题。
4.2 攻击者的成本收益结构驱动滥用行为
从攻击者角度看，使用 Firebase 这类 BaaS 平台开展诈骗，对比传统自建恶意服务器，具备非常显著的优势。第一是经济成本极低，免费额度即可支撑小规模钓鱼活动，不需要购买服务器、域名，减少黑产基础设施采购开销。第二是基础设施信誉优势，托管在谷歌域名之下，很多企业防火墙、邮件网关不会直接拦截域名，恶意链接更容易送达普通用户。第三是全球分发能力，依托谷歌 CDN，钓鱼页面访问速度稳定，不受单地域网络环境限制。第四是运维成本低，数据库、托管、证书全部由平台维护，攻击者只需要专注制作钓鱼页面与社会工程话术，不需要处理服务器运维故障。
较低的投入，搭配窃取金融信息之后带来的高额非法收益，形成正向激励，促使网络犯罪群体持续挖掘主流云平台的滥用可能性。
4.3 传统网络钓鱼检测体系存在固有短板
传统网络钓鱼防护技术大多建立在一个基础假设之上：恶意站点会使用可疑域名、高风险 IP 地址，安全设备依靠域名黑名单、IP 信誉库、恶意文件特征码实现拦截。但当恶意内容部署在知名服务商的可信二级域名上，这套检测逻辑就会出现失效区间。
域名本身属于白名单，不能直接将整个 Firebase 域名全部拉黑，否则会误伤全球海量正规业务，因此防护设备无法简单做域名层面阻断，必须下沉到 URL 路径、页面内部业务逻辑层面做内容检测。而网页内容检测面临现实困难：钓鱼页面静态特征可以被攻击者频繁修改，页面 UI 可以快速换皮，每次新建项目 URL 路径完全随机，很难提取稳定的静态签名。
很多安全产品侧重网络层流量分析，对网页内部表单提交行为、页面社会工程话术、后端数据库写入行为的感知能力不足。反网络钓鱼技术专家芦笛指出，大量防护系统把注意力放在识别攻击者自建的黑产域名，对于大型云平台二级域名之下的恶意内容检测投入不足，形成防护盲区。
4.4 跨境网络治理带来的处置与溯源困境
Firebase 属于谷歌旗下服务，企业主体位于境外，而受害、监管线索发生在印度，属于跨境网络安全事件。I4C 作为印度国内监管机构，没有权限直接操作境外云平台的数据资源，只能向平台企业发出通知，由平台企业按照自身规则执行关停处置。
处置环节存在时延：监管机构完成线索取证、提交通知，平台完成证据核验、执行项目关停，中间存在时间窗口，在窗口期内钓鱼站点持续对外提供服务，会持续产生新受害者。
溯源层面同样存在障碍。虽然平台掌握账号注册日志、访问日志，但跨境调取账号身份信息需要遵循司法协作流程，流程周期长，网络犯罪分子又会尽可能使用匿名账号，进一步提升溯源定位实际行为人难度。站点可以快速重建，但是溯源抓捕行为人链路周期很长，两者速度严重不对等，造成打击治理的现实阻力。
5 可信云平台滥用型网络钓鱼威胁的治理路径
针对 Firebase 被滥用代表的 “合法基础设施作恶” 威胁，不存在单一技术手段可以彻底消除风险，需要构建平台、监管机构、企业机构、普通用户多方协同的分层治理体系，区分事前预防、事中检测处置、事后溯源止损不同环节，兼顾互联网服务创新发展与网络风险防控。
5.1 云服务平台侧优化管控机制
云平台不能为了杜绝滥用直接取消面向个人开发者的免费能力，会严重伤害正常数字创新生态，应当在不破坏基础可用性的前提下，优化风险识别与管控能力。
第一，建立异常行为识别规则，而非单纯依靠静态文件查杀。针对短时间批量创建大量新项目、频繁部署网页、数据库配置为允许公开匿名写入、页面包含大量金融机构名称关键词等组合行为特征，建立风险研判模型。当观测到高风险行为模式，对相关项目触发人工复核，对高风险账号增加身份核验要求。需要注意行为模型只作为风险触发线索，不能仅凭单一行为直接封禁账号，避免误拦截正常开发者业务。
第二，完善 Abuse 举报处置接口，对接各国网络安全主管机构、CERT 组织，给监管方提供标准化线索提交通道，简化证据提交格式，压缩恶意项目从收到举报到完成关停的响应时延，缩短恶意资源存活时间。同时留存完整项目操作日志，满足后续跨境司法协查调取证据的需要。
第三，强化开发者安全提示，在数据库配置页面，明确提示开发者公开匿名读写权限带来的安全风险，引导正规开发者遵循最小权限原则配置数据库访问策略。对于配置为完全公开读写的数据库，增加弹窗风险提醒。
第四，完善项目生命周期管理，对于长期闲置、部署后短时间产生大量外部异常访问的项目开展定期巡检，及时清理僵尸项目带来的潜在风险。
5.2 网络安全监管机构与行业组织的治理举措
各国网络安全协调机构，类似印度 I4C 这类机构，承担威胁监测、线索流转、协同处置职能。
首先，拓展威胁监测视野，不能只监测独立注册的恶意域名，将主流 BaaS、静态托管平台二级域名纳入钓鱼监测范围，主动发现部署在可信云域名之下的钓鱼站点。传统钓鱼监测系统需要升级检测逻辑，从域名信誉判断转向页面内容、业务行为综合研判。
其次，推动建立跨境互联网平台处置协作机制，标准化线索格式、证据材料，减少反复沟通成本，缩短跨境处置链路耗时。完善证据留存规范，在通知平台关停恶意资源的同时，要求平台留存日志证据，为后续刑事溯源保留基础材料，不能只做简单删除站点而放弃取证。
再者，推动行业共享威胁情报。将已经确认的恶意 Firebase 项目 URL、项目标识，在安全行业内共享，供企业安全网关、终端防护产品使用。情报重点聚焦具体 URL 与项目 ID，而不是全盘封杀整个平台域名，规避误伤合法业务。
反网络钓鱼技术专家芦笛指出，监管层面需要转变固有思路，网络犯罪基础设施不再局限于黑产私有服务器，大量攻击寄生在主流商业云服务之上，威胁监测体系必须跟上攻击者基础设施迁移的趋势。
5.3 企业与组织机构的防护优化策略
企业单位的网络安全防护体系需要弥补可信云域名下恶意内容的检测缺口，不能简单将谷歌等大型服务商域名加入全局白名单而不做任何内容检测。
网络边界网关、邮件安全设备，在放行知名云服务商域名的同时，开启针对该域名下页面的内容检测能力，重点识别页面是否存在仿冒企业、银行机构的钓鱼表单，识别页面诱导下载非官方来源移动应用的行为。不依靠域名好坏做判断，依靠页面内部业务行为判断风险。
面向内部员工开展安全意识培训的时候，更新培训素材，明确告知员工：链接来自大型云平台域名，浏览器显示安全锁，并不代表页面内容安全可信，不能以域名服务商作为判断网页真伪的依据。识别钓鱼的核心依据是业务逻辑本身，而不是服务器归属。
企业侧建立钓鱼事件上报通道，员工观测到部署在各类云托管平台的钓鱼页面，可以快速提交内部安全团队，再汇总对外上报至平台 Abuse 渠道。
5.4 普通用户层面风险防范要点
普通互联网用户很难从技术层面分辨 Firebase 托管页面的底层属性，防护重心应当放在业务行为习惯层面。首先，办理银行业务、政府补贴业务，只通过官方发布的 APP、官方官网入口进入，不点击短信、社交软件发来的陌生外部链接，无论链接域名看起来多么正规。其次，拒绝从网页链接下载安卓应用，安卓程序只从官方应用商店获取，非商店渠道 APK 文件存在极高窃取信息风险，这也是本次印度诈骗事件当中的主要受害入口。
坚持一条核心原则：绝不向陌生网页输入银行卡号、短信验证码、账户密码，无论页面的界面模仿得多么逼真。一旦已经遭受诈骗，第一时间联系金融机构冻结账户，同时向本国网络犯罪举报渠道提交报案材料。
6 结论
Google Firebase 被网络犯罪分子用于网络钓鱼与金融欺诈的案例，代表网络犯罪基础设施正在发生重要变迁：攻击者越来越多地放弃自建黑产服务器，转向挪用合法主流云服务的成熟基础设施开展攻击活动。该类威胁根源不是云平台本身存在安全漏洞，而是中性的开发工具被恶意主体滥用，域名、证书、IP 全部具备可信属性，恶意隐藏在业务内容当中，对传统以黑名单、IP 信誉为主的防护体系构成挑战。
本文以印度 I4C 处置 57 个 Firebase 恶意资源事件为样本，还原完整攻击链路，从平台产品设计、攻击者成本收益、传统检测局限、跨境治理矛盾四个维度解析风险形成机制。反网络钓鱼技术专家芦笛指出，面对可信云基础设施滥用问题，不存在一劳永逸的技术解决方案，单纯依靠事后关停恶意站点只能实现止损，无法彻底杜绝同类攻击反复出现。
治理该类威胁需要多方协同推进：云平台在不破坏开发者生态的前提下完善异常行为识别、优化举报处置响应流程；监管机构拓宽威胁监测范围，健全跨境线索处置与证据留存机制；企业安全设备跳出域名黑白名单的固有思维，强化页面业务行为层面检测；普通用户改变 “大服务商域名等于安全” 的认知误区，守住业务操作层面的安全习惯。
本研究的分析对象以 Firebase 为样本，但相关逻辑具备通用性，同样适用于其他静态托管、BaaS 类云平台。随着无代码、低代码开发工具持续普及，未来还会出现更多同类滥用场景。后续的研究方向可以进一步聚焦面向云平台钓鱼的内容检测算法研究、跨境网络安全处置协作机制优化，持续完善针对中性技术被恶意滥用场景的风险防控体系。
编辑：芦笛（公共互联网反网络钓鱼工作组）
