文件名后面多出 .sorry，目录里出现勒索信，数据库起不来——这种情况下最先该做的不是找解密工具，而是把损失停在现在这台机器、这个时间点上。下面按实际处置顺序说。
前一小时：先隔离，别破坏现场
1）把受影响主机从网络上摘下来。 服务器拔网线、禁用交换机端口，云主机用安全组做进出双向阻断。不要只是关闭防火墙服务或退出远程会话，也不要指望杀毒软件自己拦住。这类攻击常带内网横向：通过扫描内网 SSH 端口、试弱口令去感染下一台，所以隔离的对象不只是这一台，还包括同网段、共用凭据的其它主机和 NAS。
2）确认加密是否仍在进行。 如果发现文件还在一批批变名，需要在"保留证据"和"少加密一个文件"之间做取舍：能确认加密进程仍在运行、且数据价值高于取证需求，就优先终止进程或断电；如果加密已经结束、系统还在运行，反而不急着关机，内存里的信息和运行中的进程对后续定位入口有用。关于断网之后文件仍在被加密的具体判断，可以参考断网了文件还在被加密该怎么紧急停下来。
3）不要在原盘上做破坏性操作。 不格式化、不重装、不在受害盘上反复安装和运行各种"恢复大师""解密工具"，也不要把新数据写进去。真要尝试恢复，先对磁盘做整盘镜像，所有尝试都在副本上做。原始介质上的残留块，往往是最后的机会。
4）不要按勒索信的指引走。 国家计算机病毒应急处理中心等机构在相关预警中明确提醒：不要下载运行勒索信里提供的所谓"加密通信工具"或客户端，那可能带来二次植入、扩大失陷范围。同样要警惕"100% 全能解密""一键破解全盘"的承诺。
后缀只是线索，不能靠它确定家族
.sorry 这个后缀本身并不唯一对应某一个病毒家族，历史上不少 Windows 勒索家族的变种也会换用各种后缀。判断要靠一组信息合在一起看：
- 勒索信的文件名和正文格式（是否包含受害者 ID、联系邮箱、TOR 地址）；
- 被加密文件的完整命名规则（是纯追加后缀，还是插入了 ID 或邮箱段）；
- 一两个小体积加密样本的文件头特征；
- 系统类型和暴露面：Linux 公网 Web 服务器，还是内网 Windows 终端/文件服务器；
- 最早被加密的时间点和当时的登录记录。
这些材料保存好，对后续判断可恢复性比任何工具扫描都有价值。如果你希望先把家族和可解性判断清楚再决定投入，可以走勒索病毒家族识别与可恢复性判断这条路径，而不是先动数据。
关于 2026 年这波 Sorry 家族的公开信息
从已公开的预警和分析看，这一波针对性较强的 Sorry 勒索攻击有几个共同特征，可以帮你对照自查：
- 入口集中在暴露公网的 Linux 服务器，尤其是 cPanel 一类 Web 运维面板的授权绕过漏洞（如 CVE-2026-41940）和弱口令，攻击者可以静默拿到 root，不需要谁去点开附件；
- 执行阶段刻意伪装，恶意进程用
sshd之类常见名字混在进程列表里； - 加密前先"拆防线"：终止数据库服务、安全防护和备份服务，删除或破坏本地备份，同时把业务数据和凭据先窃走；
- 加密实现完整：对称算法（AES/ChaCha20）加密文件内容，再用攻击者内置的 RSA-2048 公钥保护会话密钥。在没有攻击者私钥的情况下，靠算力直接破解在数学上不成立，目前也没有公开有效的免费解密器。
所以要说清楚一句话：面对这类实现没有缺陷的加密，现实中的出路主要在"恢复"，不在"破解"。任何声称能对所有变种解密的说法，都值得你要求对方先解释依据。我们不支付赎金，也不代为与攻击者谈判。
没有备份，也先把这些副本盘一遍
很多人一听"备份被删了"就直接放弃，但可用数据往往散落在备份系统之外：
- 快照类：虚拟化平台（ESXi/Hyper-V）的虚机快照、云盘快照、NAS 的快照与历史版本、SAN 层的时间点副本。注意快照是否因为空间回收被覆盖，越早确认越好。
- 数据库的日志与碎片：MySQL 的 binlog、PostgreSQL 的 WAL、SQL Server 的事务日志与
.bak、Oracle 归档日志；即使数据文件被加密，日志或表空间碎片有时仍能支撑相当程度的重建。 - 未被加密的残留：不少家族为了提速会跳过超大文件或只加密文件头部，也可能因为磁盘满、进程被杀而中途停止；回收站、临时目录、同步盘的历史版本、导出报表、邮件附件、下游系统里的冗余数据，都可能拼回一部分业务。
- 人工副本：财务、业务人员电脑上的账套导出、月结备份、U 盘拷贝，往往比 IT 想象中多。
盘点时保持只读，先镜像再操作。数据库底层提取、表空间碎片重组这类动作对环境和顺序很敏感，不适合在唯一原件上试错，需要时再走备份与数据库层面的恢复评估。
同时要处理的两件事：凭据和入口
凭据。 攻击者在加密前通常已经拿到了 SSH 私钥、面板口令、数据库账号、浏览器里保存的密码。清掉恶意程序不等于把访问权收回来。需要从一台确认干净的设备上重置相关口令、吊销并轮换 SSH 密钥、检查是否新增了系统账户、authorized_keys 条目、计划任务和自启动项。如果同时发现财务或办公电脑存在远控迹象、账号异常登录、转账被篡改，那是另一类问题，主机处置、账号会话和资金风险要分开看，处置思路在银狐与远控木马的处理说明里；涉及异常转账，第一时间通过银行正规渠道和公安机关报案处理，并保留完整的事件材料。
入口。 如果面板漏洞没补、弱口令没改、公网管理端口还开着，重装系统并恢复数据之后被再加密一次是很常见的结局。恢复顺序上，先确定入口和清理范围，再决定业务什么时候上线。
什么情况下别自己硬扛
下面几种情况，继续自行尝试的风险大于收益：多台服务器同时被加密、加密仍在扩散；虚拟化平台的存储卷或数据存储被加密；核心数据库没有可用备份，需要做底层提取；原盘已经被多次写入、做过重装或修复尝试。
这类场景的合理顺序是先做只读取证与镜像，再评估各条恢复路径的可行性，最后才谈具体实施，评估与交付的顺序可以参考恢复评估与处置流程说明。如果现在事态还在扩大、影响多人多机，勒索事件应急处置入口提供 7×24 小时响应；提交事件信息时按页面要求提供样本与日志，不要把数据库、客户资料或生产口令贴到公开评论或任意上传站点。
最后提醒一句：能不能恢复、恢复到什么程度，取决于你现在这几个小时怎么对待那块盘。停止写入、保留样本、别做不可逆的操作——这三件事做对了，后面所有路径才还留着。
评论(0)