某医院 HIS 系统 Oracle 数据库被 Phobos 加密的处置

客户为一家二级医院，HIS、LIS 与电子病历共用一套 Oracle 实例，运行在院内机房的物理服务器上。为便于外部厂商远程维护，运维人员在防火墙上长期开放了一个远程桌面端口，账号由医院与两家系统集成商共用。

事件在周五夜间发生。值班人员次日早晨发现门诊挂号系统无法连接数据库，检查后确认数据文件、控制文件与部分归档日志被追加了含联系邮箱的长后缀，服务器桌面与多个目录出现文本形式的勒索信。院内另有一台用于报表的数据同步服务器同时受影响。

医院最近一次完整备份是四天前写入本地备份盘的冷备份，备份盘在事件中处于挂载状态，部分备份文件被加密；但归档日志所在的独立磁盘因路径未被加密程序遍历而基本完好。

门诊在周六上午改为手工挂号收费，压力集中在窗口与药房，医院要求当日内至少恢复门诊与收费能力。

考虑到医疗业务的时效性，处置按「先让门诊跑起来、再补齐历史数据」的顺序推进。

• 止损与取证：隔离受影响服务器与同步服务器，保留内存与磁盘镜像，采集防火墙、远程桌面登录与 Oracle 告警日志。
• 家族与行为确认：依据后缀结构与勒索信格式确认为 Phobos 家族的某一变种；经比对该变种不在 2025 年 7 月公布的官方解密工具覆盖范围内，解密路径不可行。实测发现该版本对大文件采用固定区段加密，对 DBF 文件的破坏集中在文件头部与前段。
• 优先级排序：与医院信息科确认恢复顺序为门诊挂号与收费、药房与库存、住院与病历、科研与统计。
• 恢复实施：以未受影响的归档日志为核心，结合四天前的冷备份中未被加密的部分文件，在隔离环境重建实例并做介质恢复；对备份缺失的表空间，采用文件级修复从加密数据文件中提取未被改写的数据块补齐。
• 并行验证：由信息科与门诊窗口人员按真实业务流程逐模块抽样验证，确认后再切换至生产。