软银旗下IDCF Cloud遭勒索攻击，495家客户受影响，黑客公开嘲讽运维应急处置。

10月7日凌晨3点40分，日本软银旗下的云服务商IDC Frontier（IDCF Cloud）东日本第1区域突发大面积故障。众多客户发现自己的虚拟机无法启动，控制台密码被重置，工单像雪片一样涌进来。而彼时，机房里的运维人员还在做一件事——反复重启那些根本不可能再启动的服务器。

直到客户比他们更早发现问题，直到黑客把嘲讽信息直接打在了云管理控制台的首页上，这场持续7小时的事故才被”确认”。这不是一场零日漏洞攻防战，而是一次教科书级别的安全应急响应失败。更值得所有做云、做运维、做安全的人警醒：当攻击者已经在你家里待了7小时，而你连门都没发现被撬开，问题就不只是技术了。

一、事故回放：一场7分钟与7小时的荒诞对照

根据日本ITmedia NEWS报道和安全内参整理，这起事件的经过堪称离奇。

攻击者声称，仅用7分钟就完成了对东日本第1区域全部数据的加密。涉及的数据量令人瞠目：239台虚拟化宿主机、225个数据存储区、至少1.66万块虚拟机磁盘无法使用，被加密的主存储数据达3.6PB，被摧毁的554153份快照，造成的备份容量损失高达41.5PB。

而之后的7个小时，IDC Frontier的运维团队始终没有发现异常。攻击者早在凌晨3点就已在225个数据存储区的根目录中留下了勒索信，文件名为RECOVER-INFO.txt。但运维人员没有找到任何一封，反而不断通过VMware vCenter尝试重启那些已经无法运行的虚拟机，并一遍遍修改管理控制台密码。

客户比运维更早发现问题。日本时间早上8点34分之前，第75号工单就已经报告”虚拟机无法启动”。攻击者显然被这种处置能力”整破防”了，最终直接篡改了云管理控制台，用黑底红字主页面对外宣告：”IDCF CLOUD INFRASTRUCTURE SEIZED（IDCF云基础设施已被我们接管）”，副标题是”YOUR CLOUD IS OURS（你们的云，现在归我们了）”。

攻击者甚至贴心地给出了排查指引：任选一台JE0集群ESXi宿主机，打开SSH或DCUI shell，执行命令查看RECOVER-INFO.txt。言下之意——我们留了225份通知，你们居然一份都没看到。

二、技术拆解：这不是攻防战，是应急响应失能

抛开戏剧性，这起事件有几个技术点值得同行反复咀嚼。

第一，加密速度与破坏规模严重不对等。7分钟加密3.6PB数据，说明攻击者在此之前已经完成了权限获取、横向移动、宿主机控制等前置动作，最后一波加密只是”按下按钮”。真正的入侵窗口远早于10月7日，只是到这天凌晨才引爆。这再次印证了一个残酷事实：勒索软件只是”最后一公里”，前面的潜伏期可能长达数周甚至数月。

第二，备份被同时摧毁。攻击者不仅加密了主存储，还销毁了55万份快照、抹除了41.5PB备份。这在勒索攻击中是最致命的一环——没有离线、不可变备份，受害者就彻底失去了议价能力。IDC Frontier在10月8日的公告中承认，受影响区域存储的客户数据预计难以提取或恢复，只能让客户依靠自己的独立备份在别处重建业务。翻译过来就是：服务商这边的数据，救不回来了。

第三，应急响应的”失明”。反复重启已死掉的虚拟机、反复重置控制台密码，这些操作说明运维团队从未建立起有效的告警—研判—拉群通报链路。勒索信落在宿主机根目录，7小时无人发现，本质是资产清点不清、日志监测缺位、应急SOP形同虚设三重问题的叠加。

三、影响评估：495家客户的”数据孤儿”困境

据IDC Frontier官方公告，此次故障影响东日本第1区域的tesla、henry、pascal、joule四个可用区，当时一对一通知的受影响客户达495家，其中包含企业及地方政府机构。

对云服务客户而言，这起事件暴露了”上云即安全”的认知误区。当你把业务托付给云服务商，你实际上是把数据的可用性、完整性、机密性都托付了出去。一旦服务商遭遇”灭顶式”攻击，客户几乎没有自救空间——除非你自己在异地、离线保留了独立备份。

值得注意的是，IDC Frontier没有支付赎金，而是选择持续对外发布事故进展公告、同步调查情况。这个处置方向是对的，但代价是客户数据的实际损失已经发生。

四、应对措施：运维和安全团队今天就能做的几件事

从这起事件里，我们可以提取出几条可落地的建议。

一是把备份从”在线”变成”离线+不可变”。3-2-1备份原则（3份数据、2种介质、1份异地）是老生常谈，但真正做到”物理隔离、不可篡改”的团队并不多。建议对核心数据实施WORM（一次写入多次读取）存储或直接离线冷备，让攻击者即使拿到宿主机权限也无法一键删除。

二是虚拟化平台的加固必须单独立项。VMware vCenter、ESXi宿主机是勒索攻击的高价值目标。要限制vCenter的外网暴露，启用强认证，对宿主机SSH/DCUI访问做源头管控和白名单，并监测异常的批量磁盘加密行为。

三是建立”不可忽视”的告警通道。攻击者这次是靠篡改控制台才让运维”看见”，说明常规告警完全失效。建议对关键存储根目录、宿主机文件变动、批量虚拟机异常宕机等设置高优先级告警，并直接推送到值班人员手机。

四是定期做无预告的勒索应急演练。这次事故最扎心的地方在于——真出事时，团队连”我们被勒索了”都判断不出来。只有反复演练，才能在真实的7小时里做出正确动作，而不是当7小时的”重启仙人”。

总结

一场7分钟的攻击，和一场7小时的失明。IDCF Cloud事件最值得我们记住的，不是黑客有多嚣张，而是那句被公开写在人家控制台上的”YOUR CLOUD IS OURS”。云平台的安全，从来不取决于你买了多少安全设备，而取决于当攻击者真正进来时，你的团队能不能在第一时间”看见”、能不能在数据被抹除前”保住备份”、能不能在混乱中”止损”。这三件事，任何一件掉链子，7小时后就只能对着屏幕发愣。别等勒索信堆满225个目录，才发现自己一直在重启一场早就结束的战争。