凌晨4点半系统瘫痪，遭LockBit勒索却一分钱没付：这所大学是如何恢复业务的？
安全牛 2026-10-27 11:57 北京
承认安全控制可能失效，不是否定防护工作的价值。相反，正是通过对真实攻击的持续复盘，组织才能更清楚自己的安全边界，提高应对未知威胁的能力。安全建设的目标，不只是避免攻击发生，更要在攻击发生后控制影响、恢复业务，并从中获得持续改进的能力。
点击蓝字 关注我们
引言：噩梦般的凌晨来电
对于企业安全负责人来说，勒索软件攻击可能是最可怕的噩梦。系统突然瘫痪，核心数据被加密，攻击者还威胁要公开敏感信息——这时候该怎么办？是乖乖付赎金，还是硬扛到底？
2026年9月，美国圣路易斯健康科学与药学大学（UHSP）的首席信息安全官Zach Lewis接受采访，详细讲述了他们在2023年遭遇LockBit勒索软件攻击的完整经过。
最终，这所大学没有支付一分钱赎金，完全靠自己的力量恢复了业务。这不是一个"完美防御"的故事，而是关于当防御失效后，如何控制损失、恢复运营的真实案例。
一、事情是怎么发生的
1. 最开始只是以为系统故障
2023年某天凌晨4点半，Lewis接到电话：学校的本地服务器出问题了，系统访问不了。
他先在家里试着远程连接，没成功。赶紧开车去办公室，路上还联系了团队成员。当时大家都以为只是普通的IT故障，没想到是被攻击了。
到了现场，团队开始排查问题，折腾了大约两天，终于把系统恢复了。大家都松了口气，以为事情解决了。
但其实，攻击者早就潜伏在系统里了，只是还没发动最后一击。
2. 几小时后，真正的灾难降临
系统恢复运行没几个小时，又崩了。
这次技术人员发现情况不对——很多文件打不开了。然后他们看到了一个README文件，里面是攻击者留下的勒索信。
到这时候才确认：学校遭遇了勒索软件攻击，攻击者是LockBit勒索组织。
Lewis说，看到那封勒索信的瞬间，压力巨大。这不只是技术问题，整个学校的运营都受到了影响。
3. 迅速启动危机响应
确认遭到攻击后，Lewis马上叫来了网络主管和首席运营官一起商量对策。
他们优先做了几件事：
联系网络安全保险公司
联系FBI等执法机构
组织跨部门协同应对
这时候，事情已经不只是安全团队的事了。法律、保险、业务、对外沟通都得跟上。仅靠技术团队单打独斗，根本应付不过来。
二、提前准备救了大忙
1. 幸好之前做过演练
Lewis特别提到一个关键细节：在攻击发生前几个月，学校管理层做过一次勒索软件桌面演练。
这次演练让校长、董事会这些高层提前了解了勒索攻击可能造成的影响，也知道了应对措施大概是什么样的。
所以当真的出事了，管理层没有一脸懵。他们很快就理解了事态严重性，也愿意支持安全团队的决策。
如果没有这次演练，Lewis可能要花大量时间向管理层解释"什么是勒索软件""为什么这么严重"，那样响应效率会大打折扣。
2. 让技术团队专心干活
Lewis还做了一个很聪明的决定：他自己去应付管理层和董事会的各种会议和提问，让技术团队专心恢复系统。
同时，他要求团队成员轮换休息，不能连轴转导致过度疲劳。
这听起来像是简单的人员管理，其实对恢复效率影响很大。勒索攻击往往要处理好几天，如果关键技术人员不断被打断去开会、汇报，工作效率肯定会受影响。
Lewis承担了对外沟通的压力，为技术团队创造了相对稳定的工作环境。
三、不付赎金，靠什么恢复业务？
1. 和攻击者沟通，但不是为了付钱
确认攻击后，学校开始和攻击者联系。
但这不是为了准备付赎金，而是想核实攻击者到底窃取了多少数据，以及争取时间进行自救。
在沟通的同时，技术团队在做什么呢？
采购新设备
调取离线备份
逐步恢复关键系统
验证恢复后的环境是否安全
这里的关键是：学校有离线备份，并且备份是可用的。
随着核心系统一个个恢复，学校发现自己已经能够维持基本运营了。于是决定：不付赎金。
备份的意义不只是保留数据，更是给了你拒绝支付赎金的底气。
2. 攻击者改变策略：从加密勒索到泄露威胁
当攻击者发现学校已经能靠备份恢复业务，原来的勒索方式不管用了。
于是他们换了招：威胁公开窃取的数据。
这就是典型的"双重勒索"——不仅加密你的系统，还偷走你的数据威胁要公开。即使系统恢复了，数据泄露的风险还在。
3. 声称偷了200GB，实际只公开了2GB
这里有个重要细节。
攻击者声称从学校偷走了200GB数据，但最后实际公开的只有大约2GB。
在数据被公开之前，学校只能根据攻击者展示的少量文件名来判断风险，并不掌握全貌。这时候就是考验判断力的时候了。
校方对自己的判断有信心，坚持不付赎金。
攻击者最后把数据公开了。学校仔细检查了这些文件，发现只有4个人的信息涉及敏感内容，Lewis亲自给这4个人打电话说明情况。
系统恢复了，不代表事情结束了。数据风险评估和后续处置同样重要。
四、攻击之后的安全改造
1. 加快向云和SaaS迁移
其实在攻击发生之前，学校就已经在推动应用向云平台和SaaS模式迁移了。攻击发生后，这个方向进一步加速。
到2026年受访时，Lewis说学校绝大部分应用都已经是SaaS模式，重要数据不再主要保存在本地系统中。
这降低了对传统本地基础设施的依赖，但也意味着安全管理的重点变了——身份认证、访问权限、云服务配置这些变得更重要。
2. 引入企业浏览器，统一管理访问
学校还部署了Island企业浏览器。
为什么要这么做？因为随着应用迁移到SaaS，用户的日常工作越来越依赖浏览器。与其分别管理员工的各种设备、各种访问行为，不如通过统一的浏览器入口来集中管理安全策略。
Lewis说，这样可以更集中地控制员工身份、访问权限和能访问的内容。
不过需要说明，企业浏览器不是万能的，它只是整体安全体系的一部分，不能替代终端安全、身份管理等其他必要防护。
3. 搞清楚数据在哪里
Lewis还强调了一个重点：弄清楚组织到底有哪些数据，这些数据存在哪里。
这和勒索经历直接相关。当攻击者威胁公开数据时，如果你连自己有什么数据都不清楚，怎么判断影响范围？怎么评估风险？
所以数据资产管理不只是合规要求，也是应对勒索攻击的实际需要。
五、值得学习的经验
根据这个案例，结合美国CISA和NIST的建议，可以总结出几条实用经验：
1. 别把所有故障都当成普通IT问题
UHSP第一次发现系统不可用时，没认出是攻击。修好后攻击者还在，最后才发动真正的加密。
启示：关键服务器访问不了、多个服务同时中断、修好后又坏了——这些异常别只想着恢复可用性，也要考虑是不是安全事件。
特别是恢复原因不明确时，要检查登录日志、管理操作记录、异常访问行为。
2. 备份要真能用
有备份不等于能恢复。
勒索软件可能攻击在线备份，也可能用偷来的管理员密码删除备份。
所以备份建设要注意：
离线保存，和生产环境隔离
定期验证是否真能恢复
明确关键系统的恢复优先级
搞清楚RTO（恢复时间目标）和RPO（恢复点目标）
衡量备份能力的标准不是"备份任务完成了没"，而是"真出事了能不能恢复"。
3. 让管理层参与演练
Lewis和高层的信任不是临时建立的，而是之前的演练打下了基础。
勒索软件演练不能只是安全团队和IT人员的事，董事会、管理层、法务、业务负责人都应该参与。
演练可以模拟：系统不可用、备份失败、数据泄露威胁、对外通知、资源调配等场景。
演练的目标不是完成一套文件，而是让组织在真正危机时能够协同决策。
4. 事先安排好沟通机制
出事后，管理层要了解损失、业务部门关心恢复时间、员工想知道什么时候能正常工作、技术团队需要专心处理问题。
如果所有人都直接找技术人员问，响应效率会很低。
应该事先明确：
谁负责指挥
谁负责技术处置
谁负责对外沟通
决策如何升级
如何协调外部资源
还要安排轮换休息，别让人连续工作导致疲劳影响判断。
5. 别只想着加密，还要考虑数据泄露
现代勒索软件攻击是"双重勒索"：既加密系统，又窃取数据威胁公开。
应急预案不能只考虑恢复系统，还要覆盖数据泄露风险：
核心数据在哪里
数据有哪些类别
谁有访问权限
敏感程度如何
真发生数据泄露时，要根据日志、取证结果等可信证据分析影响，不能只听攻击者怎么说。
涉及个人信息的，还要按法律要求决定是否通知相关人员。
重点：付赎金不能保证数据不被泄露，必须为数据风险准备独立的处置流程。
6. 重点管好身份和访问权限
UHSP事后继续推进SaaS迁移，并用企业浏览器强化访问控制，体现了安全思路的变化。
以前的安全管理主要围绕设备和本地网络。现在远程办公、个人设备、SaaS应用普及，用户可能用不同终端访问分布在多个平台的数据。
这种情况下，身份认证、权限控制、数据访问策略变得更重要。
可以考虑：统一身份认证、多因素认证、最小权限原则、会话访问控制、日志审计、数据访问保护等措施。
注意：云服务同样有风险——账号被盗、权限配置错误、数据误共享等。
迁移到云不是目的，目的是更清楚地掌握身份、应用、数据之间的访问关系。
7. 持续测试，开放交流
Lewis强调：没有组织能做到百分之百安全。
所以要持续测试环境，关注新技术和威胁情报，根据实际风险调整防护。
他还呼吁安全行业更开放地讨论真实事件，包括哪些防御失效了、组织有什么弱点、事后做了哪些改进。
现实中，大家更愿意展示成功阻止攻击的案例，很少公开讨论为什么没能阻止攻击。
但对整个行业来说，真实事件暴露的问题，往往比理想条件下的演示更有参考价值。
六、三个值得思考的问题
回顾这次事件，有三个问题值得安全负责人思考：
第一，当部分安全控制失效后，你还能维持核心业务吗？
不能只关注能不能拦住攻击。当攻击者已经进来并造成破坏时，你有没有可用的备份？清不清楚关键业务依赖什么？能不能建立可信的恢复环境？
第二，你能把技术判断转化为组织行动吗？
Lewis能快速获得管理层支持，和他之前建立的信任、开展的演练密切相关。
出事时，管理层需要理解的不只是技术术语，还有业务影响、风险边界、需要什么资源。安全团队只有和管理层形成有效协同，才能推动应急响应。
第三，事件结束后，你真的改变了原有的风险管理方式吗？
UHSP没把系统恢复当成终点。他们继续落实云化战略，引入新的访问管理手段，加强数据资产管理。
有价值的复盘不只回答"攻击怎么发生的"，还要回答"下次面对类似攻击，我们应该具备哪些不同的能力"。
结语：重要的是恢复能力和改进能力
UHSP的经历说明，重大勒索软件事件不只是技术对抗。当系统瘫痪、勒索信出现、敏感信息可能被公开时，组织面对的是技术、业务、管理、信任多方面的复杂挑战。
在这次事件中：
离线备份帮助恢复关键业务
提前演练和沟通为决策提供了支持
明确分工让技术人员能专心工作
后续的数据核查和架构调整体现了对长期风险的重视
更重要的是，Lewis选择公开分享这段经历。
承认安全控制可能失效，不是否定防护工作的价值。相反，正是通过对真实攻击的持续复盘，组织才能更清楚自己的安全边界，提高应对未知威胁的能力。
安全建设的目标，不只是避免攻击发生，更要在攻击发生后控制影响、恢复业务，并从中获得持续改进的能力。
这可能才是这次勒索软件实战经历，留给安全负责人最值得重视的启示。
相关阅读
联系我们
合作电话：18610811242
合作微信：aqniu001
联系邮箱：bd@aqniu.com
本文转载自微信公众号「安全牛」，查看原文。版权归原作者所有，如有侵权请联系删除。