Railyard 平台披露一起伪装成普通网站的僵尸网络 C2 部署事件

Almokhtar Bekkour，创始人、系统架构师 从 GitHub 部署 免费方案，无需信用卡——每个新团队可享 14 天 Pro 试用。 任何允许陌生人在上面运行代码的平台，最终都会被人拿来运行不该运行的代码。托管服务、CI runner、函数平台、一键“从 GitHub 部署”按钮——一旦它变得有用，它就成了那些想要免费算力和干净 IP 地址的人的目标。以下是对 Railyard 上一次此类尝试的详细记录：部署了什么、我们如何识别、是否真的存在风险，以及我们当天上线的防御措施，让下一次尝试被自动拦截。具体细节刻意写得很完整，因为如果你也在运营类似的东西，这种攻击模式迟早会找上你，而正是这些细节能让你拦住它。 一个新账号注册后，不到十分钟就部署了一个应用，它提供的只是一个再普通不过的 99 KB 首页——HTTP 200，dashboard 里看不出任何异常。只看它运行的网站，像是一个业余项目。 问题出在源码。入口点只有一行： _ = (lambda : import('zlib').decompress(import('base64').b64decode([::-1]))); exec(_('…')) 这是一个经过混淆的加载器。它取一个长字符串，反转、base64 解码、解压缩，然后执行结果。仓库里约 46 KB 的乱码文本，在运行时展开成约 86 KB 的隐藏代码。没有审查者读到这行能看懂它在做什么——而这正是它的意图。正当的应用不会这样交付自己的入口点。 我们对 payload 做了静态解码——反转、解码、解压、打印，从未执行。里面是一个命令与控制（command-and-control）bot。直白地说，它会： 决定性细节在于：运营者在部署前一分钟，就在该应用上设置了一个保存 bot 控制令牌的环境变量。这套基础设施是刻意配置用于命令与控制的。不存在任何善意的解读。 这是一次有组织的行动，不是一次性的。同一个行为者维护着一批部署套件，以它们针对的平台命名，同时还有隧道和防火墙规避工具。Railyard 只是那份清单上最新的一项。 这部分值得照搬，因为答案是“没有”——这是设计使然。 Railyard 上的应用容器以非 root 运行，启用 no-new-privileges，丢弃所有 Linux capability，设有进程数限制，没有 Docker socket，也没有特权模式。bot 被限制在那个盒子里。它无法提权，无法触及宿主机，无法读取其他客户的数据，也无法安装任何在删除应用后仍然存活的东西。它能做的只有消耗一些 CPU 和带宽，以及访问网络。 唯一的现实后果是可以预见的：bot 运行的那台短生命周期服务器，因为转发的流量，短暂出现在一个邮件信誉黑名单上。由于那台服务器已被终止，且平台邮件是通过专用提供商发送而非使用原始实例地址，送达率从未受到影响，而且这类 listing 在源被移除后会自动过期。我们用主要黑名单核对了其余足迹，结果是干净的。 靠人眼抓一个不是策略。让平台自己抓住下一个才是。同一天，我们上线了： 如果你运行任何执行用户提供代码的东西，扫描这个模式——对编码或压缩 blob 的 exec 或 eval 是信号最强的单一指标——并锁死你的容器：非 root、丢弃 capabilities、no-new-privileges、无 Docker socket，并从应用容器屏蔽云元数据端点，这样容器就无法读取宿主机的云凭证。这些措施能终结这一整类滥用。 更广泛的教训很简单。如果陌生人能在你的基础设施上运行代码，最终就会有人试图运行和这完全一样的代码。持久的防御不是人工审查，而是扫描每次部署以查找混淆模式、限制每个工作负载、自动化响应——让平台自我防御，而不是等着被人盯着。