夭寿啦~ 2026 年最抽象的安全事故出现了……🐶
10 月 7 日，日本软银旗下的云平台（IDCF Cloud）遭遇勒索软件攻击，
黑客攻击了它家的云基础设施，植入勒索软件，加密了整个区域的宿主机与虚拟机磁盘（被加密的主存储数据 3.6 PB + 被抹除的备份总容量是 41.5 PB），还留下了 225 封勒索信。
但是呢，IDCF 运维团队的操作把黑客给整懵了。
攻击发生后长达 7 个小时，他们化身重启仙人，反复重启故障虚拟机、重置控制台密码，就是没发现出现问题，更没看到勒索信文件… 
结果还是有不少客户提交工单，说无法启动虚拟机，运维才后知后觉 
②
黑客等不到回应，被搞破防了，于是直接篡改了云管理控制台……
黑色背景，标题红色加粗 + 正文绿色，这下总归显眼了：
标题大字：IDCF CLOUD INFRASTRUCTURE SEIZED（IDCF 云基础设施已被我们接管）
核心标语：YOUR CLOUD IS OURS.（你们的云，现在归我们了）
③ 黑客的嘲讽解释
“2026.10.7，只用 7 分钟，我们就把东日本一区全部数据加密。拿下这套国家级云平台。但接下来整整 7 小时，你们运维居然找不到我们留下的勒索通知。”
“我们本来不打算这么高调公开。没想到你们处置能力这么差。你们在 04:25 才察觉到异常，之后只会反复重置控制台密码。”
写给 IDCF 网络运维中心（NOC）的：
“整整 7 小时，你们一直在 vCenter 里反复尝试重启已经死掉的虚拟机、反复开机，这些机器根本不可能再启动。你们却一直没发现我们放在宿主机上的勒索文件。”
👉 黑客直接贴心地给出查找勒索信的操作命令（绿色代码块）
任选一台 JE0 集群 ESXi 宿主机
打开 SSH 或者 DCUI shell（你们今早刚改了密码，你们自己知道）
执行命令查看 RECOVER-INFO.txt
黑客说明：从凌晨 3 点开始，225 套存储根目录全都放了这份勒索信文件。
“客户比你们运维更早发现故障。日本时间 08:34 前，第 75 号工单就报：虚拟机无法启动。”
“客户基础设施已被加密，快照已销毁。恢复唯一途径，就是和我们谈判（支付赎金）。”
“就像宿主机上的勒索文件写的那样，情况没有变化。只是你们浪费时间找不到勒索信的这段时间，赎金截止期限在缩短。”
“没有公开联系方式。联系我们的方法写在 RECOVER-INFO.txt 里面，存在你们自己的存储盘上，需要 root 权限才能读取。”
“你们每花一小时「排查故障」而不联系我们，你们的客户就多一小时体会：国家级云平台，在备份全部被毁之后是什么样子。”
④
出事之后，IDCF Cloud 在 10 月 8 日立刻成立应急指挥部，把被攻陷的东日本一区网络切断隔离，还临时关停全平台管理控制台，防止黑客横向扩散。同时联系外部安全机构排查入侵源头，一对一通知 495 家受影响客户。
后来还明确告知客户：被攻击区域内服务商这边的数据基本救不回来，没法解密恢复，只能让客户依靠自己独立备份，在别的地方重新搭建业务。公司没有支付赎金，持续对外发布事故进展公告，同步事件调查情况。
（参考：IDCF，本文经由 AI 优化）
文章原文
