前往网站首页 / 一次 Cloudflare Worker 被劫持的完整记录

一次 Cloudflare Worker 被劫持的完整记录

2026-10-19

起因:一段网上抄来的 Worker 代码

事情要从 58 天前说起。当时我在网上看到一段 Cloudflare Worker 代码,功能看起来挺实用,就顺手复制粘贴部署到了自己的 Cloudflare 账户里。

这是第一个错误:我没有仔细审查这段代码,也没有意识到部署 Worker 时可能涉及的权限问题。

Worker 部署本身没问题,问题出在我当时使用的 API 密钥或者部署方式上。攻击者很可能就是通过这个环节拿到了我的 Cloudflare API 凭证,或者在我复制的代码里本身就埋了后门。

发现:主域名被注入恶意脚本

最近我在浏览器里查看自己网站主域名的 HTML 源码时,发现了一段可疑的 jаvascript 代码。这段代码会去请求 r2.mydomain.com/__rpc_proxy__,然后从某个区块链合约地址拉取一段 Base64 编码的脚本并执行。

更早之前,我访问这个域名时还遇到过一个假的“Cloudflare 验证码”页面,提示我右键、在终端里粘贴并回车完成验证。我当时照做了——现在回头看,这是典型的 ClickFix 攻击,那个“验证码”是伪造的,目的是让我亲手在电脑上运行恶意命令。

排查:为什么开了小黄云才有恶意代码

关键线索出现在这里:关闭小黄云(Cloudflare 代理)后,恶意代码消失;开启小黄云后,恶意代码又出现。

这个差异直接排除了源服务器被植入文件的可能。如果源站文件被黑,无论开不开代理,恶意代码都应该存在。但实际情况是“开代理才有”,说明恶意代码是在 Cloudflare 边缘层被注入的。

顺着这条线索,我登录 Cloudflare 后台检查,发现了几个异常:

攻击链还原

把各个线索拼起来,整个攻击过程大概是这样的:

  1. 部署Worker代码:我部署了一段从网上抄来的 Worker 代码。攻击者通过这个环节获取了我的 Cloudflare API 凭证,或者代码本身就有问题。

  2. 攻击者利用窃取的凭证,在我的账户里创建了一个名为 my-worker 的恶意 Worker,并把它绑定到我的域名上。

  3. 恶意 Worker 拦截经过 Cloudflare 边缘的 HTML 响应,向页面注入一段加载器脚本。

  4. 加载器脚本请求 r2.mydoain.com/__rpc_proxy__,从一个区块链合约地址拉取第二阶段恶意代码。

  5. 第二阶段代码连接 mytds1029380.com/jsrepo,下载真正的恶意载荷。

  6. 攻击者还做了扫尾:清理审计日志、禁用日志记录,尽量不留下痕迹。

至于那个假的 Cloudflare 验证码,是攻击链的另一环,用来诱导我手动在电脑上执行恶意命令。

解决办法

确认问题出在恶意 Worker 后,处理起来就明确了:

  1. 删除恶意 Worker:在 Cloudflare 后台找到 my-worker,直接删除,并移除它绑定的路由。

  2. 轮换所有 API 密钥:在 Cloudflare 的 API Tokens 页面,删除所有可疑 Token,重新生成新的密钥,确保旧密钥全部失效。

  3. 检查审计日志:翻看账户操作记录,确认没有其他异常操作。

  4. 检查电脑安全:因为之前执行过假的验证码操作,我用另一台干净设备修改了重要账号密码,并对电脑做了全盘扫描。最稳妥的做法是备份数据后重装系统。

删除 Worker 后,主域名的恶意代码立刻消失了。开不开小黄云都正常。

防范办法

这次踩坑之后,我总结了几个必须遵守的原则:

关于 Worker 和第三方代码

关于 Cloudflare 账户安全

关于浏览器端的异常

关于网站内容监控

最后

这次问题的根源,是之前那次图方便的代码部署。一个看似不起眼的操作,给了攻击者进入我 Cloudflare 账户的入口。好在最终定位到了恶意 Worker,删除后问题解决。

写这篇记录,一方面是给自己留个教训,另一方面也是提醒看到这篇文章的人:Cloudflare Worker 很强大,但部署前一定要清楚自己在运行什么代码,账户密钥的权限也要收好。 攻击者不一定直接黑你的服务器,他们更倾向于利用你自己账户里的权限,借你的手完成攻击。

返回网站