#安全资讯 黑客遇到日本企业都很无奈：软银旗下云平台 IDCF 被黑客部署勒索软件，运维竟然超过 7 小时都没发现勒索信，还在尝试不停地戳电源重启。最后黑客迫于无奈只能拿下 IDCF 官网并挂上勒索信，从勒索信里可以看到黑客非常生气也非常无奈。IDCF 的操作包括：7 小时内不停地尝试重启、修改密码、批量关闭客户提交的问题工单 (还要求提交满意度评价)、不公布事件。黑客并不想如此高调，但留下的 225 份勒索信都没被运维发现，黑客持续在后台监控运维操作，在没有办法后黑客只能在官网挂上勒索信以及代替 IDCF 安全公告。查看全文：https://ourl.co/127250
日本软银集团旗下的云计算平台 IDCF 在 2026 年 10 月 7 日遭到勒索软件攻击，随后该平台发生故障并导致东日本第 1 区域部分虚拟服务器停机且无法重启。IDCF 随后发布公告确认四个分区受影响，这些分区为 495 家企业和日本地方政府提供服务。
众所周知日本的 IT 产业相对来说有些落后，但按理说像是云计算这类专业平台应该还是有比较深厚的技术积累的。问题在于，对 IDCF 发起攻击的黑客也遇到麻烦，黑客在成功拿下内部权限后将勒索信放在每个虚拟机的根目录。
黑客留下 225 份勒索信，只要运维工程师检查任意 ESXi 服务器上的虚拟机应该都可以发现异常文件。然后在服务中断 7 个小时内，IDCF 运维工程师仍然没有发现勒索信，还以为是常规问题于是不断地尝试重启虚拟机，而黑客可以看到运维工程师的全程操作。
黑客本来并不想如此高调，但最后实在没办法只能将 IDCF 官方网站拿下并挂上勒索信，提醒 IDCF 运维工程师这是勒索软件攻击，不要再继续戳那该死的电源，
黑客在勒索信里还提到，IDCF 的客户早就发现服务器异常并提交工单寻求技术支持，报告的问题包括无法启动虚拟机实例、虚拟服务器已宕机等，但 IDCF 选择的应对方式竟然是批量关闭这些工单，更讽刺的是还收集客户对工单处理的满意度评分。
黑客吐槽 IDCF 始终不发异常公告，难道是等着自己 (指黑客) 帮忙宣布消息吗？事实证明最终也确实是黑客帮着宣布的，因为超过 7 小时运维工程师也没发现勒索信，黑客拿下 IDCF 官网并挂上勒索信后 IDCF 才发布公告。
IDCF CLOUD // 基础设施已被接管
你们的云，现在是我们的。
2026 年 10 月 7 日。七分钟。整整七分钟，就够把你们整个东日本一区变成密文。七分钟拆掉一片国家级云——而这七小时里，你们甚至没能找到我们留下的那条消息，上面写着我们已经得手。我们通常不会这样公开炫耀。没想到你们的反应这么糟。你们 04:25 才发现。从那以后就一直在轮换控制台密码。
- 239：已触及的虚拟化主机
- 225/225：数据存储已加密
- 16,600+：虚拟机磁盘已封存
- 3.6 PB：主存储
- 554,153：快照已销毁
- 41.5 PB：备份容量已消失
// 致 IDCF 网络运维中心——对，说的就是你们
七个小时。整整七个小时，你们一直在 vCenter 里戳那些已经死掉的虚拟机，给再也不会启动的机器强制按电源，却还是没找到我们留在你们自己虚拟化主机上的消息。我们留了 225 份。我们故意让它不可能被错过。你们还是错过了。
现在就去看。方法如下：
在 JE0 里随便挑一台 ESXi 主机。任何集群。随便哪一台——上面都有。
打开 SSH 或 DCUI shell。你们今早刚轮换过密码，所以你们知道密码。
运行：
# ls -l /vmfs/volumes/*/RECOVER-INFO.txt
# cat /vmfs/volumes/$(ls /vmfs/volumes | head -1)/RECOVER-INFO.txt
就在那儿。从今天凌晨 03:00 起，它就放在每一块数据存储的根目录里。里面写的全是真的。里面的计时也是真的。
// 你们什么都没读的时候
你们的客户比你们先搞清楚了。当天第 75 号支持工单在日本时间 08:34 之前就到了——“Unable to start VM instance”（无法启动虚拟机实例）、“仮想サーバがダウンしています”（虚拟服务器已宕机），东日本一区全部实例，自 03:40 起持续发生。你们的支持台用模板把工单关掉，还在收集“ふつう”（一般）的满意度评分。你们到现在还没发过一条事故通知。要我们等晚间新闻替你们宣布吗？
客户的基础设施已被加密，快照已被破坏。恢复的唯一办法，是与我们交涉。